Proposing Carbon (FINAL)

[mbr]

This proposal has been reviewed and edited since its original publication. This proposal describes six (6) decisions requiring a DAO vote. Each is expected to appear, separately, on Snapshot no earlier than 2023-04-16T14:00:00Z.

TL;DR:

• Carbon aims to become the flagship offering of Bancor.

• Carbon is not a conventional Automatic Market Maker (AMM), nor is it a conventional order book, but its features borrow from both of those paradigms.

• The mechanics that underpin Carbon’s features borrow from AMM theory, but its unique implementation results in a changed financial instrument compared with its AMM precursors.

• Carbon offers its users the ability to decide on independent buy and sell levels for a base/quote asset pair, whereas AMMs prescribe a specific portfolio rebalancing strategy.

• Another important distinction between the two paradigms is that users who subscribe to an AMM trading strategy (i.e. ‘liquidity providers’ or ‘makers’) expect to benefit from a bid-ask spread resulting from a nominal trading fee, paid by takers on the protocol.

• Carbon’s users do not directly benefit from fee accrual; the benefits to users are driven by order execution.

• Rather than the trading fee serving the role of producing a bid-ask spread, the user creates one explicitly, and benefits as the market moves across it.

• All trading fees on Carbon accumulate to the protocol itself.

• As decided by the BancorDAO in a prior vote (and subject to change by future votes), the fee accrual on Carbon will be used exclusively to recover BNT from the market and destroy it, with a view to returning the token balances on legacy Bancor protocols (v2.1 and v3) to surplus.

• An initial 0.2% (20 bps) taker fee is proposed on swaps, taken variably from either the ‘source’ or ‘target’ tokens on trades, depending on the specific function call that facilitated the exchange.

• An initial maker fee is discussed herein, which can be applied to all contract interactions involving the maker’s management of their strategy, and is suggested to be precisely 0.0005 ETH (approximately $1).

• The maker fee is arranged into five categories, corresponding to the individual types of actions that makers on the platform can take.

• Unlike the taker fee, the maker fee does not involve the token balances of the maker’s order; instead, the maker fee is proposed to be paid exclusively in the gas token of the blockchain environment on which Carbon is deployed and is discussed with a view to making this aspect of the system sufficiently unobtrusive as to be a negligible influence on consumer decision making.

• A framework for the ongoing governance of Carbon is proposed, seeking to create well-defined responsibilities for the BancorDAO and its obligations to protocol management.

• This document presents several topics, before arriving at six (6) individual proposals (BIPs 23-28), requiring a ruling by the BancorDAO.

[mbr]

Introduction:

The formal proposal process for Carbon can be traced back to November 2022, when a litepaper, white paper, and invention disclosure were published. Since then, the development and release of simulation resources through GitHub and JupyLite have enabled interested individuals to examine the proposed system in unparalleled depth for any proposal considered on this forum. A comprehensive public discourse on Carbon’s design, development, and use cases can be found on platforms such as YouTube and Medium, as well as through a dedicated Twitter account. Carbon remains a regular topic of discussion during scheduled DAO meetings.

The purpose of this proposal is not to add further redundancy to the resources already available. The resources and cumulative efforts to openly discuss Carbon has fostered more community engagement and dialogue surrounding the proposed system than any standalone proposal ever could. Only a cursory review of the existing material is provided for context, and readers are referred to the above resources for a detailed exploration of the proposed system.

Nonetheless, this proposal serves not only as a formality. The sections below are intended to provide a view of Carbon’s governance, which has not been featured in the prior literature. A proposed framework is introduced that defines and organizes the responsibilities of the BancorDAO with respect to the protocol fees, and their use in recovering the BNT token from the market.

[mbr]

Carbon in Brief:

Carbon is a decentralized exchange (DEX). Its defining characteristic is asymmetric liquidity, which is modeled after the behavior already exhibited by traders in their interactions with traditional order book systems. Notably, its underlying bonding curves trade in a single direction, which prohibits back running. As a consequence, makers on the system can be confident that their trades are executed irreversibly, and takers benefit from shelter from common MEV manipulations, including and especially sandwich attacks.

Users create permissionless strategies with one or two orders, and are issued a transferable NFT receipt token. The NFT also serves as the credentials for interacting with the underlying position, affording its holder the ability to pause trading on the underlying tokens, edit the curve parameters, and add and withdraw liquidity from the strategy. A matching engine (by way of a browser-enabled SDK) handles spot trading requests. User strategies are not aggregated together. Instead, the smart contracts simply expose the collection of bonding curves and their associated token balances and the aggregation occurs externally, either via the complement SDK, or using any custom software capable of reading and processing the on-chain data.

