The marker module provides comprehensive capabilities for creating and managing fungible tokens on the Provenance blockchain, supporting both standard coins and restricted coins (securities) with configurable supply controls, permission-based access management, and sophisticated transfer restrictions including required attributes and forced transfers, enabling fractional ownership tracking and governance-controlled or user-managed token administration.
ConceptsContextOverviewTransfersTransfer RestrictionsTransfer PermissionForced TransfersRequired AttributesDeposits and WithdrawalsStateSummaryMarker AccountsMarker TypesAccess GrantsFixed Supply vs FloatingWhen a Marker has a Fixed Supply that does not match targetForced TransfersRequired AttributesMarker Address CacheMarker Net Asset ValueParamsState TransitionsUndefinedProposedFinalizedActiveCancelledDestroyedMessagesSummaryMsg/AddMarkerRequestMsg/AddAccessRequestMsg/DeleteAccessRequestMsg/FinalizeRequestMsg/ActivateRequestMsg/CancelRequestMsg/DeleteRequestMsg/MintRequestMsg/BurnRequestMsg/WithdrawRequestMsg/TransferRequestMsg/IbcTransferRequestMsg/SetDenomMetadataRequestMsg/AddFinalizeActivateMarkerRequestMsg/GrantAllowanceRequestMsg/SupplyIncreaseProposalRequestMsg/UpdateRequiredAttributesRequestMsg/UpdateSendDenyListRequestMsg/UpdateForcedTransferRequestMsg/SetAccountDataRequestMsg/AddNetAssetValuesRequestEventsSummaryMarker AddedGrant AccessAccess Grant FormatRevoke AccessFinalizeActivateCancelDestroyMintBurnWithdrawTransferSet Denom MetadataDenom Unit FormatSet Net Asset ValueQueriesSummaryParamsQueryParamsRequestQueryParamsResponseAllMarkersQueryAllMarkersRequestQueryAllMarkersResponseMarkerQueryMarkerRequestQueryMarkerResponseHoldingQueryHoldingRequestQueryHoldingResponseBalanceSupplyQuerySupplyRequestQuerySupplyResponseEscrowQueryEscrowRequestQueryEscrowResponseAccessQueryAccessRequestQueryAccessResponseDenomMetadataQueryDenomMetadataRequestQueryDenomMetadataResponseAccountDataQueryAccountDataRequestQueryAccountDataResponseNetAssetValuesQueryNetAssetValuesRequestQueryNetAssetValuesResponseParamsSummaryParamsDefinitionsSpecial Topics
Concepts
The marker module provides the capability for creation and management of fungible tokens on the Provenance blockchain. Various types of tokens can be represented including standard coins and restricted coins (securities).
Further the marker module allows for coins to be fixed upon creation or managed by an identified list of accounts, or through the governance proposal process.
Context
Using the blockchain as a ledger requires the ability to track fungible and non-fungible resources on chain with fractional ownership. Each of these resources requires rules governing supply and exchange. Examples of resources include fractional ownership in the network itself (stake), credits for network resources (gas/fees), fractional ownership of an arbitrary asset (metadata/scope), and omnibus account balances (stable coins). The rules governing the asset must be enforced by the blockchain itself such that the entity controlling the asset must abide by these rules and is not able to invalidate these processes. These enforced constraints are what provide the value and support trust in the platform itself.
Overview
The marker module provides various tools for defining fractional ownership and control. Markers can be created and managed by normal Msg requests or through the governance process. A marker can have many users with explicit control or none at all.
A marker can be used to create a coin that can be freely exchange or one that requires facilitated transfer by the marker itself when invoked by a user/process with appropriate permissions.
Transfers
There are some complex interactions involved with transfers of restricted coins.
Transfer Restrictions
Accounting of restricted coins is handled by the bank module. Restricted funds can be moved using the bank module's MsgSend or MsgMutliSend. They can also be moved using the marker module's MsgTransferRequest. During such transfers several things are checked using a SendRestrictionFn injected into the bank module. This restriction is applied in almost all instances when funds are being moved between accounts. The exceptions are delegations, undelegations, minting, burning, and marker withdrawals.
Transfer Permission
One permission that can be granted to an address is transfer. The transfer permission is granted to accounts that represent a "Transfer Agent" or "Transfer Authority" for restricted marker tokens. An address with transfer permission can utilize MsgTransferRequest to move restricted funds from one account to another.
The source account must be the admin's own account, or else there must be a MarkerTransferAuthorization grant (in the authz module) from the source account to the admin. MsgSend and MsgMultiSend can also be used by an address with transfer permission to move funds out of their own account.
Forced Transfers
If a restricted marker allows forced transfers, the force_transfer permission grants an account the ability to use the Transfer endpoint to move marker funds out of almost any account. An account with force_transfer cannot use other means to move marker funds (e.g. MsgSend) unless they also have transfer access.
A restricted coin marker can be configured to allow forced transfers. If allowed, an account with force_transfer permission can use a MsgTransferRequest to transfer the restricted coins out of almost any account to another. Forced transfer cannot be used to move restricted coins out of module accounts or smart contract accounts, though.
Required Attributes
Required attributes allow a marker Transfer Authority to define a set of account attestations created with the name/attribute modules to certify an account as an approved holder of the token. Accounts that possess all of the required attributes are considered authorized by the Transfer Authority to receive the token from normal bank send operations without a specific Transfer Authority approval. Required attributes are only supported on restricted markers.
For example, say account A has some restricted coins of a marker that has required attributes. Also say account B has all of those required attributes, and account C does not. Account A could use a MsgSend to send those restricted coins to account B. However, account B could not send them to account C (unless B also has transfer permission). If a restricted coin marker does not have any required attributes defined, the only way the funds can be moved is by someone with transfer permission.
Deposits and Withdrawals
Deposits: A deposit is when any funds are being sent to a marker's account. The funds being sent do not have to be in the denom of the destination marker. Whenever funds are being deposited into a marker, the sender (or transfer authority) must have deposit permission on the target marker. If the funds to deposit are restricted coins, the sender (or transfer authority) also needs transfer permission on the funds being moved; required attributes are not taken into account.
Withdrawals: A withdrawal is when any funds are being sent out of a marker's account. The funds being sent do not have to be in the denom of the source marker. Withdraws can be made using the Withdraw endpoint, or another endpoint that utilizes a transfer agent (e.g. the exchange module's MarketCommitmentSettle). Whenever funds are being withdrawn, the transfer agent must have withdraw permission on the source marker.
State
Summary
The marker module state consists of MarkerAccount structures that extend the base account type with comprehensive configuration including access control lists, supply management, required attributes for restricted transfers, forced transfer capabilities, and net asset value tracking, along with performance-optimized address caching and module-wide parameters for system-level marker functionality control.
Marker Accounts
Markers are represented as a type that extends the base_account type of the auth SDK module. As a valid account a marker is able to perform normal functions such as receiving and holding coins, and having a defined address that can be queried against for balance information from the bank module.
GitHub Repository: provenance/proto/provenance/marker/v1/marker.proto#L28-L63
protobuftype MarkerAccount struct { // cosmos base_account including address and account number Address string AccountNumber uint64 PubKey *types.Any // NOTE: not used for marker, it is not possible to sign for a marker account directly Sequence uint64 // NOTE: always zero on marker // Address that owns the marker configuration. This account must sign any requests // to change marker config (only valid for statuses prior to finalization) Manager string // Access control lists. Account addresses are assigned control of the marker using these entries AccessControl []AccessGrant // Indicates the current status of this marker record. (Pending, Active, Cancelled, etc) Status MarkerStatus // value denomination. Denom string // the total supply expected for a marker. This is the amount that is minted when a marker is created. For // SupplyFixed markers this value will be enforced through an invariant that mints/burns from this account to // maintain a match between this value and the supply on the chain (maintained by bank module). For all non-fixed // supply markers this value will be set to zero when the marker is activated. Supply Int // Marker type information. The type of marker controls behavior of its account. MarkerType MarkerType // A fixed supply will mint additional coin automatically if the total supply decreases below a set value. This // may occur if the coin is burned or an account holding the coin is slashed. (default: true) SupplyFixed bool // indicates that governance based control is allowed for this marker AllowGovernanceControl bool // Whether an admin can transfer restricted coins from a 3rd-party account without their signature. AllowForcedTransfer bool // list of required attributes on restricted marker in order to send and receive transfers if sender does not have // transfer authority RequiredAttributes []string }
Marker Types
There are currently two basic types of markers:
- Coin - A marker with a type of coin represents a standard fungible token with zero or more coins in circulation
- Restricted Coin - Restricted Coins work just like a regular coin with one important difference--the bank module "send_enabled" status for the coin is set to false. This means that a user account that holds the coin can not send it to another account directly using the bank module. In order to facilitate exchange there must be an address set on the marker with the "Transfer" permission grant. This address must sign calls to the marker module to move these coins between accounts using the transfer method on the api.
Access Grants
Control of a marker account is configured through a list of access grants assigned to the marker when it is created or applied afterwards through the API calls to add or remove access.
goconst ( // ACCESS_UNSPECIFIED defines a no-op vote option. Access_Unknown Access = 0 // ACCESS_MINT is the ability to increase the supply of a marker. Access_Mint Access = 1 // ACCESS_BURN is the ability to decrease the supply of the marker using coin held by the marker. Access_Burn Access = 2 // ACCESS_DEPOSIT is the ability to transfer funds from another account to this marker account // or to set a reference to this marker in the metadata/scopes module. Access_Deposit Access = 3 // ACCESS_WITHDRAW is the ability to transfer funds from this marker account to another account // or to remove a reference to this marker in the metadata/scopes module. Access_Withdraw Access = 4 // ACCESS_DELETE is the ability to move a proposed, finalized or active marker into the cancelled state. // This access also allows cancelled markers to be marked for deletion. Access_Delete Access = 5 // ACCESS_ADMIN is the ability to add access grants for accounts to the list of marker permissions. // This access also gives the ability to update the marker's denom metadata. Access_Admin Access = 6 // ACCESS_TRANSFER is the ability to manage transfer settings and broker transfers of the marker. // Accounts with this access can: // - Update the marker's required attributes. // - Update the send-deny list. // - Use the transfer or bank send endpoints to move marker funds out of their own account. // This access right is only supported on RESTRICTED markers. Access_Transfer Access = 7 // ACCESS_FORCE_TRANSFER is the ability to transfer restricted coins from a 3rd-party account without their signature. // This access right is only supported on RESTRICTED markers and only has meaning when allow_forced_transfer is true. Access_ForceTransfer Access = 8 ) // A structure associating a list of access permissions for a given account identified by is address type AccessGrant struct { // A bech32 encoded address string of the account the permissions are assigned to Address string // An array of enum values as defined above Permissions AccessList }
An admin with
Access_ForceTransfer
can use the Transfer
endpoint to move marker funds (forced or not). However, an admin with Access_ForceTransfer
, but without Access_Transfer
, cannot move marker funds by other means (e.g. a bank Send
). I.e. Access_ForceTransfer
only has meaning with the Transfer
endpoint.Fixed Supply vs Floating
A marker can be configured to have a fixed supply or one that is allowed to float. A marker will always mint an amount of coin indicated in its supply field when it is activated. For markers that have a fixed supply an invariant check is enforced that ensures the supply of the marker always 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.
When a Marker has a Fixed Supply that does not match target
Under certain conditions a marker may begin a block with a total supply in circulation less than its configured amount. When this occurs the marker will take action to correct the balance of coin supply.
A fixed supply marker will attempt to automatically correct a supply imbalance at the start of the next block:
- If the supply in circulation exceeds the configured amount the attempted fix is to burn a required amount from the marker's account itself. If this fails an invariant will be broken and the chain will halt.
- If the requested supply is greater than the amount in circulation (as occurs when a coin is burned in a slash) the marker module will mint the difference between expected supply and circulation and place the created coin in the marker's account.
A supply imbalance typically occurs during the genesis of a blockchain when a fixed supply for a marker is less than the initial balances assigned to accounts. It may also occur if the marker is associated with the bind denom of the chain and a slash penalty is assessed resulting in the burning of a portion of coins.
Forced Transfers
A marker with the Restricted Coin type can be configured to allow forced transfer of funds for that marker's denom.
A forced transfer is one where the admin (with
ACCESS_FORCE_TRANSFER
) is different than the from address. In such cases, if the marker allows forced transfers, the transfer is allowed. If forced transfers are not allowed, an admin cannot transfer the marker's coins from another account unless granted permission to do so via authz.Forced transfers can only be made using the marker module's
Transfer
endpoint.Markers with Coin type cannot be configured to allow forced transfers.
Required Attributes
A marker with the Restricted Coin type can be configured to allow transfers with a normal
MsgSend
to address that have defined attributes.This can be configured by setting the
required_attributes
array on the Marker. When a MsgSend
transaction is executed and the coin type is restricted, the required_attributes
are checked. If the ToAddress
associated with the MsgSend
command has all the required attributes, the transfer will be executed.A single wildcard can only be used for the starting name of the required attribute. For example,
*.provenance.io
is a valid wildcard attribute. Invalid wildcard usages include forms such as *kyc.provenance.io
or kyc.*.provenance.io
. Matching will be accepted for any number of child level names, i.e. one.two.three.provenance.io
and one.provenance.io
will be accepted for *.provenance.io
.Marker Address Cache
For performance purposes the marker module maintains a KVStore entry with the address of every marker account. This allows for cheap iterator operations over all marker accounts without having to filter through the native account iterator from the auth module.
plain text0x01 | Address -> Address
Marker Net Asset Value
A marker can support multiple distinct net asset values assigned to track settlement pricing information on-chain. The price attribute denotes the value assigned to the marker for a specific asset's associated volume. For instance, when considering a scenario where 10 billion nhash holds a value of 15ยข, the corresponding volume should reflect the quantity of 10,000,000,000. The update_block_height attribute captures the block height when the update occurred.
GitHub Repository: provenance/proto/provenance/marker/v1/marker.proto#L96-L104
Params
Params is a module-wide configuration structure that stores system parameters and defines overall functioning of the marker module.
- Params: Paramsspace("marker") -> legacy_amino(params)
GitHub Repository: provenance/proto/provenance/marker/v1/marker.proto#L14-L25
State Transitions
The marker module implements a comprehensive state transition system with five distinct states (Undefined, Proposed, Finalized, Active, Cancelled, and Destroyed) that control marker lifecycle from initial creation through supply management, access control enforcement, and final destruction, with specific requirements and permissions governing each transition to ensure proper marker configuration and supply validation before activation.
This document describes the state transition operations pertaining markers:
Undefined
The undefined status is not allowed and its use will be flagged as an error condition.
Proposed
The proposed status is the initial state of a marker. A marker in the proposed status will accept changes to supply via the mint/burn methods, updates to the access list, and state transitions when called by the address set in the manager property.
On Transition:
- Proposed is the initial state of a marker by default. It is not possible to transition to this state from any other.
Next Status:
- Finalized
- Cancelled
Finalized
The finalized state of the marker is used to verify the readiness of a marker before activating it.
Requirements:
- Marker must exist
- Caller address must match the manager address on the marker
- Current status of marker must be Proposed
- Supply of the marker must meet or exceed the amount of any existing coin in circulation on the network of the denom of the marker
On Transition:
- Marker status is set to Finalized
- A marker finalize typed event is dispatched
Next Status:
- Active
- Cancelled
Active
An active marker is considered ready for use.
On Transition:
- Marker status is set to Active
- Requested coin supply is minted and placed in the marker account
- For markers with a fixed_supply the Invariant checks are performed in begin_block
- Permissions as assigned in the access list are enforced for any management actions performed
- The manager field is cleared. All management actions require explicit permission grants.
- A marker activate typed event is dispatched
Next Status:
- Cancelled
Cancelled
A cancelled marker will have no coin supply in circulation. Markers may remain in the Cancelled state long term to prevent their denom reuse by another future marker. If a marker is no longer needed at all then the Destroyed status maybe appropriate.
Requirements:
- Caller must have the delete permission assigned to their address or
- Caller must be the manager of the marker (applies only to proposed markers that are Cancelled)
- The supply of the coin in circulation outside of the marker account must be zero.
On Transition:
- Marker status is set to Cancelled
- A marker Cancelled typed event is dispatched
Next Status:
- Destroyed
Destroyed
A destroyed marker is denoted as available for subsequent removal from the state store by clean up processes. Markers in the destroyed status will be removed in the Begin Block ABCI handler at the beginning of the next block (v1.3.0+).
On Transition:
- All supply of the coin denom will be burned.
- Marker status is set to Destroyed
- Marker will ultimately be deleted from the KVStore during the next ABCI Begin Block (v1.3.0+)
Next Status:
- None
Messages
Summary
The marker module provides comprehensive message endpoints for complete marker lifecycle management including creation, access control, state transitions, supply management, transfers for restricted coins, metadata configuration, governance proposals, and specialized features like forced transfers, required attributes, send deny lists, and net asset value tracking, with detailed validation rules and permission requirements for each operation.
In this section we describe the processing of the marker messages and the corresponding updates to the state. All created/modified state objects specified by each message are defined within the state section.
Msg/AddMarkerRequest
A marker is created using the Add Marker service message. The created marker can not be directly added in an Active (or Cancelled/Destroyed) status. Markers must have a valid supply and denomination value.
GitHub Repository: provenance/proto/provenance/marker/v1/tx.proto#L83-L102
protobufmessage MsgAddMarkerRequest { cosmos.base.v1beta1.Coin amount = 1; string manager = 3; MarkerType marker_type = 4; repeated AccessGrant access_list = 5; bool supply_fixed = 6; bool allow_governance_control = 7; bool allow_forced_transfer = 8; repeated string required_attributes = 9; uint64 usd_mills = 10; }
Expected failures:
- The Denom string is already in use, doesn't conform to validation expressions, or is invalid
- The supply value is less than zero or greater than max supply parameter
- The Marker Status is Active, Cancelled, or Destroyed
- The manager address is invalid
If issued via governance proposal with
from_address
of the governance module account, additional rules apply for status, denom validation, and manager settings.Msg/AddAccessRequest
Add Access Request is used to add permissions to a marker that allow the specified accounts to perform the specified actions.
GitHub Repository: provenance/proto/provenance/marker/v1/tx.proto#L98-L103
protobufmessage MsgAddAccessRequest { string denom = 1; string administrator = 2; repeated AccessGrant access = 3; }
Expected failures:
- Invalid denom or marker doesn't exist
- Invalid administrator address or insufficient permissions
- Invalid access list with duplicate entries or invalid access values
Msg/DeleteAccessRequest
DeleteAccess Request defines the Msg/DeleteAccess request type
GitHub Repository: provenance/proto/provenance/marker/v1/tx.proto#L108-L113
protobufmessage MsgDeleteAccessRequest { string denom = 1; string administrator = 2; string removed_address = 3; }
Msg/FinalizeRequest
Finalize Request defines the Msg/Finalize request type
GitHub Repository: provenance/proto/provenance/marker/v1/tx.proto#L117-L121
protobufmessage MsgFinalizeRequest { string denom = 1; string administrator = 2; }
The Finalize marker status performs a set of checks to ensure the marker is ready to be activated. It serves as an intermediate step prior to activation that indicates marker configuration is complete.
Msg/ActivateRequest
Activate Request defines the Msg/Activate request type
GitHub Repository: provenance/proto/provenance/marker/v1/tx.proto#L125-L129
protobufmessage MsgActivateRequest { string denom = 1; string administrator = 2; }
The Activate marker request will mint any coin required to achieve a circulation target set by the total supply. The marker will no longer be managed by an indicated "manager" account but will instead require explicit rights assigned as access grants for any modification.
Msg/CancelRequest
Cancel Request defines the Msg/Cancel request type
GitHub Repository: provenance/proto/provenance/marker/v1/tx.proto#L133-L137
protobufmessage MsgCancelRequest { string denom = 1; string administrator = 2; }
Msg/DeleteRequest
Delete Request defines the Msg/Delete request type
GitHub Repository: provenance/proto/provenance/marker/v1/tx.proto#L141-L145
protobufmessage MsgDeleteRequest { string denom = 1; string administrator = 2; }
Msg/MintRequest
Mint Request defines the Msg/Mint request type
GitHub Repository: provenance/proto/provenance/marker/v1/tx.proto#L149-L154
protobufmessage MsgMintRequest { cosmos.base.v1beta1.Coin amount = 1; string administrator = 2; }
Msg/BurnRequest
Burn Request defines the Msg/Burn request type that is used to remove supply of the marker coin from circulation. In order to successfully burn supply the amount to burn must be held by the marker account itself (in escrow).
GitHub Repository: provenance/proto/provenance/marker/v1/tx.proto#L158-L163
protobufmessage MsgBurnRequest { cosmos.base.v1beta1.Coin amount = 1; string administrator = 2; }
Msg/WithdrawRequest
Withdraw Request defines the Msg/Withdraw request type and is used to withdraw coin from escrow within the marker. Any denom coin can be held within a marker "in escrow", these values are not restricted to just the denom of the marker itself.
GitHub Repository: provenance/proto/provenance/marker/v1/tx.proto#L167-L174
protobufmessage MsgWithdrawRequest { string denom = 1; string administrator = 2; string to_address = 3; repeated cosmos.base.v1beta1.Coin amount = 4; }
Msg/TransferRequest
Transfer Request defines the Msg/Transfer request type. A transfer request is used to transfer coin between two accounts for RESTRICTED_COIN type markers. Such markers have send_enabled=false configured with the x/bank module, and thus cannot be sent using a normal MsgSend operation.
GitHub Repository: provenance/proto/provenance/marker/v1/tx.proto#L178-L185
protobufmessage MsgTransferRequest { cosmos.base.v1beta1.Coin amount = 1; string administrator = 2; string from_address = 3; string to_address = 4; }
Msg/IbcTransferRequest
Ibc transfer Request defines the Msg/IbcTransfer request type. The IbcTransferRequest is used to transfer RESTRICTED_COIN type markers to another chain via ibc. These coins have their send_enabled flag disabled by the bank module and thus cannot be sent using a normal send_coin operation.
GitHub Repository: provenance/proto/provenance/marker/v1/tx.proto#L190-L197
protobufmessage MsgIbcTransferRequest { cosmos.base.v1beta1.Coin transfer = 1; string administrator = 2; string from_address = 3; string to_address = 4; }
Msg/SetDenomMetadataRequest
SetDenomMetadata Request defines the Msg/SetDenomMetadata request type. This request is used to set the informational denom metadata held within the bank module for improved user experience in block explorers or similar applications.
GitHub Repository: provenance/proto/provenance/marker/v1/tx.proto#L202-L207
protobufmessage MsgSetDenomMetadataRequest { cosmos.bank.v1beta1.Metadata metadata = 1; string administrator = 2; }
Msg/AddFinalizeActivateMarkerRequest
AddFinalizeActivate requested is used for adding, finalizing, and activating a marker in a single request.
GitHub Repository: provenance/proto/provenance/marker/v1/tx.proto#L221-L236
protobufmessage MsgAddFinalizeActivateMarkerRequest { cosmos.base.v1beta1.Coin amount = 1; string manager = 3; MarkerType marker_type = 4; repeated AccessGrant access_list = 5; bool supply_fixed = 6; bool allow_governance_control = 7; bool allow_forced_transfer = 8; repeated string required_attributes = 9; uint64 usd_mills = 10; }
Msg/GrantAllowanceRequest
GrantAllowance grants a fee allowance to the grantee on the granter's account.
GitHub Repository: provenance/proto/provenance/marker/v1/tx.proto#L61-L72
protobufmessage MsgGrantAllowanceRequest { string denom = 1; string administrator = 2; string grantee = 3; google.protobuf.Any allowance = 4; }
Msg/SupplyIncreaseProposalRequest
SupplyIncreaseProposal is a governance-only message for increasing the supply of a marker.
GitHub Repository: provenance/proto/provenance/marker/v1/tx.proto#L229-L239
protobufmessage MsgSupplyIncreaseProposalRequest { cosmos.base.v1beta1.Coin amount = 1; string target_address = 2; string authority = 3; }
See also: Governance: Supply Increase Proposal
Msg/UpdateRequiredAttributesRequest
UpdateRequiredAttributes allows signers that have transfer authority or via gov proposal to add and remove required attributes from a restricted marker.
GitHub Repository: provenance/proto/provenance/marker/v1/tx.proto#L244-L255
protobufmessage MsgUpdateRequiredAttributesRequest { string denom = 1; repeated string remove_required_attributes = 2; repeated string add_required_attributes = 3; string transfer_authority = 4; }
Msg/UpdateSendDenyListRequest
UpdateSendDenyList allows signers that have transfer authority or via gov proposal to add and remove addresses to the deny send list for a restricted marker.
GitHub Repository: provenance/proto/provenance/marker/v1/tx.proto#L295-L308
protobufmessage MsgUpdateSendDenyListRequest { string denom = 1; repeated string remove_denied_addresses = 2; repeated string add_denied_addresses = 3; string authority = 4; }
Msg/UpdateForcedTransferRequest
UpdateForcedTransfer allows for the activation or deactivation of forced transfers for a marker. This message must be submitted via governance proposal.
GitHub Repository: provenance/proto/provenance/marker/v1/tx.proto#L260-L272
protobufmessage MsgUpdateForcedTransferRequest { string denom = 1; bool allow_forced_transfer = 2; string authority = 3; }
Msg/SetAccountDataRequest
SetAccountData allows the association of some data (a string) with a marker.
GitHub Repository: provenance/proto/provenance/marker/v1/tx.proto#L279-L291
protobufmessage MsgSetAccountDataRequest { string denom = 1; string value = 2; string signer = 3; }
This endpoint can either be used directly or via governance proposal.
Msg/AddNetAssetValuesRequest
AddNetAssetValuesRequest allows for the adding/updating of net asset values for a marker.
GitHub Repository: provenance/proto/provenance/marker/v1/tx.proto#L327-L332
protobufmessage MsgAddNetAssetValuesRequest { string denom = 1; repeated NetAssetValue net_asset_values = 2; string administrator = 3; }
This endpoint can either be used directly or via governance proposal.
Events
Summary
The marker module emits comprehensive events for all marker operations including creation, access management, state transitions, supply operations, transfers, metadata configuration, and net asset value updates, providing detailed attribute information for tracking marker lifecycle changes, administrative actions, and value management across the Provenance blockchain ecosystem.
The marker module emits the following events:
Marker Added
Fires when a marker is added using the Add Marker Msg.
Type:
provenance.marker.v1.EventMarkerAdd
Attribute Key | Attribute Value |
Denom | {denom string} |
Address | {marker address} |
Amount | {supply amount} |
Manager | {admin account address} |
Status | {current marker status} |
MarkerType | {type of marker} |
Grant Access
Fires when administrative access is granted for a marker
Type:
provenance.marker.v1.EventMarkerAddAccess
Attribute Key | Attribute Value |
Denom | {denom string} |
Administrator | {admin account address} |
Access | {access grant format} |
Access Grant Format
Type:
provenance.marker.v1.EventMarkerAccess
Attribute Key | Attribute Value |
Address | {bech32 address string} |
Permissions | {array of role names} |
Revoke Access
Fires when all access grants are removed for a given address.
Type:
provenance.marker.v1.EventMarkerDeleteAccess
Attribute Key | Attribute Value |
Denom | {denom string} |
Administrator | {admin account address} |
RemoveAddress | {address removed} |
Finalize
Fires when a marker is finalized.
Type:
provenance.marker.v1.EventMarkerFinalize
Attribute Key | Attribute Value |
Denom | {denom string} |
Administrator | {admin account address} |
Activate
Fires when a marker is activated.
Type:
provenance.marker.v1.EventMarkerActivate
Attribute Key | Attribute Value |
Denom | {denom string} |
Administrator | {admin account address} |
Cancel
Fired when a marker is cancelled successfully.
Type:
provenance.marker.v1.EventMarkerCancel
Attribute Key | Attribute Value |
Denom | {denom string} |
Administrator | {admin account address} |
Destroy
Fires when a marker is marked as destroyed and ready for removal.
Type:
provenance.marker.v1.EventMarkerDelete
Attribute Key | Attribute Value |
Denom | {denom string} |
Administrator | {admin account address} |
Mint
Fires when coins are minted for a marker.
Type:
provenance.marker.v1.EventMarkerMint
Attribute Key | Attribute Value |
Denom | {denom string} |
Amount | {supply amount} |
Administrator | {admin account address} |
Burn
Fires when coins are burned from a marker account.
Type:
provenance.marker.v1.EventMarkerBurn
Attribute Key | Attribute Value |
Denom | {denom string} |
Amount | {supply amount} |
Administrator | {admin account address} |
Withdraw
Fires during a marker Withdraw.
Type:
provenance.marker.v1.EventMarkerWithdraw
Attribute Key | Attribute Value |
Denom | {denom string} |
Amount | {supply amount} |
Administrator | {admin account address} |
ToAddress | {recipient account address} |
Transfer
Fires during a marker Transfer.
Type:
provenance.marker.v1.EventMarkerTransfer
Attribute Key | Attribute Value |
Denom | {denom string} |
Amount | {supply amount} |
Administrator | {admin account address} |
FromAddress | {source account address} |
ToAddress | {recipient account address} |
Set Denom Metadata
Fires when the denom metadata is set for a marker
Type:
provenance.marker.v1.EventMarkerSetDenomMetadata
Attribute Key | Attribute Value |
MetadataBase | {marker's denom string} |
MetadataDescription | {description string} |
MetadataDisplay | {denom string} |
MetadataName | {name string} |
MetadataSymbol | {symbol string} |
MetadataDenomUnits | {array of denom units} |
Administrator | {admin account address} |
Denom Unit Format
Denom units have a specified exponent (1-18), a specified denom, and a list of optional aliases. Example aliases for
uhash
might be microhash
or ยตhash
Type:
provenance.marker.v1.EventDenomUnit
Attribute Key | Attribute Value |
Denom | {denom string} |
Exponent | {uint} |
Aliases | {array of denom strings} |
Set Net Asset Value
Fires when a NetAssetValue is added or updated for a marker.
Type:
provenance.marker.v1.EventSetNetAssetValue
Attribute Key | Attribute Value |
Denom | {marker's denom string} |
Price | {token amount the marker is valued at for volume} |
Volume | {total volume/shares associated with price} |
Source | {source address of caller} |
Queries
Summary
The marker module provides comprehensive query endpoints for retrieving marker information including parameters, marker details, holder balances, supply amounts, escrow funds, access controls, denomination metadata, account data, and net asset values, enabling complete visibility into marker state and configuration across the Provenance blockchain ecosystem.
Params
Query the parameters of the marker module.
HTTP Endpoint:
/provenance/marker/v1/params
QueryParamsRequest
protobufmessage QueryParamsRequest {}
QueryParamsResponse
protobufmessage QueryParamsResponse { // params defines the parameters of the module. Params params = 1 [(gogoproto.nullable) = false]; }
AllMarkers
Returns a list of all markers on the blockchain with optional status filtering and pagination.
HTTP Endpoint:
/provenance/marker/v1/all
QueryAllMarkersRequest
protobufmessage QueryAllMarkersRequest { // Optional status to filter request MarkerStatus status = 1; // pagination defines an optional pagination for the request. cosmos.base.query.v1beta1.PageRequest pagination = 2; }
QueryAllMarkersResponse
protobufmessage QueryAllMarkersResponse { repeated google.protobuf.Any markers = 1 [(cosmos_proto.accepts_interface) = "MarkerAccountI"]; // pagination defines an optional pagination for the request. cosmos.base.query.v1beta1.PageResponse pagination = 2; }
Marker
Query for a single marker by denomination or address.
HTTP Endpoint:
/provenance/marker/v1/detail/{id}
QueryMarkerRequest
protobufmessage QueryMarkerRequest { // the address or denom of the marker string id = 1; }
QueryMarkerResponse
protobufmessage QueryMarkerResponse { google.protobuf.Any marker = 1 [(cosmos_proto.accepts_interface) = "MarkerAccountI"]; }
Holding
Query for all accounts holding the given marker coins.
HTTP Endpoint:
/provenance/marker/v1/holding/{id}
QueryHoldingRequest
protobufmessage QueryHoldingRequest { // the address or denom of the marker string id = 1; // pagination defines an optional pagination for the request. cosmos.base.query.v1beta1.PageRequest pagination = 2; }
QueryHoldingResponse
protobufmessage QueryHoldingResponse { repeated Balance balances = 1 [(gogoproto.nullable) = false]; // pagination defines an optional pagination for the request. cosmos.base.query.v1beta1.PageResponse pagination = 2; }
Balance
protobufmessage Balance { option (gogoproto.equal) = false; option (gogoproto.goproto_getters) = false; // address is the address of the balance holder. string address = 1; // coins defines the different coins this balance holds. repeated cosmos.base.v1beta1.Coin coins = 2 [ (gogoproto.nullable) = false, (gogoproto.castrepeated) = "github.com/cosmos/cosmos-sdk/types.Coins", (amino.dont_omitempty) = true, (amino.encoding) = "legacy_coins" ]; }
Supply
Query for supply of coin on a marker account.
HTTP Endpoint:
/provenance/marker/v1/supply/{id}
QuerySupplyRequest
protobufmessage QuerySupplyRequest { // address or denom for the marker string id = 1; }
QuerySupplyResponse
protobufmessage QuerySupplyResponse { // amount is the supply of the marker. cosmos.base.v1beta1.Coin amount = 1 [(gogoproto.nullable) = false]; }
Escrow
Query for coins on a marker account.
HTTP Endpoint:
/provenance/marker/v1/escrow/{id}
QueryEscrowRequest
protobufmessage QueryEscrowRequest { // address or denom for the marker string id = 1; }
QueryEscrowResponse
protobufmessage QueryEscrowResponse { repeated cosmos.base.v1beta1.Coin escrow = 1 [ (gogoproto.nullable) = false, (gogoproto.castrepeated) = "github.com/cosmos/cosmos-sdk/types.Coins", (amino.dont_omitempty) = true, (amino.encoding) = "legacy_coins" ]; }
Access
Query for access records on an account.
HTTP Endpoint:
/provenance/marker/v1/accesscontrol/{id}
QueryAccessRequest
protobufmessage QueryAccessRequest { // address or denom for the marker string id = 1; }
QueryAccessResponse
protobufmessage QueryAccessResponse { repeated AccessGrant accounts = 1 [(gogoproto.nullable) = false]; }
DenomMetadata
Query for denomination metadata associated with a marker.
HTTP Endpoint:
/provenance/marker/v1/getdenommetadata/{denom}
QueryDenomMetadataRequest
protobufmessage QueryDenomMetadataRequest { string denom = 1; }
QueryDenomMetadataResponse
protobufmessage QueryDenomMetadataResponse { cosmos.bank.v1beta1.Metadata metadata = 1 [(gogoproto.nullable) = false]; }
AccountData
Query for account data associated with a denomination.
HTTP Endpoint:
/provenance/marker/v1/accountdata/{denom}
QueryAccountDataRequest
protobufmessage QueryAccountDataRequest { // The denomination to look up. string denom = 1; }
QueryAccountDataResponse
protobufmessage QueryAccountDataResponse { // The accountdata for the requested denom. string value = 1; }
NetAssetValues
Query for net asset values associated with a marker.
HTTP Endpoint:
/provenance/marker/v1/netassetvalues/{id}
QueryNetAssetValuesRequest
protobufmessage QueryNetAssetValuesRequest { // address or denom for the marker string id = 1; }
QueryNetAssetValuesResponse
protobufmessage QueryNetAssetValuesResponse { // net asset values for marker denom repeated NetAssetValue net_asset_values = 1 [(gogoproto.nullable) = false]; }
Params
Summary
The marker module contains several governance-controlled parameters that regulate module operation including maximum supply limits for markers, governance control requirements, and denomination validation through regular expressions, all managed by the Param module and modifiable through governance proposals.
The marker module contains several settings that control operation of the module managed by the Param module and available for control via Governance proposal to change parameters.
Params
Key | Type | Example |
MaxTotalSupply | uint64 | "259200000000000" |
MaxSupply | math.Int | "259200000000000" |
EnableGovernance | bool | true |
UnrestrictedDenomRegex | string | "[a-zA-Z][a-zA-Z0-9-.]{7,83}" |
Definitions
- Max Total Supply (uint64) - A value indicating the maximum supply level allowed for any added marker. This is now deprecated and should not be used.
- Max Supply (math.Int) - A value indicating the maximum supply level allowed for any added marker.
- Enable Governance (boolean) - A flag indicating if
allow_governance_control
setting on added markers must be set totrue
.
- Unrestricted Denom Regex (string) - A regular expression that is used to check the denom value on markers added by calling AddMarker. This is intended to further restrict what may be used for a denom when a generic marker is created.