BIP3 Governance Changes: BIP documentation requirements, and new majority and quorum rules

Information and Templates
1

Summary

This BIP proposes to make three changes to Bancor governance by i) requiring BIP documentation to meet a satisfactory standard of presentation and time for community engagement before commencing a vote, ii) increasing the majority rule from >50% to 66.7% and iii) increasing quorum requirements for whitelist BIPs from 20% to 40%.

i) BIP Documentation Requirements

Bancor Improvement Proposals (BIPs) must be presented in a manner suitable for review by the Bancor Community.

Suitable presentation includes but is not necessarily limited to: a well argued, concise, and coherent case for the BIP, appropriate references, and figures and diagrams where complex financial concepts or protocol features are central to the BIP. Additional guidelines apply specifically to whitelist BIPs and must be stringently adhered to. These include links to the project Github page and community discussion channels, contact information for the project spokesperson, all relevant security audits by trusted sources, a detailed discussion or explanation of the token utility or the project value proposition, up-to-date market and trading data including total market capitalization, trading volumes, and existing availability on other exchanges. Importantly, a single BIP may propose multiple changes if and only if the entirety of the BIP is thematically consistent, and the proposed improvements are addressing the same issue. BIPs containing multiple proposals for abjectly different purposes are invalidated, regardless of the voting outcome. However, stand-alone BIPs invalidated for containing two or more divergent improvement proposals may be reorganized into separate BIPs and resubmitted.

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 2-3 days for community engagement before voting commences; moderate-to-high levels of complexity must allow 3-5 days for community engagement before voting commences.

Full documentation must be provided by the proposer, and displayed on gov.bancor.network. The proposal must have a descriptive title that accurately reflects the content and/or expected outcome. The proposer is expected to answer all reasonable questions and respond appropriately to comments while the BIP is being reviewed. Direct contact information for the proposer, such as a Discord or Telegram handle, is preferred.

ii) Two Thirds Majority Rule

All governance decisions made by the BancorDAO will be contingent on a minimum two-thirds majority, defined as 66.7%.

iii) Quorum Requirements for Whitelisted Assets.

The current governance structure requires a 20% quorum for a legitimate vote. This proposal seeks to increase the quorum requirement for adding assets to the Bancor protocol whitelist to 40%; quorum requirements for BIPs not seeking to whitelist an asset will remain at 20% .

The motivation for increasing the quorum requirement for whitelisting assets is to reflect the gravity of the decision. Whitelisting an asset exposes the Bancor protocol to potential exploits. A 40% quorum, combined with a two-thirds majority rule, minimizes the potential for an individual, or group of individuals, to create selfish opportunity at the expense of the Community. This BIP asserts that whitelisting is the most vulnerable target for hacking the governance system, and the security provided by increased quorum is a sound response to that threat.

The caveat to increasing the quorum is that it is inherently less likely that the requirement will be met, making any whitelisting BIP especially challenging, including those for tokens that deserve to be whitelisted. However, this will also shift the responsibility to the proposer to make a strong case, and campaign for it via the available channels. This could create a greater government awareness, and culture of informed decision making by Community members. This BIP asserts that the increased challenge associated with higher quorum requirements for whitelist BIPs is risk-averse, and culture-positive in the long term.

ā€“end of proposalā€“

5 Likes
2

i think we should also clarify the ā€œtechnicalā€ side of these elements:

i) requiring BIP documentation to meet a satisfactory standard of presentation and time for community engagement before commencing a vote

  • the concept and idea is valid in my opinion and we should really require some ā€œidea vestingā€ before a vote is introduced. that said, there is not technical way to enforce this. which means, as a community, we need to understand that if a vote starts before the discussion meets this proposed requirement time and structure, it will not be implemented even if the vote passes.

ii) increasing the majority rule from >50% to 66.7%

  • again a valid point but this might be risky as more vBNT is added to the governance. this as well is not enforced in the contract level at this stage (there is no code to support this functionality) and will be enforced based on community understanding and agreement.

iii) increasing quorum requirements for whitelist BIPs from 20% to 40%.

  • this part has a simple function in the contract that controls the quorum and can be updated (once vote passes). meaning, this can be enforced later on in the contract level directly.
2 Likes
3

Thank you for the technical insight.

4

I donā€™t agree with this proposal at all. Iā€™ve been involved in several governance protocols and this is unnecessarily burdensome, so much so that it has the potentially to totally cripple governance. Nothing will get done or proposed.

A simple majority is more than enough to signal interest and sufficient support in favor or against something. 67% is far to restrictive, it is unlikely in key, votes to achieve such an overwhelming single-sided support.