The granular organization of user positions inside Carbon’s smart contracts, the asymmetry of its liquidity, and irreversibility of its trading represents radically changed thinking for on-chain liquidity applications, and the products that power the token economy.

[mbr]

Proposed Governance of Carbon:

A precedent has been established that 100% of fees accumulated via Carbon are to be used to repair Bancor’s deficits in its legacy protocols (v2.1 and v3) by buying & burning BNT. While the DAO-approved proposal sets this objective, it does not offer a description for how this objective should be accomplished. The focus of this section is to describe the mechanisms by which fees accumulate to the Carbon protocol, and to propose methods that can be used to convert accumulated value into BNT and burn it, as dictated by the policy approved by the BancorDAO in February, 2023.

[mbr]

Fees:

Fees accumulate to the Carbon protocol from two major sources:

• Taker Fees, which are paid by traders while filling orders on the system. Taker fees are proposed to be taken as a fixed proportion of either the base or quote token being traded, depending on the specific function being called (vide infra).

• Maker Fees, for which a specific implementation is described at a high-level. Maker fees could be paid by users while creating and editing their strategies and/or their component orders. The presented high-level concept recommends five categories of maker fee (below), to be paid in the gas token of the blockchain on which the system is deployed, and as a fixed amount (initial settings proposed are 0.0005 ETH on Ethereum for all categories).

  • Strategy/Order Creation,
  • Increase Strategy/Order Funding,
  • Decrease Strategy/Order Funding,
  • Edit Strategy/Order Settings,
  • Pause Trading

[mbr]

Taker Fees:

Takers on Carbon can perform their trade in two main ways. To describe these methods, consider a generic case where a liquidity pool exists for a generic BASE/QUOTE token pair, composed of an arbitrary number of unique user strategies, orders, token balances and so on. The trader wishes to perform a trade whereby their QUOTE tokens are exchanged for BASE tokens. There are two ways the trade can be performed, each with dedicated functions in the contracts:

1. The trader can nominate a precise amount of the QUOTE token to be sent to the protocol, and request from the system the maximum number of BASE tokens they can receive in exchange, according to the underlying order parameters of each user’s position.
   • In this scenario, the number of tokens being sent to the contract from the trader is the input, and the number of tokens being sent from the contract to the trader is the output.
2. The trader can nominate a precise amount of the BASE token they wish to receive from the protocol, and request from the system the minimum number of QUOTE tokens they must send in exchange, according to the underlying order parameters of each user’s position.
   • In this scenario, the number of tokens being sent to the trader from the contract is the input, and the number of tokens being sent from the trader to the contract is the output.

Scenario	Input	Output	Fee Adjustment	Example
1	QUOTE token sent from the trader to the protocol (Δx).	BASE token sent from the protocol to the trader (-Δy).	-Δy(1 - fee)	Trader asks to send exactly Δx QUOTE tokens to the protocol and receives -Δy(1 - fee) BASE tokens from the protocol.
2	BASE token sent from the protocol to the trader (-Δy).	QUOTE token sent from the trader to the protocol (Δx).	Δx/(1 - fee)	Trader asks to receive exactly -Δy BASE tokens from the protocol and sends Δx/(1 - fee) QUOTE tokens to the protocol.

To resolve complexity in the code, the fee is always applied to the output. Therefore, depending on the function being called, the fee can be collected in either the BASE or QUOTE token.The consequences of this design choice are now elaborated. In each of the following examples, a trade is simulated against a single maker order composed of the following parameters:

Curve Parameter	Value	Notes
B	1.111081	The highest ask (y = BASE), or lowest bid (y = QUOTE) boundary metric, depending on context.
S	0.420455	The range width parameter.
yint	1000.000000	The curve capacity metric.
y	500.000000	The remaining token balance
fee	0.002000	The protocol fee setting.

[mbr]

Example 1: Constant Maker Send and Receive Amounts.

Scenario 1:

The taker requests to send exactly 10.000000 QUOTE tokens to the protocol, all of which is swapped against the maker’s order, and returns a value of 17.362090 BASE tokens. Of the 17.362090 BASE tokens relinquished by the maker’s order, the taker keeps 17.327366 BASE, and the protocol keeps 0.034724 BASE.

Scenario 2:

