LogoLogo
  • About Bancor Network
    • Bancor V3
    • Bancor Basics
      • About Bancor
      • What Can I Do With Bancor?
      • Liquidity Pools
      • Single-Side Liquidity
      • Why Use Bancor?
      • Resources
    • Resources for DAOs
      • Token Whitelisting Requirements
      • Liquidity Mining
        • Auto Compounding Rewards
          • How Auto Compounding Rewards work
          • How to Create an Auto Compounding Rewards Program
          • Custom Rewards Programs
        • Dual Liquidity Mining
        • Standard (External) Rewards
    • Security & Audits
      • Multisig Rights
      • Oracles
      • DAO MSIG Intervention Policy
  • Contracts & Functions
    • Contracts
    • Write Functions
      • Transaction Prerequisites
        • approve() / allowance()
      • Trading
        • tradeBySourceAmount()
        • tradeByTargetAmount()
        • Trading Troubleshooting
      • Adding Liquidity
        • deposit()
        • depositFor()
        • Deposit Troubleshooting
        • depositAndJoin()
      • Removing Liquidity
        • Initiating Cooldown
          • initWithdrawal()
        • withdraw()
        • cancelWithdrawal()
        • Withdraw Troubleshooting
      • Flashloan
        • flashLoan()
        • Flashloan Troubleshooting
      • Migrating Liquidity to v3
        • Migrating Bancor positions to v3
          • migratePositions()
          • migratePoolTokens()
          • Errors and Troubleshooting
        • Migrating from Uniswap v2
          • migrateUniswapV2Position()
        • Migrating from Sushiswap
          • migrateSushiSwapV1Position()
      • Rewards
        • join()
        • stakeRewards()
        • autoProcessRewards()
        • claimRewards()
        • leave()
      • Surplus migration
        • withdrawPOL()
      • Network Fees
        • burnNetworkFees()
    • Read Functions
      • Rewards
        • Standard rewards
          • Identify if a program exists
            • Auto Compounding
            • Standard Rewards
          • programIds()
          • programs()
          • providerProgramIds()
          • pendingRewards()
          • latestProgramId()
          • isProgramActive()
          • isProgramEnabled()
          • providerStake()
          • programStake()
          • providerRewards()
        • Auto compounding rewards
          • bnToken balance
          • isProgramActive()
          • isProgramPaused()
          • pools()
          • program()
          • programs()
      • Liquidity Pool Details
        • liquidityPools()
        • isPoolValid()
        • isPoolStable()
        • tradingLiquidity()
        • depositingEnabled()
        • poolFundingLimit()
      • Trades
        • tradeOutputBySourceAmount()
        • tradeInputByTargetAmount()
        • tradingEnabled()
        • tradingFeePMM()
      • Withdrawals
        • isReadyForWithdrawal()
        • withdrawalRequest()
        • withdrawalAmounts()
        • withdrawalRequestIds()
        • withdrawalRequestCount()
        • lockDuration()
      • Pool Token Information
        • poolToken()
        • collectionByPool()
        • poolTokenToUnderlying()
        • underlyingToPoolToken()
      • Vortex
        • pendingNetworkFeeAmount()
        • minNetworkFeeBurn()
      • Surplus whitelist
        • protectedTokenWhitelist()
    • Data & Events
      • General Data
        • contextId
      • Trading Data
        • event TokensTraded()
      • Liquidity Data
        • TotalLiquidityUpdated()
        • TradingLiquidityUpdated()
        • TokensDeposited()
        • TokensWithdrawn()
        • WithdrawalInitiated()
        • WithdrawalCancelled()
        • WithdrawalCompleted()
        • LockDurationUpdated()
        • Cross AMM Migration Data
          • UniswapV2PositionMigrated()
          • SushiswapV1PositionMigrated()
      • Flashloan Data
        • FlashLoanCompleted()
        • FlashLoanFeePPMUpdated()
      • Rewards
        • Staking and Unstaking
          • Event ProviderJoined()
          • Event ProviderLeft()
        • Claiming and Restaking Rewards
          • Event RewardsClaimed()
          • Event RewardsStaked()
  • Developer Guides
    • Bancor Vortex Burner
    • Bancor Etherscan Guide
      • Etherscan Basics
      • Deposit
      • Deposit and Join
      • Rewards: Joining Standard Rewards
      • Rewards: Stake & Claim
      • Rewards: Leaving the Rewards Contract
      • Withdrawing Tokens
        • Initiating the Withdrawal
        • Completing the Withdrawal
      • Migrating V2.1 Positions
      • Rewards: Auto Compounding Rewards Distribution
    • REST API
      • API Reference
      • DLT Identifier
Powered by GitBook
On this page
  • Transparency
  • Administrative Risk
  • Technical
  • Economic Requirements
  1. About Bancor Network
  2. Resources for DAOs

Token Whitelisting Requirements

PreviousResources for DAOsNextLiquidity Mining

Last updated 2 years ago

Requirements:

Transparency

  1. The token contract needs to be verified on Etherscan.

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

  3. The project should have a publicly visible test suite with decent test coverage.

Administrative Risk

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.

Technical

  1. The token contract should not be upgradable.

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

  3. Minting of new tokens should be restricted and conform to the whitepaper and the security audit.

  4. Rebasing tokens or tokens with elastic supply aren’t currently supported.

  5. Tokens that apply transfer fees aren’t currently supported.

  6. Token transfers shouldn’t be pausable or subjected to a whitelist unless a reasonable explanation is provided.

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

  8. The token should not have any transfer hooks (notifications on sender/recipient etc.) as those open the possibility for re-entrancy issues

Economic Requirements

  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

See the most up to date technical requirements for whitelisting.