What is the Interfold?

The Interfold is an open-source protocol for Encrypted Execution Environments (E3s). Independent parties use it to get one shared, verifiable result from their private inputs. This page is for readers who are new to the protocol. It explains the problem, what the protocol does, the guarantees and what backs each one, and the roles. At the end, you know which part of the docs to read next.

The problem

Many applications need one result from inputs that belong to different parties. A vote tally, a sealed-bid auction, and a shared statistic are examples. Usually, one party collects the plaintext inputs and computes the result. That party then has custody of sensitive data, and every other party must trust it.

Trusted hardware is another approach, but it moves the trust to a hardware vendor. The Interfold needs neither a custodian nor trusted hardware. No single party holds the plaintext inputs or the full decryption key. Integrity and privacy come from cryptography and from economic incentives.

What the protocol does

The Interfold contract (Interfold.sol) coordinates each E3 on-chain. A committee of ciphernodes does the cryptographic work off-chain and publishes proofs on-chain. One E3 has these steps:

1. A requester pays a fee and requests an E3 for a registered E3 program.
2. Sortition selects a committee of ciphernodes. A Chainlink VRF v2.5 random value seeds the selection.
3. The committee runs distributed key generation (DKG) and publishes one public key. No member holds the matching secret key.
4. Data providers encrypt their inputs under that public key and submit them to the E3 program.
5. A compute provider runs the program computation over the ciphertexts. It publishes an encrypted output and a proof that the computation is correct.
6. At least T + 1 committee members publish decryption shares. The shares combine into the plaintext output, which goes on-chain with a proof.

Each step has a deadline. When a step misses its deadline, anyone can mark the E3 as failed, and the refund rules apply. The E3 lifecycle page describes each stage.

For example, in a sealed-bid auction, each bidder encrypts a bid. The computation runs over the encrypted bids, and only the result is decrypted. The individual bids stay encrypted.

Guarantees

The table shows each guarantee, the mechanism that backs it, and where the protocol checks it.

Fully homomorphic encryption

BFV is a fully homomorphic encryption scheme. A program can add encrypted values and get an encrypted sum without decryption. The compute provider runs the program on ciphertexts only. It never sees an input or the output in plaintext.

Threshold cryptography

The committee creates its public key with DKG. Each member contributes a piece of the secret key and splits it into Shamir shares for the other members. No member ever holds the complete secret key. Decryption needs T + 1 valid shares, and each share reveals nothing alone. The Cryptography page explains the committee sizes and the math.

Zero-knowledge proofs

Each ciphernode proves every key, share, and decryption step with a ZK proof. An aggregator folds these proofs into two recursive proofs for each E3. The protocol contracts verify both proofs on-chain, so anyone can check the result without trust in the committee.

Economic security

A ciphernode needs a FOLD bond (InterfoldToken) and tFOLD tickets (InterfoldTicketToken) to serve on committees. The SlashingManager can slash ticket collateral and bonds for proven faults, ban an operator, and expel a committee member. A successful E3 pays the active committee members. A failed E3 returns fee escrow to the requester according to who caused the failure.

Assumptions and limits

The guarantees depend on these conditions:

• Collusion threshold. If T + 1 committee members collude, they can decrypt any ciphertext under the committee key, including a single input. Larger committees raise T.
• Public output. The plaintext output is public on-chain. The E3 program must make sure that the output does not reveal an individual input, for example a tally with only one vote.
• Input validation. The E3 program decides which inputs to accept. The default template does not check that a ciphertext matches its commitment. A production program must verify this binding.
• Data availability. The ciphertext output is stored outside Ethereum. The E3 program verifies a receipt from the data-availability layer. CRISP uses Avail with the VectorX bridge.

Roles

One party can have more than one role. For example, an application can request an E3 and also run its compute provider.

Enclave is now The Interfold

Next steps