Summary
This topic is the permanent public record for every reconciliation executed under the bridge message reconciliation mechanism approved by community vote on 27th May 2026.
Each affected bridge message gets its own post below, containing the source network, the amount, the transaction link, the GUID, the recovery transaction proposal and the recovery transaction execution. This first post sets out the background, links the original discussion and the vote, and restates the process, so that anyone arriving at a specific incident post has the full context in one place.
Original proposal and discussion: Proposal: Bridge message reconciliation mechanism
Snapshot vote: Bridge message reconciliation mechanism
Background
Noon is deployed across multiple chains and relies on external messaging layers from LayerZero and Hyperlane. We minimise this exposure by building our own bridge infrastructure, but any external dependency carries residual risk.
In April 2026, a LayerZero incident left a quantity of sUSN irretrievably stuck during bridging, confirmed unrecoverable through all standard LayerZero recovery paths. Similar events can reoccur. Rather than handle each case ad-hoc, we established a clear, conservative, on-chain mechanism and put it through full community governance before it was needed again.
The proposal was open for discussion for two weeks, went to a one week vote, and passed.
What the mechanism does
sUSN is bridged using a lock-mint model, where tokens are locked in escrow on the source chain and minted 1:1 on the destination, preserving the invariant lockedSupply == mintedSupplyAcrossDestinations. When a message is genuinely unrecoverable, escrow on one side ends up with no corresponding live supply on the other, and the invariant breaks until manually reconciled. This mechanism is that manual reconciliation path.
Scope is deliberately narrow, and worth restating in full:
-
This is not a general recovery authority. It cannot touch user funds, vault assets, or any balance outside a specifically identified stuck bridge message.
-
This is not a minting authority. Reconciliation only restores the lock-mint invariant for a verified GUID.
-
This is not a withdrawal authority. The multisig cannot withdraw, redirect or reroute assets through this function.
-
It applies exclusively to bridge message failures, subject to per-incident public disclosure.
Process followed for every incident
-
Investigation. We confirm that no standard recovery path exists for the message.
-
Confirmation. We confirm the exact amount affected and the specific message GUID.
-
On-chain request. The multisig calls requestHandleFixIssue(bytes32 guid, string reason), which registers the pending reconciliation, starts the 48-hour timelock and emits a public event, making the pending action visible and monitorable on-chain.
-
Public disclosure. A dedicated post is published in this topic with the full details, including the exact TXID and GUID, alongside notification to the community in our official Telegram group.
-
Execution. If no issues are raised during the timelock window, the multisig calls validateExecuteHandleIssue(bytes32 guid), which emits StuckMessageReconciled with the GUID, amount and recipient.
The original proposal listed public disclosure ahead of the on-chain request. In practice we publish each incident post once the request transaction has been proposed, so that the disclosure carries a verifiable pending transaction rather than an intention, and the community review period runs alongside the full 48-hour timelock. The request remains revocable or re-queueable if anything is flagged during the window.
Timelock
The minimum delay is enforced on-chain inside the contract. Step 5 reverts if called before the 48 hours have elapsed, MIN_TIMELOCK is set as a hard floor in the contract itself, and the multisig cannot bypass or shorten it.
How to read this topic
Incident posts follow a fixed format and are updated in place as each stage confirms:
-
Transaction link
-
Source network
-
Amount
-
GUID
-
Recovery Transactionx Proposal time:
-
TXID:
-
[Estimated] Recovery Transaction Execution time:
Individual posts for each follow below.
Raising a concern
If you have any objection to a proposed reconciliation, reply directly in the relevant incident post during the 48-hour window, or reach the team in the Noon Telegram. The timelock exists precisely so that the community can act before anything executes.