The taker requests to receive exactly 17.362090 BASE tokens from the protocol. To satisfy the requirements of the maker’s order, exactly 10.000000 QUOTE tokens must be exchanged (ignoring the fee). After adjusting for the protocol fee, the taker must send a total of 10.020040 QUOTE tokens to the protocol. The protocol keeps 0.020040 QUOTE tokens, and the remaining 10.000000 QUOTE tokens are exchanged with the maker’s order for 17.362090 BASE tokens, which are sent from the protocol to the taker.

Example 1 Summary:

In both of the above scenarios, the maker exchanged 10.000000 QUOTE tokens for 17.362090 BASE tokens. Therefore, the specific function call has no impact on the maker’s preset exchange rates.

Scenario	Taker Sent	Taker Received	Maker Sent	Maker Received	Protocol Fee Collected
1	10.000000 QUOTE	17.327366 BASE	17.362090 BASE	10.000000 QUOTE	0.034724 BASE
2	10.020040 QUOTE	17.362090 BASE	17.362090 BASE	10.000000 QUOTE	0.020040 QUOTE

[mbr]

Example 2: Constant Taker Receive Amount.

Scenario 1:

The taker requests to send exactly 10.000000 QUOTE tokens to the protocol, all of which is swapped against the maker’s order, and returns a value of 17.362090 BASE tokens. Of the 17.362090 BASE tokens relinquished by the maker’s order, the taker keeps 17.327366 BASE, and the protocol keeps 0.034724 BASE.

Scenario 2:

The taker requests to receive exactly 17.327366 BASE tokens from the protocol. To satisfy the requirements of the maker’s order, exactly 9.979889 QUOTE tokens must be exchanged (ignoring the fee). After adjusting for the protocol fee, the taker must send a total of 9.999889 QUOTE tokens to the protocol. The protocol keeps 0.020000 QUOTE tokens, and the remaining 9.979889 QUOTE tokens are exchanged with the maker’s order for 17.327366 BASE tokens, which are sent from the protocol to the taker.

Example 2 Summary:

In both of the above scenarios, the taker received exactly 17.327366 BASE tokens. The taker receives a vanishingly small improvement in the exchange rate for scenario 2 (approx. 1/10,000). Therefore, the specific function call has a negligible impact on the taker’s exchange rates.

Scenario	Taker Sent	Taker Received	Maker Sent	Maker Received	Protocol Fee Collected
1	10.000000 QUOTE	17.327366 BASE	17.362090 BASE	10.000000 QUOTE	0.034724 BASE
2	9.999889 QUOTE	17.327366 BASE	17.327366 BASE	9.979889 QUOTE	0.020000 QUOTE

[mbr]

Example 3: Constant Taker Send Amount.

Scenario 1:

The taker requests to send exactly 10.000000 QUOTE tokens to the protocol, all of which is swapped against the maker’s order, and returns a value of 17.362090 BASE tokens. Of the 17.362090 BASE tokens relinquished by the maker’s order, the taker keeps 17.327366 BASE, and the protocol keeps 0.034724 BASE.

Scenario 2:

The taker requests to receive exactly 17.327557 BASE tokens from the protocol. To satisfy the requirements of the maker’s order, exactly 9.980000 QUOTE tokens must be exchanged (ignoring the fee). After adjusting for the protocol fee, the taker must send a total of 10.000000 QUOTE tokens to the protocol. The protocol keeps 0.020000 QUOTE tokens, and the remaining 9.980000 QUOTE tokens are exchanged with the maker’s order for 17.327557 BASE tokens, which are sent from the protocol to the taker.

Example 3 Summary:

In both of the above scenarios, the taker sent exactly 10.000000 QUOTE tokens. The taker receives a vanishingly small improvement in the exchange rate for scenario 2 (approx. 1/10,000). Therefore, the specific function call has a negligible impact on the taker’s exchange rates.

Scenario	Taker Sent	Taker Received	Maker Sent	Maker Received	Protocol Fee Collected
1	10.000000 QUOTE	17.327366 BASE	17.362090 BASE	10.000000 QUOTE	0.034724 BASE
2	10.000000 QUOTE	17.327557 BASE	17.327557 BASE	9.980000 QUOTE	0.020000 QUOTE

[mbr]

Taker Fee Notes:

