TKN Surplus Example
TKN Surplus Example¶
A TKN is in surplus if the total vault balance is greater than the staked amount, after accounting for the exit fee. It is necessary to separate the vault balance into the trading liquidity (b), and non-trading liquidity (c) components; b + c is the vault balance of TKN:
where e is the TKN balance of the staking ledger, and n is the withdrawal fee (e.g. 0.0025, or 0.25%). So long as the above expression evaluates as True, the protocol is in an effective surplus (i.e. the quantity of TKN exceeds that of the combined user stakes). Therefore in all cases, it is guaranteed that any user withdrawing will receive only TKN. However, the protocol will also attempt to reduce the surplus and recover BNT from the secondary markets. The following paragraphs will explore the three different situations that cover the discrete behaviors of the withdrawal algorithm during a surplus state of TKN.
The most important decision the protocol makes is to evaluate the abuse vector described above. To do this, two important thresholds are calculated, hlim and hmax; the former determines whether there is sufficient non-trading TKN in the vault to support the user’s withdrawal without changing the trading pool depth, and the latter determines if an apparent abuse vector exists. These two values are calculated as follows:
These two values, hlim and hmax, define the maximum value for x that is allowable without creating a possible abuse incentive. Therefore, the user’s withdrawal amount (x) must be less than both hlim and hmax:
To examine this further, consider the following case: the staking ledger reports a staked balance of 1,400 TKN (e), the vault balance of TKN is 1,500 TKN (b+c), the TKN trading pool has 1,000 TKN (b) and 1,000 BNT (a) in available liquidity. Then, a user confirms a withdrawal for 100 TKN (x).
In this case, hlim evaluates to 466.6667 TKN, and hmax evaluates to 501.486064 TKN. As the user’s withdrawal amount (x) is less than both of these values, there must be sufficient non-trading TKN in the vault to support the withdrawal, and there is no financial incentive to create the withdrawal for the purpose of back running. Therefore the protocol can attempt to recover a small amount of BNT from the outside markets.
The withdrawal algorithm has six different outputs:
P, BNT quantity to remove (burn) from the available trading liquidity.
Q, BNT ownership renounced by the protocol (i.e. removed from the staking ledger).
R, TKN quantity to add to the available trading liquidity from the non-trading liquidity.
S, TKN quantity to remove from the vault (and send to the user).
T, BNT quantity minted for, and sent to the user as compensation.
U, TKN removed from the external protection wallet and sent to the user as compensation.
The method for calculating each of these outputs is dependent on the state of the system. The case where there is a TKN surplus, and the user’s withdrawal satisfies the hlim and hmax checks, the outputs are calculated as follows:
It is important to note that during a surplus, the algorithm reacts by moving the price of BNT vs TKN in the pool; note that the pool began with a spot rate of 1:1, and arrived at a slightly higher price for BNT at the conclusion of the process. This repricing is such that, if and when the pool returns to balance (defined as state of the pool before the withdrawal was executed), the relative surplus of TKN compared to the staked balance will remain constant, (ignoring vortex fee effects). In essence, either the valuation of BNT is allowed to increase vs TKN, or the closing of a future arbitrage opportunity positively affects the total BNT balance of the protocol. The number of BNT burned from the trading liquidity is equal to the amount that would be returned in a hypothetically perfect arbitrage, assuming the rate inside the pool is in agreement with consumer expectations (i.e. the rest of the market). This anticipatory BNT is part of the process - while BNT is lost from the trading liquidity in this case, the protocol does not relinquish its pool tokens. It might be helpful to think of this as a small trade of TKN to BNT having just occurred. Whether or not the apparent arbitrage opportunity is closed immediately is irrelevant; for example, it is likely that these small adjustments will occasionally close existing arbitrage opportunities. It is only important that a compensatory action is taken by the protocol that addresses the implicit BNT valuation and/or its liquidity equilibrium state.
Such actions can only be taken if the hlim and hmax tests evaluate to True. To examine a case wherein these tests do not pass, consider a scenario nearly identical to that presented above, but where the non-trading TKN balance (c) is increased to 1,000 TKN. Therefore, the staking ledger reports a staked balance of 1,400 TKN (e), the vault balance of TKN is 2,000 TKN (b+c), the TKN trading pool has 1,000 TKN (b) and 1,000 BNT (a) in available liquidity, and the user confirms a withdrawal for 100 TKN (x).
In this case, hlim evaluates to 700 TKN, and hmax evaluates to 18.208192 TKN. For this scenario, the hlim test still passes, but the hmax test fails. Therefore, the protocol’s repricing strategy is potentially abusable, and the withdrawal algorithm will default to a different set of operations. As the protocol prefers to not interfere with the depth of the pool where possible, a bifurcation in the logic at this point is required. In essence, the protocol asks if there is sufficient TKN in the non-trading vault balance to cover the user’s withdrawal.
In this case the inequality is True, which essentially means that the user’s withdrawal can be processed without touching the trading liquidity. A modified method for calculating each of the algorithm outputs is necessary:
This is the simplest case to understand. The user withdraws their TKN directly from the vault, and no compensatory actions are taken. The last remaining case for withdrawals is when there are insufficient non-trading funds to process the user’s withdrawal - when the inequality presented above is False. Consider the situation where the vault balance of TKN is the same, but the proportion of funds used for trading liquidity is much higher. Instead of a pool only 1,000 TKN deep, let it be 1,995 TKN deep instead, while maintaining the same vault balance (i.e. the non-trading TKN balance (c) is reduced while the trading liquidity balance (a) is increased). As before, the staking ledger reports a staked balance of 1,400 TKN (e), the vault balance of TKN is 2,000 TKN (b+c), the TKN trading pool has 1,995 TKN (b) and 1,995 BNT (a) in available liquidity, and the user confirms a withdrawal for 100 TKN (x).
In this case, hlim evaluates to 3.5 TKN, and hmax evaluates to 36.325343 TKN. For this scenario, both of the hlim and hmax tests fail. As before, the protocol detects that its repricing method can be abused, and proceeds to check if the available non-trading liquidity is sufficient to cover the withdrawal.
In this case the inequality is False. Therefore, it is necessary to reduce the available trading liquidity. A third series of methods is required to calculate each of the algorithm outputs:
To summarise the outcome for this scenario, the protocol gives up what is left of the non-trading TKN, and then the remaining balance is taken from the trading liquidity. Since the pool depth is directly affected, the protocol must renounce the BNT component of the pool. Previously, the variables Q and R were treated independently, as the small change in the BNT trading liquidity was akin to a simulated swap, rather than a formal withdrawal. However, in this case Q = R, as the reduction in the pool is appropriately treated as the protocol performing a withdrawal. The Q quantity is denominated in BNT, and is later processed into its equivalence in bnBNT; both the BNT and the bnBNT are destroyed, and the staked balance of BNT is adjusted down, accordingly. Let us do this in the context of a simple example, and then use the method with a larger dataset.