Asset Withdrawal

Fast, secure appchain withdrawals with TEE + zk proofs using native bridges. Key concepts and required configuration.

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 challenge-based fraud proofs, it delivers near-instant finality 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.

Future Upgrades

  • Multi-TEE across different cloud providers
  • Multi-zkVM system with multiple providers
  • Requires sign-off from multiple parties
  • Includes challenge mechanisms when systems disagree

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
  • Decentralized Operation: TEEs can be run by anyone, not just the core team
  • Multi-Provider Redundancy: Future multi-TEE/multi-zkVM architecture prevents single points of failure

Current Status

  • Withdrawal system is currently under development
  • Starting with one TEE 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.

On this page