In general, token exchange protocols take the fee exclusively from one of the trade directions (in this case, either the BASE or the QUOTE token). For example, Uniswap V1, V2, and V3 all take the fee from the asset that is being sent from the protocol to the trader (i.e. the BASE token in the above examples), whereas Balancer takes the fee from the asset being sent from the trader to the protocol (i.e. the QUOTE token in the above examples). There are good arguments to be made in support of either decision. Carbon does both (variably, depending on which function is being called). Examples 2 and 3 clearly demonstrate that there is a non-zero (very nearly financially irrelevant) advantage for the taker in forcing the protocol to collect the fee in the QUOTE token. So be it. While MEV searchers and especially frugal integrators are likely to always pre-compute the input as necessary to facilitate the desired swap exclusively via the cheaper of the two options, a 1/10,000 advantage matters very little in a market that moves as violently as the one Carbon lives in.

One possible caveat to the opinion offered above is that with larger taker fees, the separation in exchange values becomes more significant. The consensus view at a recent DAO meeting was that 20 bps/0.2% taker fee is an attractive target. However, if more aggressive pricing policies are considered at some point in the future, the impact may be more significant. If it becomes necessary to revisit this discussion at any point in the future, the following code is provided to allow DAO members to easily reproduce this section of the proposal (APPENDIX).

[mbr]

Maker Fees:

This proposal introduces a high-level implementation concept for the maker fee, only. Makers on Carbon could pay fees to the protocol with various interactions with their position (e.g., strategy creation, edits, and withdrawals). However, unlike takers, makers could pay a flat rate, and always in the gas token of the blockchain (e.g. ETH on Ethereum, AVAX on Avalanche, MATIC on Polygon, xDai on Gnosis Chain, XRD on Radix, and so on). Moreover, the flat fee should be sufficiently small, to go essentially unnoticed by makers on the system.

A flat rate is desirable over a pro-rata policy for two key reasons. First, Carbon’s value proposition is exchange rate execution and token accumulation - taking tokens from a maker’s strategy balances is a self-defeating product decision. Second, a flat rate results in an intrinsic benefit to those contributing large token balances, whereas a pro-rata policy can become prohibitively expensive very quickly. Even seemingly reasonable pro-rata fee rates do not scale well when maker order sizes are likely to span several orders of magnitude. However, a flat fee rolled in with the gas cost of protocol interaction can quickly become inconsequential for those trading with significant amounts of capital.

As each blockchain has its own gas economy, this proposal does not suggest a single value that should be adopted in all environments. Decisions regarding initial maker fee settings, and revisions to these settings over time, may be an infrequent but important aspect to the implicit responsibilities of the BancorDAO following Carbon’s release.

With this proposal, a structured set of five distinct maker fee types is offered, where each type corresponds to a well-defined action that can be taken by makers on the platform:

	Maker Fee Type	Description	Example
1	Strategy/Order Creation	A global fee value that is applied when a new strategy or order is created.	Alice creates a strategy on Carbon with USDT and wBTC, and pays the protocol 0.0005 ETH as a service fee.
2	Increase Strategy/Order Funding	A global fee value that is applied when additional tokens are added to an existing strategy or order by the maker.	Bob sends additional USDT to his order to buy wBTC, and pays the protocol 0.0005 ETH as a service fee.
3	Decrease Strategy/Order Funding	A global fee value that is applied when tokens are removed from an existing strategy or order by the maker.	Charlie removes some wBTC from his strategy, and pays the protocol 0.0005 ETH as a service fee.
4	Edit Strategy/Order Settings	A global fee value that is applied when the parameters of an existing strategy or order are changed by the maker.	Deborah changes her wBTC sell targets from 30,000 USDT per wBTC, to 35,000 USDT per WBTC, and pays the protocol 0.0005 ETH as a service fee.
5	Pause Trading	A global fee value that is applied when an existing strategy or order is paused by the maker.	Erin stops all trading on her USDT/wBTCstrategy, and pays the protocol 0.0005 ETH as a service fee.

Each of the five types of maker fees are proposed to be individually addressable by a DAO vote. However, the suggested initial maker fee settings on Ethereum mainnet is to target approximately 0.0005 ETH (approximately $1 at the time of writing) in all cases. As the specific implementation details have not yet been determined, further discussion surrounding the minutiae of it is impossible. However, it is a worthwhile exercise to explore the economics of the maker fee policy being proposed here.

Assume that a typical contract interaction has an approximate gas cost of $20 (not a true estimate; used for convenience sake). The suggested maker fee is the difference between $20 and $21 while signing a transaction - regardless of the size of the maker’s position. The fluctuations in the gas cost of interacting with the chain, to which the users on Ethereum are already exposed, dwarf this amount by an absurd margin. Therefore, at least in the context of Ethereum, an additional $1 added to the transaction cost is unlikely to be a deciding factor for the prospective consumer base. Moreover, with the gas optimizations of Carbon seeking to establish a cost-efficient alternative with respect to other liquidity operation on-chain, the maker fee could be very nearly imperceptible to the DeFi veterans. This argument gets stronger with larger maker positions, as the $1 difference tendered by this hypothetical applies equally to positions worth $100, or $1,000,000. The diminishing relative return on larger positions is offset from a protocol perspective, as larger orders are expected to attract more retail interest, and drive increased taker transaction volumes and implied protocol revenue thereon.

