Use Cases
This page describes tasks that fit an E3 and the limits that apply to them. It is for developers who want to know if the Interfold fits their application. At the end, you can compare your task with a working example and with the checks in Limits to check.
What fits an E3
An E3 fits a task that has these properties:
- Several independent parties contribute inputs that must stay private.
- The application needs one result from all inputs, and the result can be public.
- The result is a computation that BFV supports well, for example a sum, a count, or a tally.
- No single operator is acceptable as the custodian of the inputs.
- The application can wait for the E3 stages. An E3 does not give a real-time result.
Private voting (CRISP)
CRISP (Coercion-Resistant Impartial Selection Protocol) is the reference application in
examples/CRISP. It is a complete, working E3 program for secret ballots.
| Part of the E3 | What CRISP does |
|---|---|
| Request | The CRISP command-line tool requests one E3 for each voting round. |
| Inputs | Each voter encrypts a ballot in the browser under the committee key. |
| Input proof | The client generates a Noir proof that the ballot is valid. CRISPProgram.sol verifies it. |
| Data availability | The ciphertext bytes go to Avail. The program checks the VectorX receipt. |
| Secure process | An OpenVM program adds the encrypted ballots into an encrypted tally. |
| Output | The committee decrypts only the tally. Individual ballots stay encrypted. |
CRISP has its own contracts, Noir circuits, a Rust coordination server, and a React client. Start with the CRISP introduction, then follow Setup to run it.
Sealed-bid auctions and private markets
Bidders submit encrypted bids, and only the auction result is decrypted. This pattern matches the E3 model. The limit is the computation. The template and CRISP use only homomorphic addition. Other operations cost more and use the limited noise budget of the BFV parameter set.
Before you build an auction, confirm that your secure process can compute the result within that budget. A design can also decrypt an aggregate, for example the number of bids at each price level. The contract can then compute the result from the aggregate. This design reveals the aggregate, but not the individual bids.
Aggregate statistics over private data
Several organizations can compute a total, a count, or a histogram over records that they do not share. Each organization encrypts its values, and the secure process adds them. Only the aggregate is decrypted. This pattern uses the same addition as the default template, which sums all inputs.
Limits to check
Check these limits before you design an E3 program:
- The output is public. The plaintext output goes on-chain. A small number of inputs can reveal an individual value, for example a tally with one vote. The program must enforce a minimum input count or other rules where this matters.
- The committee is the trust boundary. T + 1 committee members that collude can decrypt any
ciphertext under the committee key. A larger committee raises T. On mainnet, only
Small(T = 9) can be requested at launch. - Inputs need validation. The E3 program decides which inputs to accept. Without an input proof, a malformed ciphertext can corrupt the result or stop the E3.
- Time matters. Committee setup, the input window, computation, and decryption each have a deadline. The E3 lifecycle page lists the values.
- Costs grow with the committee. The fee pays for the committee work, and it grows with N. Use
getE3Quoteto get the fee before you request.
Data protection
The design can help an application meet data-protection goals. No single operator holds a plaintext input, and the committee decrypts only the output. The design does not by itself make an application compliant with a regulation. The application owner is responsible for that assessment.