Empirical Study: x/tokenfactory CosmWasm Bindings and Admin Lifecycle in Gaia v26

TL;DR

We ran 6 real on-chain transactions on the provider testnet to document the complete lifecycle of a token created through a CosmWasm contract using the x/tokenfactory module in Gaia v26.

Key finding: when a denom is created via a CosmWasm contract, the contract, not the user wallet, becomes the denom admin. All privileged operations (mint, burn, modify-metadata) must be routed through the contract unless admin is explicitly transferred.


Background

Gaia v26 introduced the x/tokenfactory module to the Cosmos Hub, enabling any account to create native tokens in a fully permissionless manner, no governance proposal required. Tokens are namespaced by creator address:

factory/{creator_address}/{subdenom}

In this study we created CUM (Cumulo Validator Community Token), a limited-supply token, to explore the full operational lifecycle through a CosmWasm contract, including admin control, metadata registration, and supply management.


Operations Tested

Step Operation TX Hash
1 Instantiate contract (code 360) C613BBE9…
2 Create denom CUM 819BA821…
3 Mint 1000 CUM 75DB7FC4…
4 Transfer admin: contract → wallet D92F7AA5…
5 Set token metadata 7CF4C6B2…
6 Burn 100 CUM E080A82B…

Explorer: cumulo.pro/services/cosmos_testnet


The Admin Hierarchy

This is the most critical concept to understand when working with tokenfactory through CosmWasm:

User wallet (cumwallet)
    └── owner of the wasm contract
            └── admin of the CUM denom in x/tokenfactory

After creating the denom through the contract, querying on-chain confirms:

json

{
  "authority_metadata": {
    "admin": "cosmos1ujttrfpkslrgcml078hpeh9l6f3ssn3u8m44vyzyaahkxeecpw6s23fxvx"
  }
}

That address is the contract, not the wallet. Without transferring admin, you cannot call burn, force-transfer, or modify-metadata directly, those operations require wallet-level admin.


Transferring Admin to the Wallet

The demo contract exposes change_admin as an execute message. After calling it:

json

{
  "authority_metadata": {
    "admin": "cosmos1cdekug2t0rzjjw96yaytw4ryt4u0mzwyaskz3m"
  }
}

With the wallet as direct admin, we registered metadata (symbol, description, 6-decimal precision) and burned 100 CUM, permanently reducing supply from 1000 to 900 units.


Key Findings

1. Contract is denom admin, not user wallet. When a denom is created through a CosmWasm contract, the contract address becomes the admin. Any privileged operation must be routed through the contract unless admin is explicitly transferred.

2. The minimal demo contract (code ID 360) doesn’t expose all tokenfactory operations. Only create_denom, mint_tokens, and change_admin are available as contract messages. Operations like burn, force-transfer, and modify-metadata require wallet-level admin.

3. Admin renouncement is irreversible. Calling change-admin with "" permanently removes all admin control. Supply becomes fixed forever, no minting, burning, or metadata updates possible. This can be a desirable property for a community token seeking credible supply scarcity.

4. get_denom is a local computation, not an on-chain lookup. The contract constructs the denom string from the creator_address argument provided, not from chain state. If you pass your wallet address, you get back a denom that doesn’t actually exist on-chain (the real denom uses the contract’s address as creator).

5. subdenom is case-sensitive. CUM and cum would be registered as two distinct denoms.


Complete Command Reference

Via wasm contract execute messages (contract is admin):

bash

# Create denom (10 ATOM fee required)
gaiad tx wasm execute <contract> '{"create_denom": {"subdenom": "<name>"}}' --amount 10000000uatom

# Mint to any address
gaiad tx wasm execute <contract> '{"mint_tokens": {"amount": "<n>", "denom": "<denom>", "mint_to_address": "<addr>"}}'

# Transfer admin
gaiad tx wasm execute <contract> '{"change_admin": {"denom": "<denom>", "new_admin_address": "<addr>"}}'

Via gaiad tokenfactory (wallet must be admin):

bash

gaiad tx tokenfactory mint "<amount><denom>" --from <key>
gaiad tx tokenfactory burn "<amount><denom>" --from <key>
gaiad tx tokenfactory burn-from "<amount><denom>" <address> --from <key>
gaiad tx tokenfactory force-transfer "<amount><denom>" <from> <to> --from <key>
gaiad tx tokenfactory change-admin <denom> <new_admin> --from <key>
gaiad tx tokenfactory change-admin <denom> "" --from <key>   # IRREVERSIBLE renouncement
gaiad tx tokenfactory modify-metadata <denom> <symbol> "<description>" <exponent> --from <key>

Useful queries:

bash

gaiad q tokenfactory denoms-from-admin <address>
gaiad q tokenfactory denom-authority-metadata <denom>
gaiad q bank denom-metadata <denom>
gaiad q bank balance <address> <denom>

Resources

Resource Link
Task specification cosmos/testnets - demoday25
Sample contract source cosmos/tokenfactory - wasm-demo
CosmWasm token-factory bindings CosmWasm/token-factory
Osmosis tokenfactory module docs docs.osmosis.zone/tokenfactory
Cosmos Developer Documentation docs.cosmos.network
Full study with all TX details github.com/Cumulo-pro/cumulo-cosmoshub-infra
Explorer cumulo.pro/services/cosmos_testnet

Cumulo ¡ Cosmos Hub Validator ¡ Testnet Tuesday April 2026

4 Likes

@mon.cumulo Thank you for this empirical study. Clear, well-documented, and extremely useful for the community.

