12-Hour Fraud Proof Window

Enhancing Security and assuming optimistic Finality

12-Hour Fraud Proof Window

Enhancing security with assumed optimistic finality

Symmio is structured like an optimistic L2: trades execute against the belief that everything is valid and final the moment the user sees the confirmation, regardless of the underlying chain's finality. That belief is what gives the platform its CEX-like responsiveness. The 12-hour fraud proof window is the safety net under it — a buffer in which watchdogs and the protocol's own dispute machinery can detect bad behavior, stop transactions in flight, and unwind anything that shouldn't have happened.

In the current version this system is still intact, but where the window applies has shifted. The old "deallocate, wait 12 hours, withdraw" path is now one of three withdrawal types in the unified Withdraw System. Express and virtual providers can pay users instantly while the cooldown still runs against a separate piece of liquidity that the protocol holds back; the providers reclaim the funds at the cooldown's end. The ClearingHouse and the dispute resolver use the same window to clear up the cases the decentralized flow can't reach.

Why 12 hours?

The window also acts as a buffer against unknown vulnerabilities. If a class of bug is discovered post-deployment, the protocol has 12 hours to detect, verify, and intervene before the attacker can exit. Pause roles (PAUSER_ROLE) and the SUSPENDER_ROLE can stop in-flight withdrawals; the dispute resolver and ClearingHouse can correct corrupted on-chain state.

Symmio's layered verification model

The fraud-proof window is the last layer in a stack of checks:

Layer 1 — User ↔ Solver. Users and solvers interact directly to execute trades. Disputes are arbitrated by the Muon oracle in the first instance: the off-chain TSS network attests to unrealized profits/losses, prices, and solvency, and the contract uses those attestations to check every state-changing operation.

Layer 2 — Oracle fraud protection. Should a malicious actor compromise or manipulate the oracle, fraud-proof checkers serve as an additional safeguard. They monitor the Muon attestations and the resulting on-chain state, and can suspend addresses or withdrawals when discrepancies appear. The new per-MuonFunction authorization in MuonSignatureVerifier reduces the blast radius here: a key compromised for one category cannot sign for another.

Layer 3 — Fraud-proof checkers. Watchdogs that look for issues like double-spends, reorganizations, or signature corruption — scenarios that on most chains would be prevented by deep finality, but which Symmio's optimistic finality leaves room for. In the cases the dispute resolver or watchdogs cannot resolve, the ClearingHouse can take over a stuck PartyA liquidation entirely and complete it with its own price feed.

Withdrawals

Cooldown is anchored to deallocation

In the current version, the cooldown is computed from the user's last deallocation:

cooldownEndTime = max(deallocateTimestamp + withdrawCooldownPeriod, block.timestamp)

If the funds have been idle for the full cooldown (typically 12 hours), a freshly initiated withdrawal can finalize immediately. Subsequent deallocations don't reset the cooldown of an already-initiated withdrawal. The view function getWithdrawableTime(user) returns the earliest time a withdrawal initiated now could finalize.

The four withdrawal types

A withdrawal request is built from one or more receiver parts, each routed through a path:

Type	Express	Virtual	Description
Normal (Classic)	✗	✗	Standard cooldown, same-chain delivery
Pure Express	✓	✗	Instant same-chain withdrawal
Pure Virtual	✗	✓	Standard cooldown, cross-chain delivery
Virtual Express	✓	✓	Instant cross-chain withdrawal

Express providers front the funds for a fee and reclaim them after the cooldown ends. Virtual providers sit on top of the Virtual Fund System and deliver on the user's preferred chain via lifecycle callbacks (onWithdrawRequest, acceptWithdrawRequest, onWithdrawComplete, onWithdrawCancel). A provider can be one or the other, not both.

The fraud-proof window is preserved even when the user's funds arrive instantly. The mechanism:

• The user calls initiateWithdraw(...). Status: PENDING.

• The express provider is notified via onWithdrawRequest and decides whether to accept.

• On acceptWithdrawRequest, status moves to PROVIDER_ACCEPTED. The provider pays the user out of its own liquidity, immediately.

• The cooldown clock continues to run against the original on-chain balance, which remains held by the protocol.

• After cooldown expires, finalizeWithdrawRequest releases that balance to the express provider, which reclaims its outlay.

If something goes wrong inside the window the protocol can prevent finalization and the express provider's liquidity is at risk, not the user's funds.

Cancellation, blackouts, and force-cancel

• Before a provider has accepted, the user may cancel any time.

• After acceptance, outside any blackout window the provider configured, the user may still cancel directly.

• Inside the blackout, cancellation goes to CANCEL_REQUESTED and waits for provider approval — protecting the provider from being cancelled on after they've already paid out.

• An admin (SETTER_ROLE / dispute resolver) can forceCancelWithdraw in pathological cases.

• Speed-up approvals for whitelisted users can shorten the cooldown for specific cases without changing the global parameter.

The legacy transferToBridge flow has been retired in favour of the express/virtual paths; bridges in the old version are now express providers with their own liquidity pools. If the protocol detects misuse, the relevant SUSPENDER_ROLE can suspend an address and stop a transaction inside the window.