Multichain Stablecoin Deployment Verification Checklist
Quick answer. Treat each new chain as its own release. Match the bytecode to the audited build, confirm every owner and role is the intended multisig, check peers and DVNs on every pathway, and simulate each queued transaction.
Video transcript
An audited stablecoin can still be deployed wrong. On every new chain, you have to prove the code, wiring and owners match what was intended.
Connected to the wrong peer or owned by the wrong address, a correct contract becomes an unbacked token or an unrecoverable transfer.
The code is usually identical across chains. What drifts is everything around it. Constructor values. Peer wiring, in both directions. Silent fallbacks to defaults. And missing pieces, like DVNs not yet deployed.
Treat each chain as its own release. Match the bytecode to the audited build, check the messaging configuration, confirm every owner and role is the intended multisig, and simulate each queued transaction.
For each pathway, peers must be reciprocal and DVNs set explicitly. LayerZero warns a single DVN is one point of forgery. Confirmations must be pinned on both sides, and shared decimals must match everywhere.
Transactions carry risk too. On Polygon in August 2025, a queued migration sent USDT to a multisig instead of the adapter backing USDT0. Guardian flagged it, and it was fixed before it ran.
Guardian has applied this standard across the USDT0 rollout, with more than forty five deployment, configuration and verification engagements across over twenty five chains on EVM, Solana and Stellar.
Read the full checklist below, or talk to Guardian about verifying your next chain before it goes live.
Stablecoin deployment verification sits between an audit and a live chain.
It proves that what was deployed, wired and configured on each network is what was audited and intended.
For a multichain stablecoin, it repeats on every chain, for every migration and every configuration change.
Guardian's USDT0 case study puts it plainly: “An audited contract can still be deployed wrong.”
Connected to the wrong peer or owned by the wrong address, “a correct contract becomes an unbacked token or an unrecoverable transfer.”
The OFT rules below come from LayerZero's documentation. The USDT0 facts come only from Guardian's published case study and client story.
Why Multichain Deployments Drift
The contract code is usually the same on every chain. What changes is everything around it:
- Constructor values. Endpoint addresses and chain IDs differ per network, and immutables are written into the code itself.
- Wiring. Each OFT pairs with its counterpart on every other chain, and each direction is configured separately.
- Defaults. LayerZero warns that “unintentional fallbacks to defaults are a common cause of blocked or failing pathways.”
- Other virtual machines. On Solana, per Guardian's client story, program authorities replace contract ownership, with the same risk that a misconfigured peer leaves unbacked supply.
- Missing pieces. In USDT0's Superchain review, Guardian recorded that no DVNs were yet deployed for USDT on Optimism or Unichain.
None of these show up in a source-code audit. Someone has to read the deployed state, chain by chain.
Check 1: Bytecode
First, prove that the code at each address is the audited code.
- Find the real implementation. Read the ERC-1967 implementation and admin slots instead of trusting a deployment log.
- Rebuild and compare. Compile the audited commit with the same compiler and settings, then compare runtime bytecode for proxy, implementation and admin.
- Account for metadata. Solidity appends a metadata hash, and “a single whitespace change results in different metadata, and different bytecode.”
- Mask immutables, then check them. Mask the positions the compiler reports in
immutableReferences, then confirm each value is right for that chain. - Outside the EVM, compare the equivalent artifact. On Stellar, Guardian verified USDT0's WASM hashes onchain.
A byte-exact match means you reproduced the exact build. A match only after stripping metadata needs an explanation.
For USAT, Tether's US-regulated stablecoin, proxy, implementation and admin bytecode matched byte-exact on two networks.
Check 2: Configuration and Peers
The messaging configuration decides which chains the token trusts, and how much verification a message needs before it mints or unlocks funds.
LayerZero treats each direction, A to B and B to A, as a separate pathway. Per pathway, read and record:
| Setting | Where to read it | Pass condition |
|---|---|---|
| Peers | peers(eid) on the OApp, on both chains | Reciprocal; a zero peer means the pathway is unpeered |
| Send and receive libraries | getSendLibrary and getReceiveLibrary on the endpoint | Set explicitly, not resolving to a default |
| DVNs | getConfig(..., 2): required and optional DVNs, threshold | Explicit, sorted ascending, at least two independent DVNs, none dead |
| Confirmations | The same ULN config, on send and receive sides | Pinned on both sides, at or above the production floor |
| Executor | getConfig(..., 1) | Executor address and maximum message size set |
| Enforced options | The OApp's enforced options for each destination | Enough destination gas for each message type |
| Delegate | delegates(oApp) on the endpoint | The intended multisig |
Three LayerZero rules matter most for a stablecoin:
- One DVN is one point of forgery. A 1-of-1 setup lets a single operator forge messages that mint tokens or release collateral.
- Pin confirmations on both sides. If one side inherits the default, in-flight messages can stall when that default changes.
- Check against your target, not the defaults. LayerZero's pre-launch checks include a resolved config that matches intent, and matching send and receive sides.
LayerZero's recommended floor for Ethereum mainnet is 15 confirmations, with 32 preferred for high-value pathways.
Token-level invariants
- Shared decimals must match everywhere. Otherwise, LayerZero warns, “amount conversion will vary by orders of magnitude and allow double spending.”
- Only one lockbox adapter. “There can only be one lockbox OFT Adapter used in an OFT deployment.” Adapters on several chains create separate pools, and a transfer larger than the destination pool can be permanently lost.
Check 3: Ownership and Roles
LayerZero's OApp and OFT contracts have two control roles:
- Owner, on the OFT: controls
setPeer,setEnforcedOptionsandsetDelegate. - Delegate, on the endpoint: controls
setConfig, the send and receive libraries, and message recovery.
LayerZero says to use a multisig for both, and to set the Delegate before transferring ownership. After the move, the old key can no longer call setDelegate.
LayerZero's Stablecoin OFT is the exception. It uses role-based access control, where DEFAULT_ADMIN_ROLE takes the owner's place and setDelegate always reverts.
Per chain, confirm:
- Owner (or
DEFAULT_ADMIN_ROLE), delegate and upgrade admin are the intended multisig; no deployer key remains. - The multisig's signer set and threshold match the plan on that chain.
- Per the Stablecoin OFT threat model, only the OFT contract holds the minter role, and pauser and unpauser sit on separate multisigs.
- A pauser exists on the new chain, and pause state and allowlist mode at launch are what you intend.
- Proxies were deployed and initialized in one transaction, so
initialize()could not be front-run. - Mock and test functions from example contracts are gone.
Check 4: Transactions and Migrations
Most deployment risk is in the transactions that change state: wiring, configuration updates, supply migrations and delistings.
For USDT0, Guardian decodes and simulates every queued Safe and OneSig transaction before execution, and fork-tests against live mainnet state.
The clearest example came on Polygon in August 2025. The contracts were correct; the migration playbook was not.
The queued migration sent USDT from Polygon's ERC20Predicate to a multisig instead of the OAdapter that backs circulating USDT0.
In Guardian's words, the plan “will create an insolvency case”: more USDT0 would circulate than the USDT in the OAdapter could redeem.
It was filed as Informational and fixed before the transactions ran. The report is public.
Before any migration runs, write down the supply invariant it must preserve. Then check the simulated end state against it.
How Guardian Verified USDT0
USDT0 is the omnichain deployment of Tether's USDT, built on LayerZero's OFT standard.
Guardian's case study describes it as live on more than 25 chains with over $150B in volume.
Guardian audited the OFT architecture in January 2025. Since February 2025, it has verified every step of the rollout.
The case study counts 45+ deployment, configuration and verification engagements through September 2026, across 25+ chains on EVM, Solana and Stellar.
| Asset | Deployments named in Guardian's case study |
|---|---|
| USDT0 | Flare, Sei, Corn, Rootstock, XLayer, Polygon, Conflux, Monad, Mantle, MegaETH, Morph, Tempo, Hedera and Stellar |
| XAUT0 | Plasma, Ink, Celo, Solana, BSC, Conflux and Stable |
| USAT | Ethereum and Celo |
| CNHT0 | Conflux |
Over a dozen chains have a Guardian deployment report in the client's own audit repository.
Guardian also reviewed Gasolina, LayerZero's DVN service and the offchain signer in USDT0's cross-chain path.
Guardian verifies every deployment, wiring change and transaction before it ships, as the USDT0 deployment verification case study describes. We can apply the same standard to your rollout.
Frequently Asked Questions
What is stablecoin deployment verification?
It is the check that the code, configuration, privileged addresses and transactions on each chain match what was audited and intended. For a multichain stablecoin, it repeats on every chain.
Why is an audit not enough for a multichain stablecoin?
An audit reviews source code at one commit. Deployment adds per-chain constructor values, wiring, verifier configuration, ownership transfers and migration transactions that the audit never saw.
What has to match across every chain in a LayerZero OFT deployment?
Shared decimals must be identical, and peers reciprocal on every pathway. DVN, confirmation and library settings must be explicit on both sides, with only one lockbox adapter.
How many DVNs should a stablecoin pathway use?
LayerZero's production guidance treats fewer than two effective DVNs as a setup where one compromised DVN can forge messages. It recommends independent operators, and favors higher tiers for tokens with composable downstreams.
Sources
- Guardian: USDT0 Deployment and Configuration Verification case study
- Guardian: USDT0 cross-chain stablecoin audits case study
- Guardian: USDT0 client story
- Guardian: USDT0 Gasolina DVN review case study
- Everdawn Labs: USDT0 audit reports, Guardian folder
- Guardian: USDT0 Polygon Deployment and Peer Verification report (August 2025)
- Guardian: USAT Deployment Verification report (December 2025)
- Guardian: USDT0 Stellar Deployment Review (August 10, 2026)
- LayerZero Docs: Omnichain Fungible Token (OFT) Technical Reference
- LayerZero Docs: Integration Checklist
- LayerZero Docs: Production DVN Configuration
- LayerZero Docs: Best Practices for Contract Ownership
- LayerZero Docs: Stablecoin OFT RBAC Reference
- LayerZero Docs: Stablecoin OFT Security and Compliance
- Ethereum Improvement Proposals: ERC-1967 Proxy Storage Slots
- Solidity Docs: Contract Metadata
- Solidity Docs: Constant and Immutable State Variables
Verify your next chain before it goes live
Guardian checks bytecode, roles, peers and every queued transaction for each deployment, the same standard applied across USDT0's rollout.