Hans Schmidt :  December 2021

hans_schm1dt@protonmail.com


Evermore: A Defi Roadmap for Ravencoin

Update 2021-12-13:
The information documented here was proposed to the Ravencoin community in August 2021 as a new roadmap for the continued development of the Ravencoin blockchain.

This proposal as documented here includes not only extensive technical details of the proposal, but also an integrated financial mechanism which imposed taxes on various transaction fees in order to fund software development. The technical roadmap was well received by the community, but transaction taxes were viewed as being inconsistent with the spirit under which Ravencoin was founded.

I have chosen to leave the complete documentation intact (both technical protocol enhancements as well as the financial mechanism). But the functionality improvements stand on their own, and can be evaluated independent of any funding plan or no funding plan.


Evermore is not a new coin. It is not a chain split. It is not a code split. It is an extended roadmap for Ravencoin which would make Ravencoin much more powerful. It IS Ravencoin - on steroids.

Ravencoin is wonderful blockchain asset technology. It is elegant. It is simple. It is secure. It can be made much more powerful.
Bitcoin's simple protocols and UTXO model are Ravencoin's strengths, to which Ravencoin adds simple enhancements to natively understand assets. Similar enhancements could provide it with an understanding of partial order fulfillment, stop-limit orders, interest rates, options and futures contracts, and many other useful financial primitives.

The entrenched Wall Street oligarchs and their political puppets have succeeded in preventing the wide-spread emergence of KYC Security Token Offerings (STOs) as anticipated in the original Ravencoin whitepaper and roadmap. That mainstream vision by Bruce Fenton and Tron Black is dead (or at least dormant). If Ravencoin wants to prosper, this new roadmap could make it a leader in Defi 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
  • Now let's upgrade again....

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

Note: Evermore describes a set of ideas which I have compiled over the past few years. During that time, as I observed Defi grow rapidly in capability and volume but without Ravencoin's participation, I kept notes on how Ravencoin might be extended to add many of the needed capabilities. But Evermore does not exist. It is only a set of proposals for what could exist, but only if sufficient engineering effort is put into implementing it. I have recorded it here for posterity in case I choose to work on this, or in case I decide to move on and someone else has interest.

Documents:

The Evermore Defi Roadmap for Ravencoin consists of 3 documents:

  1. This document including
    1. Evermore Guiding Principles
    2. Evermore  Roadmap Summary
    3. Evermore Preliminary Details of Proposed Changes
    4. Evermore Weekly Financial Support for Code Development
  1. Evermore 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 RVN 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. RavenVault-Plus


Evermore Guiding Principles:

1) Continue to build Ravencoin in the spirit of Bitcoin- decentralized, permissionless, as simple as possible.

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

3) Do not change the founding economic principles related to coinbase rewards of miners of Ravencoin when adding new features. No change to coinbase rewards or schedules. No mining tax.

4) Whenever possible, add new ways for Ravencoin 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.

5) Support for new functionality in Ravencoin 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 Ravencoin will be able to support a range of product and service vendor businesses.

6) 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. Ravencoin core sync code has not yet been very well optimized, and future technologies such as Utreexo and Flyclient may provide additional solutions.

7) Ravencoin's success depends on Code Development. Code Development requires salaried funding- bounties don't work for anything beyond bug fixes and small feature additions. Medici spent over $720K/yr, which was quite small compared to many projects.



