Every transaction on a public blockchain is visible to everyone. Validators see it. Mempool watchers see it. MEV bots see it. “Privacy” on most chains means hoping nobody is looking, or routing through a mixer after the fact.
We just shipped something different. RP1 now has hardware-level confidential transaction processing — encrypted payloads that only get decrypted inside verified secure enclave hardware. The plaintext never exists outside trusted execution boundaries.
How it works
Clients wrap their transaction in a TEE envelope — encrypted payload, nonce, provider metadata. That envelope hits the chain like any other transaction, but it stays encrypted through the mempool, through propagation, through everything.
Before block execution, the consensus engine sends the envelope to a verified enclave gateway. The gateway decrypts it inside secure hardware and returns the plaintext along with a signed attestation proving:
- Which enclave produced the result (provider + measurement hash)
- That the software running inside hasn’t been tampered with
- When the decryption happened
- A cryptographic signature binding all of it together
RP1 validators check every claim before accepting the decrypted transaction. Wrong enclave? Rejected. Stale attestation? Rejected. Tampered payload? Rejected. There’s no fallback mode — if enclave verification fails, the transaction doesn’t execute. Period.
What this gets us
Private DeFi operations. Swap amounts, LP positions, trading strategies — all invisible during execution. MEV bots that can’t read transaction contents can’t front-run them.
Replay protection that actually works. Every attestation carries a unique nonce. RP1 tracks seen nonces in persistent storage that survives restarts. Resubmitting an old enclave response fails even after a validator reboot. Most TEE integrations skip this. We didn’t.
Stateful confidential execution. Beyond simple decrypt-and-execute, we built a second mode — confidential-state — where the enclave maintains its own signed state roots per contract context. Each new state root must chain from the previous one, verified by attestation. The host machine never sees intermediate state.
No hardware lock-in. Intel SGX, ARM TrustZone, AMD SEV-SNP — all supported behind one protocol. Validators pick whatever enclave hardware fits their setup. The chain doesn’t care which produced the attestation, only that it’s trusted.
Two trust models
We support both a simple and a production-grade path:
Pinned key mode — an Ed25519 public key check. Straightforward, good for testnet and controlled environments.
Certificate chain mode — full x509 chain-of-trust verification against operator-provided root CAs. Supports certificate rotation, intermediate CAs, standard PKI workflows. This is what production looks like.
The security posture
There’s no “best effort” mode here. TEE processing is on or it’s off — no silent fallback to plaintext. A few things worth being honest about though: host-level compromise after decryption can still expose plaintext in process memory, and key management for envelope encryption is an operational responsibility that sits outside the protocol. That’s on the operator, not papered over by the design.
What’s next
This is heading to testnet. We’ll validate the full flow end-to-end: encrypted submission, gateway decryption, attestation verification, block execution. Certificate rotation procedures and operational runbooks are already documented.
Confidential transactions aren’t a feature we added on top — they’re built into the consensus pipeline. That distinction matters.