Bridged supply is the amount of a token represented on a destination chain after tokens are locked on the source chain. It stays backed only while the source escrow holds enough of the corresponding asset to cover outstanding destination tokens, so integrations should reconcile both chains rather than trust either token’s supply figure alone.
What should the accounting invariant measure?
For a lock-and-mint bridge, compare the source token balance held by its bridge escrow with the destination token’s outstanding supply, using the correct token mapping and units. In a simple one-to-one mapping, 1,000 USDC locked on Ethereum supports 1,000 bridged USDC on Polygon PoS; a withdrawal burns destination tokens before the source escrow releases the same amount.
Track the balance change caused by valid bridge deposits and withdrawals, not every token that happens to arrive at the escrow address. The Polygon PoS portal contracts use Predicate contracts for token-specific locking and exit logic, while EIP-20 defines token queries such as balanceOf and totalSupply. Those live queries are useful checks, but they do not identify why a balance changed.
How can an integrator reconcile deposits and withdrawals?
Reconcile finalized bridge actions against the escrow’s balance and the mapped destination token’s supply. For example, if 100 USDC is deposited and the destination representation is minted, record a 100-unit increase in backing and supply; after a valid 25-USDC withdrawal burns 25 on Polygon and releases 25 on Ethereum, both figures should return to 75, assuming no other activity.
For a user moving assets between Ethereum and Polygon, Polygon Bridge is the Polygon bridge interface for initiating that transfer. In an integration, treat the user’s transaction as the start of a cross-chain state change, then update accounting only when your chosen finality rules say each event is safe to count.
Use this reconciliation sequence for each mapped token:
- Identify the exact Ethereum token, its Polygon representation, and the bridge escrow or Predicate address responsible for holding it.
- Read the source escrow’s token balance and the destination token’s totalSupply at recorded block heights; normalize amounts using each token’s decimals.
- Process confirmed deposit and withdrawal events, matching token, amount, sender or recipient, and transaction identity across the two chains.
- Apply each action once: deposits increase expected backing and destination supply; withdrawals decrease destination supply when burned and expected backing when released.
- Compare expected backing with the escrow balance and expected destination supply with the token’s reported supply; alert on any unexplained difference.
What can make the figures diverge?
A direct transfer to the escrow can raise its balanceOf without creating a corresponding destination mint. Count that transfer as unassigned surplus until bridge records explain it; otherwise, a balance-only monitor can falsely report extra backing. Conversely, fee-on-transfer or rebasing tokens can make the escrow’s observed balance differ from the nominal deposit amount, so the token’s behavior must be tested against the bridge’s accounting assumptions before integration.
Keep a per-token ledger of bridge events and periodically compare it with both chains’ contract state at finalized blocks. If the check fails, pause any application logic that depends on the disputed backing and investigate the specific mapping and events. That reconciliation is the useful next step before relying on bridged supply in lending limits, collateral checks, or cross-chain accounting.