Asset Withdrawal

Interoperability is critical for appchains to maximize reach, utility, and user experience. Syndicate's withdrawal system combines a Trusted Execution Environment (TEE) with a zk-verified attestation to enable permissionless, non-interactive verification. By replacing stake-based fraud proofs, it delivers significantly faster withdrawals with native-bridge security, combining the speed of fast bridges with the safety of canonical bridges, without forks or extra operational overhead.

Design Rationale

Our customized sequencing layer changes how transactions are processed, ordered, and derived, which created two options:

1. Fork Arbitrum Orbit and customize its fraud proof system (violates our no-fork principle, delays updates, and requires custom work for every rollup framework)
2. Build a generalizable solution that works with any rollup framework (no forks, no custom fraud proofs)

We chose the generalizable solution.

Core Components

TEE (AWS Nitro)

Provides a secure compute enclave. (Note: AWS Nitro TEE, not Arbitrum Nitro)

• Role: Executes derivation, verifies sequencing/appchain transitions, and outputs a signed withdrawal assertion.
• Trust: Only enclaves whose attestation (PCR measurements) is zk-verified are allowlisted on-chain.
• On-chain check: TeeModule verifies ECDSA signatures; TeeKeyManager accepts keys proven by the zk verifier.
• Developer experience: Use the native bridge as usual; proposers interact with the enclave. Upgrades only require re-attesting/allowlisting keys, not app changes.

zkVM (Succinct SP1)

• Role: Proves the AWS Nitro attestation is valid without revealing the full document.
• On-chain: AttestationDocVerifier checks SP1 proofs (Groth16/Plonk) and enforces expected root cert, PCRs, and validity window, returning the tee_signing_key for allowlisting.
• Public outputs: Root cert hash, validity window, PCR0/1/2, and tee_signing_key.
• Developer experience: You don’t call the zkVM. A proof-submitter generates the proof and registers/rotates enclave keys on-chain.

Withdrawal Process Flow

[User/Appchain] -- withdrawal request
      |
      v
[Proposer] -- validate request + build trusted input
      |
      v
[TEE Enclave] -- verify state + sign assertion --> [TeeModule on settlement]
      |
      |-- attestation verified on-chain -------> [TeeKeyManager + zk verifier]
      |
[TeeModule] -- finalize -----> posts to rollup (e.g., Base) -> withdrawals enabled

1. Request Reception: System receives withdrawal request
2. Validation & Sign-off:
   • Confirms all state transitions in the withdrawal request are valid
   • Verifies withdrawal request is committed as a state root in a reorg-resistant manner to the settlement chain
   • Performs standard checks: user balance verification, state validity, state currency
3. TEE Signing: If validated, TEE signs off using its internal key
4. Key Validation: The TEE's key is considered valid because the ZKVM attestation has validated it
5. Bridge Integration: Hooks into Arbitrum's native bridge via their fast withdrawal mechanism (using the Data Availability Committee interface, but with our withdrawal system providing sign-offs instead of a DA layer). No modifications to the Arbitrum bridge itself.

Key Benefits

• Framework Agnostic: Works with any rollup framework without customization
• No Fork Maintenance: Customers can immediately incorporate Arbitrum Orbit updates
• Native Bridge Security: No custom bridge to hold the funds. Funds are held in Arbitrum's bridge and existing functionality is used to enable withdrawals
• Escalating Security: Fast withdrawals with challenge mechanisms for disputed cases and a dynamic challenge window for additional security
• Decentralized Operation: TEE validators can be run by anyone, not just the core team
• Multi-Provider Redundancy: Future multi-TEE provider/multi-zkVM architecture prevents single points of failure

Withdrawal Timing

Withdrawal times depend on three factors: the challenge period, the batch posting interval, and L1 finalization. Understanding these helps you set accurate expectations for your users.

Timing Components

1. Challenge Period: The window during which withdrawals can be disputed (configurable by chain owner, 60 minutes recommended)
2. Batch Posting Interval: How often withdrawal batches are posted to L1 (1 hour)
3. L1 Finalization: Ethereum L1 finality takes approximately 12.8 minutes

The variability in withdrawal time depends on where in the batch posting window your withdrawal lands. If you submit right before the next hourly batch, you get the minimum time. If you submit right after a batch posts, you wait for the next batch cycle.

60-Minute Challenge Period (Recommended)

With a 60-minute challenge period:

The 60-minute challenge period provides strong security guarantees and sufficient time for TEE validators to detect and flag invalid withdrawals. Unchallenged withdrawals complete in under 3.5 hours.

Shorter Challenge Periods

The challenge period can be configured by the chain owner at any time, but shorter periods increase operational risk. Chain owners can optionally use a timelock contract to govern challenge period changes. A shorter window means less time for TEE validators to detect and challenge invalid withdrawals—if TEE validators experience downtime during a short challenge period, invalid withdrawals could go uncontested.

For example, with a 5-minute challenge period:

While this offers faster unchallenged withdrawals, the reduced window requires higher TEE validator uptime guarantees.

Challenged Withdrawals

Challenges are triggered by TEE validators when they detect an invalid withdrawal (indicating either a bug or TEE compromise). Challenged withdrawals are sent to a security council for manual resolution. Since disputes are rare, this process operates outside the normal timing expectations above.

Instant Bridges and User Experience

In practice, most bridge routes use instant bridges that abstract away withdrawal timing from end users. Users see withdrawals complete in seconds with minimal slippage. The underlying withdrawal time only affects how quickly the instant bridge can rebalance its liquidity.

For instant bridge rebalancing, sub-4-hour withdrawals are more than sufficient. This means the technical withdrawal time has minimal impact on actual user experience when instant bridges are integrated.

L1 Finality Constraint

Withdrawals cannot be faster than Ethereum L1 finalization (~12.8 minutes). Attempting to process withdrawals on unfinalized blocks introduces reorg risk—Ethereum L1 experiences reorgs roughly once every two hours, which could cause loss of funds.

Timing Formula

For reference, withdrawal times can be calculated as:

Min:     1   × challenge period + 0   × batch interval + 12.8 min
Average: 1.5 × challenge period + 0.5 × batch interval + 12.8 min
Max:     2   × challenge period + 1   × batch interval + 12.8 min

Current Status

• Withdrawal system is enabled
• Starting with one TEE provider and one zkVM implementation
• Additional providers will be added progressively

Note: This is a new system under development. Architecture is stable, but details may evolve. For questions or feedback, contact the Syndicate team.