Your own native token on the JUNO chain! Better UI, UX, and Developer Experience
The Cosmos stack has a native x/bank module which allows for the minting and sending of tokens without having to follow the CW20 (from ERC20) spec.
- Airdrops are many times easier for users holding DAO tokens from a state export, rather than slow paginated CW20 queries
- Frontends such as Keplr and Mintscan will be able to show off your tokens via a single query, rather than RPC querying every CW20 contract (inefficient!)
- Contract developers no longer have to add support for CW20 when all contracts already have native tokens support built in to work with Juno!
- CLI based users will be able to send any token via the standard junod tx bank send instead of wasm execute CW20 message passthroughs with base64 encoded data
To get started, you will need to create a new denomination from the factory. At the time of writing (March 3, 2023) the cost to create a new token is 1 JUNO. This is to deter spamming of tokens. You can create this token like so:
junod tx tokenfactory create-denom [denom-name] [flags]
This will create a denomination you are the admin of which will follow the format
factory/juno1addresshere/denom1. This ensures there are no namespace conflicts.
You can view the tokens you control with the following:
junod q tokenfactory denoms-from-creator juno1address... [flags]
This command will return a list of all denominations created by the account with address
You can modify the token metadata to include a human readable ticker symbol, description, and the exponent of the token. We recommend setting these for your denomination before deploying out into production.
junod tx tokenfactory modify-metadata \
factory/juno1/denom1 SYMBOL "https://description.com" 6 [flags]
SYMBOLis the Ticker symbol for your token. Usually this should be the all capitalized version after the last / in your factory. Example: If your token is
factory/juno1/ugoldyour tokens symbol should likely be
GOLDfor it to show up as
$GOLDin frontends such as Mintscan and Keplr.
The description is an area to link to your website, ipfs, discord, or any other data which is useful to describe what the token does.
Finally the exponent section is helpful for frontends to display your token as expected. Typically this will be
6for most cosmos tokens. If you do not know what value to give it, stay with
6. This means 1TOKEN in human readable form is actually 1x(10^6) tokens (1_000_000) to allow for fractional tokens. Without this, each token has no ability to handle fraction like values.
If you are creating this token to be used as a GAMM, Liquidity Pool, or EVM compatible denomination, you should use**
You can query the token metadata via the x/bank module query
junod query bank denom-metadata --denom [denom-name] --output=json [flags]
Where denom-name is the entire denomination value
"description": "my description here https://domain.com",
junod tx tokenfactory mint 100factory/juno1.../denom1 --from key [flags]
junod tx bank send [key] juno1addresshere 10factory/juno1.../denom1 [flags]
One of the biggest use cases for a tokenfactory token is to allow a contract to mint on the behalf of other contracts / DAOs. This is possible with the Token Factory Core Middleware Contract on github. This contract can:
- Mint tokens on behalf of whitelisted contracts addresses via WasmMsg
- Allows an address to add / remove addresses from minting on its behalf
- Burn tokenfactory tokens
This means a DAO/SubDAO/Mutlisig is the manager of the contract. On its behalf, the middleware contract is the direct admin of the tokenfactory denominations so it can mint tokens. Then the DAO/SubDAO/Multisig can add or remove deployed contracts from minting tokens on its behalf. Without this, every contract you control would need its own denomination, which is too limiting if you want to use the same denomination on 2 or more contracts.