Crosschain Stablecoin Monitoring: What to Track

Crosschain stablecoin monitoring is the practice of tracking a single stablecoin's supply, transfers and reserves across every chain it lives on at the same time, then reconciling those views so the numbers agree. The hard part is not reading any one chain. It is that USDC on Ethereum, USDC on Base, USDC on Solana and USDC bridged through a third-party wrapper are four different onchain objects that all claim to be the same dollar, and a naive monitor will either double-count them or miss the bridge burn that ties them together.

According to Allium's dataset (as of September 23, 2026), total tracked onchain stablecoin circulating supply, adjusted for bridged double-counting, sits at $313.74B, with USDT at $189.28B and USDC at $72.32B. Neither figure lives on a single chain. Getting to a trustworthy $313.74B requires summing per-chain balances and de-duplicating wrapped and bridged representations, using a native flag so a bridged mint is not treated as new supply (native $284.44B, bridged $29.31B).

Key takeaways

• Crosschain stablecoin monitoring is a reconciliation problem, not a data-collection problem. Reading each chain is easy. Making the chains agree is the work.
• The two failure modes are double-counting (bridged supply counted on both origin and destination) and blind spots (a chain or a wrapped variant you are not indexing).
• Native issuance (Circle's CCTP burning on chain A and minting on chain B) and lock-and-mint bridges produce different onchain signatures and must be handled differently.
• The fields you need on every chain are identical: asset, issuer, sender, recipient, amount, USD value and transaction type. Without a shared schema, cross-chain sums do not tie out.
• Allium's dataset puts total onchain stablecoin supply at $313.74B by reconciling per-chain balances against bridge activity, which is exactly the calculation a monitor has to reproduce.

Why the same stablecoin counts as several different things

A stablecoin arrives on a new chain by one of two mechanisms, and they leave different traces.

The first is native issuance. Circle's Cross-Chain Transfer Protocol burns USDC on the source chain and mints an equal amount on the destination chain, so total supply is conserved and no wrapped token exists. Circle documents this burn-and-mint model in its developer documentation. For a monitor, native issuance is the clean case: sum the per-chain supplies and you get the real number, because the burn on chain A already removed the tokens you are about to see minted on chain B.

The second is lock-and-mint bridging. A third-party bridge locks the real token in a contract on the origin chain and mints a wrapped representation on the destination chain. The origin tokens still exist onchain (they are locked, not burned), and the wrapped tokens exist too. Count both and you have double-counted. A correct monitor must identify the lockbox contract, treat its balance as escrow rather than circulating, and attribute the wrapped supply to the bridge rather than to fresh issuance.

This is why a headline supply number is only as good as its bridge accounting. Tether's own transparency reporting, published on the Tether site, reports authorized supply per chain, and authorized supply is a different measure from circulating supply, and circulating on a wrapped chain is not the same as new dollars in the system.

The reconciliation, with real numbers

Here is the calculation a crosschain monitor performs, using Allium's figures for the largest stablecoins by adjusted circulating supply. Every one of these numbers is already a cross-chain sum, net of bridge lockboxes.

Notice USDT0 and USDT in the same table. USDT0 is a cross-chain transport standard for USDT built on LayerZero's OFT framework, described in the LayerZero documentation. If a monitor treats USDT0 supply as separate from the USDT that backs it, the total inflates by billions. If it treats them as identical without checking the escrow, it can understate the transport float. The correct answer requires reading both the USDT lockbox and the USDT0 mint on each chain, then reconciling.

The same discipline applies to USDS, SUSDS and DAI. SUSDS is the yield-bearing wrapper of USDS, and USDS is the upgraded form of DAI, per Sky's documentation on the Sky site. Adding all three as independent supply triple-counts value that is, in economic terms, largely the same dollars moving between wrappers.

What a monitor has to capture on every chain

Regardless of chain, a stablecoin transfer needs the same descriptive fields before it can be compared to a transfer anywhere else:

• Asset: the specific token contract, not just the ticker, because "USDC" resolves to different contracts on different chains.
• Issuer: whether the mint came from the native issuer or a bridge, which determines if it is new supply or wrapped supply.
• Sender and recipient: to distinguish user transfers from mint, burn and bridge-escrow movements.
• Amount and USD value: raw amount in token decimals, normalized to dollars.
• Transaction type: mint, burn, transfer, bridge-lock or bridge-release, since only some of these change circulating supply.

Miss the transaction type and a burn looks like a transfer to a dead address. Miss the issuer field and a bridge mint looks like organic growth.

The field-level problem this creates

To reconcile USDT on Tron against USDT on Ethereum against a USDT0 transport mint on a rollup, the same transfer has to resolve to the same fields on all three: asset, issuer, sender, recipient, amount, USD value and transaction type. Tron encodes token transfers differently from Ethereum, which encodes them differently from Solana, which handles token accounts differently again. A raw log from each chain is not comparable to the others until it is parsed into a common shape, and the bridge contracts on each chain have to be labeled so their balances are excluded from circulating supply.

Allium ingests raw data from 150+ blockchains and standardizes stablecoin transfers into those shared fields, with bridge and issuer labeling built into the stablecoin datasets, so a cross-chain supply number can be summed without double-counting the bridged variants. It is SOC 2 Type II attested infrastructure, which is what lets a reconciled figure be treated as accountable rather than a best-guess sum.

Where crosschain monitoring feeds into risk and treasury work

A reconciled cross-chain supply view is the input to two downstream jobs. For risk teams, sudden divergence between a stablecoin's supply on one chain and its bridge escrow is an early depeg or bridge-exploit signal, which is the subject of our guide to stablecoin risk monitoring. For finance teams holding stablecoins across chains, the same reconciliation is what makes a balance sheet figure defensible, covered in stablecoin treasury monitoring for finance teams. In both cases the monitoring is only useful if the underlying cross-chain sum is trustworthy, which returns to the escrow and issuer accounting that makes the number hold.

Frequently asked questions

How do you avoid double-counting a stablecoin that exists on many chains?

You classify each mint by mechanism. Native burn-and-mint (such as Circle's CCTP) conserves total supply, so per-chain balances can be summed directly. Lock-and-mint bridges leave the original tokens locked in an escrow contract while minting a wrapped version elsewhere, so the escrow balance must be excluded from circulating supply and the wrapped tokens attributed to the bridge, not to new issuance.

What is the difference between USDT and USDT0 for monitoring purposes?

USDT0 is a cross-chain transport standard for USDT built on LayerZero's OFT framework. The USDT0 supply on a destination chain is backed by USDT locked elsewhere. Treating USDT0 as fully independent supply inflates the total, while ignoring the escrow can understate the transport float. A monitor must reconcile the USDT0 mint against the USDT it locks.

Why does native issuance make monitoring easier than bridging?

Native issuance protocols burn tokens on the source chain before minting an equal amount on the destination chain, so total supply is conserved and no wrapped duplicate exists. That means per-chain supplies can be summed without a correction step. Lock-and-mint bridging leaves the original tokens in circulation as locked collateral, which forces an escrow subtraction to avoid double-counting.

What fields do you need to compare stablecoin transfers across different chains?

Every transfer needs the same descriptive fields regardless of chain: the specific token contract (asset), the issuer or bridge source, sender, recipient, raw amount, normalized USD value, and transaction type (mint, burn, transfer, or bridge movement). Chains encode transfers differently, so raw logs must be parsed into this shared shape before any cross-chain sum is valid.

Does yield-bearing wrapping like SUSDS count as separate stablecoin supply?

No. SUSDS is a yield-bearing wrapper of USDS, and USDS itself is the upgraded form of DAI. Adding SUSDS, USDS and DAI together as independent supply counts largely the same economic value multiple times. Correct monitoring tracks the wrapper relationships so value moving between wrappers is not mistaken for new issuance.

How large is total onchain stablecoin supply across all chains?

According to Allium's dataset as of September 23, 2026, total tracked onchain stablecoin circulating supply, adjusted for bridged double-counting, is $313.74B, with USDT at $189.28B and USDC at $72.32B. That figure is itself a cross-chain reconciliation: a sum of per-chain balances net of bridge lockboxes so bridged variants are not double-counted.

Interested in learning more about Allium’s stablecoin data? Speak to someone on the team.

Allium provides onchain data infrastructure. Companies named in this article may be Allium customers, prospects or commercial counterparties. This article is informational only and is not investment, legal or tax advice. Data and information last reviewed: September 23, 2026.