Ravencoin — Asset Issuance Cost
Let me start by thanking everybody in the community that has passionately contributed thoughts and ideas on the economics of asset creation and RVN burn rates. There are several great ideas that have been thoroughly discussed by the developers. That being said, there will be some that will be unhappy with the final decision. Please don’t let that affect the unity of the Ravencoin community as that is one of our greatest strengths.
Overview
First, let me summarize the problem and introduce a few token economic concepts.
Ravencoin’s value proposition is the integrated asset layer. Also unique to the asset layer in Ravencoin is the unique naming of assets. There are other second layer asset solutions that name their asset using some guaranteed unique information such as transaction hash, contract hash, block-tx-vout, or similar, but this is not the same as being able to select a desired name. Because other token platforms do auto assignment of a non-selected unique id is the reason there are not examples we can learn from in this space.
Asset names in Ravencoin are a limited resource. As an example, there will only ever be one top-level asset named LEMONADE. There must be a cost associated with reserving these unique names, otherwise one person can reserve them all, rendering the Ravencoin assets useless.
There is also the concept in token economics of a source and a sink. The source in Ravencoin is the block reward, also known as the Coinbase (not be confused with the company named Coinbase). The sink in Ravencoin includes fees (similar to Bitcoin), and the cost to issue assets, reissue assets, and issue unique assets. Fees in Ravencoin, as in Bitcoin, are recycled back to the miners.
Burning RVN is beneficial to the token economics. It solves three problems. First, it increases the value of existing RVN because the circulating supply goes down. Second, it limits the number of assets that can be created which is good because a blockchain is a limited data store. Third, the cost to create assets increases as the value of RVN increases, which is tightly correlated to the security of the blockchain indicated by mining hash power cost.
Another component of the problem is the nature of the cost to create assets. Ordinarily in software, every controversial value can be made configurable, with an intelligent guess at a default value. If the designers and developers get the default wrong, the setting can be changed easily. This isn’t the case for a consensus based system where the value must be identical for everyone and cannot be changed. A change to this value would require a majority of the miners, and 100% of the exchanges to agree to upgrade the software.
Priorities of Ravencoin
Easy to Use — This is a high priority of Ravencoin. There are other asset platforms, like ERC20, but they are confusing and require an understanding of smart contracts, GAS, and it’s possible to lose your tokens if you don’t know what you’re doing.
Easy to understand and easy to plan your project — If the model used for asset issuance is too complex, there will be potential token issuers that will move to another platform because it is too difficult to understand, or too difficult to predict how the economics of the issuance works.
Not dependent on human or organizational intervention — One suggestion was to allow the cost of asset creation come from an external source. The way to communicate the cost of asset issuance to the software so that all nodes are equally aware of the cost is through an oracle. An oracle is a designated human or organization that owns the private key that can sign a transaction to communicate external information, like the cost of asset issuance, to every node. The distributed nature of Ravecoin means that any suggestion of human or organizational intervention other than a future voluntary software upgrade is not an option.
Not tied to an external fiat price — A natural instinct is to peg the asset issuance to USD, or another fiat price. This has two issues. First, Ravencoin is trans-jurisdictional, and second any type of linkage to an external source of pricing is not compatible with consensus rules. Only a trusted oracle that signs pricing data would allows this type of price targeting, and then we’re back to goal of not being dependent on a human or organization.
Other than the nodes holding the name of the assets, there isn’t much additional space used in the chain for issuing an asset. It is about ~350 bytes for an issuance (depends on asset name length), when a normal send transaction is about ~250 bytes.
Benefit of burning RVN is to mop up some of the RVN being issued. With 21 billion RVN being issued, it is beneficial to holders, and miners, that some of the RVN is burned to decrease the circulating supply. Decreasing the supply of RVN allows the price to increase as the circulating supply of RVN is less plentiful (more scarce) and therefore a higher value per RVN.
It is not at all a concern that all the Ravencoin will be burned to create assets. This is a market, and the cost should increase if the Ravencoin platform is a better, easier-to-use, more secure platform. As the price goes up, the hash power increases, and the platform increases in value because it is more secure. As the platform becomes more secure, the value of issuing an asset on the platform increases, which burns RVN which increases the price. It is the virtuous circle that every platform wants to create.
Proposed Options
Fixed 500 RVN burn for asset issuance
- Pro: It is consistent with the roadmap.
- Pro: It is simple and easy to understand.
- Pro: It automatically puts limits on the number of assets
- Pro: As mining hash power and price increase, the cost of asset issuance should increase.
- Pro: If 500 RVN too high, then market for 100 RVN sub-assets under premium top-level will materialize.
- Con: It may price out some use cases as the cost per RVN increases.
Fixed 500 RVN burn adjusted at the halvenings (with a floor)
- Slight modification from the roadmap
- Pro: Adapts to the potential (but unknown) increase in price at the halving.
- Caveat: Can’t continue to halve or it goes to zero.
- Con: Not as straightforward as 500 RVN (fixed)
- Con: Shifts to arbitrary floor.
- Con: Assumptions about market price of RVN increasing at halvening.
- Con: Need to code for transitions around halvening to prevent asset creation failure — could be as simple as >= X where X is cost to create asset.
- Pro: Less likely to price out use cases.
Halvening Options with floor — So it doesn’t go to free
- 2 halvenings (500->250->125)
- Scaled halvening (25% off at each halvening with a floor of X)
- 4 halvenings (500->250->125->skip->62.5->skip->skip->31.25)
- Reduces by 20% of original value at each halvening. (500->400->300->200->100)
YEAR ISSUANCE RE-ISSUE/SUBS UNIQUE
Now 500 100 5
2022 400 80 4
2026 300 60 3
2030 200 40 2
2034 100 20 1Adaptive RVN based on number of asset issuances in X blocks
- Con: Requires more constant values to be guessed, and estimation on the “right” amount of asset issuance
- Pro: If no assets are being created, the cost (in RVN) lowers.
- Pro: If “too many” assets are being created, the cost (in RVN) increases.
- Con: Complexities like asset issuances failing because cost went up between asset creation tx and confirmation in a block.
- Con: Mempool holding asset creation creates a potential time lag.
Adaptive RVN based on mining hash power
- Pro: Hashpower is a proxy for value, but only after factoring for electricity price, and hardware efficiency.
- Caveat: Intelligent guesses must be made on efficiency increases and power costs and target a range.
- Example: Set 50,000 difficulty as baseline at which 500 RVN is the target. If diff drops to 25,000 make it 1000 RVN, if the diff goes to 100,000, it would be 250 RVN to create an asset. Note: This does not factor in gains in mining efficiency or electricity costs increasing.
- Con: Unknown hardware efficiency changes.
- Con: As security increases exponentially, this keeps the cost of asset creation relatively static (subject to volatility in hardware efficiency — — cheaper with more efficient hardware)
- Con: Similar complexities for the code to adapt by X blocks. As hash power goes up and cost goes up, some asset issuances will fail because they were priced incorrectly for consensus algorithm.
Recycling RVN through mining instead of burn
- Con: RVN not removed from circulation
- Con: Ravencoin not being burned does not help token economics with excessive circulating supply.
- Con: We want the market to limit the number of assets created because blockchain data, UTXO sets, and storing of all asset names to prevent duplicate creation needs to be done by all nodes.
A second token with its own economics
- Some have suggested an additional token with its own economics. Ravencoin will not have two different tokens because it is confusing and goes against the ease-of-use goal.
Send RVN to a development fund instead of burn
- Con: Not compatible with the model of RVN which is to not have a developer set-aside.
Recurring payments for asset names (expiring assets) — returning names to the pool
- Pro: Recurring burn
- Pro: Unused assets return to available pool.
- Con: This is too complicated in a UTXO model.
- Con: There will be unspent outputs owned by users.
- Con: If a single unpaid renewal invalidates the assets, it’s unlikely to be the type of system where people know with certainty they have the tokens.
Ratios
500 RVN — Asset issuance (any qty) — Minimum 100
100 RVN — Sub-asset issuance (any qty) — Minimum 20
100 RVN — Asset reissuance (any additional qty) — Minimum 20
5 RVN — Unique asset issuance (qty 1 only) — Minimum 1
— — — — — — — — — — — — — — — — — — — — — — — — -
Addressing specific suggestions:
- Agree, not controlled by human hands. Also agree that the community has requested something better than just 500 RVN (fixed).
- Agree that a secondary market (GAS) is not a good idea for Ravencoin — primarily due to excessive complexity.
A) Agree — a spam proof floor is a good idea.
B) Cost effective ceiling — A ceiling would be appropriate if the mechanism increases the cost under high asset issuance load.
C) Halving Schedule — This would work. See options above. Requires some adaptation for the boundary conditions.
D) Based on space taken in blocks — Agreed, the price should not be correlated to blocks space. Fees will be in addition to RVN burn and will compensate for full blocks.
E) Agreed — No correlation to fiat.
Addressing @Bayminer007
This secondary market might work, but violates several of the ease-of-use and predictability goals of Ravencoin.
Addressing the concept that Ravencoin Assets should only be used for STOs, or certain types of assets
This may happen naturally as the cost of asset creation increases, but should not be determined in any way by the protocol. The highest value use case may saturate the blockchain despite our best efforts at scalability.
Addressing the cost of assets being too high
The cost of asset creation should rise with the security of the blockchain. As the security (mining hash power) goes up, the price of RVN will go up. They may not go up at exactly the same time, as it adjusts over time as it becomes more economical to buy RVN, or more economical to buy/rent hash power. https://letstalkbitcoin.com/blog/post/bitcoin-value-and-mining-difficulty