This proposal is expected to appear on Snapshot for voting on TBD. Make sure to stake your vBNT for voting before this date and time to participate in the DAO decision.
To pass, this proposal needs 35% Quorum and 66.7% FOR votes.
TL;DR
Whitelisting requirements are meant to prevent tokens that pose too much protocol risk from being added to the system.
These requirements resulted in about 50% of tokens from interested projects not being able to be whitelisted.
BNT is still part of 50% of the value in the pools, and therefore the protocol can incur a maximum protocol loss of 50% of the pool TVL. However, BNT is not currently minted for liquidity protection and therefore the whitelisting requirements should be revisited and updated where possible.
Rebasing tokens or tokens with elastic supply aren’t currently supported.
Tokens that apply transfer fees aren’t currently supported.
The token must not have any transfer hooks (notifications on sender/recipient etc.) as those open the possibility for re-entrancy issues.
Economic Requirements
The token must be fairly distributed - it can’t be concentrated in a few addresses. More than 20% of the addresses must control 80% of the tokens, i.e, if a token has 100 holders, at least 21 holders can hold 80% or less of the supply. If not, the token can only be whitelisted with external protection provided 1:1 to the proposed trading liquidity. Note: Liquidity pools, treasuries, team multisigs, and vested token contracts will not count towards the token supply count.
Quorum and Supermajority requirements
Minimum quorum and supermajority requirements for a whitelisting proposal to pass must be the larger of the:
a. Whitelisting requirements, currently at 35% quorum and 66.7% supermajority.
b. Quorum and supermajority for a trading liquidity limit increase proposal to the specified trading liquidity in the whitelisting proposal.
Voting instructions
To support the proposed whitelisting requirements detailed herein, vote FOR
To oppose the proposed whitelisting requirements detailed herein, vote AGAINST
The current requirements are designed to keep shady projects away from the protocol. This proposal would enable unaudited, EOA owned projects without any mining/burning restrictions and with pausable transfers to get whitelisted. Such projects can pose a risk for the protocol and therefore all BNT holders. If any of those projects ends up being a rugpull or having a critical vulnerability,it would cause a further decline in trust in the Bancor brand and would also increase the total deficit. I get that we are desperate for more fees, butreally is not worth it for the tiny increase in fees we can expect from such centralized TKNs.
As this proposal is very instrusive I would like you to explain in detail for every requirment why you want to remove it.
With this proposal we would vote to remove the following requirements:
Transparency (the following 2 out of 3 requirements would get removed)
The token contract should have an audit from a known security auditor or explain why it wasn’t audited (for example, if it’s a standard token from the OpenZeppelin library).
The project should have a publicly visible test suite with decent test coverage.
Administrative Risk (this entire section would get removed!)
Special administrative privileges over the protocol - such as minting privileges - should be restricted:
They should not be owned by EOA.
They can be governed by multisigs.
They can enforce timelock or similar restrictions.
Protocols that don’t comply with this should provide an explanation why (the DAO reserves the right to decide whether to accept the explanation or not).
The above may not contradict with the technical requirements - e.g. an upgradable token can not be whitelisted regardless of the reasoning.
Technical (the following 4 out of 8 requirements would get removed)
Only the token holders themselves should be able to transfer or burn their tokens. It shouldn’t be possible for any other account (including owners/admins) to transfer or burn tokens belonging to other users, without their explicit permission.
Minting of new tokens should be restricted and conform to the whitepaper and the security audit.
Token transfers shouldn’t be pausable or subjected to a whitelist unless a reasonable explanation is provided.
There should not be any restrictions on transferring or trading (e.g., restricting how many blocks you have to hold a token before you can transfer it, fees/taxes on transfers, including to/from trading pools, etc.)
Economic Requirements (1. would only get modified, 2. removed)
The token should be fairly distributed (e.g., it can’t be concentrated in a few addresses). If not, the token can only be whitelisted if they provide external liquidity protection equal to the proposed trading liquidity.
Deprecated tokens cannot be whitelisted if already deprecated at the time of the proposal
Also, I don’t see the following in the current whitelisting requirements, so for transparency it would be good to know how do they differ from the current Quorum and Supermajoyrity requirements:
Quorum and Supermajority requirements
Minimum quorum and supermajority requirements for a whitelisting proposal to pass must be the larger of the:
a. Whitelisting requirements, currently at 35% quorum and 66.7% supermajority.
b. Quorum and supermajority for a trading liquidity limit increase proposal to the specified trading liquidity in the whitelisting proposal.
@glenn Also, I am wondering why this proposal got moved to Level 1 so quickly, without any discussion happening, while other less intrusive proposals usually take weeks to months until they get moved here? I strongly suggest to not bring this to vote until we have given the DAO enough time to discuss this, a few weeks should be given at minimum.
Looking forward to your reply @tfns (and other contributors and community members).
The previous requirements kept about 50% of projects that were interested from being able to join the network from participating (mostly because they had admin rights that conflicted with the rules).
I don’t agree. The previous requirements were meant to protect the protocol - not determine shady vs non shady.
Can you outline the risks you see?
For example, let’s say TKN has an admin that cause pause transfers of TKN. They can freeze a pool, but if they are not actually removing or causing a print of BNT - should we allow this TKN to join? That seems to be a risk for TKN holders but not the protocol itself (pls correct me if I’m missing something).
Given that ILP is off - many of the risks that were previously VERY scary are no longer relevant but some others remain.
Letting the DAO vote on those individual 50% of projects would be much safer than just dropping all requirements for any project. This also indicates that ILP will never be re-enabled. If ILP in some form will ever be returning, changing WL requirements entirely needs much more review and forethought
First of all, thank you for checking the previous requirements and providing feedback.
I’ll provide answers to the changes and explain further how I arrived at this list of new requirements. Understandably, these can be changed after discussion and are not set in stone.
Most tokens are ERC-20 OpenZeppelin standard. Because those contracts have already been audited, very rarely is an audit available for a token contract.
The test suite is not a requirement that is often checked as well, and I don’t think it means that a project should not be considered.
Furthermore, the requirement for the token contract to be verified on Etherscan means that it can be checked and a small audit/risk analysis is always part of the whitelisting process - and since this isn’t obviously state, perhaps this information should be included in the requirements.
Notice that 2 and 3 are not really requirements, but 1 is.
Notice the “should not” means it isn’t a strongly imposed requirement. As far as being owned by an EOA, some projects choose to do this especially in the initial phases of a token launch. The risk of private keys being controlled is higher vs using a multisig as well as token manipulation risk. I don’t feel strongly against including this requirement, but the language must be changed here to enforce it, and perhaps allow exceptions for tokens that provide external protection.
Not a requirement, this is often the case.
Not a requirement, this is often the case.
Now that BNT minting is paused, most of these requirements no longer pose any risk to the protocol.
I believe it is mostly up to the users whether to hold tokens that can be transferred or burnt on their behalf. This requirement doesn’t protect the protocol necessarily.
This is a hard to verify requirement. Even if the whitepaper specifies restrictions on the minting of new tokens, unless these are enforced in the token’s smart contract, there is no way to ensure they are met. Don’t feel strongly against it, but if a new requirement specifies that a restriction must exist at the smart contract level, there will be multiple tokens that won’t be whitelistable.
Token transfers being paused might brick the pool but does not pose risk to the protocol with the BNT minting mechanism paused.
The proposed technical requirement #3 covers transfer fees. As far as restricting blocks to hold a token or restrictions on trading, there is no risk for the protocol to allow these to happen. Technical requirement #3 can be modified to cover trading restrictions as well as transfer fees. Some stablecoins implement whitelists to conform to regulations and would not be eligible for whitelisting based on this requirement.
This requirement is now updated to more clearly explain what “fairly distributed” means. The metric chosen here is a suggestion and personal opinion - up to change.
Why would a project pursue a whitelisting of a deprecated token? Perhaps it should be up to the BancorDAO to decide whether or not to whitelist a deprecated token. I don’t mind adding this requirement back if you feel strongly against.
I’d like to rephrase the current Economic Requirement #1 to:
The token must be fairly distributed - it can’t be concentrated in a few addresses. The token cannot have more than 80% of its supply held by 20% or less of the addresses., i.e, if a token has 100 holders, at least 21 holders can hold 80% or less of the supply. If not, the token can only be whitelisted with external protection provided 1:1 to the proposed trading liquidity. Note: Liquidity pools, treasuries, team multisigs, and vested token contracts will not count towards the token supply count.
This change means that whitelisting proposals that request higher trading liquidity limits will require similar quorum and supermajority requirements to the ones for trading liquidity increase requests. To illustrate:
Since the quorum and supermajority requirements are prone to change, this section clarifies that trading liquidity increases and whitelisting proposals should have similar quorum and supermajority requirements.
A point can be made that a change to the quorum and supermajority requirements to illustrate this instead of adding it to the whitelisting requirements makes more sense. If you think so, I can remove this section and propose a change to the quorum and whitelisting requirements.
I usually put them on level 1 for discussion, as the proposal is in a finished state and therefore “Under Review”. Notice however that the date at which the proposal can go up on Snapshot is set to TBD, to allow much needed discussion and feedback as the one you’ve presented. FIY, anyone can move a proposal to Level 1, this is not a Discourse admin right.
Finally, notice the change in the language of the current requirements, mentioned throughout this reply. Most previous requirements used words like “should”, “can” that are not enforceable and are somewhat vague such as the “fairly distributed” mention in the Economic Requirements. The proposed whitelisting requirements use a more enforceable language and I believe this makes them clearer to new projects.
Sorry for not replying earlier, I am very busy these days and I can’t answer in detail atm. But I wanted to say thank you for providing this detailed answers and explaining your reasoning. While (at first glance) I don’t necessarily agree with every point you make it should help everyone to to decide why those changes might be needed (or not).