Evrmore Core
Version-2 Functional Enhancements
Bug Fixes
- Fixed a bug in which large numbers in the response of
"getaddressbalance" RPC call were returning a negative
number
- Importing a mnemonic now triggers a rescan from
genesis block to make sure all transactions and the
balance are correct
- Fixed a bug in which Verifier strings (for Restricted
Assets) longer than 75 characters failed. Up to 80
characters is now properly supported.
- Fixed assorted typos and incorrect URLs
Modify the behavior of metadata field
"ipfs_hash"
- "ipfs_hash" == 46-character IPFS_address or 32-byte
TXID
- Permitted for all asset types
- Alterations are permitted at any time for all assets
including Unique_Assets (using "updatemetadata"), and
also assets with "reissueable"==False
- It can be set by RPCs "issue", "issueunique",
"issuequalifierasset" and "issuerestrictedasset"
- It can be altered by RPCs "reissue",
"reissuerestrictedasset" and "updatemetadata"
Add support for new
"permanent_ipfs_hash" metadata field for assets:
- "permanent_ipfs_hash" == 46-character IPFS_address or
32-byte TXID
- Permitted for all asset types
- permanent_ipfs_hash can never be changed after it is
set
- For legacy reissuable assets, permanent_ipfs_hash can
be set to any value
- For legacy non-reissuable assets or Unique Assets and
the asset has an ipfs_hash, permanent_ipfs_hash will be
automatically set to the same value as ipfs_hash
- For legacy non-reissuable assets or Unique Assets and
the asset has no ipfs_hash, permanent_ipfs_hash can be
set to any value
- Details:
- Post-fork, "permanent_ipfs_hash" can be set by RPCs
"issue", "issueunique", "issuequalifierasset" and
"issuerestrictedasset"
- Post-fork, for post-fork-issued (V2) assets,
"permanent_ipfs_hash" can be set by RPCs "reissue",
"reissuerestrictedasset" and "updatemetadata" if not
previously set, regardless of "reissuable"==True/False
- Post-fork, for post-fork-issued (V2) assets, if an
RPC generates an error by attempting to set an
already-set "permanent_ipfs_hash", then none of the
changes requested by that RPC will be performed
- Post-fork, for pre-fork-issued (V1) assets with
"reissuable"==True, "permanent_ipfs_hash" can be set
by RPCs "reissue", "reissuerestrictedasset" and
"updatemetadata" if not previously set
- In this case "permanent_ipfs_hash" can be set
regardless of whether an "ipfs_hash" exists, and
there is no requirement to set an "ipfs_hash" value
in the same RPC that sets the "permanent_ipfs_hash"
value
- Post-fork, for pre-fork-issued (V1) assets with
"reissuable"==False and the asset has an ipfs_hash,
"permanent_ipfs_hash" will be automatically set to
"ipfs_hash"
- In this case, if the first "reissue",
"reissuerestrictedasset" or "updatemetadata" RPC
call on that asset attempts to change
"permanent_ipfs_hash" to another value, then that
request will have no effect, it will not generate an
RPC error, and other change requests within that RPC
call will be performed.
- Subsequent RPCs which attempt to change
"permanent_ipfs_hash" will generate an RPC error and
the RPC will not perform any requests within that
call.
- Post-fork, for pre-fork-issued (V1) assets with
"reissuable"==False and the asset has NO ipfs_hash:
- setting and subsequently changing the "ipfs_hash"
value can be done by RPC at any time
- setting the ipfs_hash does not automatically set
the "permanent_ipfs_hash"
- the ONLY way to set the "permanent_ipfs_hash" is
by using an RPC which specifies the values of both
"ipfs_hash" and "permanent_ipfs_hash" in the same
RPC
- the two values can be the same or different
- the "ipfs_hash" can have been unset prior to
this RPC or it could have been previously set
- attempting to set the "permanent_ipfs_hash"
without specifying the "ipfs_hash" in the same RPC
generates an RPC error
Add new RPC "getburnaddresses"
- returns a list of all the burn addresses for the chain
"EXissueAssetXXXXXXXXXXXXXXXXYiYRBD"
"EXReissueAssetXXXXXXXXXXXXXXY1ANQH"
"EXissueSubAssetXXXXXXXXXXXXXWW1ASo"
"EXissueUniqueAssetXXXXXXXXXXTZjZJ5"
"EXissueMsgChanneLAssetXXXXXXXD3mRa"
"EXissueQuaLifierXXXXXXXXXXXXW5Zxyf"
"EXissueSubQuaLifierXXXXXXXXXUgTjtu"
"EXissueRestrictedXXXXXXXXXXXZZMynb"
"EXaddTagBurnXXXXXXXXXXXXXXXXb5HLXh"
"EXBurnXXXXXXXXXXXXXXXXXXXXXXZ8ZjfN"
"EXBurnMintXXXXXXXXXXXXXXXXXXXbdK5E"
- testnet/regtest burn addresses:
"n1issueAssetXXXXXXXXXXXXXXXXWdnemQ"
"n1ReissueAssetXXXXXXXXXXXXXXWG9NLd"
"n1issueSubAssetXXXXXXXXXXXXXbNiH6v"
"n1issueUniqueAssetXXXXXXXXXXS4695i"
"n1issueMsgChanneLAssetXXXXXXT2PBdD"
"n1issueQuaLifierXXXXXXXXXXXXUysLTj"
"n1issueSubQuaLifierXXXXXXXXXYffPLh"
"n1issueRestrictedXXXXXXXXXXXXZVT9V"
"n1addTagBurnXXXXXXXXXXXXXXXXX5oLMH"
"n1BurnXXXXXXXXXXXXXXXXXXXXXXU1qejP"
"n1BurnMintXXXXXXXXXXXXXXXXXXbVTQiY"
Add new RPC "updatemetadata" (cost = 1
EVR)
- costs only 1 EVR fee paid to
- can change only the fields:
- "ipfs_hash"
- "permanent_ipfs" (if not already set)
- "toll_address"
- "toll_amount"
- "toll_amount_mutability"
- "toll_address_mutability"
- these fields can be changed using the "updatemetadata"
RPC regardless whether the asset has "reissuable" set
True or False
Add new RPC "getcalculatedtoll"
- useful for calculating the toll you must pay for a
Toll_Asset transfer and determining which address to pay
the toll to.
- note that while the toll_amount can be set as low as 1
satoshi (1e-8 EVR) and the qty can be set as high as 21
billion, the calculated toll will be reassigned within
the limits of 0.00005 EVR minimum and 1 Billion EVR
maximum
Add new RPC "remint" (cost = 0.1 EVR)
- Use to remint assets which were previously sent to the
BurnMint address
- For more details, see description below of BurnMint
functionality
Add Toll_Asset support
- Uses four (4) new asset metadata fields:
- "toll_amount" >= 0 EVR per qty per asset
- "toll_address" == any valid Evrmore address
- "toll_amount_mutability" == True/False
- "toll_address_mutability" == True/False
- Permitted for Root_Assets, Sub_Assets,
Restricted_Assets and Unique_Assets
- Not permitted for Qualifier_Assets or
SubQualifier_Assets
- Toll payment is required for transfers of an asset to
all addresses except to the address from which the asset
came
- note the implication that this requires address
reuse for asset "wallet change" to avoid paying toll
on asset transfers to yourself
- The toll required is ("toll_amount" * qty_of_asset)
paid to "toll_address"
- The calculated toll will be reassigned within the
limits of 0.00005 EVR minimum and 1 Billion EVR maximum
- For legacy pre-fork (V1) assets "toll_amount"==0 and
can never be increased
- The 4 toll metadata fields can be altered by the RPCs
"issue", "issuerestrictedasset", "reissue",
"reissuerestrictedasset", "issueunique" and
"updatemetadata"
- "toll_amount_mutability" can be changed from True to
False but never from False to True
- "toll_address_mutability" can be changed from True
to False but never from False to True
- "toll_amount" can be decreased but never increased
- The issue RPCs generate an error if toll_amount is
set non-zero without specifying a valid toll_address
or if a valid toll_address is specified with
toll_amount=0
- Unwanted Toll_Assets can be sent to the GlobalBurn
address toll-free
- Mainnet GlobalBurn address:
"EXBurnXXXXXXXXXXXXXXXXXXXXXXZ8ZjfN"
- Testnet/Regtest GlobalBurn address:
"n1BurnXXXXXXXXXXXXXXXXXXXXXXU1qejP"
Add new BurnMint addresses for
remintability
- Mainnet BurnMint address:
EXBurnMintXXXXXXXXXXXXXXXXXXXbdK5E
- Testnet/Regtest BurnMint address:
n1BurnMintXXXXXXXXXXXXXXXXXXbVTQiY
Add support for Burn/Remint
functionality
- Uses the new "remint" RPC to remint assets which were
previously sent to the BurnMint address
- Permitted for Root_Assets, Sub_Assets,
Restricted_Assets
- Not permitted for Unique_Assets, Qualifier_Assets or
SubQualifier_Assets
- Uses one new asset metadata field:
- "remintable" == True/False
- Can be used only if the asset metadata
"remintable"==True
- "remintable" can be set True by RPCs "issue" and
"issuerestrictedasset" (defaults to True if not
specified)
- "remintable" can be set False by RPCs "issue",
"issuerestrictedasset", and "remint"
- On legacy pre-fork (V1) assets, "remintable" will be
shown post-fork as "False" initially and will remain
"False" if the asset is non-reissuable. But if the asset
is reissuable, then the "remintable" value will be
automatically changed to "True" during any asset
transfer, reissue, or remint RPC.
- The node calculates and tracks: "total_burned",
"currently_burned", "reminted_total"
- The max qty of assets to remint must be <=
"currently_burned" which is calculated and tracked by
the node as ("total_burned"-"reminted_total")
- In scenarios where assets are burned and reminted
within the same block, reminting will be restricted to
the balance burned prior to the block being processed.
- Note that reminting assets does not remove the
quantity of those assets at the BurnMint address (nobody
has the key to that address). But assets at the BurnMint
address are not counted in the "amount" of assets
reported by the RPCs such as "getassetdata".
For Burn/Remint functionality,
- the assets should be burned by transferring them to:
- "EXBurnMintXXXXXXXXXXXXXXXXXXXbdK5E" for mainnet
- "n1BurnMintXXXXXXXXXXXXXXXXXXbVTQiY" for
testnet/regtest
- and when reminting, the fee (0.1
EVR) should be sent to:
- "EXReissueAssetXXXXXXXXXXXXXXY1ANQH"
- "n1ReissueAssetXXXXXXXXXXXXXXWG9NLd"
Note:
The update metadata RPC will only modify
parameters which are modifiable and it is up to the
application which is making the RPC calls to keep track of
the modifiability states. The state of the asset's
"reissuable" metadata is irrelevant. The user gets charged
the transaction fee and the 1 EVR RPC fee, and the
transaction will be mined, regardless whether the RPC was
able to do what the user wanted. There are guard rails for
the RPC commands to stop them from broadcasting
transaction which cannot have the desired effects. People
who manually build transactions in a third-party
application will not be protected by those guard rails so
they need to check metadata states. Note also that an
attempt to change "permanent_ipfs_hash" when it has
already been set will generate an error and none of the
requested changes will be performed.
Note:
The RPC commands "reissue" and
"reissuerestrictedasset" can be used to change asset
metadata fields regardless whether the asset has
"reissuable" set True or False. If the reissue RPC is used
to change only these metadata fields, then the operation
is equivalent to an "updatemetadata" RPC call, and only 1
EVR fee is required for the RPC rather than the full 100
EVR usually required for reissue RPCs. The metadata fields
are the same as for the "updatemetadata" RPC command
("ipfs_hash", "permanent_ipfs", "toll_address",
"toll_amount", "toll_amount_mutability",
"toll_address_mutability") and additionally "reissuable",
which can be set False if it is True. The RPC will change
only those requested fields which it is permitted to
change, and will return an error only if it makes no
changes (because no changes were requested or because none
of the requested changes were permitted). There is an
exception that an attempt to change "permanent_ipfs_hash"
when it has already been set will generate an error and
none of the requested changes will be performed.
RPC Fees
- Issue Asset: 500 EVR
- Reissue Asset: 100 EVR
- Issue Sub-Asset: 100 EVR
- Issue Unique Asset: 5 EVR
- Issue Msg Channel Asset: 100 EVR
- Issue Qualifier Asset: 1000 EVR
- Issue Sub Qualifier Asset: 100 EVR
- Issue Restricted Asset: 1500 EVR
- Add Null Qualifier Tag: 0.1 EVR
- Reissue Metadata Only: 1 EVR
- Remint Asset: 0.1 EVR