Compliance and safety
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 21 — 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 22 — 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.
This page is for people writing contracts on a chain produced by the platform. It does not teach syntax; it tells you what syntax cannot: which rules block your transaction, at which layer, and why the layer you can see is not the only one.
The fundamental difference from an ordinary public chain: here, most of the rules are not in your contract. They sit beneath it, inside the consensus mechanism — the full mechanism is in Platform architecture, under Compliance at the protocol layer. What that means for whoever writes the code:
| What you do | Which layer sees it | What to expect |
|---|---|---|
| Submit a transaction | Pre-processing (layer 1) | An unapproved wallet is rejected before the virtual machine runs — there is nothing for your contract to catch |
| Move assets | Treasury module (layer 2) | The fuel token is non-transferable; do not design mechanics that depend on moving it |
| Deploy a contract | EVM hook (layer 3) | Deployment permission is a role, not a default. Child-contract creation patterns are inspected too |
| Receive assets from an outside network | Interchain middleware (layer 4) | An unapproved recipient makes the packet return an error and refund — funds do not stick, but your flow must survive that branch |
| Ask "is this address permitted?" | Precompile (layer 5) | This is the layer you can call from inside a contract, and it is what compensates for layer 1's blind spot |
Figure 23 — Layer one's blind spot, and how a contract covers it itself.
The blind spot you must know about, because this document does not hide it: pre-processing cannot see contract-to-contract calls inside the virtual machine. An already-permitted contract can call another one without layer 1 ever knowing. Layer 5 exists precisely because of that — so if your contract forwards value to an address supplied by a user, asking the precompile is your job, not the protocol's.
The general reading rule, more durable than any table: each layer blocks exactly what it can see. Do not count layers and feel safe; ask what each layer sees.
A customer chain and the shared network are two different places. Your contract runs on the customer chain; the fuel token there has no market price and is not LOVE9. The three token layers, and the easiest confusion between them, are in LOVE9 economics.
In short: on this chain, a carefully written contract is not enough to be compliant, and a carelessly written one is not enough to escape compliance — that is exactly what "compliance at the protocol layer" means.
In this part
| Page | What it answers |
|---|---|
| Security and fault tolerance | What the network survives before it stops |
| Security and disclosure | Official channels, and the promise to reporters |
→ Next: Security and fault tolerance — What the network survives before it stops