Compliance at the protocol layer
The compliance module holds three kinds of data: the list of permitted addresses with their status and the hash of a KYC reference, the roles, and operating parameters. One point deserves emphasis: only hashes are on chain. Personally identifying data is never written there.
Five enforcement layers
| Layer | Mechanism | What it blocks |
|---|---|---|
| 1 | A block at transaction pre-processing | Who may sign and submit transactions, on both the Cosmos and EVM sides |
| 2 | Restrictions in the treasury module | Asset flows; the fuel token is non-transferable |
| 3 | A hook into the EVM | Contract deployment rights, and child-contract creation patterns — exactly as far as this layer can see |
| 4 | Interchain middleware | Assets arriving from outside: if the recipient is not approved, an error is returned and funds are refunded |
| 5 | A precompile | Lets a contract itself ask "is this address permitted?" |
Figure 20 — Each layer has its own rejection branch, and every rejection leaves a trace.
Why five layers rather than one? Because layer one has a known blind spot, and this document states it rather than hiding it: pre-processing cannot see contract-to-contract calls inside the virtual machine. An already-permitted contract can call another one without layer one ever knowing. Layer five exists precisely because of that blind spot. Saying "it cannot be bypassed" without saying this sentence would be false advertising.
From which comes a reading rule for the whole table, more durable than any table: each layer blocks exactly what it can see. Where one layer does not look, another must cover; where no layer covers, it must be listed rather than left silently blank. So the right measure of an enforcement system is not counting layers but asking what each layer sees — and five layers blind in the same place are still only as strong as one.
Assets arriving from outside
Figure 21 — The gate at the border: on refusal it refunds, never leaving assets stranded.
The status of this diagram must be stated correctly: it describes a gate that has been built and tested, not a route already carrying assets — opening the first interoperability channel is still a gate not yet passed. And a border gate is only as trustworthy as the weakest link in the chain that reads the packet, so the project's rule is to fail closed: if a packet cannot be read, block it, and never hand it down to a lower layer to handle. A gate that only blocks what it understands is a gate open to everything it does not.
Every change emits an event, and an external indexer gathers them into reports for auditors. There is a detail here that has already cost us something and is worth keeping: when the middleware rejects a packet, the layer below reverts the context and re-emits the event with a different prefix. The indexer must match the prefixed form as well, or it will undercount exactly the packets that were blocked — that is, be blind precisely where it most needs to see.
In short: compliance is only trustworthy when it does not depend on the goodwill of whoever wrote the contract.