From an investor and macro perspective, your finding #3 (Admin renouncement is irreversible) is the absolute golden nugget here. For the Cosmos Hub to attract serious institutional capital and host high-grade financial assets, we need mechanisms that guarantee credible supply scarcity. Knowing that a contract can permanently lock out human intervention prevents rug-pulls and builds absolute trust in the asset.

Furthermore, having x/tokenfactory operate permissionlessly while requiring an ATOM fee for creation is exactly the kind of utility and economic sink the Hub needed.

Excellent work running these tests and sharing the operational lifecycle. Seeing validators do this kind of ground testing is exactly what gives investors peace of mind.

2 Likes

Thanks @TRAVE! Comments like this are what give us energy to keep going, knowing it sparks the same excitement we felt while researching it is the best thing you can tell us.

And totally agree on point 3, this kind of implementation is what makes the difference when we’re talking about serious financial assets.

We’ll keep working to contribute the best we can to the community :saluting_face:

2 Likes

Really useful doc! Thank you. The admin lifecycle section should be standard onboarding material for anyone building token logic on Hub. The contract-as-admin behavior is non-obvious and I haven’t seen it clearly explained elsewhere.

A few things that stood out:

Finding 4 is a production footgun. get_denom constructs the denom string from whatever address you pass as argument — not from chain state. Easy to test locally with your wallet address, get a
response that looks valid, and only discover in production that the real on-chain denom uses the contract address as creator. Worth a prominent warning anywhere this gets referenced in docs.

The --no-admin flag compounds the admin lifecycle risks. This study deploys the contract with --no-admin, which prevents future contract upgrades. Combined with the irreversible change-admin “”
renouncement, you can end up with a denom that neither the contract (immutable) nor any wallet (admin renounced) can operate on. Fine for a credibly scarce community token by design footgun for anything more complex.

The enterprise connection. Force-transfer, burn-from, and admin controls are precisely the compliance primitives regulated tokenized asset issuers need controlled redemption, OFAC freeze,
admin-gated burn. The fact that these are live and documented on Hub testnet matters for the IBC Eureka enterprise story Cosmos Labs is building. Someone should connect these dots explicitly in that roadmap conversation.

We’re also running on Hypha testnet and indexing Hub events through our chain-data-indexer. Tokenfactory events, such as: denom creation, admin transfers, supply changes are exactly the kind of on-chain history worth making queryable as these modules see mainnet adoption. Good timing on the research.

2 Likes

@serejandmyself Spot on. In my previous comment, I was looking at the ‘trustless’ side of the coin (immutable scarcity), but you just perfectly articulated the other, equally massive side: Enterprise Compliance.

The ability to execute force-transfers, OFAC freezes, and controlled burns aren’t just technical features; they are the mandatory legal prerequisites for any traditional financial institution (TradFi) or RWA (Real World Asset) issuer to even look at a blockchain.

You mentioned that someone should connect these dots explicitly in the roadmap conversations. Consider it done. I will make sure this “Enterprise Readiness” narrative is integrated directly into the business model and revenue discussions we are having right now across the forum. The Hub has the exact primitives the real-world economy demands; we just need to market them aggressively as a package.

2 Likes

@serejandmyself @TRAVE thank you both for taking the time to analyse the study in this level of detail.:folded_hands:

The points you raise are exactly the kind of things that slip through when you’re inside the work. The compound risk of --no-admin + renouncement and the enterprise connection are angles we didn’t develop enough.

We’re working on an update to the study incorporating this feedback. We’ll post it here once it’s ready.

1 Like

As promised, we’ve updated the study with the two scenarios raised in this thread.

Orphan denom: compound risk demonstrated on-chain We reproduced the --no-admin + renouncement scenario empirically. One additional finding: the demo contract itself rejects an empty new_admin_address, so renouncement actually requires a two-step process, transfer admin to a wallet first, then send it to the canonical burn address cosmos1qqqq...nrql8a. The denom is now permanently inoperable and verifiable on-chain.

Enterprise compliance: a more precise picture This is where the research added something unexpected. burn-from and force-transfer exist in the gaiad CLI and are implemented in the cosmos/tokenfactory module, but on Gaia v26 they return this capability is not enabled on chain at the baseapp message router level (cosmos-sdk@v0.53.6/baseapp/baseapp.go). They are not controllable via governance parameters, enabling them would require a software upgrade.

This doesn’t invalidate the enterprise narrative, it sharpens it. The Hub has the architecture. The compliance primitives exist in the protocol. What’s missing is a deliberate decision to register them.

Full updated study: tokenfactory-wasm-bindings-2026-04-v2

1 Like

@mon.cumulo, this is the exact kind of empirical rigor the Hub needs right now. Thank you for diving back into the code and updating the study based on this specific TradFi/RWA angle.

This finding—that the compliance primitives (burn-from, force-transfer) are already built into the x/tokenfactory module but just waiting to be enabled at the router level—is a massive strategic advantage for us. We aren’t starting from scratch; we just need to flip the switch.

As you noted: “What’s missing is a deliberate decision to register them.”

Consider this the catalyst. Over in the economic discussions (Economic Constitution), we are building the framework to capture institutional revenue (The Revenue Heatmap). But to capture that revenue, we must give institutions the legal and technical control they require.

Enabling these message routers should be a top priority for the next major software upgrade. I will make sure this specific technical requirement is championed in our governance and economic strategy discussions moving forward. We have the architecture; now let’s make the deliberate decision to open the gates to institutional capital. Excellent work from the Cumulo team.

1 Like