Cross-chain compliance is the set of controls an issuer enforces when a token moves between blockchains: who may hold it, where it may travel, how much may move, and what record the movement leaves. Those controls live in the token contract the issuer owns, one layer above the transport that carries the message.
This page explains what cross-chain compliance is, which requirements apply when a token crosses chains, the controls available to an issuer, how cross-chain audit trails are produced, and how verification is configured. To discuss issuing a controlled asset across chains, reach out to our team.
What is cross-chain compliance?
Cross-chain compliance is the practice of applying one issuer's policy consistently to a token that exists on more than one blockchain. The policy covers eligibility, sanctions screening, transfer restrictions, exposure limits, and recordkeeping. It is enforced at the asset layer by the contract the issuer controls, and it applies on every chain where supply lives.
Policy and transport stay separate, the way a card network separates them: the network carries the authorization message, and the issuer's own system decides whether to approve it. The messaging layer moves a verified instruction between chains. The token contract decides whether that instruction becomes a transfer.
What requirements apply when a token moves between chains
The same requirements that apply to the asset on its home chain. Moving a token to a second chain does not create a new regulatory regime. It creates a second place where the issuer must demonstrate the same controls. The constraint is tightest for cross-chain tokenized assets, where eligibility is part of the instrument itself.
- Eligibility. Only holders who have cleared the issuer's KYC and jurisdictional checks may receive the asset, wherever it settles.
- Sanctions and blocking. A sanctioned address must be barred on every chain, and the block must take effect without redeploying the token.
- Transfer restrictions. Some assets may only move between approved venues, chains, or account types.
- Recordkeeping. The issuer must be able to reconstruct every movement of supply: which chain it left, which chain it arrived on, and how the transfer was verified.
Supply on ten chains is one asset under one policy, which is the property the OFT standard is built around.
The control surface: allowlist, blocklist, pause, lock/unlock, rate limits
Controls are functions on the token contract, callable by roles the issuer holds. The stablecoin OFT extension modules implement them as separate modules with separate roles.
| Control | What it enforces | Who executes | Scope |
|---|---|---|---|
| Allowlist | Who can transfer, receive, mint, or burn. Runs in one of three modes: open, blocklist, or whitelist | Admin role sets the mode, blocklister and whitelister roles set the entries | Global, every token operation including local transfers |
| Pause | All token operations stop | Pauser and unpauser roles | Global |
| Pause by destination | Outbound transfers to a named chain stop | Pauser and unpauser roles | Per destination chain |
| Rate limits | Token-bucket caps on how much moves per window, outbound and inbound | Rate-limiter manager role | Per destination, or one shared bucket |
| Lock/unlock | Minted supply on other chains stays backed by tokens escrowed in one lockbox | The lockbox contract, automatically | One lockbox per token mesh |
The scope column is what makes the surface operational. An issuer can stop outbound transfers to one chain during an incident without freezing the asset everywhere, and cap one destination without touching the others. Inbound credits to an address outside the allowlist can route to an issuer-controlled escrow rather than reverting, so the message settles while the recipient is reviewed.
Two details matter for how the surface is governed. The allowlist runs in one mode at a time, and switching modes leaves the stored entries in place, so an issuer can move between blocklist and whitelist operation without rebuilding either list. Pause and unpause sit with different roles, so no single key holds the whole surface.
How cross-chain audit trails work
A cross-chain audit trail is the record of one message from source transaction to destination transaction, keyed by the message GUID. The GUID is a global identifier derived from the nonce, the source and destination endpoint IDs, and the sender and receiver addresses, so it stays stable across both chains. Each transfer produces a source-chain transaction, a verification record from each verifier that signed off, and a destination-chain transaction, all linked by that GUID.
LayerZero Scan exposes this through a public API at https://scan.layerzero-api.com/v1/. Messages can be retrieved by transaction hash, by GUID, by pathway, or by the issuer's own contract address across chains, and each record returns the message status, the per-verifier verification status, and the source and destination transaction details. Pathway lookup is what makes per-corridor reporting straightforward: one query returns every message that moved between a given pair of chains. The issuer generates the trail itself, on whatever schedule reconciliation and reporting require.
Can regulated entities use public chains?
Yes. A public chain is a settlement venue, and settling there does not make an asset uncontrolled. Eligibility, blocking, and limits are contract-level, so they hold on a public network and a permissioned one alike.
What a regulated issuer works through is custody of the admin keys, a documented control surface with named role holders, an auditable record of every transfer, and a verification configuration it can evidence.
How issuer-controlled verification works
Verification is configured by the application, per pathway and per direction. Under LayerZero's security stack model, an issuer sets required Decentralized Verifier Networks (DVNs) that must verify every message, an optional set, and a threshold of that set. The Ethereum-to-Solana pathway can carry a different configuration from the Solana-to-Ethereum one. A required verifier that stops verifying halts the pathway, which is why a threshold over an optional set is the usual way to raise the verification bar while keeping liveness.
Defaults are placeholders, so an issuer setting up a controlled asset sets the configuration explicitly rather than inheriting one. Tooling reports three views of a pathway: the configuration the application set, the LayerZero default, and the active combination of the two. The active view is what an issuer evidences to a reviewer.
An issuer can also build and operate its own DVN, which places its existing compliance logic inside the verification step: the message is not verified until the issuer's own infrastructure has checked it. Several enterprises already run production DVNs, among them Deutsche Telekom MMS, Worldpay, Fidelity's FCAT, and Google Cloud. An issuer that runs its own becomes one of the verifiers behind its own asset.
FAQ
Can an issuer freeze a token on one chain only?
Yes. Pause-by-destination stops outbound transfers to a named chain while the asset keeps operating everywhere else. A global pause stops all token operations.
Who can call the compliance controls?
Only the roles the issuer holds. Allowlist entries, pause, and rate limits sit with separate roles, and setting the allowlist mode is separate again, so one compromised key cannot exercise the whole surface.
How does an issuer produce a transaction record for auditors?
By querying the LayerZero Scan API for its own contract, a pathway, or specific transactions and GUIDs. Each record links the source transaction, the verification result from each DVN, and the destination transaction.
Can an issuer choose who verifies its transfers?
Yes. The verification configuration is set per pathway by the application. An issuer can include third-party DVNs, run its own, or combine both under a required-plus-threshold configuration.
Bring a controlled asset across chains
The controls, the audit trail, and the verification configuration are owned by the issuer. What differs between issuers is which controls they enable, which pathways they open, and who they trust to verify.
To scope those for a regulated asset, reach out to our team.