Revoke Sui Token Authority - Renounce Caps

The 20lab Sui revoke authority tool lets you permanently destroy a Sui coin's capability objects (caps), removing the ability to mint, freeze, pause, upgrade, or modify metadata forever. This is how Sui projects prove their tokens are immutable and trust-minimized.

Revoking is irreversible - once a cap is destroyed, no one can restore it. This is the cleanest way to demonstrate fixed supply (revoking treasury cap), guaranteed transferability (revoking deny cap), locked code (revoking upgrade cap), or locked tokenomics (revoking metadata cap). If you want to move a cap instead of disabling it, use the transfer authority tool.

To revoke the treasury cap on Sui:

1. Connect the wallet that currently holds the treasury cap
2. Enter your token's coin type or address
3. Select Revoke Treasury cap
4. Confirm the transaction

After confirmation, your token's supply is permanently capped at the current circulating amount and metadata becomes immutable. No one - including you - can mint additional tokens or change name/symbol/logo, ever. This is the most common cap revocation for projects committing to a fixed supply, and it's typically expected by DEX listing standards before they'll display the token as trustworthy. Detailed guide: how to revoke treasury cap on Sui.

To revoke the deny cap on Sui, use the same flow as revoking treasury cap but select Revoke Deny cap. Once confirmed:

• No wallet can ever be frozen for your token again
• If your token uses Deny Cap V2 with pause enabled, the token can never be paused again either
• Existing frozen accounts cannot be unfrozen (revoke after unfreezing if needed)

Revoking deny cap is one of the strongest trust signals you can give your community on Sui - it cryptographically guarantees their tokens can never be frozen or paused. See our freezable Sui token guide for context on the deny cap model.

"Renouncing ownership" on Sui typically refers to revoking all capability objects - treasury, metadata, upgrade, and (where applicable) deny cap - making the token's properties permanently fixed.

Unlike Ethereum's Ownable pattern where one renounce call drops a single owner role, Sui has multiple separate caps per token. Full renunciation means revoking each one individually. The tool surfaces every active cap on your token and lets you revoke them in sequence or selectively.

Renouncing all caps is the strongest possible commitment to decentralization but is irreversible - so it's usually done only after the token has reached operational maturity. Transferring caps to a multisig first is the safer intermediate step.

The 20lab tool supports revoking every standard Sui cap:

• Treasury cap - Locks total supply and metadataforever
• Metadata cap - Locks name, symbol, and image permanently (see our metadata cap guide)
• Upgrade cap - Locks the token's Move smart contract code permanently
• Deny cap / Deny cap V2 - Guarantees no account can ever be frozen or paused

Each can be revoked independently. You can keep some active while disabling others - the most common pattern is revoking treasury and deny cap while keeping upgrade cap available for security patches.

Both permanently disable a cap, but they differ:

• Revoking destroys the cap object on-chain - the cleanest, most explicit signal of permanent removal. Easier for auditors and DEXes to detect automatically. Also reclaims some SUI from storage rebates since the cap object is removed.
• Burn-address transfer assigns the cap to a wallet no one can sign for. Functionally identical but the cap object still exists on-chain, slightly harder to verify, and you don't reclaim the storage rebate.

Revoking is the recommended approach. It's cleaner in transaction history, reclaims storage, and is what most Sui DEX listing standards check for.

Yes - revoking a cap is absolutely irreversible. Once the cap object is destroyed:

• The cap cannot be reinstated by anyone, including the original creator
• There is no recovery mechanism, multisig override, or upgrade path
• The corresponding action (minting, freezing, pausing, upgrading, metadata changes) is permanently disabled

Because of this permanence, consider carefully whether you may ever need the functionality again. If you're not 100% certain, transfer the cap to a multisig instead - that still provides strong decentralization while keeping the option to act in genuine emergencies.

Yes - cap revocation is selective. Common configurations:

• Revoke treasury, keep deny cap - Fixed supply with the ability to freeze suspicious wallets
• Revoke deny cap, keep treasury - Guaranteed unfreezable token, but team can still mint per published schedule
• Revoke treasury and deny cap, keep upgrade cap - Locked tokenomics with the ability to patch the contract if a vulnerability is found
• Revoke everything - Fully renounced, maximally decentralized, immutable

Match the configuration to your token's stage. Most projects revoke progressively as the ecosystem matures.

It depends on your token's stage and goals:

• Yes, for community tokens / memecoins - Revoking treasury and deny cap is essentially required to be taken seriously by Sui DEXes and listing trackers
• Yes, for fixed-supply DeFi tokens - Demonstrates supply will never inflate and metadata will never change
• Not yet, for early-stage projects - Keep caps until tokenomics and operations stabilize
• Not at all, for regulated stablecoins or compliance-bound assets - Retained deny cap is often a regulatory requirement

Many mature projects use a phased approach: transfer caps to multisig governance first, then revoke once the ecosystem matures.