This concept was conceived and documented as part of the Chorus One entry into the Seoul Hackatom (19-21 July 2019). A formal whitepaper can be written on the concept, provided it is well received by the wider community. Let us know what you think on the Chorus Telegram channel.
Other resources:
A decentralized payment processor for the multi-zone ecosystem
2.1: Individual Token Aggregation (ITA) for popular payment tokens
2.2: Basket Token Aggregation (BTA) for niche payment tokens
2.3: Auction design in the hackatom entry
2.4: Hackatom prototype overview
2.5: Offering a reward auction service to other zones
3: Potential issues with the concept and their mitigations
3.1 Transaction costs for auctions
3.3 Adverse interactions with delegation vouchers
3.4 A delegation timing attack
4: Open problems and avenues for future research
4.1: Interaction with delegation vouchers
4.2: Evaluation of Dutch auctions for individual token aggregations
4.3: Evaluation of Vickery auctions
Cosmos is moving into an ecosystem of multiple zones with the impending launch of IBC (Inter Blockchain communication). In this ecosystem, the Cosmos Hub will serve the following roles:
For all of the above, the Hub can be considered as a service provider for the end users of the customer zones. It is readily apparent that end users would like to pay transaction fees for the Hub services in the native token of the zones. For instance, a user of the Kava zone would prefer to pay for Hub services in neutrons, the native tokens of the Kava zone, since those might be the only tokens they hold. Extrapolating this need across the users of all zones, a situation arises where the Hub is paid for its services in an ever-changing basket of zone tokens. It makes sense for the Hub to entertain the diverse user needs of the zone users in order to entice greater transaction volumes and business through the Hub.
Such a scenario poses a challenge for the delegators of the Cosmos Hub. Transaction fee and other fees paid by zone users appear as interest for the users of the Cosmos Hub on their atom holdings. In a multi-zone future, this interest would consist of lots of different tokens complicating the tax statements of the delegators of the Cosmos Hub. In addition, delegators of the Cosmos Hub will need to bear responsibility of liquidating lots of different tokens received as transaction fees. Small delegators are badly impacted. Someone that has delegated 100 atoms to Chorus might need to liquidate $0.10 worth of neutrons, $0.50 worth of Regen, $2 worth of wrapped bitcoin and so on in a typical month. If they do not liquidate received transaction fees, they must pay capital gains taxes, or deduct capital gain losses, when token price values fluctuate in the future. Clearly, this complexity is undesirable.
Validators of the Cosmos Hub are also impacted by this issue because they will make their commission fees in such a basket of zone tokens. However, validators are better equipped to deal with revenues in multiple tokens as a consequence of their normal business. Nonetheless, they would prefer if all of the revenues from a particular network were made in a single token rather than a basket of tokens for the purposes of accounting simplicity.
Ergo, for both of these constituencies, it would be preferable to receive rewards in the form of atom interest only. Babelfish seeks to translate the totality of transaction fee revenue made by the Hub into atoms, and distribute these atoms to the delegators of the cosmos hub as interest. One can imagine Babelfish as solving the same need serviced by payment processor forms such as Visa and Mastercard. Any merchant prefers to receive all of their payments in a single currency of choice, such as USD. But they also want to enable their customers to pay in a wide range of currencies. The role of the payment processor is to translate an incoming diverse basket of currencies into a single destination currency for the merchant. Replace the role of the merchant by the delegators of the Cosmos Hub, and the role of the customer by the users of the zones to create a perfect analogy between these two scenarios.
The key idea is that the Cosmos Hub should have the ability to aggregate transaction fees across periods of time (defined as a certain number of blocks) and be able to auction off the collected transaction fees (the fee pool) in a batch. Once the transaction fees are auctioned off in a batch in exchange for atoms, atom amounts are distributed to the validator and the delegator set of the Cosmos Hub via atom inflation.
The aggregation of transaction fees happens in two different ways:
This section walks through the general design of the component by considering the case of cBTC, the Bitcoin derivative issued by the Bitcoin Peg Zone. The overall design works the same way for other frequent payment tokens. The Hub could run auctions, for the collected cBTC, every 100k blocks (roughly one week). The Hub blockchain is divided into epochs of 100k blocks, with each epoch hosting its corresponding auction for cBTC.
During each auction epoch, the amount of cBTC contributed to the auction pool by the individual validators is tracked. For example, the auction epoch between block 500k and 600k could have collected 1 cBTC as transaction fees (this cBTC is what shall be auctioned off). These individual contributions will be used as weights in the redistribution of atom rewards once the cBTC auction is complete.
The auction mechanism is implemented as a first price open bid auction. Bidders are required to bid the amount of atoms they are willing to exchange for the individual token transaction fee pool. In order to create a bid, the equivalent number of atoms must be escrowed by the bidder to the protocol. The protocol only requires the escrow of the current highest bidder’s purchase price (in atoms), and frees up a bidder’s escrowed atoms when a higher bid appears. Auctions can run for a suitable length of time, such as 15k blocks (1 day). The auction is cleared by accepting the highest bid for the transaction fee pool. Proceeds from the auction are distributed to the validators and their delegator sets, in proportion to the weights described in the previous paragraph. This mechanism is designed to create perfect fairness for all of the validators - they receive an amount from the auction which corresponds exactly to the amount of transaction fees they contributed to the protocol, in the particular token being auctioned off.
In case a particular auction for an epoch fails due to lack of bids, the transaction fee pool is forwarded to the next auction for that particular token. The most common reason for failure of a particular auction could be the paucity of rewards in a particular epoch. This mechanism ensures that the pool will grow to a larger size in the next auction epoch, and have a greater chance of success. In the matter of a few periods, auction success probability therefore approaches 100%.
It is important to note that this mechanism preserves the ability for the individual validators to set their own transaction fee acceptance levels. Some validators might choose to only process transactions paying greater than 0.001 cBTC, and others might be fine with transaction fees containing 0.00001 cBTC. The design also leaves open the possibility for the governance of the Cosmos Hub to impose some kind of minimal transaction fee floor for a particular payment token. Such transaction fee floors could be more economically efficient for the Cosmos Hub in extracting transaction fees from its users; compared to giving full freedom to its validator set to decide on transaction fee levels. However, such designs based on economic efficiency considerations are out of the scope of the Chorus Hackatom entry.
For niche payment tokens, the previous mechanism could have unnecessary overhead because all individual tokens require their own auctions every 100k blocks. It is expected that the total transaction fee pool from all niche tokens would be quite small. Hence, such tokens are bundled together in one transaction fee pool, and auctioned off as a bundle. Bids are received in atoms for the particular bundle of an auction epoch, and sold off to the highest bidder in a first price open bid auction. Atom proceeds received from the auction are distributed to all of the validators (and their delegator sets) in proportion to the amount of stake held by the validator at the end of the auction.
The astute reader will notice that this mechanism could create some unfairness for the particular validators that have contributed greater amounts of a niche token in the transaction fee pool. Another type of unfairness would be that validators that were slashed, lost voting power or were decommissioned in a particular auction epoch will not receive their fair share of the transaction fee contribution. The proposal tolerates this unfairness because the total amounts at play here is expected to be quite low. The quantum of unfairness is also pretty insignificant. The main purpose of this protocol component is to be able to signal to the governance of the Cosmos Hub if a particular payment token is becoming more popular, and therefore deserves its own individual token auctions. Since this mechanism can be totally permission-less, and allows the validators to accept any token they choose, it is an important component to ensure that the Hub is able to locate emergent business opportunities in new zones. The overall trade-off in creating small amounts of unfairness for Hub validators in order to allow the Hub to locate new business opportunities is judged to be a good trade-off in the Chorus Seoul Hackatom entry.
When a particular token in the basket becomes more popular for transaction fee payment, there can be a governance proposal to shift the token to having it’s individual auction, as per Section 2.1. This delivers the option to subjectively judge whether the protocol overhead of creating complete fairness is valuable enough for an individual token, and evolve accordingly.
This section covers the overall design of the auction, as implemented in the Hackatom prototype. The auction is a first price open bid auction with a protocol escrow of the currently highest bid atom amount.
In order to make the design manageable for implementation in a 2-day period, we took the following liberties with our design:
One of the hidden upsides of such an implementation for the Cosmos Hub, is that it creates a new business opportunity for the Hub and it's delegators. This problem of requiring to translate multiple incoming transaction fee tokens to a singular recipient token will be faced by all of the zones in the Cosmos ecosystem.
If the Hub has the most solid implementation of Babelfish, it can offer these auctions as a service to all of the other zones. Zones should be able to send, over IBC, baskets of transaction fee tokens to the hub and specify the destination token. The Hub would then liquidate all of the component tokens into the destination token, and forward the token back to the origin zone over IBC. In short, this implementation could open the door for the Cosmos Hub to become the auction zone of the Cosmos ecosystem.
Any market mechanism for the conversion of one asset to another imposes a transaction cost on the party requesting the conversion. While blockchain technology reduces the transaction costs of asset conversions, it does not eliminate them. For Babelfish, a set of important questions are:
It is not possible to do a quantitative analysis of (1) in the hackatom. Lacking a quantitative analysis of (1), it is arduous to answer (2) in the absolute.
Subjectively, the transaction costs are worth the benefits. An alternative design to Babelfish would be to forward the baskets of tokens received as transaction fees to the delegators. Such a design would superficially avoid the transaction costs. Underneath the facade, it's really transferring the transaction costs to the delegators. Delegators would bear costs while holding and liquidating assets on decentralised or centralized exchanges. The number of delegators on the cosmos Hub is expected to be >100k. Transaction costs plus mental costs, associated with liquidation and dealing with accounting consequences for >100k individuals, are orders of magnitude greater than the transaction costs borne by the protocol to run periodic auctions. A second consideration is that the Hub will liquidate transaction fees at volume while individual delegators will liquidate them in smaller buckets. Volume base liquidation is always more efficient than fractured liquidations. Hence, Babelfish actually saves on transaction costs when the entirety of the delegation ecosystem is considered.
The second question concerns the existence of sufficient liquidity for auctions to succeed with a high enough probability. There are a few design elements in the hackatom design to increase liquidity:
Babelfish changes the transaction fee reward pattern of validators and delegators from a continuous, per-block, model to a step function model, wherein the rewards are incremented once every auction epoch.
Therefore, between auctions, the full intrinsic value of a delegation voucher is not expressed in the conversion ratio between the voucher and the underlying atoms. The value that is currently trapped in the to-be-auctioned pool can be observed on-chain, but needs to be priced off chain when vouchers are traded. Therefore, perfectly accurate pricing of delegation vouchers can be done only by off-chain agents. An on-chain agent will be able to approximate the atom value of a delegation voucher to high level of accuracy, but will not be perfectly accurate. This deficiency could hamper some (as yet unconceived) smart contract applications on the Cosmos ecosystem.
This limitation may not be material due to the following reasons:
This section is only relevant if the underlying delegation system of the protocol is modeled after the Berlin design of delegation vouchers. These delegation timing attacks are not relevant if the underlying delegation system, is akin to the current Cosmos Hub model.
Babelfish Introduces the element of timing to delegations in order to receive delegation vouchers. Delegations done towards the end of an auction epoch get a slightly better conversion rate to underlying atoms than those delegated at the start of an auction epoch. The question is whether such timing can be used to build a trading bot that extracts value from the protocol, and creates an unfair system for the delegators of the Cosmos Hub.
Our analysis suggests that, as long as the auction epochs are smaller than the 21-day unbonding period of the Hub, a profitable trading strategy cannot be created to exploit delegation timing. This is because extraction of rewards would require the delegation timer to unbond, receive free atoms, and then sell those atoms in the open market. The 21-day unbonding results in a loss of interest rewards from the Hub ecosystem, and therefore represents the carry costs of the trade. As long as the carry costs of the trade are higher than the exploitable value of delegation timing, the attack is not practical. Making the carry costs larger is one of the design parameters of Babelfish. This translates into limitations for the Babelfish designer to indefinitely reduce the frequency of auctions.
One of the significant downsides of the Berlin implementation for delegation vouchers is that that design fails to work in a multiple fee token setting. In particular, the Berlin implementation allowed some delegators to cheat other than delegators by timing their delegation transactions in an adversarial manner.
Sunny Agarwal, from Sikka, proposed a further iteration to the Berlin design to fix that problem in this post. Babelfish is an alternative solution to the same problem from the Chorus team. With Babelfish, the Berlin implementation of delegation vouchers is consistent with a multiple fee token world. Trade-off analysis between Sunny’s design and Babelfish remains a rich research avenue for the future.
Dutch auctions could provide a superior design for individual token aggregations. One of their key advantages over our auction implementation is that bids can be made on fractional amounts of transaction fee pools. In the Chorus hackatom implementation, all bids must be made for the entire pools.
This advantage is matched by the downside of the complexity of Dutch auctions. Dutch auctions are particularly unfriendly to human participants that must wait for prices to decline to a certain level for bid placement. However, it is likely that the bidders in such actions will be bots (perhaps run by validators?) rather than humans. If that assumption is correct, Dutch auctions could be the most optimal option for this use case.
Vickrey auctions are sealed-bid auctions where the highest bidder wins, but the price paid is the second-highest bid. These auctions have better game theoretic properties than our current design, as there is a greater incentive for bidders to reveal their true price preferences.
However, Vickery auctions have greater implementation complexity due to their sealed bid nature. Sealed bids require a separate system of collateral management for entry into the auction. The hackatom implementation avoided Vickrey auctions to ward off this complexity. However, this complexity could be the right trade-off for a production solution.
In this whitepaper and hackatom entry, we have considered an incipient problem that will surface once IBC is released and other zones connect to the Hub. Babelfish translates the totality of transaction fee revenue made by the Hub into atoms, and distributes these atoms to the delegators of the Cosmos Hub as interest. Babelfish solves the same need serviced by payment processor forms such as Visa and Mastercard - the ability to accept payment in a wide range of currencies while needing to deal with the complexity of a single currency on the recipient’s end. Future iterations of the Cosmos Hub require Babelfish, or competitor solutions to the same problem in order to reach their full potential in a multi zone staking ecosystem.
We hope you enjoyed reading this article. For further discussions, please feel free to reach out to the Chorus team on the following media: