The V2.1 Difference
How Bancor's V2 Update Takes AMMs to the Next Level‌

A New Kind of AMM

When Bancor introduced the first Automated Market Maker (AMM) on Ethereum in 2017, the notion of an on-chain, order-book-less exchange was novel and experimental. Bancor v1 was designed to solve the liquidity problem where sparse order books struggled to guarantee liquidity to investors on both sides of a trade. Just a few years later, Bancor has inspired a new form of automated asset exchange which generates billions of dollars in cryptocurrency trading volume per day.‌
But the success of legacy AMMs has exposed key downsides of the initial model, affecting both traders and liquidity providers (LPs):‌
  • Involuntary Token Exposure
  • Impermanent Loss
With the interests of both traders and LPs in mind, Bancor v2.1 offers solutions to these problems.‌
Contrary to other AMMs, Bancor uses its protocol token, BNT, as the counterpart asset in every pool. Using an elastic BNT supply, the v2.1 protocol is able to provide liquidity in its pools to support single-sided token deposits and to cover the cost of impermanent loss incurred by depositors using swap fees earned from protocol-provisioned liquidity.

Single-Sided Exposure

Most first generation AMMs require LPs to contribute two tokens (e.g., LINK and ETH) representing the component parts of the liquidity pool. This is both an inconvenience and a liability for many LPs who may hold only one of the assets and/or are only interested in exposure to that single asset.
Bancor v2.1 breaks this paradigm, allowing LPs to contribute and maintain 100% exposure in a single token (e.g., LINK). As an LP, the user remains 100% exposed to the price of the token they deposited, while accruing yield from fees (paid in the token staked) and, when active, liquidity mining rewards (which can be paid in just BNT in Bancor v2.1, but in Bancor 3, can also be paid in non-BNT tokens).
LPs can provide liquidity to Bancor either entirely in their preferred asset or entirely in BNT.

Impermanent Loss Insurance

Impermanent loss is a well-known side-effect of AMMs that are subject to arbitrage opportunities. When two assets are paired in a constant-product AMM (for example, with a 50:50 ratio), the product of the cardinal values of each asset reserve in the AMM is kept constant. So reserve(TKN) * reserve(BNT) = Constant. This means that price variations lead to liquidating the asset that rises in value into the asset that drops in value.
Swap fees may offset impermanent loss; however in many cases impermanent loss can exceed swap fees earned by an LP, leading to negative returns realized by a liquidity provider upon withdrawing their tokens from the pool.
Bancor v2.1 is designed so that a liquidity provider always gets back the same value originally deposited (plus trading fees and rewards) through a novel concept called Impermanent Loss Insurance.
Impermanent Loss Insurance accrues over time, by 1% each day, until 100% protection is achieved after 100 days in the pool. There is a 30-day cliff, which means that if a liquidity provider decides to withdraw their position before 30 days passes, they incur the same IL loss experienced in a normal, unprotected AMM. If an LP holds their liquidity in the pool for 100 days or more, they receive 100% compensation for any loss incurred in the first 100 days, or anytime thereafter.
If there are not sufficient tokens in the pool to fully pay out IL compensation in the staked token, part of the insurance may be paid out in an equivalent value of BNT.

Limitations

In order to allow for the special properties of Bancor v2.1, there are a few limitations.‌
First, v2.1 currently DOES NOT support dynamically adjusting supply tokens (i.e., "rebase" tokens) that can control and adjust the token balances in users' wallets.
Second, when BNT is being withdrawn from the system (included BNT paid out as part of IL compensation), it is locked for a pre-set time (default 24 hr) as a means of preventing protocol abuse.

Token Whitelisting Requirements

Requirements:

Transparency

  1. 1.
    The token contract needs to be verified on Etherscan.
  2. 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. 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. 1.
    They should not be owned by EOA.
  2. 2.
    They can be governed by multisigs.
  3. 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. 1.
    The token contract should not be upgradable.
  2. 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. 3.
    Minting of new tokens should be restricted and conform to the whitepaper and the security audit.
  4. 4.
    Rebasing tokens or tokens with elastic supply aren’t currently supported.
  5. 5.
    Tokens that apply transfer fees aren’t currently supported. Please note that tokens that have the fee mechanism in place but haven’t activated it yet are exempt.
  6. 6.
    Token transfers shouldn’t be pausable or subjected to a whitelist unless a reasonable explanation is provided.
  7. 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.)

Economic Requirements

  1. 1.
    The token should be fairly distributed (e.g., it can’t be concentrated in a few addresses).
Last modified 25d ago