Daniel (Dan) Larimer, who’s now on a mission to create “free market” solutions to “secure life, liberty, property, and justice for all” (http://edenoneos.com, http://hive.blog) after working as CTO at Block.one and being involved in various other ventures like Steemit and BitShares, says that it’s time to upgrade the EOS token contract to “enable users and DACs to issue tokens, reserve symbols, and provide liquidity without having to deploy any contracts.”
It's time to upgrade #EOS token contract to enable users and DACs to issue tokens, reserve symbols, and provide liquidity without having to deploy any contracts. Read my latest blog post to learn more!https://t.co/ubrJ0KGTAd
— Daniel Larimer (@bytemaster7) January 7, 2022
Larimer writes in a blog post that since the launch of EOS, projects have “tended to deploy a new contract for every token they want to create.”
According to Larimer, 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.”
He also mentioned that 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.” And lastly, if a new token protocol were to be developed, then “every contract would have to be updated for compatibility.”
He also noted:
“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.”
He further explained:
“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.”
He added that it’s “a Company/Community/Country/etc because it is composed of people organized toward a particular end goal.”
Larimer believes that there’s a major 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,” Larimer claims.
He adds that 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.”
According to Larimer, 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.”
He also noted that 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,” he explained.
According to Larimer:
“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.”
Larimer further noted:
“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).”
He added that 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,” he explained.
He also mentioned:
“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.”
He added:
“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.”
According to Larimer, 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.”
Larimer added:
“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.”
He concluded:
“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.”