It is the author’s view that cost efficiency of contract interactions is of paramount importance to maintain Carbon’s competitiveness. Over-reliance on the maker fee is a cheap and dangerous tactic, and should be managed carefully.

[mbr]

Blockchain-Specific Considerations:

Alternative blockchains to Ethereum, and other related public ledger technologies (e.g acyclic graphs) vary in their gas economies. Periodic spikes in pedestrian traffic on certain blockchains, including and especially Ethereum, could result in the proposed 0.0005 ETH fee becoming obscenely overpriced. As such, the BancorDAO should periodically review the maker fee on all blockchains where Carbon is deployed. This doesn’t need to be an arduous process - it is unlikely that this aspect of the protocol will require constant attention.

This proposal acknowledges the importance of maintaining the fee settings of the protocol, and asks that the BancorDAO assign itself the duty of its proper management. To address the need for a process where management decisions are forced into an open dialogue with some level of predictability, this proposal asks that it become part of the DAO canon that no more than 180 days pass between the submission of fee maintenance proposals for a DAO decision, even if the proposal is to leave the fee settings unchanged. This part of the proposal is for the DAO to acknowledge its new responsibilities and signal a process for managing them.

[mbr]

Important Note on Maker Fee Readiness:

At the time of writing the specific implementation of the maker fee has not been finalized. This topic has been actively discussed on DAO meetings, and the general consensus view is that it is preferable to have this aspect of the system active at Carbon’s initial deployment. The major talking points were that there is little benefit to withholding such an insignificant component from the system, and that if doing so represents a significant advantage in the early phases of the protocol adoption, then let that be evidence that the maker fee is too high. In other words, if there is an incentive to participate only because the maker fee is currently absent, then it has failed in its ambition to be an innocuous element. Secondly, fears that adding additional costs over time could be conflated with bait-and-switch tactics were also voiced, and that presenting the system in completeness would avert such unfavorable impressions.

The author acknowledges the validity of these concerns; however, it is worth asking if they are sufficient to keep an early deployment on hold, if the maker fee logic remains unfinished. Readers are reminded of the views expressed above, where a successful maker fee policy is espoused to be one which is of such little consequence to individual users that its presence is barely an inconvenience. Ultimately, taker fees can and should represent the vast majority of the protocol’s revenue. If the maker fee is that much of a sticking point with respect to the concerns raised, it may be worth reexamining its proposed settings.

This proposal asks that the DAO approve Carbon’s deployment at its earliest available state, with or without the maker fee component.

[mbr]

Fees, Initial Settings and Management Responsibilities:

Taker Fees:

• Proposed to begin at 0.20% (20 bps), and taken variably from either the QUOTE or BASE token, dependent on the specific function call as outlined above.

• Applied protocol-wide, without bias for certain tokens or token pairs.

• Accumulate to the protocol itself, and not its users.

• Taker fees are a global setting, which the BancorDAO may change via the governance process.

Maker Fees:

• Suggested target a fixed value, paid in the native gas token of the blockchain (or acyclic graph) on which the contract interaction occurs.

• Categorized into 5 discrete types:

  • Strategy/Order Creation,
  • Increase Strategy/Order Funding,
  • Decrease Strategy/Order Funding,
  • Edit Strategy/Order Settings,
  • Pause Trading.

• Each of the initial maker fee quantities on Ethereum is proposed to be 0.0005 ETH (approximately $1).

• Applied protocol-wide, without bias for certain tokens or token pairs.

• Accumulate to the protocol itself, and not its users.

• Each maker fee category is a discrete value which the BancorDAO may change via the governance process.

Ongoing Management:

• No more than 180 days should pass between a formal DAO review process of Carbon’s fee settings, across all its deployments.

• If no changes to the fee settings are warranted, proposals should be submitted for a DAO decision within the 180 window all the same.

• There are no categorical consequences, or recourse actions proposed if more than 180 days should pass between fee adjustments and review; the purpose of this section is for the DAO to signal its acknowledgement and understanding of its responsibilities, and establish a process to assist self-organization.

[mbr]

