This document covers:
- The creation and publication of new proposals.
- Submitting proposals to a vote on Snapshot.
Obligations to the Bancor DAO
Anyone can create a new proposal for consideration by the Bancor DAO; there is no requirement to hold BNT or vBNT. The guidelines for proposal creation are obligatory, and were written into DAO law with the passing of BIP3 on 24 October 2020. These guidelines have since been updated to reflect the DAO decision making process on Snapshot, and were accepted with the passing of the BIP12 addendum on 26 March 2021.
Creating a New Proposal
Whitelisting Proposals
There is a generic template available for whitelisting proposals. Please refer to the Bancor Network documentation for technical and security prerequisites for token whitelisting. The proposal can be created alone; however, it is recommended that authors reach out to experienced DAO members for advice during the drafting stages. Before committing a large amount of effort, consider testing community sentiment on the Bancor Discord, with a view to determining organic interest in supporting your proposal. This is a good way to find collaborators and build awareness prior to the vote.
There are some special considerations to be mindful of when embarking on a whitelisting adventure. First and foremost, be aware of the highly challenging quorum requirements (35%). It is advisable to reach out to known influencers and/or whales during the preparation of the proposal to find support. This is not a symbolic gesture; try to start an actual conversation, rather than pleading for votes. Major BNT stakeholders want the protocol to succeed, and are likely to respond to the same arguments that any other DAO member would. Increasing TVL, attracting new users, growing trade volume and making Bancor more visible in new demographics are highly motivating. Instead of just promising these things, gather data to support your proposal. If the TKN being whitelisted has a community that is desperately seeking protection on Bancor, show it.
The last major consideration is whether or not the pool applying for whitelist status already exists. The pool cannot be activated until it is bootstrapped with an equivalent of 10,000 BNT in TKN as a minimum.
Liquidity Mining Proposals
A generic template for liquidity mining proposals has also been created to assist authors. As with whitelisting, you are welcome to prepare the LM proposal alone; however, it is highly recommended that you collaborate with other members of the community during the drafting stages. The Bancor Discord is the perfect place to find another like-minded community member with whom the details of, and justification for the liquidity mining proposal can be devised.
Bancor Improvement Proposals (BIPs)
There is no generic template for an improvement proposal. Some BIPs are complex, and require thorough documentation for economic analysis, game theory, edge cases and exploits, contract feasibility, and so on. The Bancor v3 proposal is one such example. Improvement proposals that impact the core functioning of the system, or which require new contracts, or modifications to the existing contracts, should not be created and published in a vacuum. The community developers should be consulted early, and frequently throughout the concept development phase, drafting of the proposal and/or any coding work being done for the BIP. Feedback from multiple community members throughout the process is expected, and may include consultation with expert advisors, analysts, and auditors. Such proposals are a highly collaborative, community-driven effort.
Other BIPs that have less profound consequences on the behavior of the network, such as changes to community rules or minor tweaks to the protocol parameters, have a lessened rigor with regards to community involvement during preparation of the proposal (however, collaboration is always highly encouraged). As a general rule of thumb, it is a bad idea to propose changes to the protocol without talking to another DAO member about it first, and starting a discussion about it on Discord or Telegram.
Publishing Your Proposal
Bancor Governance Forum (Discourse)
After the proposal is created, it must be published on the Bancor Discourse page (the default governance forum). Posting and commenting on Discourse requires a user account. As a spam and phishing prevention measure, new user accounts are unable to include >2 hyperlinks in proposals. Higher privileges are earned by participating in forum discussions, which removes spam restrictions after a predetermined trust threshold has been met. Alternatively, you can reach out to the forum administrators directly, who can activate these privileges for you, if only temporarily to allow the proposal to be published.
Publishing a new proposal can be done via the âNew Topicâ button in the top-right corner of the page.
In the window that appears, create a helpful, informative title for your proposal, and choose an appropriate category:
- The Community_Chatroom (DISCUSSION) category is an ideas incubator. If you are looking to engage with other DAO members, prior to drafting an official proposal, use this category.
- The LEVEL_1 (DRAFTING) category is for publication-ready proposals. If you are following one of the available templates for whitelisting or liquidity mining rewards, LEVEL_1 is an appropriate category.
- The LEVEL_2 (FINAL VERSIONS) category is for polished proposals only. This category is restricted access; in general, a community member with a high trust rating will move proposals from LEVEL_1 to LEVEL_2 when the drafting process is completed.
- After a proposal has been submitted to Snapshot, and the voting period has concluded, the proposal will be moved from LEVEL_2 to the DAO_Archive (SUBMITTED) category.
Discourse uses markdown syntax. As you create the proposal by entering text into the box on the left, a preview appears to the right. If you have prepared the proposal using the Google docs templates provided above, the markdown formatting is preserved when copy/pasting; however, the occasional bug means that reviewing the preview screen before publishing is still necessary. After you have completed the document, click the âCreate Topicâ button.
Bancor Community Server (Discord)
While not a requirement, it is highly recommended that the proposal be copied into the Bancor community Discord server. Ask the administrators to create a dedicated channel for you, then either paste the link to your post on Discourse, or paste the content in sections to recreate the entire proposal.
Responding to Community Feedback
As the author of the proposal, you are required to at least acknowledge and respond to questions and comments that appear following the publication of the proposal. You are under no obligation to incorporate proposed changes; it is your document, and no one can force you to change it. Be advised that stubbornness to adapt to community feedback is a poor tactic, and may hurt the chances of the proposal being accepted by the DAO. However, that doesnât mean that all suggestions are good, or worth incorporating; it is acceptable to post rebuttals to proposed changes.
The manner in which you respond to community feedback is a critical element to maintaining a positive culture. Donât let yourself be goaded into an internet argument. Stay polite and respectful, and alert the moderators of any unacceptable behavior in the comments section.
Mandatory Community Review Time
Before the proposal can be moved to Snapshot for voting, the proposal must be available for review by the community for at least 4 days. Therefore, the proposal should include a planned time and date for the vote to begin, and cannot be sooner than 4 days from the time of its publication. This is mandated by DAO policy, introduced by BIP3 and later on updated in
Proposal: Update mandatory community review time requirements on proposals from a minimum of 2 days to 4 days:
BIP documentation must be available with sufficient time for consideration by a reasonable and intelligent person. Time sufficiency is commensurate with the complexity of proposal. Minor adjustments to the protocol parameters, required for maintaining the health of the system, are prioritized over time for community deliberation. Similarly, urgent matters requiring immediate action can expedite the sufficient time requirement. Any other proposal that is not of imminent importance to the continuity of the project is not exempted. Low-to-moderate levels of complexity must allow 4 days for community engagement before voting commences; moderate-to-high levels of complexity must allow 4-6 days for community engagement before voting commences.
Initiating a DAO Decision on Snapshot
Anyone can create and publish proposals; however, only vBNT holders can initiate a DAO decision. A minimum of 25,000 vBNT staked in the governance contract is required to create the proposal on Snapshot. With the necessary stake, you can initiate the voting process essentially unassisted. If you do not have sufficient vBNT staked, you will either need to increase your stake, or find a collaborator to help you with this leg of the process.
Initiating a vote on Snapshot is done directly on the external Snapshot website; the âVoteâ button on the voting tab of the Bancor App redirects to the correct location.
On the Snapshot website, in the top-right corner is a prompt to connect your wallet. To be able to create the proposal, the wallet that is connected must be the one that controls the vBNT staked in the governance contracts. Click the âConnect walletâ button and follow the familiar prompts.
After completing these steps, the âConnect walletâ text is replaced with a redacted version of the chosen wallet address. After the wallet has been connected, the âNew proposalâ button appears, which navigates to a new proposal drafting window.
There are three major sections to complete before the decision is put to a vote, and there are stringent guidelines that must be observed for this leg of the process.
The Proposal Body
The proposal body has two separate fields of text that should be populated verbatim from the finalized proposal, as it appears on Discourse. Snapshot uses the same markdown syntax as the governance forum, so transferring the information should be trivial in most cases. To transfer images, you can use standard markdown image handling, using the image URLs from the discourse page. A link to the original proposal on Discourse should be prominently displayed at the top of the Snapshot document. Similar to Discourse, a preview is provided for review.
Every reasonable effort should be taken to ensure the Snapshot document is as close as possible to the original; however, the copy on Discourse is still regarded as the authoritative version. This is important because Snapshot has a fixed character limit. Some proposals will simply be too long to recreate, in which case a simplified document can still be created on Snapshot, and readers can be referred to the original proposal via the provided link.
Choices
Snapshot offers a new flexibility with regards to the number and types of voting options available. However, DAO policy has largely been constructed around the voting format on our Ethereum governance contract, which has two options, FOR and AGAINST. Therefore, this format will continue to be observed on Snapshot.
In the âChoicesâ fields, type âFORâ into position 1, and âAGAINSTâ into position 2.
In the future, the DAO can explore other voting formats involving multiple options. This is currently not the case, and strict adherence to the FOR/AGAINST format is mandatory until the DAO creates a policy to handle these new capabilities.
Actions
This is the most important step; failing to observe the guidelines presented here, which were passed into law by the DAO following the approval of the BIP12 addendum, will result in disqualification of the submission by a community moderator.
Voting Period
It is preferable to be creating the Snapshot object immediately prior to the planned commencement of voting; the planned voting period should appear on the published version of the proposal, and be prominently displayed on its Discourse page.
The âSelect start dateâ option under the available actions will open a calendar, set to your local time zone. In general, proposals will stipulate voting periods in UTC; therefore, the submitter may need to convert the voting periods into their local time before proceeding. After selecting the correct date, the time must also be set using 24 hour format. The process is repeated to choose an end date, 3 days into the future compared to the starting date and time. Then, the only remaining item is choosing the snapshot block.
Snapshot Block
The bottom field under the available actions is for nominating a snapshot block. This is the precise block that Snapshot will use to read the governance contract, count the staked vBNT associated with each signed vote, and calculate quorum. The rules for selecting a snapshot block are detailed in the BIP12 addendum.
Snapshot will automatically assign the snapshot block to the most recently mined block on Ethereum, at the time of the submission. If timed well, this can be appropriate, and easy. For example, if the proposal on Discourse has been available for community feedback for at least 4 days, and the vote is being initiated no earlier than the published date and time, then the automatic snapshot block assignment is a perfect choice. This is the preferred process, and under normal circumstances, there is no reason the snapshot block should be altered.
Best Practice:
The DAO has approved a range of block choices, to accommodate potential vote scheduling issues. It is possible to schedule votes on Snapshot for a future date, and choose a block number that is expected to fall within the voting period. There are approximately 7,200 blocks mined per day. Therefore, estimating a future block to coincide with a scheduled voting period is trivial, albeit a little imprecise. It is also possible to choose a snapshot block in the past, under the condition that the chosen block does not predate the nominated voting time and date, as it appeared on the published proposal. The DAO has approved an acceptable margin for error for this type of vote execution. Assuming the published proposal has adhered to the guidelines, then any block occurring between the original nominated date, and up to 2 days following the conclusion of the voting period is technically accepted. These guidelines are strictly for determining the legitimacy of a DAO decision on Snapshot; DAO members should consider the âBest Practiceâ, outlined above, as the standard procedure.
Technically Acceptable (example):
Submission for DAO Decision
If the above guidelines are followed carefully, then submitting the proposal for a DAO decision can be initiated with the âPublishâ button.
