TEE-Backed Fast Cross-Chain Transfers

Dymension now supports TEE-backed fast withdrawals, allowing RollApps to achieve instant finality for bridging operations. Sequencers can run a TEE sidecar, a trusted execution environment that independently verifies blocks and produces attestations. This reduces liquidity requirements for eIBC fulfillment and speeds up withdrawals for end users.

What Are TEE-Backed Fast Cross-Chain Transfers?

Traditionally, RollApp state updates require a (7 day) dispute period before finalization. During this window, anyone can challenge invalid state transitions, creating a trust delay. While essential for security, this waiting period impacts user experience and ties up capital in bridging operations.TEE-backed fast withdrawals introduce a parallel path to instant finality. A sidecar chain full node runs inside Google Cloud Platform's Confidential Space—a hardware-isolated trusted execution environment. This node independently validates every RollApp block and produces signed attestations that prove the block is valid, and that the validation computation was not tampered with in any way.When the hub receives a valid attestation, it can immediately finalize the RollApp state, bypassing the standard dispute period and enabling instant withdrawals.

Why This Matters: Faster Withdrawals, Lower Costs

Fast withdrawals directly improve Dymension's eIBC (market based IBC) mechanism. eIBC allows market makers to fulfill cross-chain transfers before full finalization, earning fees by providing liquidity. However, market makers face two constraints:Capital efficiency: Locked funds during dispute periods limit throughput and impose an opportunity costRisk premium: Longer finalization windows increase uncertainty, raising fulfillment costs for the end userTEE attestations remove both barriers. With instant finalization, market makers can recycle capital faster and remove the risk of invalid state transitions. This translates to:Lower transfer fees for usersHigher throughput and availability for cross-chain transfersImproved user experience that approaches single-chain transfer speedsFor RollApp users, this means faster bridging without the need for a market maker, and lower costs for moving assets between chains. The result is cross-chain interaction that feels more seamless and comparable to single-chain usage.

How It Works

The system has three parts:

1. TEE Sidecar (Confidential Space Workload)

A sidecar full node runs inside a GCP Confidential VM using Intel TDX. This node syncs with the RollApp network, validates blocks, and produces attestations when requested.

2. Sequencer Client

The sequencer periodically queries the TEE sidecar and submits attestations to the Dymension hub.

3. Hub Verification

The hub verifies attestations come from a genuine GCP Confidential Space environment running approved code, then uses the attestation to finalize the RollApp state.

GCP Confidential Space Architecture

What is GCP Confidential Space?

GCP Confidential Space is Google's platform for secure multi-party computation. It provides an isolated environment where sensitive data can be processed without exposure to cloud operators, workload operators, or other parties. The system is built on three key components:Confidential VM: A hardened virtual machine running on specialized hardwareWorkload: A containerized application (in our case, the RollApp full node)Attestation Service: Google's service that produces cryptographically signed proofs about what's runningThe critical guarantee: even Google cannot access the data or modify the computation happening inside a Confidential Space workload.

Intel TDX: Hardware-Level Isolation

Intel Trust Domain Extensions (TDX) provides the foundation for this security. TDX is a CPU technology that creates encrypted, isolated execution environments called Trust Domains. Each Trust Domain:Runs with its own encryption keys generated by the CPUHas memory encrypted at the hardware level, invisible to the hypervisorIs protected from physical memory attacks and side-channelsCannot be inspected or modified, even by privileged software or Google operatorsWhen a workload runs inside a TDX-enabled Confidential VM, the CPU itself enforces isolation. No amount of administrator access, debugging tools, or hypervisor control can break into the running computation.

Why GCP Confidential Space Over Alternative TEE Solutions?

