Bancor 3 Beta Status Update: Cycle 1

9 min readApr 22, 2022

Bancor 3 Beta has been live since April 19th and we will be sharing Beta Status Updates with each new cycle leading up to the full release planned for May.

Per the BIP16 Beta proposal, capacity for token deposits are being gradually increased and roughly doubled every four-day cycle.

$1m TVL reached

Capacity for token deposits is being filled quickly following cap adjustments.
Current TVL is ~$1m across BNT, ETH, DAI and LINK.

Cycle 2

With today’s cap increases, Cycle 2 has officially begun.
The target TVL during Cycle 2 is $1.96m. Note that projected target liquidity and APR may change slightly based on token prices.

As caps are gradually raised, keep an eye on the smart contracts to see when space becomes available. Contract addresses can be found here.
Caps will be fully removed for the full release planned for May, enabling unlimited Single-Sided Staking.
At any point during the proposed 28-day program, the Bancor DAO may vote to end the Beta restrictions, and begin the launch of the Bancor 3 full version.

What Exactly is Going On?

A more detailed explanation of the first days of the Beta is outlined below.

The Bancor Beta commenced on April 19th, following approval of BIP16 by the Bancor DAO. The Beta is a trial; this is the first time the contracts have been available for users to interact with. The purpose of the trial phase is to observe the system, and ensure that it is behaving as designed. Bancor 3 has a number of nuances that represent a significant leap forward from conventional AMM behaviors, and which were monitored closely during this exciting period. The following sections describe how users interacted with the new contracts, the response by the protocol, and explain how these observations are consistent with the new design.

The First Liquidity Deposits

The first liquidity additions were both for 0.001 ETH, and were produced by 0x85B…F001 and 0x916…f640 on blocks 14611842, and 14611854, respectively. As expected, these contributions resulted in the generation of the Bancor ETH Pool Token, bnETH. Shortly thereafter the first DAI liquidity was provided by 0xspark.eth on block 14611870 (~50k), and the first LINK liquidity was provided by 0x85b…f001 on block 14612016. The Bancor DAI- and LINK Pool Tokens, bnDAI and bnLINK, were issued without any irregularities detected. During the first cycle there were a total of 69 discrete liquidity additions from 28 unique addresses. It is important to note that during all of these initial liquidity additions, there is a conspicuous absence of BNT from the vault. This is a deliberate consequence of the design, and is explained in the following sections.

A summary of the transactions and addresses involved with the Beta so far can be found here.

The Steps to Watch

Due to its unique setup, Bancor 3 does not commence trading immediately. For a comprehensive elaboration of the process, please refer to the BIP15 document. However, a concise summary of the behavior could be described as follows:

Liquidity is provided to the protocol by users.
The tokens are accepted into the vault.
Pool tokens are issued by the contracts.
During the Beta, the pool tokens are atomically staked in the rewards contracts; however, in the full release these tokens will be sent directly to users.
Trading does not commence immediately, and no BNT is created by the protocol during the above steps.
After sufficient liquidity has been established for each asset, a separate transaction is required to establish the starting rates for the virtual trading pools.
After the pools are initialized, their trading liquidities are bootstrapped with 2× the minimum BNT trading liquidity, defined as 10,000 BNT by the Bancor DAO during the drafting of BIP15.
During this bootstrapping step, the protocol deposits its own BNT, and issues itself bnBNT, the BNT pool token.
As soon as BNT is available, trades can commence.
Thereafter, as new deposits are made, the trading liquidity is allowed to increase to a maximum of double its present value, regardless of the size of the liquidity addition.

Bancor Pool Tokens

Importantly, during the initial liquidity contribution phase for any token, the bnToken rate is fixed at 1:1. This behavior can be examined behaving exactly as predicted. For example, 0x1b…4bd2 provided 2,000 LINK on block 14612084. The LINK tokens were taken into the vault, and exactly 2,000 bnLINK tokens were issued to the user. The same address also contributed 4,000 DAI on block 14612114, and received 4,000 bnDAI as a result.

The 1:1 equivalence is a transient property. As trading fees accumulate on the staking ledger, the pool token rate changes, and the issuance of new pool tokens is also changed. This behavior will be covered in the liquidity growth section of this report.

The Bootstrapping Transactions

The trading liquidities were bootstrapped on blocks 14623202, 14623206 and 14623208. During each of these steps, the protocol contributes its own BNT, and issues itself bnBNT. Owing to the labor intensive nature of the Beta, these steps are manually activated; however, during the full release will be under the control of the Bancor DAO msig. The contract function is called enableTrading, and its arguments are the address of the trading pool, and the virtual balances of BNT and TKN. The arguments bntVirtualBalance and baseTokenVirtualBalanceare simple to understand. In all cases, the initial state of the virtual trading pool is defined by exactly 20,000 BNT, and the appropriate amount of LINK, DAI and ETH as determined by the virtual token balance arguments of the enableTrading function. In other words, these arguments determine the starting state of the pool, and tell the protocol how many of each token should be made available as trading liquidity. Importantly, apart from BNT, the balance of tokens in the vault does not change during the bootstrapping step — rather, the virtual pool changes the subset of tokens represented on its bonding curve. There is no transfer of tokens to another place. This behavior can be observed directly on the vault itself.

Standard Rewards Contracts

