Turbine promises zero-spread trading. The TEE layer is how it proves that promise to traders.
PropellerHeads recently launched Turbine — a trading protocol designed to settle any size trade at the lowest spread in finance. No continuous settlement. No market makers. No arbitrage bots extracting value. Just traders settling with each other and with aggregated DeFi liquidity, slowly and privately.
The order book and settlement logic runs inside Phala Cloud's Intel TDX confidential VMs.
Without TEE: The Trust Gap
A protocol that collects orders, matches them in private, and settles with a single signing key has an obvious weak point: the operator who runs the server. Without hardware guarantees:
- Orders are exposed. Anyone with server access — an employee, a cloud provider, an attacker who compromises the host — can see every order before it settles. Frontrunning is not prevented by policy; nothing stops it.
- The signing key is a honeypot. If the key lives on a regular server, extracting it is a matter of access. Once extracted, an attacker can sign arbitrary settlements, and traders cannot detect it until funds are gone.
- Code can drift from audit. A protocol can be audited by Trail of Bits and still run different code in production. Without cryptographic attestation of the running binary, "we've been audited" has no teeth.
These are not hypotheticals. Centralized order books and dark pools have a decades-long record of information leakage, internal misuse, and settlement disputes. Turbine's design needs a different answer.
Why TEE Is Non-Negotiable
Turbine addresses all three by running the full order book and settlement stack inside Phala Cloud's TEE:
Inside the TEE
Turbine runs as a dstack confidential VM on Intel TDX. dstack provides the TEE platform: it bootstraps the enclave, manages remote attestation, encrypts all networking and storage, and serves as the single entry point for external traffic. On top of this platform, Turbine's batch solver and Fynd's routing engine run as application services. The solver consumes Fynd's DEX routes to compute optimal batch settlements, then signs each one with a key that exists only inside the enclave. The entire stack is measured into a single attestation, so the platform and application are cryptographically bound together.
| Component | Function Inside TEE |
| Turbine (solver) | Core batch pipeline: collect orders → fetch liquidity → compute fees → solver clear batch → simulate/validate → sign → submit on-chain. The settlement signing key lives only inside the enclave. |
| Fynd (routing) | DEX router finding optimal AMM routes across Uniswap v2/v3/v4, Pancake v2/v3, Sushi (Bellman-Ford, up to 2 hops). Runs in-TEE so routing happens privately. |
| dstack (OS) | Manages the confidential VM lifecycle: attestation, encrypted networking (zt-https), and persistent encrypted storage. Serves attestation evidence and handles the TLS certificates that encrypt traffic end-to-end into the TEE. |
One Batch Flow
Orders enter the enclave through dstack, are batched by the solver against Fynd's routes and oracle prices, then simulated, signed, and submitted on-chain. Signing key and order data stay inside the TEE throughout.
On-chain KMS: Transparency by Default
Turbine uses Phala's on-chain KMS — a smart contract on Ethereum that governs the lifecycle of the enclave's signing key. Unlike a traditional KMS where key access is controlled by an operator's IAM policy, the on-chain KMS makes key management transparent and auditable by design.
Key derivation. The settlement signing key is derived inside the enclave through the on-chain KMS contract. No operator generates a key and uploads it. The derivation path is deterministic, so anyone can verify that the key in use matches the derivation rules.
Code upgrade governance. When Turbine deploys a new code version, the new enclave measurement hash must be registered on-chain through the KMS contract. The KMS only issues signing keys to enclaves whose measurement matches a registered version. If an unapproved binary tries to request a key, it gets nothing. This means traders can check which code version is authorized at any time, and no upgrade can happen silently.
Hardware gatekeeping (Phala side). Not every server claiming to be a TDX machine is legitimate. Phala maintains a registry of approved hardware on-chain. The KMS contract only accepts attestation quotes from machines that match the registered hardware profile. A bad actor cannot spin up a fake "TEE" and have it recognized as a valid settlement environment.
The net effect: every aspect of the signing key's lifecycle — which hardware it runs on, which code version it powers, which settlements it signs — is visible on-chain. No black boxes.
The Trust Story
Beyond key management, the runtime itself is cryptographically accountable. The signing key and TLS key are generated inside the enclave and never leave. The entire docker-compose stack is hashed into remote attestation. Anyone can:
- Take a quote from
/attestation/... - Verify it using any TDX quote verifier (e.g. Phala's dcap-qvl library)
- Recompute the hash to confirm the exact components running
Technical Specs
- TEE Type: Intel TDX via dstack
- Key Management: Onchain KMS (production) / Phala KMS (staging)
- Attestation: Remote attestation with publicly verifiable quotes
- Networking: zt-https between clients and CVMs
- Storage: Encrypted persistent volumes for order state
The Bottom Line
Turbine relies on TEE for something concrete: slow trading requires hidden order books, and hidden order books require hardware guarantees, not promises.
Phala Cloud provides those guarantees. Three containers, one compose file, cryptographic attestation.
Learn more: PropellerHeads | Phala Cloud
