Pocket Network Proposal Preparation Guide

Any member of the Pocket Network community can create and submit a proposal to the DAO. Just follow the easy steps below.

  • Part I: Idea/Hypothesis

  • Part II: Groundwork

  • Part III: Pre-Proposal

  • Part IV: Proposal Launch and Voting


There are three types of proposals:

  • Pocket Ecosystem Proposals (PEPs) involve contributions to the Pocket Network ecosystem. Generally they seek payment from the DAO Treasury for future or completed work.
  • Pocket Improvement Proposals (PIPs) are those designed to improve the Pocket Network ecosystem, including through upgrades to the Pocket Network protocol, or to the governance of the DAO or Pocket Network Foundation.
  • Parameter Update Proposals (PUPs) include any proposals to modify the value of the Pocket Network protocol parameters.

(For more detail see the Pocket Network documentation.)



Your idea is your starting point. What problem or need does it address and how? Your idea may evolve as you develop your proposal.

DAO funds are limited. Why does your idea deserve funding? In other words, how real, big and urgent is the problem or need it addresses? Is your idea the best way to address these?

Is your proposal practicable? The best proposals balance importance and ease of implementation.


Don’t be afraid to begin with an undeveloped idea.

While the DAO will not vote on an idea, if it’s a good idea, its members will help shape it into something implementable. For example, technical help is available, including from GRIP, if you lack technical expertise.


Know the general sentiment of the community.

Untested ideas should be posted to Community Suggestions at Pocket’s Dework interface where the community can upvote to indicate support. (Under the related IDEAS program, if your idea finds favor, you’re likely to earn a POKT reward :slight_smile: ) (Dework is a Web3 platform for community engagement.)

There may be posts on your topic, e.g., in the Forum, on Pocket’s Discord server, or on Telegram in The Poktopus Den. So do your homework and see what people have already said. Then, get feedback from as wide a group as possible. GRIP and the Pre-Proposal category in the Forum are good resources for this. Reach out to knowledgeable people who might be familiar with or interested in the subject matter of your idea or proposal. Get talented people excited about your idea; they may offer to help you execute.

Don’t be afraid to share your ideas. And don’t wait: share them early.


If your proposal hinges on a hypothesis, test, research and gather evidence to justify it. If you make claims, back them up. The reader should not be expected to take your word. Note the sources of information and the tools that you use to justify your hypothesis.

If your proposal is for a project, make it clear that it’s open source.



Look for collaborators - as co-authors or silent partners, especially if execution of your idea is too much for a single person. See if people with demonstrated expertise in your proposal area want to pitch in. If you’re weak in an area, seek help from community members with complementary strengths. Collaborators can help flesh out ideas and provide missing context. Having credible co-authors may lend your proposal more weight with voters. Above all, assemble the team that’s best suited to execute your proposal.


What’s the value add? How will Pocket Network benefit? Will everyone benefit or just node runners with large fleets, or other parties? Quantify the benefits. When will the benefits accrue or materialise?

If your project is monetizable, do you plan to share some upside with the DAO?


Get the price tag right.

The DAO will pay appropriately for the value provided. But it isn’t here for you to get rich; DAO voters will push back against greed. If you are seeking reimbursement for work already done, have a detailed record of the time spent and what you did, and set out the benefits, with proof, that flowed from your project (refer to “Who Benefits” above).

You can base your budget on time spent/to be spent and expenses (e.g., materials and resources) or a fixed number. The following factors may justify a premium:

  • novelty or originality of your idea
  • high degree of skill or experience for execution
  • significant utility as measured by the size of the benefit and/or the number of stakeholders who benefit

Do a rough cost-benefit analysis. Is the cost justified?

Determining your budget can be a challenge. Get input from others. If you’re uncomfortable about doing so publicly, ask community members if they’ll let you know their thoughts in private and/or reach out to GRIP. Shane has developed a formula for budgeting a tech project.

However you arrive at your budget, explain your reasoning. Don’t just post a number. This will avert pushback and help win support.

How long will it take to complete the project or is it an ongoing project?

If your project will roll out in stages or can be broken into phases, consider seeking staged payment or for milestones. Include assurances that you’ll keep the community updated as your project unfolds.



Using Google Doc or similar tool, create a document that’s divided into sections that correspond to those of the template you’ll be using for your proposal. In no particular order, start filling in the sections. Consider leaving the summary till the end as this is best completed once your ideas are fully elaborated. (More on these sections below.)

(Links to the templates for PEPs, PIPs and PUPs will be added shortly; the templates are currently being revised.)

Pay special attention to Dissenting Opinions as refuting anticipated or actual arguments against your proposal can be key to its adoption.

The template contains guidance on the information needed under each section.

The following principles should guide your writing:

  • Brevity
  • Clarity
  • Simplicity
  • Objectivity - avoid hype; let the facts and ideas speak for themselves
  • Honesty - acknowledge what you don’t know


These are key. “Most people,” says one source, “will read only the summary, some might read the conclusions, but only a few, very interested people will read the whole proposal - sad but true.”

Your summary is like an elevator pitch. It should convey the main elements of your proposal in a few sentences.

