TL;DR
We’re proposing a narrow, timelocked reconciliation mechanism scoped exclusively to unrecoverable bridge message failures. This does not create a general minting, withdrawal, or recovery authority over user funds. It is a single-purpose tool that allows Noon to restore the lock-mint invariant when, and only when, a specific bridge message is provably stuck after all standard recovery paths have been exhausted.
Every use is subject to public disclosure with the exact GUID, multisig execution and a 48-hour on-chain timelock (during which this process can be paused if issues arise).
Context
For any protocol deployed across multiple chains, bridge risk is largely inescapable. Noon has minimised this risk by building our own bridge infrastructure, but we still rely on underlying messaging layers from LayerZero and Hyperlane. Any external dependency carries residual risk.
In April 2026, a LayerZero incident resulted in a small amount of sUSN becoming irretrievably stuck during the bridging process:
| Amount affected | 12,728.9 sUSN |
|---|---|
| From (network) | Sophon |
| TXID | 0xad83125597ef4bc9bcf13e64798427b9fd80c443888c9213d27ce87a90c27360 |
| Status | Confirmed unrecoverable through all standard LayerZero recovery paths |
Similar events could reoccur. Rather than handle each case ad-hoc, we want to establish a clear, conservative, on-chain mechanism, and put it through full community governance before it’s ever needed again.
How the issue arises
sUSN is bridged across chains using a lock-mint model, used by both our LayerZero and Hyperlane integrations. Under normal flow:
-
Tokens are locked in escrow on the source chain
-
Minted 1:1 on the destination chain
-
The invariant
lockedSupply == mintedSupplyAcrossDestinationsis preserved at all times
Bridge messages can occasionally fail to deliver, stuck DVN verification, executor failure, lzReceive revert, and similar edge cases. When a message is genuinely unrecoverable after all standard recovery paths have been exhausted, the escrow on one side ends up with no corresponding live supply on the other. The invariant breaks until manually reconciled.
The mechanism proposed here is the manual reconciliation path.
Scope (what this is not)
To be explicit, because framing matters:
-
This is not a general recovery authority. The mechanism cannot touch user funds, vault assets, or any balance outside of a specifically identified stuck bridge message.
-
This is not a minting authority. Reconciliation only restores the lock-mint invariant for a verified GUID, it cannot mint sUSN out of thin air.
-
This is not a withdrawal authority. The multisig cannot withdraw, redirect, or reroute assets through this function.
-
This mechanism is scoped exclusively to bridge message failures and subject to per-incident public disclosure.
If the function is ever called for any reason other than a publicly disclosed, GUID-referenced stuck bridge message, the action will be visible on-chain in real time during the 48-hour timelock window.
Process
When Noon is made aware of a potentially unrecoverable bridge message, the following process is triggered:
-
Investigation. We thoroughly investigate the incident, ensuring no standard recovery path exists.
-
Confirmation. We confirm the exact amount of assets affected and the specific message GUID.
-
Public disclosure. A dedicated topic will be opened on the Noon Governance Forum (Unrecoverable Bridge Assets), which will be where we post any incident. For each incident, we will post all details publicly, including the exact TXID and GUID of the bridge message in question. We will also publicly notify our community via our official Telegram group, with a link to this Forum post.
-
On-chain request. The multisig calls
requestHandleFixIssue, starting the 48-hour timelock. The pending action becomes publicly visible and monitorable. -
Execution. If no issues are raised during the timelock window, the multisig calls
validateExecuteHandleIssueto complete the reconciliation.
The on-chain request is revocable or re-queueable if anything is flagged during the window.
Contract changes
Two functions are added to sUSN, both restricted to the multisig and operating as a two-step pattern with an enforced delay between them.
Step 1: requestHandleFixIssue(bytes32 guid, string reason)
-
Called by the multisig to register a pending recovery action
-
Inputs: the bridge message
guidand a human-readablereasonstring (e.g. referencing the third-party incident) -
Records the request on-chain and starts the timelock window
-
Emits an event so the pending action is publicly visible for the duration of the delay
Step 2: validateExecuteHandleIssue(bytes32 guid)
-
Called by the multisig after the timelock has elapsed
-
Validates that the corresponding request exists and the delay has passed
-
Executes the reconciliation for the given GUID
-
Emits
StuckMessageReconciledwith the GUID, amount, and recipient
Timelock
-
Enforced on-chain inside the contract: Step 2 reverts if called before
request.timestamp + MIN_TIMELOCKhas elapsed -
MIN_TIMELOCKis set to a hard floor of 48 hours in the contract itself -
The multisig cannot bypass or shorten this delay
Why this matters
Bridge risk is structural for any multi-chain protocol. The choice isn’t between “having this risk” and “not having it”, it’s between handling failures transparently with on-chain guardrails, or handling them ad-hoc when they occur.
This proposal puts the mechanism in writing, behind a timelock, behind public disclosure, and behind a community vote before it’s ever needed. We’d rather establish the rails now, in a clean governance process, than improvise under pressure later.
Next steps
This proposal is not a fait accompli. While we believe this to be the best way forward, we want to ensure our community is comfortable with this approach. Therefore, this discussion in the Governance Forum will be open for 2 weeks, followed by a 1 week voting period. Only if this passes will the changes described be implemented by the Noon team.