While several blockchain projects have adopted Intel SGX (Secret Network, Phala, Flashbots) or AWS Nitro Enclaves (Turnkey, Marlin Oyster) for trusted execution, Dymension chose GCP Confidential Space for production deployment. The alternatives demand significant operational overhead: SGX requires application refactoring and rewriting for enclave constraints and custom Intel Attestation Service infrastructure, while Nitro Enclaves lack external networking and need custom attestation verification. Both require teams to manage complex security infrastructure alongside their core application logic, which opens up the surface area for attack.Confidential Space use Intel TDX—a next-generation TEE technology that provides VM-level isolation instead of SGX's process-based enclaves—and shifts the operational burden to GCP's managed infrastructure. Dymension focuses solely on building and auditing a Docker container image. GCP handles everything else: attestation service infrastructure, OS security patches, hardware vulnerability mitigation, and attestation token generation. Operators deploy using standard tools (gcloud compute instances create), governance controls security through approved image hashes, and the system provides full networking and container-native deployment without code changes. The result is production-grade security with minimal operational complexity.Confidential Space represents the maturation of TEE technology—moving from research-grade SGX deployments requiring deep security expertise to production-grade managed services that fit standard DevOps practices.

GCP Attestation Tokens: Verifiable Proof

The attestation service is what makes this system trustworthy for blockchain use. When the TEE sidecar requests an attestation, Google's attestation service issues a signed JSON Web Token (JWT) that includes:Hardware claims: The exact CPU model (hwmodel: GCP_INTEL_TDX) and secure boot statusSoftware claims: The SHA256 hash of the Docker container image runningInstance metadata: Which GCP project, zone, and instance the workload is running onCustom nonce: Application-specific data (in our case, RollApp ID, height, and state root)These tokens are signed with Google's private key. The signature can be verified using Google's published root certificate, proving the token genuinely came from Google's attestation service. Because the claims include the exact container image hash, anyone can verify that a specific, audited piece of code is running—not a modified version.The hub validates these tokens by:Verifying the cryptographic signature chain back to Google's root certificateChecking the token claims against governance-approved policies (exact image hash, hardware requirements, etc.)Confirming the nonce matches the claimed blockchain stateThis three-layer verification ensures the attestation genuinely came from the approved code running in a real TDX environment.

Governance-Controlled Policies

All security policies live on-chain in the Dymension hub. The community controls which Docker images are approved, which hardware is allowed, and other security parameters through governance proposals. This ensures:Transparent workload verificationCommunity oversight of code changesImmutable audit trail of approved imagesChanging the approved workload requires a governance vote, giving the community direct control over the security model.

Trust Model

The security model requires trusting:Intel TDX hardware implementationGCP's attestation service and key managementThe specific Docker image hash approved by governanceCritically, it does not require trusting:GCP operators (hardware isolation prevents access)The sequencer (attestation is independent)Network providers (attestation binds to specific blockchain state)

Operational Considerations

Running a TEE sidecar requires a GCP Confidential VM with TDX support. The cost is borne by whoever operates the sidecar (typically the sequencer or a third-party service provider).If the TEE sidecar goes offline, fast withdrawals stop but standard dispute period finalization continues. RollApp operation is unaffected—only withdrawal speed degrades.Upgrading the TEE workload requires a governance proposal with the new Docker image hash. Once approved by the community, operators can deploy the updated image.

Summary

TEE-backed fast withdrawals bring instant finality to Dymension RollApps by leveraging hardware-based security:The Feature: A sidecar full node runs inside Google Cloud's Confidential Space and produces signed attestations proving correct block execution. These attestations allow the hub to finalize RollApp state instantly.The Technology: Intel TDX provides CPU-level isolation that even Google cannot break. GCP's attestation service issues cryptographically signed tokens proving what code is running. The Dymension hub verifies these tokens against community-approved policies.The Benefit: Users get instant withdrawals with lower fees. Market makers get better capital efficiency. RollApps get a competitive advantage through superior user experience. The result is cross-chain interaction that feels more seamless and comparable to single-chain usage.Dymension's modular approach continues to reduce friction between chains. TEE fast withdrawals remove another barrier, making cross-chain interaction more efficient and user-friendly. It's close to being as smooth as same-chain transfers. As more RollApps adopt this feature, the entire ecosystem benefits from deeper liquidity and faster capital flow.