The quorum is one that really is damaging for governance and the risk of making it unusable. Most protocols have reduced quorum to the current, industry-accepted norm of 20%. Making 40% turn out will be far to difficult and obtrusive, based on other protocols and history. A vote to reduce UNI quorum just the other day was overwhelmingly in favor, but barely missed the 40% quorum.

20% is the sweet spot, and with active governance such as Bancor themselves, this shouldnā€™t be an issue.

No change to governance.

1 Like
5

Thanks for the feedback. Happy to discuss these points with you further.

We already experienced such a situation. The vote to approve CAP for whitelisting seems like it could have been organized by a small group of people, who rallied a significant proportion of the voting power immediately prior to submitting the BIP. On the Telegram channel, it was clear that most of the community were not even aware that the BIP had been submitted to vote. This is concerning because (at that time) it had already reached 20% quorum and 99.8% in favor, which did not represent community sentiment at all. Many see this a near-miss, and wonder if it could have been a targeted attack. Luckily, the community mobilized some BNT holders to start new pools to get the vBNT required to vote the BIP down, but it was very close (45 vs 55%). Being that this is for a coin that no one was even remotely aware of, and for which zero information was posted on any of the Bancor discussion groups, the closeness of the race should give you pause. Achieving a two thirds majority will be easy for most issues; a 51% majority is too easy to hack.

Please note that under this proposal, the vast majority of governance will remain in the 20% quorum requirement. The 40% quorum proposal is suggested only for whitelisting new assets. Remember that whitelisting assets automatically approves them for insurance, and the protocol will mint up to 500,000 BNT as co-investment. This is a severe vulnerability, and a 20% quorum might be too easy to exploit. Remember that, unlike UNI, the Bancor system exposes all BNT holders to the risk of bad asset listings - not just the pool that holds it. For these reasons, we think a 40% quorum is justified.

2 Likes
6

You might be underestimating the Bancor Community. The Proposing Bancor v2.1: Single-Sided AMM Exposure with Elastic BNT Supply had a 48.62% participation, and the Whitelist CAP/BNT had 82.49% participation.

1 Like
7

The culture at UNI is not what it is at Bancor. If UNI participants cared about their project, the vampire attacks would not have been so successful. If you give vBNT holders a chance, I think they will surprise you.

8

The initial vote was made when few vBNT were ported over because many were not aware or inexperienced of governance. More have ported over, it wasnā€™t really a real vote and once more joined governance was voted against. 55% is more than enough.

The second example is a bad one, many people saw it was 99% approval and abstained from voting, which is why participation was lower.

Governance is working as intended. I donā€™t support changing it, and will be voting any proposal like this one. If some strange CAP type proposal did happen to slip through, which is unlikely, another one could be proposed to supersede it.

9

How do you feel about the suggested requirements for BIP proposals?

10

Not sure what the second example is.

11

contract wise, it is not supported to have 2 different quorums.
which means it will also be managed based on agreement and not code restrictions.

12

Thank you for checking this. Should be manageable.

13

I fully agree with the first point raised. It is important to hold the proposals to a certain standard, even if itā€™s subjective, etc. I agree with all references and such as well, but as long as the proposals arenā€™t word swamped. These type of proposals tend to go overboard with the ā€œlegalā€ speak, which can massively sway people away from reading the whole thing. I think for every proposal, a summary must be included at the end, as many members of the community will be looking for the TL;DR. I know I do anyway.

Re 2nd point, a compromise of maybe 60% coudl be reached. 66.7% is ALOT, as many people providing to the pool will just want to ā€œset and forgetā€ and not actually be involved in active governance. Iā€™m not saying you are, but donā€™t use yourself as the measure for others interest in voting.

I donā€™t agree with the 40% quorum though. You canā€™t underestimate voter apathy; I think 20% is the sweet spot here and agree with @BlueZoom.

1 Like
14

Itā€™s a valid point for both sides of the issue. For clarity - 40% quorum is only being proposed for whitelisting an asset; this BIP does not affect quorum for any other governance choice. To your point - addressing voter apathy is something that should be considered. Many DAOs are simply symbolic, serving as a shield from regulators. I have a higher expectation for BancorDAO. If a 40% quorum is really as big a hurdle as some think it is, then there is a systemic problem in the governance culture that will need some additional work. This leads into some other discussions that are already well under way, such as incentivizing votes, minimizing gas, and allowing for vote delegation. I would rather have a high quorum for critical decisions and mechanisms in place to support that, than accept a lower standard of community governance.

15

Itā€™s a good point. This counts as good composition, and you are right to demand it. I put the summary at the top, but I will add a TL;DR in the future.

16