Evermore  Roadmap Summary:
The following changes are proposed for the Ravencoin blockchain, consensus, and related code.
1) Implement the RavenVault Ravencoin Improvement Proposal.
  • Vault assets are assets which have a "face value" of RVN and can be "melted" to extract the RVN.
  • Vault assets can pay a daily interest rate as a % of the "face value" or a fixed amount of RVN. Or they can cost a daily demurrage rate as a % of the "face value" or a fixed amount of RVN.
  • Vault assets have many interesting applications. They will be used by the consensus code to issue payments to help fund Code Development (see #3 here and "Evermore Weekly Financial Support for Code Development" for details).

2) Implement Reusable Payment Addresses: A mechanism which creates different non-linkable addresses so that on-chain balances and payment totals can remain private. This is a highly desired feature for businesses who want to advertise a payment address yet maintain some financial privacy.
  • Similar technologies have been used on BCH (BIP-Stealth) and BTC (Stealth Addresses) as well as in Monero
  • Note that this works better on Ravencoin than on BTC or BCH because of RVN's common use of extraneous data on-chain (put the nonce in the IPFS field)

3) Begin to issue ^RVNDEV Vault assets once per week to help fund Code Development (see "Evermore Weekly Financial Support for Code Development" for more details)
  • Note that charitable donations to help fund Ravencoin Code Development will still be needed; especially until the new roadmap is implemented and chain fees increase to provide income

4) Add DEX support: See "Level-1 DEX Support" in "Evermore_Support_for_2-step_On-Chain_SIGHASH_SINGLE_Atomic_Swaps"
  • 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. 

5) 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).

6) 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 RVN (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 are extremely useful 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 Ravencoin.

7) Add Covenant support: See "Financial_Derivatives" below for details.
  • Covenants will allow Ravencoin 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.

8) Implement a 2-way Peg BTC-Relay to provide Wrapped-BTC liquidity for trading.
  • RVNWBTC tokens can be issued on the Ravencoin blockchain specifying a non-zero toll, so the liquidity providers earn a toll every time a RVNWBTC 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 RVNWBTC on the Ravencoin blockchain. During a Peg-out, the RVNWBTC must be consumed and the BTC are returned on the bitcoin blockchain. If BTC and RVN 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 RVN 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.

9) Add Enhanced DEX support: See "Level-2 DEX Support" in "Evermore_Support_for_2-step_On-Chain_SIGHASH_SINGLE_Atomic_Swaps" for details.
  • 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 Ravencoin-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.
   
10)  Implement a 2-way Peg Ethereum Relay to enable Wrapped ERC20 tokens on Ravencoin. Same considerations as for BTC-Relay.

11) Add Expiring Unique Assets: 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 RVN (1 hour life) to 5 RVN (eternal life).
   
12) Add Oracle DEX Support:  See "Level-3 DEX Support" in "Evermore_Support_for_2-step_On-Chain_SIGHASH_SINGLE_Atomic_Swaps" for details.
  • 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.

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

14) Catch up to Bitcoin on new features: PSBT, Segwit, taproot

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



