last update: July 9th 2022 Main_Menu


The Evrmore DeFi Roadmap


Bitcoin's protocol and UTXO model have proven to be wonderfully secure. Ravencoin built on that base by adding simple enhancements to natively support assets. Evrmore plans to add similar enhancements allowing it to support partial order fulfillment, stop-limit orders, interest rates, options and futures contracts, and many other useful financial primitives. This will enable Evrmore to support much of the DeFi economy without the security risks inherent in overly complex smart contracts.

  • Thank you Satoshi Nakamoto and all the Bitcoin developers for Bitcoin
  • Thank you Bruce Fenton and Tron Black and all the Ravencoin developers for Ravencoin

How long can Ravencoin adapt and become stonger? Quoth the Raven: "Evrmore"
(Not quite Edgar Allan Poe)

Note: The following text and linked documents describe the design enhancements envisioned for Evrmore at this time. The intent is to convey a sense of what is planned for Evrmore, how it builds on existing technology, and why it is superior in simplicity and security to the many overly complex smart contract platforms which have emerged to serve the DeFi market. The order of implementation is still under review, and details of the protocol will no doubt evolve as development work progresses.

Documents:

The Evrmore DeFi Roadmap consists of 3 documents:

  1. This document including
    1. Evrmore Guiding Principles
    2. Evrmore  Roadmap Summary
    3. Evrmore Preliminary Details of Proposed Changes
  1. Evrmore Support for 2-step On-Chain SIGHASH_SINGLE Atomic Swaps
    1. Level-1 DEX Support
    2. Level-2 DEX Support
    3. Level-3 DEX Support
      1. Oracle-guided trading
      2. Implementing the Price Oracles
  1. Vault Assets- Fungible Assets with Native EVR Face Value
    1. Overview
    2. Naming Rule
    3. New data maintained by the nodes for each fungible Vault asset or Vault subasset
    4. Vault-related RPC Commands
    5. Vault-related RPC Command Details
    6. Q&A
    7. A Simple Use Case Example
    8. EvrmoreVault-Plus


Evrmore Guiding Principles:


Vision: Extend the Ravencoin architecture with simple intuitive features designed to make Evrmore an excellent platform for DeFi. When core DeFi concepts become standardized, simple native support should be hard-coded into the Evrmore protocol.

Ecosystem: Whenever possible, add new ways for Evrmore users and nodes to benefit financially from use of the chain. Successful participation in DeFi requires a rich ecosystem of participants earning money in a variety of ways.

Diversity: Support for new functionality in Evrmore means changes to the protocols, data structures, and RPC calls as well as changes to the consensus rules in raven-qt/ravend. But it does not require GUI support in raven-qt for all its features because there will be far too many options and functions to support them all. GUI support and related services are best provided by ecosystem vendors through additional applications or websites on a for-profit basis. Just as TCP and HTML provide the low-level support on which internet businesses are built, the various low-level blockchain features of Evrmore will be able to support a range of product and service vendor businesses.

Scaling: Adding new data fields to the transaction and UTXO specification will increase the on-disk and in-memory storage requirements and the sync time for full nodes, and therefore should be given appropriate consideration. However, the required increase to support most financial primitives is expected to be modest. Unlike account-based systems such as Ethereum or extended-UTXO systems such as Cardano, the changes will not be storing arbitrary persistent system state. Hence, radical changes in support of scaling are not expected to be necessarily for quite some time. Long term, technologies such as Utreexo or Flyclient could be adopted to reduce storage space requirements. For transaction throughput, larger block size has been demonstrated as an effective measure by a number of bitcoin fork projects. Beyond that, technologies such as rollups and sharding as being used or planned by Ethereum, would be equally valid and simpler to deploy on Evrmore.

Governance and Funding: The Evrmore team respects the ethos adopted by Bitcoin- decentralized, permissionless, cautious progress.  Fiercely protective of the autonomy and responsibility of individual participants. But when participants in a market or members of a project choose to be cooperative and voluntarily trustworthy, performance and competitiveness increase. Cooperation and compromise can augment blockchain enforced compliance. Evrmore makes somewhat different choices than Ravencoin in order to be business-friendly, to provide stable financial funding for salaried software developers, and to respect the rights of trademark holders.



Evrmore  Roadmap Summary:
The following changes are proposed for the Evrmore blockchain, consensus, and related code.

- Add Asset tolls support: See "Asset_Tolls" below for details.
  • Each asset will be given a metadata field indicating a required per-asset Toll qty of EVR (or % of face value for Vault assets) paid to the asset owner whenever that asset is transferred.
  • The transfer of an asset from one address to another address in the same wallet could be used as a method of requesting and paying for a service.
  • Tolls can be used as a way to pay Liquidity Providers who agree to lock up valuable assets on other chains in order to provide Wrapped tokens for trade on Evrmore.
  • Tolls can be used to pay a royalty to the original creator of an NFT (unique asset) whenever the NFT is moved from one address to another

- Add a second IPFS field to asset metadata. See "Second_IPFS" below for details