A gas optimization tactic was used in the initial deployment of the rewards contracts, which resulted in an incorrect number of claimable rewards for some users. The issue was muted by the contract’s internal logic, which would have prevented the issue from being exploited, had anyone attempted it (no one did). The problem was detected immediately, and a war room was set. The cause of the issue — the aforementioned gas optimization — was identified within minutes, and a fix was prepared. The fix was tested on our mainnet fork with four sets of developer eyes, and only after it was validated was it applied. At no time were any user funds at risk.

Liquidity Growth

After bootstrapping, each pool begins with precisely 20,000 BNT and a commensurate amount of LINK, DAI and ETH. Thereafter, the pool’s trading liquidity can grow by a maximum of 2× the previous liquidity balance. Provided that the vault has sufficient TKN reserves to allow it, the pool will double in size regardless of how much liquidity is added by users. This process can continue up to the decided BNT funding limit established by the Bancor DAO. During the Beta, this value moves with each cycle in-step with the TVL targets.

This behavior can be examined on-chain. For example, bancoralchemist.eth performed a series of very small liquidity additions after the bootstrapping process was completed. On block 14624553 a single LINK token was added to the vault — which triggered the protocol to add a further 20,000 BNT in liquidity, and double the available LINK available for trading on the virtual bonding curve. Similar behavior is observed on block 14624615, where exactly 1 Wei of ETH was added, and on block 14624685, where exactly 1 DAI was added. In these cases the vault already contained a large excess of the necessary TKN, sufficient to grow the available trading liquidity by twice its previous state. The receipt of the additional TKN is necessary only to trigger the change on the contracts; the increased TKN balance, in these examples, is incidental.

The behavior seen on block 14626275, where 0x7c…4d29 added 0.01 LINK, demonstrates a slightly different scenario. In this case, the vault LINK balance was limiting, and thus the pool was unable to double in size during this transaction. The balance on the pool prior to this transaction was roughly 40,000 BNT, but the out-of-curve LINK balance could only justify an additional 28,231 BNT in liquidity.

In all cases, the liquidity bootstrapping steps are behaving as described in the BIP15 proposal, with no irregular or unexpected behavior.

BNT Liquidity Contribution

As described in the BIP15 proposal, BNT liquidity providers burn their BNT tokens in exchange for bnBNT pool tokens. The creation of bnBNT pool tokens is contingent on the TKN trading liquidity, and therefore the bootstrapping and liquidity growth steps described in the previous sections.

The consequences of the first BNT liquidity contribution occurred on block 14623212, and consists of 40,445.95 BNT burned by 0xD73…36B6 in exchange for the same quantity of bnBNT, sent from the protocol wallet. There were 31 such liquidity provision events during the first cycle of the Beta test. Like its TKN counterparts, BNT liquidity provision on the Beta test is incentivized with a standard rewards contract. The bnBNT tokens are sent directly to the rewards contract, rather than to the user’s address.

An important change between v2.1 and Bancor 3 is the issuance of the Bancor DAO voting token, vBNT. Rather than being issued 1:1 with the underlying BNT, vBNT issuance on Bancor 3 is 1:1 with the bnBNT pool token. This behavior is perhaps best demonstrated with one of the most recent liquidity additions. On block 14625490, 6,000 BNT were burned by 0xbdc…6719. By the time this transaction was processed, a small amount of trading revenue was already accumulated by the BNT staking ledger, causing the bnBNT issuance rate to have changed very slightly from its initial 1:1 parity. As a result, 5,999.999 bnBNT pool tokens were moved from the protocol to the user, and 5,999.999 vBNT, not 6,000, as would be the case on v2.1, were issued as a result.

This aspect of the system could be said to have behaved entirely as expected, were it not for a minor hiccup involving the destination of the issued vBNT during the first moments of available BNT liquidity provisioning. Instead of the user receiving the vBNT directly, the tokens were inadvertently sent to the rewards staking contract alongside the bnBNT pool tokens. Again, this was a non-issue, identified immediately and was quickly resolved after detection. No funds were at risk at any time. All addresses that provided BNT have now received the vBNT that should have been issued.

First Trades

The first trade of the Beta test was performed by 0x85B…F001 on block 14623625. The swap was 0.001 ETH for DAI. This exact swap was then performed by primalglenn.eth on block 14623992, then again by 0x85B…F001 on block 14624215. Importantly, the constant product behavior of the virtual DAI pool can be observed directly on these three transactions. The first swap returned 3.069 DAI, the second returned 3.068 DAI, and the third returned 3.067 DAI. The diminishing rate is consistent with the continuous price discovery element of the algorithm, and is a convenient demonstration of the fact that the trade functions are working as expected, as far as the trader is concerned.

Trading also results in the accumulation of swap fees on the staking ledger, and changes the issuance and redemption rates of pool tokens. This change in pool token issuance can be observed within the first cycle of the Beta. In the above trade examples, DAI is the target asset of the trade, and therefore the fee-earning asset. The relative value of the bnDAIpool token is therefore increased, and this change must be reflected in future DAI liquidity provision events. The most recent liquidity provision event that took place prior to these trades was during block 14617520, where 0xca…53b9 added 23 DAI, and received 23 bnDAI(i.e. an exact 1:1 rate). Immediately after these trades were performed, bancoralchemist.eth added exactly 1 DAI on block 14624685, and was issued 0.9999999 bnDAI. The break from the 1:1 parity caused by the accumulation of swap fees on the staking ledger is therefore demonstrated.

Helpful Links: