Vault_Assets-_Fungible_Assets_with_Native_EVR_Face

last update: July 22, 2022

Main_Menu

Evrmore Vault Assets
*Fungible Assets with Native EVR "Face Value"*

Overview:

What: Vault assets are fungible assets on the Evrmore blockchain which have native value in the form of Evrmore currency (ie a "face value"). They also pay/cost an interest/demurrage % rate of the "face value" per day or a fixed quantity of EVR per day.

Why: The Evrmore protocol is an extension of the Ravencoin protocol design which natively supports the creation and management of assets. But adoption and use of those assets depends on the traditional legal and banking systems to establish the link of value between an Evrmore asset and a real world asset. The result is that the rate of adoption of Evrmore is determined by the rate of adoption of blockchain technology by the traditional legal and banking systems. Without Vault assets, Evrmore lacks the ability to assign value to on-chain assets denominated in the on-chain Evrmore EVR currency. This is an oversight because the flexibility built into the Evrmore protocol can fully support this with the ability to securely and atomically trade between the asset and the currency in a single transaction. Enhancing an asset with the ability to carry a face value also makes it possible for the asset to implement a daily interest rate, either positive (earnings) or negative (demurrage) or a fixed daily positive or negative quantity of EVR, which opens many more interesting applications.

Naming Rule:

Vault assets are a special type of root asset or subasset. They follow the same naming rules as root assets and subassets except that their name must always start with the ^ symbol (an upside-down "v").
This naming convention makes it clear that the asset is a Vault asset which has a face value and which pays/costs an interest/demurrage rate from/to an address.
Vault assets therefore look something like ^MYNAME/^MYSUBNAME
Vault asset names may only be issued by the owner of the root asset of the same name. Thus ^MYNAME may only be issued by the owner of MYNAME!

New data maintained by the nodes for each fungible Vault asset or Vault subasset:

EF = EVR_Fund = The quantity of EVR currency held in escrow for this fungible Vault asset name

AQ = Authorized_Quantity = The inactivated quantity of this Vault asset name which has been authorized but is not currently in circulation and which has no value

Interest_Rate = A signed float which represents the interest/demurrage % rate paid/charged in EVR per day for holding the Vault asset. The payment/charge is against the face value of the Vault asset. The payments/charges are made automatically on a daily basis by the consensus code.

Interest_Amount = A signed float fixed value paid or charged in EVR per day for holding the Vault asset.

Interest_Address = The address from which interest payments are charged to increase the Vault asset "face value" or into which demurrage payments are paid from the Vault asset "face value".

Vault-related RPC Commands

Mint=> mintasset	This issues a Vault asset and then does a "monetizeasset" It is similar to a normal root asset or subasset "issueasset" except that it also creates and allows setting the Vault-specific metadata fields as defined above: EF = EVR_Fund AQ = Authorized_Quantity Interest_Rate = Signed % interest/demurrage of "face value" EVR per day Interest_Amount = Signed float fixed value EVR per day Interest_Address = The address for interest/demurrage payments/charges
Monetize=> monetizeasset	This removes a designated qty of EVR currency from the designated address and from circulation and puts it into the EF escrow account associated with this Vault asset name This increases the prorated EVR currency "face value" of each Vault asset because it increases EF It can be executed as often as desired to increase the "face value" of the Vault assets in circulation
Melt=> meltasset	This inactivates the designated qty of Vault assets by removing them from the designated address and from circulation. It increases AQ. It pays out a prorated qty of EVR from escrow (reduces EF) and puts them into the designated address and back into circulation
Unmelt=> unmeltasset	This reactivates the designated qty of Vault assets by moving them from AQ into the designated address and back into circulation. It reduces AQ. It requires a payment of EVR currency equal to the current per-asset "face value" times the qty of Vault assets being unmelted If this command is executed with qty=0, it prints the current values of AQ and EF to reveal the amount of EVR currency which will be required for an unmelt
Remint=> remintasset	Reissue a fungible Vault asset. If the Vault asset was previously monetized, then also lock raven into the EF escrow attached to this Vault asset name. That is, if EF>0 the fund_address must contain sufficient EVR currency equal to the current per-asset "face value" times the assetqty being reissued. It increases EF. Note that Interest_Rate and Interest_Address are decided during Mint and cannot be changed during a Remint operation.

Vault-related RPC Command Details:

Mint => mintasset "asset_name" assetqty rvnqty "fund_address" "to_address" interest_rate interest_amount "interest_address" "mint_burnfee_address" fee_amount "fee_address" "(change_address)" (units) ( reissuable ) (has_ipfs) "(ipfs_hash)" mintasset is like a issueasset but for a Vault asset mintasset requires payment of a EVR burn fee, just as issueasset does Issue a fungible Vault asset and lock EVR into an escrow EF attached to this asset name Asset names must begin with ^. Only the owner of the root asset of the same name may claim that name. Reissuable is true/false for whether additional Vault assets can be created Arguments:
"asset_name"	(string, required) a unique name, starts with '^' if '^' is not there it will be added automatically
assetqty	(numeric, required) the number of Vault assets to be issued
rvnqty	(numeric, required) the number of EVR to be put into escrow EF for this assetname
"fund_address"	(string, required), address from which the rvnqty will be taken and locked in the escrow for this asset name
"to_address"	(string, required), address asset will be sent to
interest_rate	(signed float, required) % interest/demurrage of "face value" EVR paid/charged per day
interest_amount	(signed float, required) fixed value EVR paid or charged per day
"interest_address"	(string, required), the address for interest/demurrage payments/charges
"mint_burnfee_address"	(string, required), the address from which the EVR burn fee will be taken to pay for the mintasset operation
fee_amount	(numeric, required) the number of ravencoins to be paid in fees for this transaction
"fee_address"	(string, required), address from which the ravencoin fee will be taken
"change_address"	(string, optional, default=""), address the Evrmore change from the fee will be sent to. If it is empty, a change address will be generated for you
units	(integer, optional, default=0, min=0, max=8), the number of decimals precision for the asset (0 for whole units ("1"), 8 for max precision ("1.00000000")
"reissuable"	(boolean, optional, default=true), whether future reissuance is allowed
"has_ipfs"	(boolean, optional, default=false), whether ifps hash is going to be added to the asset
"ipfs_hash"	(string, optional but required if has_ipfs = 1), an ipfs hash or a txid hash once RIP5 is activated
Result: "txid" (string) The transaction id

Monetize => monetizeasset "asset_name" rvnqty "fund_address" fee_amount "fee_address" "(change_address)" (has_ipfs) "(ipfs_hash)" Removes the designated qty of EVR currency from the designated address and from circulation and puts it into escrow EF associated with the designated asset name to increase the "face value" of those Vault assets Arguments:
"asset_name"	(string, required) the name of the Vault asset for which the "face value" in being increased
"rvnqty"	(numeric, required) the number of EVR to be put into escrow EF for this assetname
"fund_address"	(string, required), address from which the rvnqty will be taken and locked in the escrow for this asset name
"fee_amount"	(numeric, required) the number of ravencoins to be paid in fees for this transaction
"fee_address"	(string, required), address from which the ravencoin fee will be taken
"change_address"	(string, optional, default=""), address the Evrmore change from the fee will be sent to. If it is empty, a change address will be generated for you
"has_ipfs"	(boolean, optional, default=false), whether ifps hash is going to be added to the asset
"ipfs_hash"	(string, optional but required if has_ipfs = 1), an ipfs hash or a txid hash once RIP5 is activated
Result: "txid" (string) The transaction id

Melt => meltasset "asset_name" assetqty "from_address" "to_address" fee_amount "fee_address" "(change_address)" (has_ipfs) "(ipfs_hash)" Inactivates the designated qty of Vault assets by removing them from the designated address and from circulation. Pays out a prorated qty of EVR from escrow EF and puts them into the designated address and back into circulation. Arguments:
"asset_name"	(string, required) the name of the Vault assets which are being inactivated
"assetqty"	(numeric, required) the number of assets being inactivated
"from_address"	(string, required), address from which Vault assets will be removed and inactivated
"to_address"	(string, required), address where extracted "face value" EVR will be put
"fee_amount"	(numeric, required) the number of ravencoins to be paid in fees for this transaction
"fee_address"	(string, required), address from which the ravencoin fee will be taken
"change_address"	(string, optional, default=""), address the Evrmore change from the fee will be sent to. If it is empty, a change address will be generated for you
"has_ipfs"	(boolean, optional, default=false), whether ifps hash is going to be added to the asset
"ipfs_hash"	(string, optional but required if has_ipfs = 1), an ipfs hash or a txid hash once RIP5 is activated
Result: "txid" (string) The transaction id

Unmelt => unmeltasset "asset_name" assetqty "to_address" "from_address" fee_amount "fee_address" "(change_address)" (has_ipfs) "(ipfs_hash)" Reactivates the designated qty of Vault assets by moving them from AQ into the designated address and back into circulation. It requires a payment of EVR currency equal to the current per-asset "face value" times the qty of Vault assets being unmelted If this command is executed with qty=0, it prints the current values of AQ and EF to reveal the amount of EVR currency which will be required for an unmelt Arguments:
"asset_name"	(string, required) the name of the Vault assets which are being reactivated
"assetqty"	(numeric, required) the number of assets being reactivated
"to_address"	(string, required), address to which Vault assets will be moved and activated
"from_address"	(string, required), address from which EVR will be taken for the "face value" of the assets
"fee_amount"	(numeric, required) the number of ravencoins to be paid in fees for this transaction
"fee_address"	(string, required), address from which the ravencoin fee will be taken
"change_address"	(string, optional, default=""), address the Evrmore change from the fee will be sent to. If it is empty, a change address will be generated for you
"has_ipfs"	(boolean, optional, default=false), whether ifps hash is going to be added to the asset
"ipfs_hash"	(string, optional but required if has_ipfs = 1), an ipfs hash or a txid hash once RIP5 is activated
Result: "txid" (string) The transaction id

Remint =>
remintasset "asset_name" assetqty rvnqty "fund_address" "to_address" fee_amount "fee_address" "(change_address)" (units) ( reissuable ) (has_ipfs) "(ipfs_hash)"
or
remintasset "asset_name"

remintasset is like a reissueasset but for a Vault asset
Reissue a Vault fungible asset. If the asset was previously monetized, then also lock EVR into the escrow EF attached to this asset name
Asset name must already exist and be reissuable.
You must own the Owner Token

If EF>0 the fund_address must contain sufficient EVR currency equal to the current per-asset "face value" times the assetqty being reissued. It increases EF.

Arguments:

"asset_name"

(string, required) the name of the Vault assets which are being reissued

assetqty

(numeric, required) the number of Vault assets to reissue

rvnqty

(numeric, required) the number of EVR to be put into escrow EF for this assetname

"fund_address"

(string, required if EF>0), address from which the rvnqty will be taken and locked in the escrow for this asset name

"to_address"

(string, required), address asset will be sent to

"remint_burnfee_address"

(string, required), the address from which the EVR burn fee will be taken to pay for the remintasset operation

fee_amount

(numeric, required) the number of ravencoins to be paid in fees for this transaction

"fee_address"

(string, required), address from which the ravencoin fee will be taken

"to_address"

(string, required), address asset will be sent to

"change_address"

(string, optional, default=""), address the Evrmore change from the fee will be sent to. If it is empty, a change address will be generated for you

"reissuable"

(boolean, optional, default=true), whether future reissuance is allowed

new_units

(numeric, optional, default=-1), the new units that will be associated with the asset

"new_ipfs"

(string, optional, default=), whether to update the current ipfs hash or txid once RIP5 is active

If this command is executed with only the asset_name specified, it prints the qty of the asset in circulation and EF to reveal the amount of Evrmore currency which will be required for a reissue

Result:

"txid" (string) The transaction id

"asset_name": There are "circulation_qty" assets in circulation and "EF" Evrmores in escrow

Q & A

Q: Why is this desired?
A: This capability would give Evrmore powerful functionality to more fully participate in the cryptocurrency and fintech ecosystems.

Q: Can you give an example?
A: Business founders could distribute assets as ownership shares, or people could buy those assets as always envisioned for Evrmore assets. But now, the profits from the business can be used to do "monetizeasset" transactions, thereby giving the distributed assets immediate value. That value could be hodled or traded. Or it could be cashed out at any time by doing a "meltasset" and selling the resultant Evrmore currency on any of the exchanges. This model is especially powerful for businesses which earn their income in cryptocurrency, but it could be used for any business.

Q: Would the sale and transfer price of an asset always be determined by the quantity of Evrmore currency held in escrow for that asset?
A: No. Assets would have a "face value" determined by the escrow amount. But assets would have a higher trading price determined by the market based on people's expectations for the future value of that asset as well by the perceived value of the company or community which the asset represents. Additionally, there may be real world assets attached by traditional legal means to the on-chain asset which are not visible on-chain but which can increase its trading price.

Additional implementation explanation:

At present, the nodes keep track of the UTXO set for both EVR and assets. For assets, that implies keeping track not only of the creation and transfer history bitcoin-style, but also of some metadata (units, reissuability, etc). The nodes already have to track that metadata and changes to it just like UTXO changes. This concept adds an additional EVR_Fund metadata number to every asset name, which represents the number of EVR backing that asset name. All nodes know what the current EVR_Fund number is for each asset name, just as they know the other metadata and the UTXOs from the transaction history. The sum of all the EVR_Fund (EF) numbers plus the sum of all the EVR at addresses is the total EVR supply, which is fixed by the whitepaper and changes only due to miner rewards. That can be thought of as an extended UTXO dataset, and the EFs for all the assets can be thought of as pseudo-addresses.

When new Vault assets are created (issued) for the first time, an amount of EVR is set aside for the EVR_Fund (EF) for that asset name. After the mintasset command is executed, each Vault asset by that name will have a "face value" equal to the EF quantity of EVR divided by the quantity of Vault assets which were issued.

Anyone can transfer EVR from an address into an asset name's EVR_Fund using a new RPC which specifies the asset name and the qty of EVR, which increases the "face value" of all the assets issued with that name. This is a "monetize" transaction. The nodes track these transfers as their extended UTXO dataset and know where the EVR are. The "face value" of any single asset token is equal to the number of EVR in the EVR_Fund divided by the number of tokens in circulation, and all nodes know that number.

Assets can be transferred as usual. If the recipient of some assets wants to "cash them in", then he can execute a "melt" on those assets. To support this, there is a 2nd new metadata number attached to every asset name which I call Authorized_Quantity (AQ), and it is also tracked by all nodes as part of the extended UTXO dataset. The sum of all the assets at addresses plus the AQ for that asset name equals the total number of assets issued by that name. The AQ is the number of existing but inactivated assets temporarily removed from circulation just as the EVR_Fund is the number of EVR temporarily removed from circulation. A "melt" operation increments the AQ number for the asset and removes the assets from the owner's address. It also decrements the EVR_Fund number for the asset, and puts EVR into the owner's address. AQ and EF can be thought of as pseudo-addresses and all nodes track their change as part of the extended UTXO dataset.

An "unmeltasset" operation allows the person controlling the owner token to take inactivated Vault tokens from AQ, spend EVR into EF to catch those assets back up to the current "face value" of the assets currently in circulation, and reactivate those assets (put them back into circulation).

A "remintasset" operation is like an "unmeltasset" operation except that it creates new assets out of thin air instead of reactivating tokens which were inactive in AQ. Note that this can only be done if the Vault asset was set as "reissueable" when first issued. An "unmeltasset" operation can be done even on an asset which is non-reissuable because does not result in more assets in existence than originally authorized.

A Simple Use Case Example:

Currently, Evrmore depends entirely on the traditional legal system to give value to on-chain asset tokens tied to real-world assets. The EvrmoreVault extension provides the ability to choose any business model you prefer ranging from fully on-chain value to traditional legal value or any mix in between.

Let me describe a simple on-chain example. You might decide to start a company called Evrco which provides security services and products, along with Joe and myself and 4 other friends. So you issue the "^MYEVRMORECO" asset having 10 tokens. You keep 3 tokens for yourself, Joe gets 2 tokens for his expertise, I get 1.9 tokens because I am in charge of security, our accountant friend gets 0.1 token because the chain does most of the work, and 3 other friends get one token. You might write a subscription security blog, and the on-line shopping cart, which collects payment in EVR, immedicately "monetizes" the EVR to the Evrco EVR_Fund. You also give your subscriber list to me. I teach self-defence classes, and with the money I collect, I buy EVR and "monetize" them to the EVR_Fund. After a while, the EVR_Fund contains 1000 EVR, so every Evrco token has a face value (book value in Wall Street lingo) of 100 EVR, and your 3 tokens are worth 300 EVR. Then one of our friends needs cash, so he "melts" his token, which pays him 100 EVR and increases the Authorized_Quantity to 1.
Your 3 tokens are still worth 300 EVR. After that, you could "unmelt" that AQ token to a new business partner. Or you could remint new tokens for new investors. But either way, I don't have to worry about you diluting my value because the "unmelt" and "remint" commands fail unless you provide enough EVR to cover the face value of the tokens being put into circulation. So new partners have to buy-in at a minimum of face value. But of course, you could provide more value during the "unmelt" or "remint". Perhaps Elon Musk would desperately want to buy the token because he thinks that Evrco will take over the world, and he is willing to pay 1.2 million EVR. Then you could "unmelt" the token from AQ to him while specifing the fund_address as his address which contains the 1.2 million EVR. After that transaction, your 3 Evrco tokens are worth 360270 EVR. So you and I and our friends "melt" our tokens to get our EVR and go start a new company. All enforced on-chain. With more security than a programmed smart contract could ever offer.

The Evrco asset has a single EVR_Fund number attached to it which represents the number of EVR taken out of circulation and put into escrow to back that asset. So if there are 1000 EVR in the Evrco EVR_Fund and there are 10 Evrco tokens currently in circulation, then each token has a face value of 100 EVR. In my example, the EVR_Fund accumulated 1000 EVR from business profit "monetize" transactions, then dropped 100 EVR when our friend "melt"ed his token, then added 1.2 Million EVR when a token was "unmelt"ed to Craig. So at the end, there are 1000-100+1200000 EVR in the EVR_Fund of Evrco and still 10 tokens in circulation. So dividing the EVR_Fund quantity by the token count of 10 gives each token a face value of 120090 EVR available by "melt"ing.

Footnotes:

It is important to recognize the possible impact of round-off errors when calculating the "face value" of an asset. Since any number of EVR are allowed when creating the EVR_Fund for an asset or when adding to the EVR_Fund, it is possible for the "face value" of a single token to be a number with an infinite number of decimal places.

    For instance:

If a "mintasset" is executed to create 12 asset tokens backed by a EVR_Fund of 4 EVR, then each token will have a "face value" of 0.33333... EVR.

Likewise, a "mintasset" command creating 12 assets with a EVR_Fund of 3 EVR, followed by a "monetizeasset" command of 1 EVR to the same asset, will create the same result.

    If round-off errors are not taken into account, the movement of EVR back and forth between circulation and EVR_Funds can impact the total EVR supply.

    In order to accurately preserve the total EVR supply in existence, round-off errors are best handled as follows:

Any number of EVR are allowed during "mintasset" or "monetizeasset" commands.

When doing "face value" calculations, round up for "unmeltasset" and "remintasset" commands; round down for the "meltasset" command. In other words, unmelt and remint will always require a small over-payment, while melts will always yield a small under-payout. This will insure that the holder of the asset owner token cannot repeatedly unmelt or remint and then melt to extract EVR from the EVR_Fund. Also, round-off errors will accumulate in the EVR_Fund, which slowly raises the face value of the remaining tokens in circulation.

If all tokens are melted (that is, all tokens are moved from circulation to AQ), the amount payed out during the final melt command should be set equal to the value of the EVR_Fund balance. This insures that the final EVR_Fund=0 and the total EVR supply is accurately maintained.

EvrmoreVault-Plus

EvrmoreVault-Plus is a further modification of the EvrmoreVault proposal to allow extraction of face value from assets.

Its primary feature is that it provides a mechanism for DAO cash-outs

Vote for Unmelt at face value

doesn't change value of each outstanding token, but reduces equity share & thus voting power per token

Vote for Remint at zero value

useful for funds withdrawal off-chain; reduces value per token and equity share per token

Voting implementation:

Each token has metadata which specifies

Is a vote required to authorize Unmelt at face value

Is a vote required to authorize Remint at zero value

If a token is not re-issuable, then there is nothing to vote about

If a token is re-issuable, then during a re-issue the meta-data can be made more restrictive but not more permissive

Vote are always won by 51% of the vote

All tokens vote by design: The vote of each asset UTXO is part of the asset transfer transaction, and stays valid until changed by the next transfer

disadvantage: requires sending all your tokens to a new address to change the vote for those tokens

advantage: the token owner sets the inital default when distributing the tokens

the wallet default should be to set all the votes to permissive on each transfer

The vote could be encoded into asset transfer transactions by the addition of a new "vote" field