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

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.

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.

1 Like

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.

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.

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.

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

Not sure what the second example is.

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.

Thank you for checking this. Should be manageable.

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.

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.

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.

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.

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

Sounds like something worth avoiding.

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 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 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.

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:

[ 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,, 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 ]





[5] Reddit,; Telegram,; WeChat,; Weibo,; Discord,; Gitter,

[6] Twitter,; YouTube,;

[7] GitHub,


[9] See:,,,,,,,

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

[11] Consensys,; QuantStamp, November 2018,; SigmaPrime, December 2018,; Nick Johnson, February 2019,; SigmaPrime, May 2019,; Callisto Network, September, 2019,; Bug bounty,

1 Like

Please note that Michal Herzyk is also proposing a more comprehensive analysis of trading and market data for proposed whitelist tokens. The [Market and Trading Data] section will likely be expanded to accommodate Michal’s suggestions at a later time.

1 Like

Following BIP-3’s approval, the following updates have been implemented by the core dev team:

1 Like