For a proposal with complex subject matter, add a “Background” section explaining the problem it addresses and any other information the lay reader may need to understand it. This section could include glossary-style explanations, the history of parts of the proposal, and reference to previous related proposals. For complex proposals, an optional “Implementation” section also may be helpful. See PIP-22: Stake-weighted Servicer Rewards.

You can add other custom sections where information you need to convey does not fit under the existing sections. For example, PEP-45 included a section called “Actionable Items” that listed the measures that would be triggered by approval of the proposal. The section was useful because it highlighted the measures that did not involve disbursement of DAO funds.

Consider embedding links to outside sources that can help the community understand your proposal.

For complex proposals, GRIP can create infographics to make concepts understandable and produce a lay-friendly version by reworking your Google Doc.


Give your proposal a name. Maybe pick a catchy acronym. But be careful, an acronym can grow a life of its own and obfuscate the true nature of your proposal.

While you might pick a name earlier in the process, wait till your proposal is done before finalising as your idea may have evolved. (e.g., “Get a GRIP” started as “PEG,” “Proposal Enhancement Group.”)

Need naming assistance? The Forum Pre-Proposal category can help.


Although many of its members are native English speakers based in the U.S., the Pocket community is worldwide. Proposals therefore must be understandable by a global audience. Therefore, we should standardise our date format, time references and measurements.

Use the ISO format: YYYY-MM-DD and indicate you’re doing so the first time that you mention any date in numerical form. As to times, use the time zone most relevant to your proposal and stick with it. For clarity, indicate that time zone whenever you note a time. The first time you reference a time, It’s recommended that you also note parenthetically the corresponding times in other zones familiar to the community - e.g. ET and PT. Where measurements are noted, use the metric system.

Proposal authors should bear in mind that acronyms familiar to a U.S. audience may be foreign to others.


It’s recommended that you post your first draft in the Pre-Proposal category of the Forum for more feedback.

A wider audience can catch flaws that may escape detection no matter how many times you and your co-authors review your proposal. Further, posting in the Pre-Proposal category allows you to incorporate (additional) feedback into your proposal before you launch it formally.

Changing your proposal after launch creates confusion. Unless voters follow the Forum proposal thread closely in the run-up to the vote, they may not know what they’re voting on.

If you post your draft proposal directly to the forum, you could be blindsided by new criticism. By allowing as much dissent as possible to emerge in the Pre-Proposal category, you’re better able to control the message and persuasively counter any dissent as part of your proposal.


Based on the comments your first draft attracts, develop your proposal in your Google Doc. Once it’s revised to take account of all feedback, you can share the Google Doc with GRIP for proofreading and a grammar check. (Upon request, GRIP will do a more thorough copy edit.)



When you’re ready to launch, give your PEP, PIP or PUP a number. In the Forum category where you’ll post your proposal, check what number was given to the last proposal in that series, and take the next one. Then, select “New Topic.” Overwrite the template with a copy of your proposal. Take a few minutes to ensure that the markup is correct - check heading sizes, hyperlinks, line spacing, etc. Post your proposal and “wait for the storm.”

Votes on any proposal generally must last seven days to be valid and unless otherwise specified in the Constitution require a simple majority of entered votes to pass. (Proposals to make certain changes to the Foundation require a supermajority and two weeks of voting.)


If you publish a proposal, make sure to engage in the thread and keep the conversation going. Respond to all questions promptly, politely and respectfully. Try and give extra information when requested. Don’t overreact to criticism; be humble. Anyone can post in the forum, so don’t take any one poster’s comment as representative of the DAO.

Get the community up to speed with what you are proposing. For example, you could introduce your proposal and take questions at a Town Hall; do a presentation at Node Runners’ Office Hours; and/or host an AMA or community event call. Consider using these tools not just after formally posting your proposal, but also before.

To rally support for your proposal it may help to watch for and participate in discussions on your proposal on Pocket’s Discord server and on Telegram in The Poktopus Den.

Once appropriate time has been allowed for debate, it’s time to put your proposal to a vote. You can do this yourself if you’re a voter. Otherwise, ask a voter or a Foundation member to do so for you. The vote occurs on Snapshot (an off-chain voting platform).

To start a vote on Snapshot, do the following steps:

Connect the wallet that contains your vote.

Click “New proposal.”

Paste the title of the proposal into the “Title” field and the Forum link into the “Discussion” field.

Select the voting terms. The standard is “Single choice voting” with Approve/Reject options. You must make sure that your vote lasts at least 7 days, by selecting an “End” time that is at least 7 days from “Now” (the default “Start” time).

Then click “Publish.”


If your proposal was rejected, don’t necessarily give up. Analyse why it failed and ask the community. For example, did the community not understand it? Did you meet the Dissent with weak counter-arguments? Was the budget too high?

In particular, if your proposal targets a real problem that needs addressing, revise and resubmit. Consider posting the revised version in the Pre-Proposal category of the Forum first for more feedback.

(PoktFund’s first proposal for DAO funding for its mobile wallet was rejected but a revised version was subsequently approved.)

Still have questions? Post them in the #proposal-support channel on the Pocket Discord server. Or you can ask GRIP. Follow this link to the Get a GRIP Discord server and contact us in the #public-lobby channel.

This guide was prepared by GRIP with generous assistance from Dermot, Ben, Jessica, and Jack.