Evermore Preliminary Details of Proposed Changes:
  • Vault Assets with On-Chain Native RVN "Face Value":
    • Mint, Monetize, Melt, Unmelt, & Remint using the RavenVault RIP
    • For details see "RavenVault Ravencoin Improvement Proposal"
    • This mechanism is also used by the consensus code to issue payments to help fund Code Development (see "Evermore Weekly Financial Support for Code Development" for details).
  • Add a second IPFS field to asset metadata:
    • One of the IPFS fields is treated as immutable once the asset has been issued, even during reissue. The second IPFS field is always 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 have their IPFS mapped to the non-mutable field, while legacy reissueable assets 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 RVN) 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 RVN,  1day/0.1RVN,  1week/0.2RVN,  1month/0.5RVN,  3months/1RVN,  6months/2RVN,  1year/4RVN,  infinite/5RVN
    • 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:
    • A raven-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 RVN-Wrapped-Bitcoin, then this provides a way for the existing supply of RVN-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.
  • Assets with owner-required Toll (trading fee):
    • Each asset will be given a metadata field indicating a required per asset Toll qty of RVN (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 RVN output to the Toll address. Meeting that requirement is enforced as a consensus item by all nodes.
  • 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 RVN-WRAPPED-BTC assets on the Ravencoin 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 Ravencoin. But the review of Dmitry's work by Russell O'Connor from Liquid Network is encouraging.


Evermore Weekly Financial Support for Code Development:
  • Ravencoin's success depends on Code Development. Code Development requires salaries for dedicated programmers- bounties are not an effective solution for anything more complex than bug fixes and small feature additions.
  • Medici spent over $720K/yr on Ravencoin, which is quite small compared to many projects.
  • The financial mechanism described below is intended to help provide funding for Ravencoin Code Development in the future after the new roadmap is implemented and blockchain fees increase to help provide income.
    • Charitable donations to the "Direct Code Development Fund" to help fund Ravencoin Code Development will still be needed, especially in the short term.
    • Funding is provided by Vault tokens issued weekly direct to SIG chairmen based on a weekly Code Committee funding report. No Foundation involvement is required. Risk is limited by the weekly nature of the payments. Daily 1% demurrage insures that payments are quickly disbursed or become worthless after 100 days (and returned to the "Development Treasury").
  • Independent investors and companies should also be encouraged to provide donations to the "Direct Code Development Fund" or to support programmers directly. Ravencoin's new roadmap and new features will provide many opportunities for vendors to provide Ravencoin-related services for profit.
  • RavenVault assets are issued by the consensus code once per week to help fund Code Development. They carry a 1% per day demurrage fee (which is returned to the "Development Treasury").

    Code Committee:
  • A code committee consisting of Ravencoin Code Developers and major Dev Fund Contributors will meet once per week to discuss the allocation of Code Development Funds amoung the SIGs
  • A fixed on-chain location should contain the PGP Key of the Code Committee and a pointer to its weekly funding report.
  • The Code Committee Chairman on a weekly basis publishes the Code Committee Funding Report. The PGP-signed report lists the SIGs, the Payment Address of each SIG chairman, and what % of the Code Development budget should go to that SIG this week. The Code Committee and its Chairman are not compensated in any way for their activity or for the funding report. If no report is issued by the committee in any given week, then the previous week's report is used by the consensus code.
   
    The source of funds (aka the "Development Treasury") for Code Development are:
  • an address which collects 50% of all chain transaction fees
    • note that in 2020 transaction fees were increased by 100x because they were considered too low to be meaningful due to low Ravencoin application usage
  • all RVN in Ravencoin burn addresses
  • an address which collects 50% of all Toll fees
  • an address which collects 50% of all Oracles fees
  • an address which collects the demurrage RVN from ^RVNDEV tokens issued during previous weeks
  • an address used to collect any returned unused melted ^RVNDEV RVN from previous weeks
  • an address used to collect "Direct Code Development Fund" donations

    Fund Disbursement:
  • Each week the consensus code mints 1000 ^RVNDEV Vault tokens. The combined "face value" for those tokens is set to 1/52 of the sum of the previously listed addresses, and those addresses are debited by 1/52 of their value.
  • The tokens are issued by the consensus code to the SIG chairmen in proportion to the percentages specified in this week's Funding Report from the Code Committee Chairman. The SIG chairmen are tasked with distributing this week's Vault assets as they see fit between themselves and SIG contributors. The potential for abuse of this power is limited since it is only one week's budget.
    • To further clarify legal custody of the Vault assets, the SIG chairmen could instead pass invoice lists upstream to the committee so that each week's Funding Report directs the code to issue all payments directly to recipients.
  • The receiving parties must melt the tokens to receive the RVN they hold. Since these ^RVNDEV Vault tokens have a setting of 1%/day demurrage, they should be distributed and melted quickly since they become worthless after 100 days (and returned to the "Development Treasury").
  • If the percentages in the report from the Code Committee Chairman add up to less than 100%, then the remaining percentage of tokens are melted and the RVN returned into the ^RVNDEV collection address in the "Development Treasury". If the percentages add up to more than 100%, then all portions are scaled down to add up to 100%.

Copyright 2021 by Hans Schmidt