Since the launch of EOS, projects have tended to deploy a new contract for every token they want to create. This makes creating and using a token relatively expensive, making it much more difficult for block explorers to discover the available tokens and for exchanges to integrate with them. Furthermore, the lack of a central registry of token symbol names means that scammers can attempt to create “look-alike” tokens with the same symbol but hosted on different contacts. Lastly, if a new token protocol were to be developed, then every contract would have to be updated for compatibility.
I have recently advocated for EOS to become a DAC of DACs. For those who weren’t around the blockchain space in 2013, DAC is the original term I coined for what we now call DAOs. A DAC is a Decentralized Autonomous (Company, Community, Country, Coop, Church, Corporation, Collective). Every DAC has one or more tokens and a governance process to manage those tokens.
A DAC is “Decentralized” because there is no central point of failure and control is distributed over a large number of people. It is Autonomous because it is self-sovereign and fully in control of its own state. It is a Company/Community/Country/etc because it is composed of people organized toward a particular end goal.
There is a huge challenge when combining governance and tokens. If the governance process includes the power to upgrade the code, then there is little the code can do to enforce monetary policy limits. The code could say 1% inflation today, then, tomorrow, the code could be updated to emit at 5% inflation. Then, if the governance process is captured in some way it could grow to 1,000% inflation. The bottom line, it is difficult to combine immutable monetary policy and governance-controlled contract upgrades. Even if a developer divided their code into two contracts and made one of the contracts immutable, there would still be no standardized way to express and compare the issuance constraints across various tokens.
Even if there is no malicious behavior, a bug in the complex DAC code could corrupt the token issuance algorithm and violate the inflation invariants. The more complex a DAC becomes the greater the risk of accidental violations of the intended monetary policy.
A DAC benefits from having its token(s) compatible with as many different services as possible; therefore, I propose an update to the eosio.token contract maintained by the EOS block producers along with a new contract, eosio.symbol, which would auction off token symbol names.
Token Symbol Auctions
This contract would auction token SYMBOL names in a manner similar to EOS premium names. 3-letter symbols would be sold at most 1 per week. There may be many 3-letter symbols under auction at the same time, but only one has the highest price. It must maintain its spot as the highest price symbol for 7 consecutive days before the symbol name is allocated. All other 3-letter symbols would have to wait until the highest priced symbol closes for their turn to be the highest. 4-letter symbols would be sold every 3 days. 5-letter symbols would be sold 1 per day.
6-letter and longer symbols would be auctioned, but unlike the premium symbols, the auction ends after 24 hours without bids regardless of whether or not the token is the highest bid of all 6-letter symbols. This means there is no limit to how many 6-letter symbols can be sold in a day; however, if there is a bidding war over a single symbol it might take a while for the bidding to stop.
When bidding, the next bid must grow from the previous bid by 10%. The prior bidder will receive 38.2% (Phi Ratio) of the increase. This creates an economic incentive to bid on names early and encourages price discovery. This is a similar mechanic to bidding on the original voice.com articles, pixelmaster pixels, or violet.garden posts.
The minimum fee for any symbol could be 100 EOS. This is just high enough to prevent frivolous tokens from being created. The EOS block producers can adapt all of these parameters according to community consensus.
Once a symbol name is allocated, the winner can transfer it, offer it for sale, or send it to the eosio.token contract to actually issue the new token. When it goes to the eosio.token contract the symbol owner gets to specify the token precision, maximum supply, and other token properties.
Token Registry
With an official symbol registry, it becomes possible for DACs to publish an official logo, website, description, and social media handles in one place. This combined with the built-in price discovery, would allow EOS to have its very own version of coinmarketcap.com and help people discover new and growing DACs.
Token Issuance Limits
For example, a token creator could stipulate that tokens will be issued at no more than X tokens per day, Y% per day, or Z% per year (whichever is greatest). From this point, no matter what a DAC governance system wants to do with the token, it would never violate the inflation policy. This makes the token more valuable by increasing trust. It also protects the DAC creator from bugs in code or governance processes.
Another property a token creator could enable is the ability of the DAC to recall tokens. This enables tokens that are not the property of the holder but merely lent to the holder contingent upon the DAC’s continued approval.
The token creator can also specify a call-back that will notify the DAC every time a token is transferred and give the DAC an option to reject the transfer and/or perform other calculations.
All of these limits could be restricted over time but not increased, while the ability to recall tokens could be initially granted and then given up.
Fee-Based Transfers
With the updated eosio.token contract, users will no longer have to rent CPU/NET nor buy RAM in order to use any tokens. Instead, a minimum fee will be charged on all transfers of any token (assuming they use the updated interface). The new eosio.token contract will remain backward compatible with existing behavior for those who still want to bring their own resources. The minimum fee, as set by block producers, would be sufficiently high to not have to worry about CPU or RAM costs and yet still be lower than fees on other blockchains.
Token Liquidity
Liquidity, such as that provided by the Bancor algorithm, is a key need for most tokens. Having an official EOS contract for creating and funding an automated market maker would allow the EOS network to capture fees and free projects using tokens from any liability associated with hosting their own market maker. Building the market maker into the eosio.token contract allows the token contract to easily convert fees from other tokens into EOS. Transfer fees are used to incentivize participants to provide liquidity to market makers above and beyond a percentage trading fee.
An extra feature of the proposed token liquidity system is the ability to add tokens to one side of a relay without issuing shares in the pool. This allows DACs to subsidize liquidity in a cost-effective manner.
This creates a major difference from other implementations of Network Provided Liquidity where the network owns the tokens within the pools. The net result should be an amplification of the liquidity provided. Consider the difference between the network seeding the Market Maker with a one-time injection vs. the network subsidizing market participants who provide funds to the Market Maker over time.
In the traditional approach, a DAC would auction off tokens to fund a market maker. In the new approach, a DAC can provide an incentive to market participants who provide liquidity. This multiplies the liquidity, minimizes downside risks, and prevents one DAC from having a treasury of another DACs tokens which could be stolen or mismanaged. It also minimizes the potential for DACs to be considered a collective investment scheme because they don’t have any assets under management.
The easiest way to understand the difference is by analogy. Suppose you want to build a big house (relay) and you have an income of $1,000 per month to purchase building resources. In this case, you must live in a small house and build it over time. Now suppose you took that same $1,000 per month and used it to rent an existing house. Free market competition would lower the cost of the housing allowing you to rent the biggest possible house for the money. Now you could afford to live in a house worth hundreds of thousands of dollars immediately. More importantly, you are not responsible for maintaining the house nor insuring it against fires!
Likewise, a DAC that buys equity in their market maker at $1,000 per month takes a long time to build up liquidity; however, that same DAC that opts to pay $1,000 per month to rent liquidity can have an order of magnitude more liquidity immediately.
Because of the potential to rent the liquidity, liquidity providers must commit to at least 6 days of liquidity in place of the rent. Without the lockup period, people could time their deposits into the market maker just before the rent is paid and withdraw it immediately after. This lockup period also opens the door to future liquidity-dependent lending opportunities.
The other significant effect is that the DACs transfer the price volatility risk to market participants in exchange for a “fixed cost”. The DACs recognize the market participants for the ongoing real value of having liquidity between two currencies and don’t need to worry about managing or liquidating DAC-owned market maker tokens.
This means that both sides of the liquidity partnership between DACs have no ongoing interest in the market maker and may choose to increase or decrease their contribution to the liquidity providers independently. In fact, it allows unilateral liquidity subsidies. This makes for a smooth transition when a Mother DAC wants to kick a Child DAC out of the nest once it is mature enough. It allows either party to remove subsidies without disrupting the market maker. It frees both DACs from having to make rapid decisions with respect to pulling liquidity in the event the counterparty adopts an exploitive monetary policy.
Both DACs only risk the recurring daily inflation rather than a large pool of funds. Meanwhile, if the market sees a DAC proposing changes to its monetary policy, the market participants will react to rapidly adjust the price and/or liquidate their market maker tokens. This prevents large DACs from having to rapidly respond to changes in other DACs.
For example, if Eden on EOS were to issue a community token, then the EOS Network Foundation could subsidize the community’s efforts by simply directing some EOS inflation to the market maker. This would reward EOS holders who choose to fund liquidity to the Eden community.
Future Expansion
Any token that leverages the eosio.token contract to issue and manage its token will be able to automatically take advantage of new capabilities such as pay-to-key and privacy features. This would enable wallets without requiring users to create expensive accounts. It could eventually make all tokens from all DACs compatible with Bitcoin or Ethereum style RPC interfaces.
All of these tokens will see an increase in liquidity on the EOS network and bring value to EOS.
Summary
With the proposed changes, EOS would have a native, community-managed, decentralized exchange that supports user-issued tokens without having to deploy any contracts nor write a single line of code. This is the first step into turning EOS into a DAC of DACs!
Token Creation & Liquidity for DACs on EOS was originally published in EdenOnEOS on Medium, where people are continuing the conversation by highlighting and responding to this story.