Recovery of BNT from the Market, and Deficit Repair on Legacy Products:

An objective articulated by the BancorDAO, as ratified in a prior vote, is to return the token balances on V2.1 and V3 to surplus via the recovery of BNT from the market. The DAO determined that Carbon’s protocol-accumulated fees be used for this purpose, exclusively. However, the precise mechanism was not established by the prior vote. With this proposal, the specifics of the BNT burning process are proposed.

[mbr]

Modified Bancor Vortex Contract:

As outlined in the preceding sections, protocol fees can accumulate in any token comprising an active trading pair, as well as the gas token of the blockchain (or acyclic graph) Carbon is deployed on. Bancor’s legacy protocols (V2.1 and V3) have many existing pairs with BNT, and an existing smart contract implementation (the Bancor Vortex) is superbly suited to utilizing the network’s capabilities to recover and destroy BNT. The following illustration is provided to supplant the prior descriptions of the Bancor Vortex.

Assume that after a period of time, the protocol has accumulated 1,234.56 USDC, 65,43.21 USDT, 10,987.65 DAI, 1.23 wBTC and 4.32 ETH in fees. A caller may choose any set of these tokens to swap into BNT via its own liquidity pools, and the Vortex contract offers a small incentive in return. The incentive is equal to 2% of the total recovered BNT, up to a maximum of 100 BNT, which is returned to the caller.

In this hypothetical, the caller has selected USDC, USDT and DAI for the Vortex to use. Each of these token balances are routed through the liquidity pools on Bancor V2.1 and V3. For the sake of demonstration, the simulated USDC, USDT and DAI pools contain precise liquidity amounts of $2M, $4M, and $8M, and their fee settings are 0.2%, 0.2%, and 0.3%, respectively. The simulated BNT price is $0.50. This Vortex call results in the recovery of 37,328.16 BNT.

Since 2% of the recovered BNT amount is > 100 BNT, the burn reward defaults to 100 BNT. The remaining 37,328.16 BNT are destroyed.

It is important to note that the prior vote specified that 100% of the accumulated protocol fees be used to destroy BNT. However, without a caller incentive to interact with the Vortex contract, it is not clear how to maintain a consistent turnover rate. Therefore, this proposal asks the BancorDAO to approve the policy and implementation described above for any token pairs that exist on V2.1 and V3, with the express understanding that a minimum of 98% of protocol fees are used for this purpose (rather than 100%). It is noteworthy that 98% is the worst-case scenario. With reference to the figure above, it is trivial to demonstrate that effective burn efficiencies more than 99% of the protocol fees value are unremarkable.

[mbr]

Clarification - Carbon Vortex Contract:

For clarity - this section of the proposal discusses adapting the Bancor Vortex contract for use with Carbon, where the destination token is BNT, not vBNT, in alignment with the unambiguous precedent already established.

[mbr]

BNT Burning:

BNT Burning Mechanism on Carbon:

• The protocol’s accumulated token balances from taker and maker fees will be prominently displayed on Carbon’s complement analytics dashboard.
• The Bancor Vortex contract will be modified for use with Carbon, and will offer 2% of the exchanged value in BNT, up to a maximum of 100 BNT, back to the caller as an incentive.
• Therefore a revision to the existing precedent is required: “no less than 98%, and up to 100% of the protocol fees from Carbon should be used to recover BNT from the market, and destroy it”, where the difference is attributed exclusively to the effective cost of incentivizing the Vortex contract’s caller.
• Therefore, any protocol fees denominated in a token that is paired with BNT on V2.1 or V3 can be serviced easily by the community.
• Tokens not paired with BNT on V2.1 or V3 will be held in the protocol wallet until an alternative mechanism is proposed that does not have this limitation.

[mbr]

Voting Instructions:

BIP 23 - BancorDAO Authorization of Carbon Deployment on Ethereum Mainnet:

This decision relates to Carbon, as described in the litepaper, white paper, and its ancillary simulation and research materials as they appear on GitHub and JupyLite .

• Vote FOR to agree to the deployment of Carbon on Ethereum mainnet.

• Vote AGAINST to disagree to the deployment of Carbon on Ethereum mainnet.

BIP 24 - Taker Fee Implementation and Initial Settings:

This decision relates to the initial value of the taker fee on Carbon, and is contingent on the authorization of the BancorDAO to deploy the proposed Carbon protocol on Ethereum mainnet.

• Vote FOR to agree to the proposed taker fee implementation, and initial value of 0.2% (20 bps), applied protocol-wide to all tokens and token pairs.

