TKN Surplus Examples
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.
TKN Deficit Examples
A TKN is in deficit if the total vault balance is less than or equal to 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 is True, the protocol is in an effective deficit (i.e. the quantity of TKN is insufficient to reimburse the totality of all user stakes). In this state, it is possible that some users will receive partial reimbursement in BNT. However, the protocol will also attempt to reimburse users entirely in TKN using the reverse of the repricing strategy described for the surplus case - essentially to recapture TKN from the external markets. The following paragraphs will explore the three different situations that cover the discrete behaviors of the withdrawal algorithm during a deficit state of TKN.
As before, the potential for abuse is the most important component of the decision tree. The same thresholds, hlim and hmax, defined previously are used again here; however, the hmax calculation is modified to account for the reversed direction:
The hlim and hmax terms are used in exactly the same fashion as before; they 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 2,000 TKN (e), the vault balance of TKN is 1,800 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 888.888889 TKN, and hmax evaluates to 1138.958507 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 TKN from the outside markets.
The withdrawal algorithm outputs are the same, although the sign is effectively reversed in P and R, relative to the surplus calculations. To maintain unsigned arithmetic, the following descriptions are provided:
P, BNT quantity to add (mint) to the available trading liquidity.
Q, BNT ownership renounced by the protocol (i.e. removed from the staking ledger).
R, TKN quantity to remove from the available trading liquidity (and send to the user).
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 deficit, and the user’s withdrawal satisfies the hlim and hmax checks, the outputs are calculated as follows:
Note the opposite behavior of the protocol, compared to the surplus case. During a deficit, the algorithm reacts by quoting a higher price for TKN. The same considerations applied in the previous argument also apply here; if and when the pool returns to balance (defined as state of the pool before the withdrawal was executed), the relative deficit of TKN compared to the staked balance will remain constant, (ignoring vortex fee effects). The number of BNT minted to the trading liquidity, and the amount of TKN taken from the trading liquidity, is determined such that a hypothetically perfect arbitrage trade would return the deficit to its pre-withdrawal value. As before, there is no specific requirement for the implied arbitrage opportunity to close immediately, or even eventually.
The method is abusable if the withdrawal value (x) is greater than hlim or hmax. To examine a case where these abusability thresholds are exceeded, consider a scenario nearly identical to that presented above, but where the TKN balance of the staking ledger (e) is increased to 2,200 TKN. Therefore, the vault balance of TKN remains at 1,800 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).
For this scenario, hlim evaluates to 977.777778 TKN, and hmax evaluates to 87.855051 TKN. As the user’s withdrawal is still 100 TKN, the hlim test still passes, but the hmax test fails.
Therefore, the protocol’s repricing strategy is potentially abusable. Similar to what was discussed in the surplus sections, the withdrawal algorithm defaults to another set of operations, and a bifurcation occurs depending on the sufficiency of the non-trading TKN balance of the vault.
In this case the inequality is True; the user’s withdrawal can be processed without recourse to reducing the trading liquidity. The outputs of the algorithm are calculated as follows:
The most intuitive way to interpret this result is to add the TKN and BNT amounts together. In this case, the BNT/TKN rate is precisely 1:1, which makes it easy. The S and T outputs represent an amount of TKN, and BNT tokens sent to the user, respectively. Since these tokens have the same value, their sum should represent the total value the user was expecting, save for the exit fee. In this case, the sum is precisely 99.75, which is what we expect. These BNT tokens received in reimbursement are minted at withdrawal, and do not originate from inside the protocol. While this example uses a 1:1 valuation of BNT:TKN, the output T handles any BNT valuation.
Lastly, the case wherein the hlim or hmax test fails, and where it is impossible to refund the user without affecting the trading liquidity, should be considered. For this example, let the BNT trading liquidity (a) be 1,800 BNT, let the TKN trading liquidity (b) be 1,800 TKN, let the vault balance of TKN (b+c) be 1,850 TKN, and let the balance of TKN on the staking ledger (e) be 2,200 TKN, and assume the user confirms a withdrawal for 100 TKN (x).
For this scenario, hlim evaluates to 59.45945946 TKN, and hmax evaluates to 203.670372 TKN. As the user’s withdrawal is still 100 TKN, the hlim test fails, but the hmax test passes. The repricing method is therefore abusable. As before, the protocol 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:
As with its surplus counterpart, the outcome of this scenario is that the protocol gives up what non-trading TKN was left in the vault, and then takes the remaining balance from the trading liquidity. As this results in a formal protocol withdrawal of BNT, the Q output is populated, and is later transformed into an equivalent amount of bnBNT tokens. Both the BNT and the bnBNT are burned, and the quantity of BNT on the staking ledger is adjusted down appropriately.