> For the complete documentation index, see [llms.txt](https://docs.symm.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.symm.io/security-and-architecture/12-hour-fraud-proof-window.md).

# 12-Hour Fraud Proof Window

## 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](/contract-documentation/symmio-perps-v0.8.5/diamond-core-facets/clearing-house-facet.md) 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** ](/contract-documentation/symmio-perps-v0.8.5/diamond-core-facets/clearing-house-facet.md)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.

{% hint style="info" %}
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.
{% endhint %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.symm.io/security-and-architecture/12-hour-fraud-proof-window.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.