# Consolidating recent proposals by @alphavalion **URL:** \ **Category:** Community Chatroom (DISCUSSION)\ **Created:** [June 18, 2023, 11:23am UTC](https://gov.bancor.network/t/consolidating-recent-proposals-by-alphavalion/4330 "2023-06-18T11:23:48Z")\ **Posts on this page:** 1\ **Showing post:** 1
**Author:** ![mbr](https://dub1.discourse-cdn.com/flex013/user_avatar/gov.bancor.network/mbr/32/3021_2.png) [@mbr](https://gov.bancor.network/u/mbr)\ **Post date:** [June 18, 2023, 11:23am UTC](https://gov.bancor.network/t/consolidating-recent-proposals-by-alphavalion/4330/1 "2023-06-18T11:23:48Z")
# **Bootstrap Carbon with POL from Bancor 3** ## **Context:** _This proposal is a continued discussion of the proposals created by alphavalion [[here](https://gov.bancor.network/t/proposal-to-start-sunsetting-bancor-v3/4279), and [here](https://gov.bancor.network/t/proposal-to-create-a-ddx-eth-strategy-on-carbon-using-ddx-bancor-3-surplus-for-snapshot-6-25-2023/4318)]. In brief, there are two key aspects that should be consolidated:_ #### **Winding down of Bancor V3 and cementing the lossless state of tokens in surplus** The Bancor V3 contracts allow the DAO to determine the trading liquidity value of any pool. If the trading liquidity is set to zero, that pool can no longer trade. For pools with tokens currently in surplus, stopping trading will ensure that all LPs will forever be able to withdraw their tokens without incurring a loss. This point was elaborated in a [comment](https://gov.bancor.network/t/proposal-to-start-sunsetting-bancor-v3/4279/28) on alphavalion’s original proposal; these mechanics are described in the [Comprehensive Description of Bancor 3](https://gov.bancor.network/t/bip15-proposing-bancor-3/3445/49) section of [BIP 15](https://gov.bancor.network/t/bip15-proposing-bancor-3/3445/49), and can be scrutinized in detail via the [Bancor V3 simulation resources](https://simulator.bancor.network/chapters/bancor-simulator.html). Importantly, the single-sided pool tokens of Bancor V3 represent a pro-rata share of the [Staking Ledger](https://gov.bancor.network/t/bip15-proposing-bancor-3/3445/2), which is distinct from the Master Vault balances. The Bancor V3 [withdrawal algorithm](https://gov.bancor.network/t/bip15-proposing-bancor-3/3445/4) was designed to [handle these situations](https://gov.bancor.network/t/bip15-proposing-bancor-3/3445/5), where a withdrawal from a pool in a state of surplus would trigger an adjustment in the pool’s marginal rate so as to effectively reduce its asking price and encourage the return of BNT tokens back into its reserves. In essence, the protocol would use surplus TKN to re-purchase BNT tokens from the market sporadically as users withdraw from these pools. Then, the recaptured BNT is destroyed as LPs withdraw in the future. The source of surplus tokens is the rebalancing nature of the AMM. For illustrative purposes, consider the DRC token, which was among those that had their [trading liquidity set to zero](https://gov.bancor.network/t/proposal-to-set-funding-limit-to-0-on-drc-bancor-3-pool/4291) in a recent collection of similar decisions submitted for [a vote via Snapshot](https://vote.bancor.network/#/proposal/0x5e7fba6622cd4eb27f8826481d2c446f5d6c2a2fb8cf2f572c4e889d23fb1c4e). The [proposal to whitelist DRC](https://gov.bancor.network/t/proposal-to-whitelist-drc-digital-reserve-currency-30-000-bnt-co-investment/2602) appeared in the governance forums in July 2021, and was [approved by the BancorDAO](https://vote.bancor.network/#/proposal/QmWgeibU4kbrRiJCaj7puPh2Pnv2BhkEH3hhHczW99jPxr) via Snapshot shortly thereafter. This was during the V2.1 paradigm, where protocol contributed BNT (aka the “co-investment” using the vernacular of the time) was an inflexible part of the system. Essentially, the protocol would provide BNT to complete the trading pair, from which the single-sided liquidity provisioning paradigm emerged. In V2.1, once the protocol exhausted its DAO-permitted BNT contribution to the pair, no additional liquidity contribution was possible. That is, unless the protocol BNT contribution limits were increased via a DAO vote. The DRC token was approved with an initial protocol BNT contribution capacity of 30k BNT, which was quickly exhausted. After approximately 1 month of the pool’s operation, a proposal to [increase the protocol BNT contribution for DRC liquidity to 50k](https://gov.bancor.network/t/proposal-to-increase-co-investment-for-drc-to-50-000-bnt/2691) was published to the governance forums, which was also [approved by the BancorDAO](https://vote.bancor.network/#/proposal/QmTBGuQ8Gqs5mq9NigbmuLWZcMCZiDz9UFeamvkY2vNk1A) shortly thereafter. Much has happened in the time since these proposals were approved. The BNT token significantly out-performed DRC in terms of price action during the first 12-months of the pool’s existence, and continued to out-perform DRC up to and including the present day. While this helps to illuminate the origin of the surplus, it is a worthy exercise to inspect precisely how these tokens arrived on Bancor V3. ![](https://europe1.discourse-cdn.com/flex013/uploads/bancordao/original/2X/c/c625a8dd1b17aa34e7e839e34ccd111f283f95ca.png) In [July 2022](https://gov.bancor.network/t/proposal-move-v2-1-liquidity-to-v3/3872) a discussion began surrounding the re-equilibration of token balances on Bancor V3 by migrating protocol-owned tokens from V2.1 (i.e. tokens that cannot be ascribed to user-owned balances). In [September 2022](https://gov.bancor.network/t/migrate-pol-from-v2-1-to-v3/4081) a full analysis of the aggregate states of V2.1 and V3 was posted to the forums, including a [google sheets](https://docs.google.com/spreadsheets/d/1HDDao0GzaVDdrIi1XElKwNQr9VrID1KNPPzvLrmLwYI/edit?usp=sharing) document which itemizes the data by token. These discussions culminated in a proposal, posted to the forums in [October 2022](https://gov.bancor.network/t/proposal-migrate-v2-1-surplus-and-open-withdrawal/4103), which was subsequently [approved by the BancorDAO](https://vote.bancor.network/#/proposal/0x9f80570a9133c733e81cb6578980a571be242904c9dc2dc61c2a12f8546fdd2d) via Snapshot vote the same month. In the [google sheets](https://docs.google.com/spreadsheets/d/1HDDao0GzaVDdrIi1XElKwNQr9VrID1KNPPzvLrmLwYI/edit?usp=sharing) document, DRC appears on row 64 (index 62), and columns F and G (current\_poolTokenSupply and current\_POL\_poolTokens, respectively) reveal the surplus existed on V2.1 at least that long ago. Column I (current\_POL\_total\_perc) lists the protocol ownership of DRC at 63%, which translates to a 237% surplus (column W, ‘current\_surplus\_perc’). The calculated amount of DRC to migrate at that time was 22,307,903.72 (column AB, ‘migrate\_amount\_tkn’). As the vote concluded Oct 19, 2022, 4:43 PM UTC, after a brief rally in DRC, I expect that the token amount that could be migrated was slightly reduced, which may explain why V3 has a balance of 16,348,845 DRC, not 22,307,903.72 as detailed in the original report. #### **Moving surplus tokens to Carbon and creating a protocol-owned strategy** The proposals by alphavalion generalise the purpose of this protocol-owned liquidity (POL) by introducing an intermediate step; the surplus tokens are first moved to Carbon and destined for inclusion in a “protocol-owned strategy”, which through fee generation also directly translates to BNT recapture and destruction. As an aside, the increased liquidity levels in Carbon ought to help maintain persistent volumes and assist with the adoption of the new product. However, [several issues have been raised](https://gov.bancor.network/t/proposal-to-start-sunsetting-bancor-v3/4279/27) that represent an insurmountable obstacle to implementing the protocol-owned strategies as initially envisioned by alphavalion. While a [rebuttal](https://gov.bancor.network/t/proposal-to-start-sunsetting-bancor-v3/4279/33) was provided, it suggests a fundamental misunderstanding by the original author regarding the feasibility of what is being proposed. The only satisfactory process must be one where there are a set of functions that can be called by literally anyone, which facilitate the exchange of tokens into the desired pair, and the creation of a strategy with unambiguous settings. This is the decentralization requirement which, for example, would prohibit the use of a generic token tracker and entrusting an individual with correctly interpreting it, and maintaining the strategy on chain in accordance with the DAO’s guidelines, as suggested in the proposal. To create a system of smart contracts to achieve what is proposed, in terms of regularly updating the strategy conditions in accordance with a TWAP, is similarly untenable. ## **Consolidation:** As ongoing strategy management is untenable, this proposal suggests that a generic stablecoin strategy be adopted which can exist in perpetuity without changing its parameters. ### **Strategy Details** #### **Suggested Tokens** A low maintenance token pair that can meet the restrictions and enforced criteria would be between two “like” tokens preferrable stable. Since there are many options for stable tokens, it would be preferred to select the two tokens which are most popular and trade with the largest volumes. Therefore, USDC/USDT is an obvious candidate. #### **Competition for Volume** Carbon’s smart contracts are sufficiently gas-efficient to hold their own against industry giants, including Uniswap V3 and Curve Finance, with respect to the most competitive of liquid pairs: stable coins. Uniswap V3 is superbly efficient on a liquidity unit basis, commanding ~45% of all USDC/USDT volume ($1.8 billion last month), predominantly via its 1 bp liquidity pool despite having only ~$50 million in liquidity. It’s a simple calculus; with the vast majority of liquidity concentrated within only a 2-tick range, and median and mean gas on swaps of 134k and 137k, respectively, Uniswap V3 offers attractive stable coin exchange rates at low overhead cost. Carbon should be able to offer competitive rates, and lower overheads than even Uniswap’s shining example. On Carbon, the average gas overhead is comfortably at the 45th percentile of Uniswap’s gas distribution, meaning it is poised to be an immediate contender for a compelling share of volume. There is one caveat - Carbon’s contracts apply a network-wide taker fee of 20 bps. However, it is possible to create a single, protocol-owned stable coin strategy with price settings that compensate for the difference and effectively emulate a 1 bp swap fee. #### **Competition for Price (Emulation of a sub 20 basis-point USDC/USDT Liquidity Pool)** To compensate for the network-wide 20 bp augmentation of exchange rates, the strategy will deliberately bid high on both USDT and USDC sides of the pair, sufficient only to compensate for swap fee. Therefore, with each trade, a maximum of 20 bps worth of the swap value is transferred from the strategy itself to the `feeBurner`. For perspective, this would allow a protocol-owned strategy containing $2 million in stablecoin liquidity to process $1 billion in swap volume before the last penny is transferred from the strategy to the `feeBurner`. The transfer of value from the strategy to the `feeBurner` is over-unity; whatever stablecoin value the strategy begins with, will eventually be transferred to the `feeBurner` together with the yields garnered on the taker volumes. #### **Strategy Settings** _1 basis point USDC/USDT spread_ Both order’s y-intercepts (y\_{int}) are be forced to an arbitrarily high number, and the high, low, and marginal rates are held constant (i.e. S = \sqrt{P\_{a}} - \sqrt{P\_{b}} = 0). The precise bidding and asking prices are held at precisely 1.0019 and 0.9981, respectively. The precise strategy configuration, before it has received any tokens, is: ```auto # USDC ORDER 'y' : 0 'Z' : 5192296858534827628530496329220096 'A' : 0 'B' : 422346370619417 (compressed), 281742787817522 (decompressed); {mantissa: 140871393908761, exponent: 1} # USDT ORDER 'y' : 0 'Z' : 5192296858534827628530496329220096 'A' : 0 'B' : 422346370619417 (compressed), 281742787817522 (decompressed); {mantissa: 140871393908761, exponent: 1} # Example trades on the proposed 1 basis-point USDC/USDT strategy # TRADE BY SOURCE Trader sends: 1000000.000000 USDC Trader receives: 999900.009998 USDT Gas overhead: 133681 Trader sends: 1000000.000000 USDT Trader receives: 999900.009998 USDC Gas overhead: 132975 # TRADE BY TARGET Trader sends: 1000100.000002 USDC Trader receives: 1000000.000000 USDT Gas overhead: 134132 Trader sends: 1000100.000002 USDT Trader receives: 1000000.000000 USDC Gas overhead: 133426 ``` # **Work to be done** 1. Expose a public function on Bancor V3 to handle the transfer: a. The caller chooses a token on Bancor V3. If the pool for that token has its trading liquidity set to zero, and the token is in surplus, then the function call is permitted. b. This function will transfer the precise surplus amount from the Bancor V3 master Vault, to a dedicated contract on Carbon. c. The caller receives a small incentive to call the function, proposed to be 0.2% of the total amount being transferred. For example, assume that there is a token TKN, which has balances of 200 and 100 in the Staking Ledger, and Master Vault, respectively. Further, assume the DAO has recently set its trading liquidity to zero. Therefore, all LPs in TKN can withdraw at any time, and without incurring a loss, at any point in the future. The surplus 100 TKN is available for transfer to the dedicated contract on Carbon for the purpose of growing the protocol-owned strategy. Alice calls the function and receives 0.2 TKN to her wallet. The remaining 99.8 TKN are transferred from the Bancor V3 Master Vault to the dedicated contract on Carbon. 1. Expose a public function on the `carbonPOL` contract to exchange the tokens received from Bancor V3 for USDC: a. The caller chooses a token from the available balances on the `carbonPOL` contract, to perform a swap into USDC. b. A `minReturn` value in the target stablecoin is obtained via a price oracle, and is not decided by the caller; `minReturn` is protecting the function from being abused. The proposed `minReturn` value is the oracle price - 0.5%: For example, assume that the 99.8 TKN from the previous function call are chosen by the caller. The Uniswap V2 price oracle indicates that these tokens have an approximate value of 1000 USDC. Bob calls the function with a specific trade route, and the swap successfully returns exactly 1000 USDC. Bob is rewarded with 2 USDC, and the remaining 998 USDC are returned to the contract. 1. Expose a public function that allows USDC to be transferred from the contract, to the protocol-owned strategy: For example, assume that the 998 USDC from the previous function call are chosen by the caller. Charlie calls the function and receives 1.996 USDC as a reward. The remaining 996.004 USDC are transferred from the contract to the protocol-owned strategy. ## DAO Decisions: 1. #### Proposed stablecoin strategy and settings. Vote FOR to support the creation of a protocol-owned USDC/USDT strategy on Carbon, which emulates a 1 basis point concentrated liquidity pool, via the setting detailed above. Vote AGAINST to defeat this part of the proposal 1. #### Function to transfer surplus tokens from Bancor V3 to Carbon with a 0.2% caller incentive. Vote FOR to support the creation of the proposed public function that moves surplus tokens from Bancor V3 to Carbon for the explicit purpose of being swapped for USDC, and where the function’s caller receives 0.2% of the surplus token amount as an incentive. Vote AGAINST to defeat this part of the proposal. 1. #### Function to swap surplus tokens for USDC with a 0.2% caller incentive and an oracle price - 0.5% minReturn (contingent on decision # 2). Vote FOR to support the creation of the proposed function that allows anyone to provide a trade route whereby the tokens received by the contract are exchanged for USDC, with a minimum return value provided by an external price oracle, and where the function’s caller receives 0.2% of the received USDC amount, after the swap, as an incentive. Vote AGAINST to defeat this part of the proposal. 1. #### Function to move USDC to the protocol-owned strategy with a 0.2% caller incentive (contingent on decision # 3). Vote FOR to support the creation of the proposed function that allows anyone to move the protocol-owned USDC received by the contract into the protocol-owned USDC/USDT strategy, and where the function’s caller receives 0.2% of the received USDC amount, after the swap, as an incentive. Vote AGAINST to defeat this part of the proposal. --- _[View the full topic](https://gov.bancor.network/t/consolidating-recent-proposals-by-alphavalion/4330)._