Messages
In this section we describe the processing of the tokenfactory messages and the corresponding updates to the state.
Messages
CreateDenom
Creates a denom of factory/{creator address}/{subdenom}
given the denom creator address and the subdenom. Subdenoms can contain [a-zA-Z0-9./]
.
State Modifications:
Fund community pool with the denom creation fee from the creator address, set in
Params
.Set
DenomMetaData
via bank keeper.Set
AuthorityMetadata
for the given denom to store the admin for the created denomfactory/{creator address}/{subdenom}
. Admin is automatically set as the Msg sender.Add denom to the
CreatorPrefixStore
, where a state of denoms created per creator is kept.
Mint
Minting of a specific denom is only allowed for the current admin. Note, the current admin is defaulted to the creator of the denom.
State Modifications:
Safety check the following
Check that the denom minting is created via
tokenfactory
moduleCheck that the sender of the message is the admin of the denom
Mint designated amount of tokens for the denom via
bank
module
Burn
Burning of a specific denom is only allowed for the current admin. Note, the current admin is defaulted to the creator of the denom.
State Modifications:
Safety check the following
Check that the denom minting is created via
tokenfactory
moduleCheck that the sender of the message is the admin of the denom
Burn designated amount of tokens for the denom via
bank
module
ChangeAdmin
Change the admin of a denom. Note, this is only allowed to be called by the current admin of the denom.
SetDenomMetadata
Setting of metadata for a specific denom is only allowed for the admin of the denom. It allows the overwriting of the denom metadata in the bank module.
State Modifications:
Check that sender of the message is the admin of denom
Modify
AuthorityMetadata
state entry to change the admin of the denom
Expectations from the chain
The chain's bech32 prefix for addresses can be at most 16 characters long.
This comes from denoms having a 128 byte maximum length, enforced from the SDK, and us setting longest_subdenom to be 44 bytes.
A token factory token's denom is: factory/{creator address}/{subdenom}
Splitting up into sub-components, this has:
len(factory) = 7
2 * len("/") = 2
len(longest_subdenom)
len(creator_address) = len(bech32(longest_addr_length, chain_addr_prefix))
.
Longest addr length at the moment is 32 bytes
. Due to SDK error correction settings, this means len(bech32(32, chain_addr_prefix)) = len(chain_addr_prefix) + 1 + 58
. Adding this all, we have a total length constraint of 128 = 7 + 2 + len(longest_subdenom) + len(longest_chain_addr_prefix) + 1 + 58
. Therefore len(longest_subdenom) + len(longest_chain_addr_prefix) = 128 - (7 + 2 + 1 + 58) = 60
.
The choice between how we standardized the split these 60 bytes between maxes from longest_subdenom and longest_chain_addr_prefix is somewhat arbitrary. Considerations going into this:
Per BIP-0173 the technically longest HRP for a 32 byte address ('data field') is 31 bytes. (Comes from encode(data) = 59 bytes, and max length = 90 bytes)
subdenom should be at least 32 bytes so hashes can go into it
longer subdenoms are very helpful for creating human readable denoms
chain addresses should prefer being smaller. The longest HRP in cosmos to date is 11 bytes. (
persistence
)
For explicitness, its currently set to len(longest_subdenom) = 44
and len(longest_chain_addr_prefix) = 16
.
Please note, if the SDK increases the maximum length of a denom from 128 bytes, these caps should increase.
So please don't make code rely on these max lengths for parsing.
Last updated