- Add Expiring Unique Assets (expiring NFTs): See "Expiring_Unique" below for details.
  • Unique assets can be given a lifetime ranging from 1 hour to eternal. The price for creating the asset will vary from 0.05 EVR (1 hour life) to 5 EVR (eternal life).
   
- Add Level-1 DEX support: See details HERE.
  • Enhanced support for 2-step SIGHASH_SINGLE|SIGHASH_ANYONECANPAY On-Chain Atomic Swaps by adding Asset_Name/Ask_Qty/Signature fields to every UTXO to communicate the desired trade. This makes it possible to do offer tracking and broadcast on-chain as a way to bootstrap initial DEX activity without requiring a new database of communication channel. DEX trading can also be taken off-chain to speed up activity and to save transaction fees. 

- Add Asset Consumption support: See "Consumable_Assets" below for details.
  • Assets can be destroyed as well as issued. This capability is important for on-chain tokens which represent off-chain assets, such as wrapped-bitcoin, for which the number of tokens in existence should be adjusted up or down to match the number of bitcoin in escrow. As another example, assets can be issued as one-time-use utility tickets which are consumed (destroyed) when used. This is particularly useful when used with expiring unique assets (#11 below).

- Add Covenant support: See "Financial_Derivatives" below for details.
  • Covenants will allow Evrmore script to support more complex smart contracts within limitations. In particular, an options contract or futures contract on the sale of a valuable token or stablecoin can reside in a separate contract token which can be traded separately from the value token. Recent research on the necessary contracts and the mechanism to link the contracts to a tradeable token separate from the underlying value asset token indicate that this is possible using the covenant opcode extensions which have already been in production use for a few years on Blockstream's Liquid Network blockchain.

- Implement Evrmore Vault Assets.
  • Vault assets are assets which have a "face value" of EVR and can be "melted" to extract the EVR.
  • Vault assets can pay a daily interest rate as a % of the "face value" or a fixed amount of EVR. Or they can cost a daily demurrage rate as a % of the "face value" or a fixed amount of EVR.

- Add support for Schnorr signatures, Taproot, and Tapscript
  • Schnorr will provide performance and privacy improvements. Taproot and Tapscript, especially when combined with Covenants and MAST (Merkelized Abstract Syntax Trees), will allow more powerful scripting


- Add Level-2 Enhanced DEX support: See details HERE.
  • On-chain 2-step Atomic Swaps can support "Partial Order Fullfillment" with specified "Granularity". They can also support different order types: Precise(Legacy)/Market/Stop/Limit/Stop_Limit/Stop_Market. This primarily requires only new data fields in the UTXO definition and a change in the related consensus rules. Independent vendors are responsible for matching offer and seller half-transactions for submission to the miners, for which those vendors can make a profit on the spread.
  • It is interesting to note that most of these features and Evrmore-like asset trading were proposed as a bitcoin extension by Mark Friedenbach in 2013 for his Freicoin project, but the project was dropped when Adam Back convinced Mark to become a co-founder of Blockstream instead.
   
- Add Oracle DEX Support:  See details HERE.
  • On-chain 2-step Atomic Swap support for Oracle-based price discovery can provide another vast improvement in price discovery and flexibility. Markets use many different methods of price discovery. Some use traditional off-chain bid/ask order books. DeFi projects are experimenting with a variety of Automatic-Market-Maker algorithms. Oracle support allows the offer creator to select any Oracle of his choice based on the Oracle's public key and signed price reports. Only the price quote and signature format need to be standardized, and a few changes need to be made to the UTXO definition and consensus rules.  The buyer can choose an Oracle from any independent vendor who provides that service on a for-profit basis. New technologies such as "Gravity Protocol" are expected to make Oracles much more common.

- Add explicit support for PSET (Partially Signed Evrmore Transactions)
  • This will enable more powerful off-chain and Layer-2 financial protocols.

- Implement a 2-way Peg BTC-Relay to provide Wrapped-BTC liquidity for trading.
  • EVRWBTC tokens can be issued on the Evrmore blockchain specifying a non-zero toll, so the liquidity providers earn a toll every time a EVRWBTC token is traded.
  • Technically, the implementation is similar to a P2SH HTLC Cross-chain Atomic Swap. During a Peg-in it locks up BTC on the bitcoin blockchain and issues an equal number of EVRWBTC on the Evrmore blockchain. During a Peg-out, the EVRWBTC must be consumed and the BTC are returned on the bitcoin blockchain. If BTC and EVR had sufficiently powerful scripting, this could easily be fully automated as a Relay. Since that is not the case, and to improve security, many projects implement it as a Trusted Federation as done by Blockstream for LBTC on the Liquid blockchain, by Rootstock for RBTC on RSK, and by WBTC for Ethereum. In some juridiction, this solution creates KYC requirements for the users. Other projects use more complex solutions to fully automate the Relay such as by running both EVR and BTC chains and transfer code in a Trusted Execution Environment (as done by pTokens for pBTC) or running a Secure Multi-party Computation on distributed VMs (as done for Ren). The maturity of the available solutions and regulatory changes relating to stablecoins will dictate the best solution.

- Implement a 2-way Peg Ethereum Relay to enable Wrapped ERC20 tokens on Evrmore. Same considerations as for BTC-Relay.

- Implement Relays to additional popular blockchains: LTC, DOGE, BCH, Cosmos



Evrmore Preliminary Details of Proposed Changes:


  • Assets with owner-required Toll (trading fee):
    • Each asset will be given a metadata field indicating a required per asset Toll qty of EVR (or % of face value for Vault tokens) paid whenever that asset is transferred. Another metadata field specifies the address to which the payment is made.
    • The value of Toll amount and Toll address fields will be selected at asset creation time, Toll amount and Toll address can be changed during reissue unless Toll Amount is zero, in which case it will always be zero. 
    • There is no toll charged for a "Consume" operation (consumes are not transfers), so a Wrapping token which has a toll can be "cashed in" for its associated value asset by consuming it without incurring a toll.
    • The Toll is paid as a EVR output to the Toll address. Meeting that requirement is enforced as a consensus item by all nodes.

  • Add a second IPFS field to asset metadata:
    • One of the IPFS fields will be treated as immutable once the asset has been issued, even during reissue. The second IPFS field will always be mutable, even for unique assets and other non-reissuable assets (needs additional RPC and GUI support). For backward compatibility, legacy assets which are unique or otherwise non-reissueable will have their IPFS mapped to the non-mutable field, while legacy reissueable assets will have their IPFS mapped to the mutable field. See Ravencoin Issues #336 and #547 for the application uses driving this feature.

  • Expiring Unique Assets:
    • Unique assets will be given a lifetime when they are created. There is a minimum lifetime (1 hour) and a minimum cost (0.05 EVR) to prevent spam and to limit computational load. All legacy issued unique assets will be treated as infinite lifetime unique assets. Only a fixed set of lifetimes and associated prices will be supported.
    • Proposal:    1hour/0.05 EVR,  1day/0.1EVR,  1week/0.2EVR,  1month/0.5EVR,  3months/1EVR,  6months/2EVR,  1year/4EVR,  infinite/5EVR
    • Such assets could represent concert tickets (serial numbered with assigned seating) which expire after the concert, or 1-hr worth of VPN service, or a 10-year bond.
    • The expiring nature of such an asset would also make it ideal for representing an expiring option or futures contract. Such securities exhibit unique pricing behavior because expiring option contracts trend to a value of zero at the time of expiration while expiring futures contracts trend toward the spot market price.


  • Consumable Assets:
    • An evrmore-script opcode will be created for "Consume()" for any asset. Note that while an asset can be "burned" by sending to a non-spendable address, there are advantages to being able to destroy assets and remove them from the UTXO..
    • If used for voting, then destruction can be done after voting is completed. More generally, If the asset is a utility token, then the token could be consumed after it is used to obtain the service.
    • If the token represents a "wrapped" asset such as for EVR-Wrapped-Bitcoin, then this provides a way for the existing supply of EVR-Wrapped-Bitcoin tokens to be made equal to the number of Bitcoins locked on the bitcoin blockchain, which could vary up or down.
    • Adds a Consumable(T/F) metadata to every asset which determines whether to allow the Consume() asset function. Legacy assets have Consumable='F'.
    • During reissue, Consumable(T/F) can be changed from T to F but never from F to T
    • Note that this makes ^Vote assets unnecessary, and the "^" symbol is used to identify Vault asset instead
    • Owner tokens may not be consumed. Therefore there is no concern about whether a subasset name exists below any given asset name.

  • Trading of Financial Derivatives:
    • For DeFi, it is critical to be able to trade in Financial Derivatives such as Options Contracts and Futures Contracts
    • This capability is also a great motivator to attract Liquidity Providers. People who lock up their bitcoins on the bitcoin blockchain and accept EVR-WRAPPED-BTC assets on the Evrmore blockchain could then write and sell covered Options and Futures Contracts against their bitcoins in order to earn income.
    • For this to work, it must to possible to freely trade a token which represents the Derivative Contract separately from the token which represents the underlying value asset.
    • Implementing this requires "Covenants"
    • Recent research on the necessary contracts and the mechanism to link the contracts to a tradeable token separate from the underlying value asset token indicate that this is possible using the covenant opcode extensions which have already been in production use for a few years on Blockstream's Liquid Network blockchain as described here:
    • Additional details of how the new Opcodes support Covenants on the Liquid Network is described here:
    • Blockstream's Liquid Network directly uses the open-source code of the Elements project according to: https://docs.blockstream.com/liquid/technical_overview.html which was referred to by: https://www.blockstream.com/liquid/
    • So Elements on github (which is a bitcoin code fork) appears to contain the needed code changes to support the Financial Derivative covenants.
    • The contracts as described do not appear to require SegWit. Further work will be required to verify the work of Dmitry Petukhov and to implement it on Evrmore. But the review of Dmitry's work by Russell O'Connor from Liquid Network is encouraging.



Copyright 2022 by Hans Schmidt