From a coding perspective, I am imagining* that the BIP has a bunch of parameters attached to it. Can there be a second, separate BIP object with its own set of values? The idea being that the contract could have a dedicated set of rules for whitelisting assets, such as vBNT requirements to launch, quorum rules, etc.

ā€˜*ā€™ I am not familiar with smart contract code yet, but I am going to do something about that.

17

The UniSwapā€™s proposal was a almost one-sided attempt of Dharma (private company with roots in Silicon Valley) to reward itā€™s users with retrospective UNI airdrop. Dharma has ~30M UNI delegated to them, lowering the quorum from 40% to 30% as ā€˜theyā€™ proposed would grant them almost sovereign control over UniSwap.

1 Like
18

Sounds like something worth avoiding.

19

For the sake of anyone not on discord, I want to share some additional discussion points from there.

Leonard Today at 4:17 AM

Hey guys, i went thought the proposal however personally speaking i feel undecided. On the one hand, such a proposal right from the beginning feels necessary in order to set the parameters correct. But on the other hand the proposed changes are relatively harsh and I would rather wish more incremental changes in those figures. Tbh the platform just launched and a lot of people are not familiar with the mechanism which can be seen on the numbers of active participation in the gov protocol. Thus changing the fundamentals basics right now feels wrong. Iā€™m happy to hear your feedback

mbr Today at 4:03 PM

Iā€™m happy to hear your feedback

@Leonard You are right to observe that the new requirements set a high bar. BIP3 is an anti-scam BIP; it was drafted in response to what could have been a deliberate attempt to pass a risky low-cap and obscure cryptocurrency into the protocol whitelist, namely BIP2. The discord channel, and the gov.bancor.network discussion board had zero discussion on it, and somehow still went to vote and achieved suspiciously high levels of support in a very short time. BIP3 is designed to protect the protocol from this type of exploit with immediacy. I refer to the points raised by @Avi, in the future we can roll back some of these changes when the governance is sufficiently robust. For now, we need additional protection.

mjc716 Today at 4:43 AM

maybe late to this, but why are these three initiatives grouped together into one vote? these seem like discrete issues to me

mbr Today at 4:12 PM

maybe late to this, but why are these three initiatives grouped together into one vote? these seem like discrete issues to me

@mjc716 I can see how it would seem that way. If you look at it as an anti-scam bill, I think you might see how the three dovetail together. The structure is bottom-up. The first part of BIP3 states that the proposal itself must be composed in a such a way that it is almost impossible to deceive the community . The second and third parts are to make it impossible for whales to become de facto owners of the BancorDAO . As Azshken has pointed out on the gov.bancor.network discussion board, UniSwap very recently almost lost sovereign control to a single company. It is important that we realize that, if this ever happens, it can never be undone.

20

Note: This document was prepared after BIP3 was passed by governance. BIP3 introduced a standard for the quality of presentation and contents of any proposal to whitelist future tokens in the protocol. Below, a hypothetical proposal is made to whitelist Chainlink (ticker: LINK). LINK is already whitelisted; therefore, this mock-BIP has no other purpose than to serve as a template for future whitelisting proposals.

BIP_X: Proposal to whitelist Chainlink

Contract address: 0x514910771af9ca656af840dff83e8264ecf986ca

Project Website: https://chain.link/

[ Discussion ]

An ā€˜oracleā€™ is a component of an abstract machine in complexity and computability theory, that assists in decision problems [1]. Oracles can be used to provide data to smart contracts that originates from outside the immutable ledger, of which the blockchain would otherwise have no knowledge. Oracle data feeds have a deterministic impact on smart contract outcomes. Therefore, there is an innate security risk that a contract could be compromised by inaccurate data. In this sense, the oracle assisting in the decision becomes a type of trusted custodian. If a corrupt entity was in control of the oracle, then they are also in control of the connected smart contract. This is an unacceptable concession for blockchain security.

The Chainlink project provides technology for trustless oracles. Chainlink is a distributed oracle network, rather than a single trusted entity. As with any distributed system, Chainlink is nearly impossible to compromise, as the adversary must control the majority of the network to influence its behavior. Therefore, Chainlink offers a compelling solution to trustless smart contract execution, where the contract is dependent on data from outside its own blockchain. Due to the general nature of oracles, and the already well-established and rapidly growing use of smart contracts, Chainlink serves a clear purpose now and in the future. The Chainlink blog features a detailed list with 44 examples of how the technology can be used with smart contracts [2].

[ Tokenomics ]

