coinsaccording to a set of rules. These rules include the total supply, initial ownership, inflation rules, etc. A token's issued
coinscan be transacted like any other coin. They must go through an
exchangeto change denominations. A token is either created by defining a coin denomination and distribution in the genesis block, or through a special
markermodule that provides these features on a running network.
govmodule that takes a submitted configuration proposal and posts it for vote by stake holders. If the vote passes then the proposed changes are applied.
markeris created the address that submits the transaction is bound as the manager of the marker. While the
markeris in this initial
proposedstate the manager address is allowed to submit transactions to modify without further permission checks. After a marker transitions to the
activestate the manager is removed and the normal permission controls are fully enforced.
mint(increase supply) for an active status marker
burn(decrease supply) for an active status marker
scopeagainst the marker (Note: scope permission checks are separately performed, address must have access to both marker and scope to perform this action)
proposedstatus marker, finalizes configuration (manager only)
finalizedstatus marker, activates configuration (manager only)
proposedmarker to a cancelled state
send_enabled, transfer authority allows the coins to be sent between accounts when the send transaction includes a signature from the account holding this permission using the marker module's send function. This permission only applies to markers with a type of RESTRICTED. Note: only
markerdenom may be transfered using this capability
1..∞bounded only by the maximum amounts supported by the SDK for storing coin values. Depending on the type of marker a supply invariant will be enforced that will mint coin directly into the marker's account if an external burn is performed (for example if a slashing penalty has been applied).
mintfunction is used to issue
coinagainst the marker. This action is implicitly done for any amount greater than zero for
Supplywhen the finalized marker is
mintmay also be performed (as allowed) post activation. Minted coins are assigned to the marker account itself after which they maybe withdrawn by an authorized user into their own account. Once withdrawn these coins are moved through normal transfer or exchange processes.
coinof the current
markerdenom may be burned in any case regardless of what coin denominations are held in the marker's account.
withdrawpermissions or though the governance process.
send_enabledcoin may be sent to a marker account. These amounts are subject to the same
withdrawpermissions regardless of their denomination.
tokencontrolled against an omnibus bank account. The bank itself (or its designated integrator) is responsible for ensuring the supply of the token always matches value of the fiat account balance in its omnibus account.
markermodule is used to issue the
tokenon chain. The integrator's account address must configure the marker to reserve the right to mint and burn coin issuances in order to match the account balance changes. An initial supply may be set to reflect the starting account balance. The deposit and withdraw features for assets backing the marker do not apply and should be disabled to prevent their accidental use. The ability to modify the settings of the marker should be reserved by the integrator's account address (if allowed at all).
tokendenomination. The integrator is also responsible for providing a facility to accept coin and remit value from the omnibus account to the entity presenting the coin. When a withdraw is made from the omnibus bank account the removed fiat balance must be burned from the supply of coin issued from the marker. As the coin in circulation can not be burned directly, this will require the integrator to ensure that any withdraw has an associated transfer of the coin back to the integrator or marker accounts such that the integrator has control of the coin asset to fill the burn request. This process keeps the account in sync with the value represented on chain.
hash. As the power to control the network is defined up front, the initial allocations of
hashcoins are distributed in the
genesisprocess. The terms of the supply are fixed such that there is no need to use the
markermodule to support any kind of on going management of the
token. To support these restrictions the marker module list of permissions is empty.
inflationconcept is not used for
hashand as such the overall supply will always remain at exactly
100 billionand is enforced through an
hashstake token on the Provenance Blockchain are not expected to change, if provisions for this process are desired then the Governance based management process can be used to adjust the parameters of the
send_enabled: falseconfiguration on the denomination to prevent users from directly transferring value between addresses.
transferpermission allows an address possessing it to directly exchange value using the marker module send function. This permission can be granted to a smart contract address for example to provide strict controls on the transfer of value of the marker's denominated coins between accounts.
transfermethod on the api.
supplyfield when it is activated. For markers that have a fixed supply an invariant check is enforced that ensures the supply of the marker alway matches the configured value. For a floating supply no additional checks or adjustments are performed and the supply value is set to zero when activated.
proposedstatus will accept changes to supply via the
burnmethods, updates to the access list, and state transitions when called by the address set in the
manageraddress on the marker
fixed_supplythe Invariant checks are performed in
managerfield is cleared. All management actions require explicit permission grants.
deletepermission assigned to their address or
UnrestrictedDenomRegexparameter would be used to enforce longer denom values (preventing users from creating coins with well known symbols such as BTC, ETH, etc). Markers added via governance proposal are only limited by the more generic Coin Validation Denom expression enforced by the bank module.
Activestatus with the appropriate minting operations performed immediately.