• Vote AGAINST to defeat the proposal, requiring either a future proposal for a new taker fee concept, quantity, or to indicate you would prefer no taker fee at all.

BIP 25 - Maker Fee Implementation and Initial Settings:

This decision relates to the tentative maker fee implementation, where fees are collected in the gas token of the chain Carbon is deployed on, and targets an approximate $1 value (0.0005 ETH) at the time of writing, with its initial deployment on Ethereum.

• Vote FOR to agree to the five proposed maker fee categories, and initial settings of 0.0005 ETH (approx. $1 at the time of writing) for each, which is applied equally to all maker actions, regardless of the position size.

• Vote AGAINST to defeat the proposal, requiring either a future proposal for a new maker fee concept, quantity, or to indicate you would prefer no maker fee at all.

BIP 26 - BancorDAO Authorization of Carbon Deployment on Ethereum Mainnet in Lieu of Maker Fee Implementation:

This decision relates to the approval of Carbon’s deployment at its soonest available date, with or without a finalized maker fee implementation.

• Vote FOR to agree to an initial Carbon deployment, with or without a maker fee implementation.

• Vote AGAINST to require a maker fee implementation prior to the initial release of Carbon.

BIP 27 - Protocol Fee Maintenance Policy:

This decision relates to the proposed constancy requirement and DAO process for maintaining reasonable fee values for Carbon, wherever it is deployed.

• Vote FOR to agree that a maximum 180 day period between proposal submissions to review protocol fee settings for Carbon, wherever it is deployed, should become part of the DAO canon.

• Vote AGAINST to disagree to the fee review policy, requiring either a future proposal for a different policy, or no policy at all.

BIP 28 - BNT Burning Policy and Procedures on Carbon:

This decision relates to the proposed use of the Bancor Vortex to perform exchange between the protocol’s accumulated tokens and BNT for the purpose of returning token balances on Bancor’s legacy protocols to surplus.

• Vote FOR to agree to the proposed Vortex implementation, and the following revision to a prior vote: “no less than 98% and up to 100% of the protocol fees from Carbon should be used to recover BNT for the express purpose of burning it, where the difference between the burning efficiency and 100% is attributable to the cost of incentivizing the contract’s caller”.

• Vote AGAINST to disagree with the proposed use of the Bancor Vortex, and/or the provided revisions to the prior vote, requiring a future proposal.

[mbr]

APPENDIX:

Taker Fees Discussion Section Generator:

from tabulate import tabulate
from decimal import Decimal, getcontext
import textwrap
getcontext().prec = 100

ONE = Decimal("1")
TWO = Decimal("2")

# Curve Parameters
P_a = Decimal("2.3456")
P_b = Decimal("1.2345")
B = Decimal.sqrt(P_b)
S = Decimal.sqrt(P_a) - Decimal.sqrt(P_b)
y_int = Decimal("1000")
y = Decimal("500")
fee = Decimal("0.002")

def print_parameter_table():
    table = (("Curve Parameter", "Value", "Notes"),
             ("$B$", f"{B:.6f}", "The highest ask (y = BASE), or lowest bid (y = QUOTE) boundary metric, depending on context."),
             ("$S$", f"{S:.6f}", "The range width parameter."),
             ("$y_{int}$", f"{y_int:.6f}", "The curve capacity metric."),
             ("$y$", f"{y:.6f}", "The remaining token balance"),
             ("$fee$", f"{fee:.6f}", "The protocol fee setting."))
    print(tabulate(table, headers = "firstrow", tablefmt = "pipe", floatfmt = ".6f", numalign = "right", stralign = "left"))
    print("\n")
    return(None)

def print_summary_table(scenario_1, scenario_2):
    table = (("Scenario", "Taker Sent", "Taker Received", "Maker Sent", "Maker Received", "Protocol Fee Collected"), scenario_1, scenario_2)
    print(tabulate(table, headers = "firstrow", tablefmt = "pipe", floatfmt = ".6f", numalign = "right", stralign = "right"))
    print("\n")
    return(None)

def print_trade_by_target_text(taker_sends_1, maker_sends_1, taker_receives_1, protocol_receives_1):
    text = (f"The taker requests to send exactly {taker_sends_1:.6f} QUOTE tokens to the protocol, all of which is swapped against the maker's order, and returns a value of {maker_sends_1:.6f} BASE tokens. Of the {maker_sends_1:.6f} BASE tokens relinquished by the maker's order, the taker keeps {taker_receives_1:.6f} BASE, and the protocol keeps {protocol_receives_1:.6f} BASE.")
    print(textwrap.fill(text, width = 132))
    print("\n")
    return(None)

def print_trade_by_source_text(taker_receives_2, maker_receives_2, taker_sends_2, protocol_receives_2):
    text = (f"The taker requests to receive exactly {taker_receives_2:.6f} BASE tokens from the protocol. To satisfy the requirements of the maker's order, exactly {maker_receives_2:.6f} QUOTE tokens must be exchanged (ignoring the fee). After adjusting for the protocol fee, the taker must send a total of {taker_sends_2:.6f} QUOTE tokens to the protocol. The protocol keeps {protocol_receives_2:.6f} QUOTE tokens, and the remaining {maker_receives_2:.6f} QUOTE tokens are exchanged with the maker's order for {taker_receives_2:.6f} BASE tokens, which are sent from the protocol to the taker.")
    print(textwrap.fill(text, width = 132))
    print("\n")
    return(None)

text_functions = [print_trade_by_target_text, print_trade_by_source_text]

def trade_by_target(maker_receives):
    maker_sends = maker_receives*(B*y_int + S*y)**TWO/(maker_receives*S*(B*y_int + S*y) + y_int**TWO)
    return(maker_sends)

def trade_by_source(maker_sends):
    maker_receives = (maker_sends*y_int**TWO)/((S*y + B*y_int)*(B*y_int + S*(y - maker_sends)))
    return(maker_receives)

swap_functions = [trade_by_target, trade_by_source]

def apply_fee_trade_by_target(maker_sends):
    taker_receives = maker_sends*(ONE - fee)
    protocol_receives = maker_sends*fee
    return(taker_receives, protocol_receives)

def apply_fee_trade_by_source(maker_receives):
    taker_sends = maker_receives/(ONE - fee)
    protocol_receives = taker_sends - maker_receives
    return(taker_sends, protocol_receives)

fee_functions = [apply_fee_trade_by_target, apply_fee_trade_by_source]
protocol_fees = ["BASE", "QUOTE"]

def perform_swap(input_array):
    scenarios = []
    for i, j in enumerate(input_array):
        print(f"##### *Scenario {i + 1}:*")
        output = swap_functions[i](j)
        fee_adjusted_outputs = fee_functions[i](output)
        scenario_template = [f"{i + 1}", f"{j:.6f} QUOTE", f"{j:.6f} BASE", f"{j:.6f} BASE", f"{j:.6f} QUOTE", f"{fee_adjusted_outputs[1]:.6f} {'BASE' if i == 0 else 'QUOTE'}"]
        scenario_template[2 - i] = f"{fee_adjusted_outputs[0]:.6f} {'BASE' if i == 0 else 'QUOTE'}"
        scenario_template[3 + i] = f"{output:.6f} {'BASE' if i == 0 else 'QUOTE'}"
        scenarios.append(tuple(scenario_template))
        text_functions[i](j, output, fee_adjusted_outputs[0], fee_adjusted_outputs[1])
    return(scenarios)

def numerator(seed_input, fee_multiplier):
    return(seed_input*fee_multiplier*(B*y_int + S*y)**TWO)

def denominator(seed_input, fee_multiplier):
    return(S*seed_input*fee_multiplier*(B*y_int + S*y) + y_int**TWO)

def create_examples(seed_input):
    example_1_scenario_1 = example_2_scenario_1 = example_3_scenario_1 = seed_input
    example_1_scenario_2 = numerator(seed_input, ONE)/denominator(seed_input, ONE)
    example_2_scenario_2 = numerator(seed_input, ONE - fee)/denominator(seed_input, ONE)
    example_3_scenario_2 = numerator(seed_input, ONE - fee)/denominator(seed_input, ONE - fee)
    return((example_1_scenario_1, example_1_scenario_2),
           (example_2_scenario_1, example_2_scenario_2),
           (example_3_scenario_1, example_3_scenario_2))

def write_taker_fees_proposal_section(seed_input = Decimal('10')):
    swaps = create_examples(seed_input)
    subheadings = ("Constant Maker Send and Receive Amounts.",
                   "Constant Taker Receive Amount.",
                   "Constant Taker Send Amount.")
    print_parameter_table()
    for i, input_array in enumerate(swaps):
        print(f"#### Example {i + 1}: {subheadings[i]}")
        scenario_1, scenario_2 =  perform_swap(input_array)
        print(f"##### *Example {i + 1} Summary:*")
        print_summary_table(scenario_1, scenario_2)
    return(None)

write_taker_fees_proposal_section()