Cosmos Bank and IBC: Where Each Compliance Check Must Run
Your token checks every ordinary transfer it sees. Does your chain let value move where the token can’t see?
IN 30 SECONDS
A compliance policy is a rule on who may hold an asset and how it may move. On a Cosmos EVM chain, each ledger that holds the asset needs its own policy, on the path that changes its balances.
KEY TAKEAWAYS · 3
- Every ledger that holds the asset needs its own policy, placed on the path that changes its balances.
- A token contract doesn’t automatically govern native bank balances or remote vouchers.
- Before enabling conversion, list every token-coin pair, name the policy on each form of the asset, and test a prohibited transfer and a recovery action on the deployed chain.
On this page
Where can the check actually run?
IN SHORT Every ledger that holds the asset needs its own policy, placed on the path that changes its balances.
WORDS TO KNOW
- Bank module
- The built-in ledger of a Cosmos chain, also written x/bank. It records coin balances and moves them itself, outside any token contract.
- Conversion
- Moving ERC-3643 tokens into escrow in exchange for the same amount of coins in the bank module.
- IBC
- The protocol Cosmos chains use to send tokens to each other. When a token leaves its home chain, what arrives on the other chain is a voucher for the original.
- Middleware
- Extra code a chain adds on a path, such as IBC, that can inspect or refuse what passes through.
The chain does check contract execution. The gap is a separate path that never calls the contract: after a Conversion Moving ERC-3643 tokens into escrow in exchange for the same amount of coins in the bank module. See the glossary, the coins move in the Bank module The built-in ledger of a Cosmos chain, also written x/bank. It records coin balances and moves them itself, outside any token contract. See the glossary and over IBC The protocol Cosmos chains use to send tokens to each other. When a token leaves its home chain, what arrives on the other chain is a voucher for the original. See the glossary.
STEP BY STEP
Step 1. Token contract. The ERC-3643 transfer checks and agent powers live here, and the chain validates their execution.
- Token contract The ERC-3643 transfer checks and agent powers live here, and the chain validates their execution.
- Conversion module It escrows the converted portion. A token transfer runs on entry and on redemption.
- Bank module It holds the bank coin balances. Any bank restriction needs its own review.
- IBC and the other chain Packets, middleware and vouchers. Policy and recovery are needed at both ends.
IN PLAIN WORDS
A check can only stop a move that passes through it. Here the asset can take several roads, so each road needs a gate, even if several gates apply the same policy.
The same design question comes up in agent authorization: find every path that changes state, and put the check where that path can’t skip it.
Coming up next: So is your own token on one of those roads?
Is your token exposed to this?
IN SHORT Start with the paths your deployment actually turns on, then follow each one to the ledger it changes.
Chainlink ACE is a vendor product, not a token-interface standard. Chainlink describes its Automated Compliance Engine and Cross-Chain Identity as infrastructure for policy-aware token workflows. That doesn’t show how a given Cosmos bank path is controlled.
Judge a compliance product by its deployed contracts, supported networks, middleware and recovery behavior, not by its name.
In my CTO role at Integra in 2025-2026, I led an RWA Layer-1 through testnet operations to mainnet launch-ready. That role ended in June 2026.
This post is about design choices. It doesn’t announce a mainnet date or claim these proposed controls are deployed.
A well-enforced contract can still need extra integration controls when another ledger represents the same asset.
Before you enable conversion, run three checks. The wider deployment trade-offs are in episode 1.
- List every token pair for your ERC-3643 token, and who may register or convert it on each chain.
- For each form of the asset (ERC-20, bank coin, IBC voucher), name the code that changes its balances and the policy there: bank rules, Middleware Extra code a chain adds on a path, such as IBC, that can inspect or refuse what passes through. See the glossary on the bridge, redemption.
- Test a prohibited transfer and a recovery action on each form, on the deployed chain, not only in the module source.
ITEM GET
Test the live chain
Sources: the cosmos/evm conversion code at the reviewed commit; Chainlink ACE vendor description.
FAQ
This post describes an integration risk read from source code, not a documented case of someone exploiting it. It doesn’t show whether such a case has happened elsewhere.
STAGE CLEAR
What you now know
- Why every ledger that holds the asset needs its own policy, on the path that changes its balances.
- How to tell whether your own token is exposed, and what to test before you enable conversion.
Check yourself
Tap or click a question to see the answer.
Your token lives on one EVM chain, with no bank module, but a bridge carries it to another chain. Is it exposed to the conversion path? What should you still review?
Not to this path: the original contract’s controls stay on its source ledger. But the bridge is another path that changes balances, so review it and the token’s form on the other chain, along with wrappers and privileged roles.
Former CTO of Integra. Named author (1 of 5) of ERC-3643, first author of ERC-6960, co-author of ERC-7410, and co-author of ERC-8203, which is still a draft. Building production AI and regulated Web3 systems.
Have a project to ship or a role to fill?
Discuss your project or roleFollow the engineering notes
Get new articles on production AI and smart contracts by email.