Chainlinkā€™s native token, LINK (ERC20), is required to access, and participate in the oracle network. Node operators stake LINK with the network, for the purpose of reputation metrics and to disincentivize bad behaviour. LINK is also the native currency of the network; contract holders must pay LINK to node operators for maintaining an oracle and providing data. Therefore, the LINK token is a utility token, and not merely a symbolic representation of the project. Gemini, a reputable centralized exchange, has a helpful blog entry that discusses LINK token use, in addition to a general introduction to the Chainlink project [3].

[ Community and Communication ]

Chainlink is highly engaged with its community. The Chainlink Ecosystem [4] website provides an unofficially-curated selection of the latest news and information about partnerships, collaborations and integrations with the Chainlink network. The Chainlink Community Factsheets section contains high-quality documents detailing Chainlink scope of utility and important project milestones, in 10 different languages. This is a terrific place to begin further reading. The community, who identify themselves as ā€œLink Marinesā€ are active on Reddit, Telegram, WeChat, Weibo, Discord, and Gitter [5]. The Chainlink team also opperates official Twitter and YouTube accounts [6]. Activity on GitHub is frequent, with new updates appearing every 2-3 days [7]. The development team and advisors are presented on the team tab on the Chainlink website [8]. Sergey Nazarov, the co-founder and CEO of Chainlinkā€™s parent company, SmartContract.com, is the projectā€™s main spokesperson [9]. The Chainlink website includes a mailing address in Grand Cayman, and four contact e-mails [10]. There are no phone numbers provided.

[ Available Audits ]

Chainlink has been audited at least five times since 2018, by reputable auditors, including QuantStamp and SigmaPrime [11]. Chainlink also has an open bug bounty program.

[ Market and Trading Data ]

Chainlinkā€™s price at the time of writing is $12.26. Itā€™s all-time high was $19.83 (16th August 2020), and its all-time low was $0.148 (29th November, 2017). There are 389,509,556 tokens in circulation, of a 1,000,000,000 maximum supply. The current market capitalization is $4,785,618,839. The LINK token is available on major exchanges, including Binance, Digifinex, Kraken, Huobi Global, and Coinbase Pro. The 24-hour spot volumes range from $6,770,124 (Kraken) to $88,127,005 (Binance).

[ References ]

[1] https://en.wikipedia.org/wiki/Oracle_machine

[2] https://blog.chain.link/44-ways-to-enhance-your-smart-contract-with-chainlink/

[3] https://gemini.com/learn/what-is-chainlink-and-how-does-it-work

[4] https://chainlinkecosystem.com/

[5] Reddit, https://www.reddit.com/r/Chainlink/; Telegram, https://t.me/chainlinkofficial; WeChat, https://blog.chain.link/chainlink-chinese-communities/; Weibo, https://weibo.com/chainlinkofficial; Discord, https://discord.gg/gyG7Td; Gitter, https://gitter.im/smartcontractkit-chainlink/Lobby.

[6] Twitter, https://twitter.com/chainlink; YouTube, https://www.youtube.com/c/ChainlinkOfficial;

[7] GitHub, https://github.com/smartcontractkit/chainlink

[8] https://chain.link/team/

[9] See: https://www.youtube.com/watch?v=Mx8-VBijyXA, https://www.youtube.com/watch?v=ulyI_K-TFDI, https://www.youtube.com/watch?v=OTaSvj9Fc60, https://www.youtube.com/watch?v=wn5f3yN3lr0, https://www.youtube.com/watch?v=LIEQcEO1nZA, https://www.youtube.com/watch?v=VT0enNGV78s, https://www.youtube.com/watch?v=q-SzVFyddqE, https://www.youtube.com/watch?v=AUwV2WivcA4

[10] Mailing, Strathvale House, 90 North Church Street, George Town, KY1-1102, Grand Cayman, Cayman Islands; Security email, [email protected]; Technical support email, [email protected]; Custom projects email, [email protected]; Press email, [email protected]

[11] Consensys, https://consensys.github.io/blockchainSecurityDB/projects/chainlink/; QuantStamp, November 2018, https://github.com/smartcontractkit/audits/blob/master/reports/Quantstamp%20-%20Chainlink%20Audit%20Report.pdf; SigmaPrime, December 2018, https://github.com/sigp/public-audits/blob/master/chainlink-1/review.pdf; Nick Johnson, February 2019, https://github.com/smartcontractkit/audits/blob/master/reports/Nick%20Johnson%20-%20Chainlink%20Audit%20Report.pdf; SigmaPrime, May 2019, https://github.com/sigp/public-audits/blob/master/chainlink-2/review.pdf; Callisto Network, September, 2019, https://callisto.network/blog/post/chainlink-link-security-audit-report/; Bug bounty, https://hackerone.com/chainlink

1 Like