Zaab
Hello everyone,

I have created a google spreadsheet outlying what I feel would be a better way set the Asset Creation price. I propose we set a max % of total supply as the max burnable RVN amount, then have a % of the max burn amount remaining (max burnable RVN - burned RVN) for each asset creation cost. Sub Assets/Unique Assets could then be a % of main asset creation cost. This would result in Asset cost slowly rising as the max total supply of RVN increases. However, cost would decrease as RVN were burned. For any time if Max_Burn% * Blockreward RVN is greater than the Burned RVN amount the price of assets increases, if they equal price stays the same.

The max % burn would likely need to be evaluated by someone with an economics background. The current % Burn rate was set arbitrarily to match the current planned 500 RVN/Asset cost.

I feel this is more flexible than a hardcoded 500 RVN burn that isn't aware of how many assets have been created. I do not want to see RVN lose liquidity due to over burnage of RVN. However, this provides more variables which could be exploited. Possible defenses to this could be a baseline cost + algo, a failcheck to assure current asset creation cost is in line with previously created assets, or perhaps hold asset creation until a pool of 20 assets is created, with only the highest burn winning creation rights. Here I'm not sure what would be the best way to create a defense against manipulation. 

I'm more then willing to explain if it's unclear what I'm proposing and the google doc below should help out a bit as well. It's not that I have a problem with a hardcoded value, I truly understand the security benefits of it (it's very easy for anyone on chain to detect and back check burned RVN to assure asset is properly created) but feel it is slightly nearsighted and not flexible to handle potentially 50 years of usage.





https://docs.google.com/spreadsheets/d/1DTXNh7LuKwyvrg4shJtCd9_4PZW1ztBMVkAi9L7V3qo/edit?usp=sharing
Quote 1 0
Vincent
I agree, well done
Quote 0 0
Chatturga
Tron just published “Ravencoin — Asset Issuance Cost” https://medium.com/@tronblack/ravencoin-asset-issuance-cost-52b553c507cb … $RVN @Ravencoin #Ravencoin
Quote 0 0
Seppat
Thanks Chatturga. It's a well-written in depth post.

I definitely think that dynamic burn fees are a must because even comparing RVN to BTC 1:1 that would mean you'd need to burn 0.5BTC to create an asset. If we're hoping for this to be big, such as equal to Bitcoin's market cap as of right now, that's going to be extremely expensive to create a top-level asset for $4000. 
Quote 1 0
4k4
I like the idea of having a hefty sum to be burned, basically limiting the number of new assets that can be allocated through the protocol. However, there is a possibility of re-visiting this topic again if there are too many *names* created on this blockchain, i.e. simply put, if there aren't be many ravens left, market may lose its liquidity.

Name space allocation can be viewed as a domain registration / hosting scheme which is basically a subscription. Viewing in this regard, say, 500 RVN for registration and a renewal fee 5 RVN per month (fixed to a block height) for a top-level asset name, including late-payment extras, looks like a good option. There can also be a liquidation property for such assets: All amount of ravens that was paid for registering a specific asset-name, which hasn't renewed by its issuer (say, after 18 months worth of mined blocks since it's registered) can be used to pay back it's holders. When an asset of such shuts down, system can ask for more registration fees (i.e. double, triple of the original cost + same monthly payments) if one party should decide to revive a previously liquidated asset name.

By keeping such property, system can avoid generation of domain resell market, because it'll be costly to maintain the space for others. As we want small business owners to use this tokens for communicating and paying (i.e. dividends) to its clients & shareholders, avoiding a name-hosting market would be beneficial to the chain.

Renewal rates may be altered if a predefined number of time passes, such that number or ratio of circulating RVN reaches to a threshold.
Quote 0 0
Chatturga
After listening to and watching many discussions, I've come to realize that there are some major variables that are pointed out in Tron's article that aren't being considered when it comes to the burn rates, and one specifically that I haven't looked at that I want to mention.  The overview section mentions that the burn "limits the number of assets that can be created which is good because a blockchain is a limited data store".  If Raven was just about creating assets which could be traded and sold, this wouldn't be as much of an issue.  However, with the amount of repeatable UTXO transactions for voting, messaging, and dividends that could potentially number in the tens of thousands per asset, the more assets exist, the more of a resulting drain on storage space and processing memory will be required. These increasing requirements could eventually put too much of a strain on the network if the number of assets is not kept in check.  If an adjustment is made to the burn rate that allows the number of assets o the network to increase infinitely over time, the required resources for efficient nodes increases infinitely, which will result in a bloated, slow, inefficient chain.
Quote 0 0