Your Trades Are Nobody's Business: How We Built a Private RFQ Engine

Every trade you make on-chain is public

When you trade on a DEX, everyone sees it. Your wallet address. The token pair. The amount. The price. The MEV bots see it before it even hits the chain.

On centralized exchanges, you trust the platform not to peek. Spoiler: they peek. Order flow data is valuable, and front-running by exchange insiders is an open secret.

Prediction markets are worse. If a market maker sees that a whale is building a large position on “BTC > $100K,” they can adjust their quotes — or trade ahead of you. Your intent becomes their signal.

We think your trades should be nobody’s business except yours and your counterparty’s. So we built the RFQ engine to enforce that at the hardware level.

What’s an RFQ engine?

Request-for-quote is how large trades work in traditional finance. Instead of hitting a public order book (where everyone sees your order), you send a private request to market makers. They compete to give you the best price. You accept the best quote. Both sides sign. Settlement happens.

The key difference from an order book: your intent stays private until you commit.

Our RFQ engine handles this for prediction market parlays. You pick your outcomes, we fan out the request to market makers, they quote odds, you pick the best one. The whole exchange happens over WebSocket in sub-second timeframes.

But here’s the problem: the server routing these messages can see everything. Token pairs, amounts, prices, wallet addresses. A traditional backend is a single point of trust.

AWS Nitro Enclaves: trust the hardware, not us

AWS Nitro Enclaves are hardware-isolated virtual machines with no persistent storage, no network access, and no interactive login. Not even AWS administrators can access what’s running inside. The only way in or out is through a constrained communication channel.

The key property: the enclave can prove what code it’s running. When a Nitro Enclave boots, it generates a cryptographic attestation document — signed hashes of the exact enclave image, kernel, and application code. Anyone can verify that the enclave is running exactly the code you expect, with no modifications.

This isn’t “trust us, we encrypted it.” This is “here’s a cryptographic proof from the hardware that this specific code is running in an environment we can’t access.”

How our architecture works

The RFQ backend has three components with clearly separated trust boundaries:

The blind relay

The API server handles WebSocket connections, routes messages, and manages session state. But it’s designed to be a blind relay — it routes encrypted payloads between traders and the enclave without reading them.

The API sees:

• Connection IDs (for routing)
• Anonymous session identifiers
• Encrypted blobs (which it can’t decrypt)

The API does NOT see:

• Token pairs or amounts
• Prices or quotes
• Wallet addresses
• Trade parameters of any kind

Even if someone compromised the API server, they’d get encrypted blobs with no way to decrypt them.

The enclave

All privacy-sensitive logic runs inside the enclave:

• Authentication: Verifying your identity
• RFQ processing: Receiving requests, fanning out to market makers, collecting quotes
• Quote validation: Simulating settlements before presenting them to you
• Order construction: Building the signed settlement orders
• Signing: Using keys that only activate after cryptographic attestation

The enclave is the only component that sees trade parameters in plaintext. It processes them, produces results, and encrypts everything before it leaves.

The encryption layer

Your browser and the enclave establish a direct encrypted channel:

1. Your browser fetches the enclave’s attestation document
2. It verifies the hashes match the expected, published enclave image
3. A shared secret is negotiated
4. All subsequent messages are end-to-end encrypted

The API server relays these encrypted messages but cannot decrypt them. Even if the API server is fully compromised — root access, memory dumps, everything — the attacker gets ciphertext.

What market makers see

Market makers need to see RFQ parameters to price them — that’s the whole point. But they don’t see the taker’s identity.

When the enclave fans out an RFQ to market makers:

• MMs receive: the market, the size, the deadline
• MMs do NOT receive: your wallet address, your identity, other MMs’ quotes

Each MM sees only their own RFQ and responds with a signed quote. The enclave collects quotes, ranks them, and presents the best options to you. MMs never learn who they’re trading with until settlement hits the chain.

The three-stage rollout

We’re building this incrementally because privacy architecture has to be right:

Stage 1 — Code boundary (current) All sensitive logic is cleanly separated behind a privacy boundary. The simulator runs in-process for now — no hardware isolation yet, but the architecture enforces the separation. This lets us build and test the full flow before adding encryption.

Stage 2 — Cryptographic boundary End-to-end encryption between your browser and the enclave. The API server handles only encrypted payloads. Even without hardware isolation, the API can’t read trade data.

Stage 3 — Hardware isolation Real AWS Nitro Enclave deployment. Hardware-enforced process isolation. Signing keys that only activate after attestation. The full deal.

Each stage is independently useful. Stage 1 prevents accidental data leaks. Stage 2 prevents deliberate inspection. Stage 3 prevents even physical access attacks.

What the attestation proves

When you connect to Purrdict, your browser can request the enclave’s attestation document. This document, signed by the Nitro hardware, contains:

• Hashes of the exact binary running inside the enclave
• Hashes of the kernel and application code
• A timestamp and anti-replay nonce

Your browser compares these hashes against the published, audited enclave image. If they match, you know:

1. The enclave is running the exact code that was published
2. Nobody — not us, not AWS — has modified it
3. The signing keys are bound to this specific enclave instance
4. Any quote signed by this key was produced by unmodified code

This is a strictly stronger guarantee than any centralized exchange offers. You don’t trust our word. You verify against the hardware.

Why this matters for parlays

Parlay pricing reveals more about a trader’s thesis than a single bet. If you’re building a 5-leg parlay on correlated crypto outcomes, the combination itself is a signal — it tells the market what you think is about to happen.

Without privacy, market makers could:

• Adjust quotes based on your identity (worse prices for known sharp traders)
• Trade ahead of your parlay on the underlying markets
• Leak your position to other traders

Inside the enclave, none of this is possible. The MM sees an anonymous RFQ. The API sees encrypted blobs. The chain sees the final settlement. Your thesis stays yours.

Contract security

The smart contracts that handle settlement have been through an internal security review with fixes applied for reentrancy protection, replay attack prevention, fee-on-transfer exploits, and gas griefing. Third-party audit is planned before mainnet launch.

The contracts are the enforcement layer. The enclave is the privacy layer. Together, they ensure that your trades are both private and correctly settled.

Your trades are nobody’s business. Try Purrdict on testnet, or join the waitlist for mainnet.