Bringing confidential compute to Avalanche

How we stood up a full FHE stack on our own infrastructure — and how it becomes a decentralized service for C-Chain and every Avalanche L1.

Most of what happens on-chain today is public by default. For a lot of the things our ecosystem wants to build next — confidential payments, private DeFi, sealed-bid auctions, on-chain games with hidden state — that's a dealbreaker. This is our engineering take on closing that gap natively, on infrastructure we control, with no dependency on any outside operator.

1. What we set out to prove

The enabling technology is Fully Homomorphic Encryption (FHE) — it lets a computer do math on numbers while they stay encrypted. Applied to a chain, that means balances and inputs can live on-chain as ciphertext, and the network can still verify a transaction is valid without ever seeing the values. Zama's FHEVM is the most mature implementation, and it's open source.

So we asked a simple question: can Avalanche run this entire stack itself? Not as a hosted service someone else operates and meters — but built from source, on our own boxes, serving our own chains. The answer is yes, and this site is the proof:

2. The core idea: math on locked boxes

You don't need cryptography background for the intuition. FHE is like being able to add up the contents of two sealed boxes and get a third sealed box with the correct sum — without ever opening any of them. The chain can update an encrypted balance, check an encrypted amount is affordable, and move encrypted funds, all without learning a single number.

The way users interact with it mirrors a casino:

3. What's private, and what isn't

We're precise about this, because over-promising privacy is how people get hurt. Here's exactly what each action exposes on-chain:

Deposit/withdraw amounts are public because they're the on/off-ramp between public and confidential funds — the same boundary every privacy system has. Everything inside the pool is encrypted.

How "private send" hides the receiver

A private transfer doesn't touch only you and the recipient — it touches every member of the pool at once, handing each an encrypted amount. Almost all are encrypted zeros; only the real recipient's is the actual amount. Since every entry is ciphertext, an observer can't tell which one was real — the recipient is hidden in the crowd, and privacy scales with the size of that crowd. (You still sign the transaction, so your own address shows as the sender; hiding that too needs zero-knowledge spend proofs, which we'll come back to.)

4. The stack we run

Here's the system we self-host, component by component. The useful split: the chains remember state and agree on order, the coprocessor does the encrypted math, the KMS guards the key, and the relayer + listeners are the plumbing that connects them.

5. The lifecycle of a transaction

Every confidential action has the same shape: encrypt → submit → compute → (later) decrypt.

We built an interactive view that walks each action through these phases, station by station:

6. Making it ours: decentralizing on an Avalanche L1

What's running today is centralized — one box, one key holder, one coprocessor. That's the right scope for a proof of concept, but it means users are trusting us. The whole point of doing this on Avalanche is to spread that trust across the validator set we already operate. One rule guides the design:

What becomes what

So exactly one thing becomes a new chain — the gateway. The KMS and coprocessor don't become chains; they become the two big jobs our validators perform. Everything else is plumbing.

How we'd ship it

7. Should Fuji itself be the gateway?

There's a tempting shortcut: skip the dedicated gateway L1 and deploy the gateway contracts directly on Fuji C-Chain. Fuji is already secured by our full validator set, so there's no new chain to bootstrap. It's a real option — but it changes the trade-offs, and it hits two audiences differently.

For Fuji-native confidential apps (host = gateway)

• No cross-chain bridging. The ACL and decryption coordination sit on the same chain as the app, so there's none of the cross-chain "wait for the permission to read across" step — the trickiest part of a multichain setup. Reveals and withdrawals settle faster and more reliably.
• Top-tier security, free. Coordination is protected by C-Chain's validators, no separate chain to secure.
• But the load lands on C-Chain. Every decryption request and verification becomes a C-Chain transaction — paying AVAX gas and competing with all other C-Chain activity. Fine at small scale; meaningful at ecosystem scale.

For onboarding other Avalanche L1s (Fuji as the shared gateway)

• Fast onboarding. A new L1 deploys its host contracts on itself and just registers with the Fuji gateway — it doesn't run its own gateway or KMS, it reuses ours.
• Cross-chain comes back. Each L1 is now a host chain talking to a remote gateway (Fuji), so every one pays the cross-chain ACL-read cost we just avoided for Fuji-native apps.
• C-Chain becomes the shared bottleneck. Every confidential L1's coordination traffic funnels through Fuji, concentrating the ecosystem's privacy load and gas on C-Chain — and coupling every L1 to its congestion.

8. Where this goes

The proof is done: the full stack runs on our infrastructure and serves real confidential transactions on Fuji. The path from here is incremental and each step stands on its own:

• Threshold KMS across a validator committee — the headline decentralization and trust win.
• Multiple coprocessors with co-signing, scaled horizontally as confidential TPS grows (and a GPU build when we want the ~4× throughput it brings).
• A gateway L1 so C-Chain and every Avalanche L1 can offer confidentiality through one coordinated hub.
• Production hardening — managed Postgres/S3, multiple relayers behind TLS, hot-key handling via a KMS signer — so it's an ecosystem service, not a single box.

The strategic takeaway is the simple one: confidential compute can be a native Avalanche capability that we own outright — no external operator in the critical path, extensible to the whole ecosystem.

Built on Zama's open-source FHEVM, self-hosted by Avalanche. This is a testnet proof of concept on Fuji using mock USDC.