Proposal: Update Whitelisting Requirements

[tfns]

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.

@VictimBurner

Transparency (the following 2 out of 3 requirements would get removed)

• 1. 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).
• 2. The project should have a publicly visible test suite with decent test coverage.

1. Most tokens are ERC-20 OpenZeppelin standard. Because those contracts have already been audited, very rarely is an audit available for a token contract.
2. 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.

@VictimBurner

Administrative Risk (this entire section would get removed!)

Special administrative privileges over the protocol - such as minting privileges - should be restricted:

1. They should not be owned by EOA.
2. They can be governed by multisigs.
3. 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.

Notice that 2 and 3 are not really requirements, but 1 is.

1. 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.
2. Not a requirement, this is often the case.
3. Not a requirement, this is often the case.

@VictimBurner

Technical (the following 4 out of 8 requirements would get removed)

1. 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.
2. Minting of new tokens should be restricted and conform to the whitepaper and the security audit.
3. Token transfers shouldn’t be pausable or subjected to a whitelist unless a reasonable explanation is provided.
4. 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.)

Now that BNT minting is paused, most of these requirements no longer pose any risk to the protocol.

1. 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.
2. 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.
3. Token transfers being paused might brick the pool but does not pose risk to the protocol with the BNT minting mechanism paused.
4. 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.

@VictimBurner

Economic Requirements (1. would only get modified, 2. removed)

1. 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.
2. Deprecated tokens cannot be whitelisted if already deprecated at the time of the proposal

1. 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.
2. 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:

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

@VictimBurner

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

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

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:

Current whitelisting requirements:

Proposal	Supermajority	Quorum
Whitelisting <1M BNT trading liquidity	66.7%	35%
Trading liquidity increase to <1M BNT	66.7%	35%
Whitelisting >1M BNT trading liquidity	66.7%	35%
Trading liquidity increase to >1M BNT	66.7%	40%

Proposed whitelisting requirements:

Proposal	Supermajority	Quorum
Whitelisting <1M BNT trading liquidity	66.7%	35%
Trading liquidity increase to <1M BNT	66.7%	35%
Whitelisting >1M BNT trading liquidity	66.7%	40%
Trading liquidity increase to >1M BNT	66.7%	40%

Quorum and Supermajority requirements (as per BIP20: Quorum and Supermajority Requirements)

type	quorum	supermajority
whitelisting proposals	35%	66.70%
trading liquidity limit < 1M BNT	35%	66.70%
trading liquidity limit > 1M BNT	40%	66.70%
BNT emissions for TKN	35%	80%
BNT emissions for BNT	35%	66.70%
pool fees	20%	66.70%
governance and protocol	35%	66.70%

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.

@VictimBurner

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

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.