Evermore: A Defi Roadmap for
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
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
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
- 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
(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.
The Evermore Defi Roadmap for Ravencoin consists of 3
- This document including
- Evermore Guiding
Preliminary Details of Proposed Changes
- Evermore Weekly
Financial Support for Code Development
Support for 2-step On-Chain SIGHASH_SINGLE Atomic
the Price Oracles
Assets- Fungible Assets with Native RVN Face Value
data maintained by the nodes for each fungible Vault
asset or Vault subasset
RPC Command Details
Simple Use Case Example
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
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
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.
The following changes are
proposed for the Ravencoin blockchain, consensus, and
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
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
- 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
- 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
- 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
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
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
- 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
9) Add Enhanced DEX support: See "Level-2
DEX Support" in
- On-chain 2-step Atomic Swaps can support "Partial
Order Fullfillment" with specified "Granularity". They
can also support different order types:
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
- 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
10) Implement a 2-way Peg Ethereum Relay to enable
Wrapped ERC20 tokens on Ravencoin. Same considerations as
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
12) Add Oracle DEX Support: See "Level-3
DEX Support" in
- 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,
15) Implement Relays to additional popular blockchains: LTC,
DOGE, BCH, Cosmos
Details of Proposed Changes:
- Vault Assets with On-Chain Native RVN "Face Value":
- Mint, Monetize, Melt, Unmelt, & Remint using the
- 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
for the application uses driving this
- Expiring Unique
- 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,
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
- 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
- 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
- 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
- For Defi, it is critical to be able to trade in
Financial Derivatives such as Options Contracts and
- 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:
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.
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
- 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
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
- 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.
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
- all RVN in Ravencoin burn addresses
- an address which collects 50% of all
- an address which collects 50% of all
- an address which collects the
demurrage RVN from ^RVNDEV tokens issued during
- an address used to collect any
returned unused melted ^RVNDEV RVN from previous weeks
address used to collect "Direct Code Development
- 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
- 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