Contracts & Addresses

This page lists the deployed Interfold contracts on Ethereum mainnet and Sepolia, with the address and deploy block of each one. It is for operators who configure a ciphernode and for developers who call the contracts. It also describes the role of each contract and the enums and events that clients read. Copy addresses from this page or from the manifest, not from other sources.

Deployment manifest

The source of every address on this page is deployments/manifest.json in the repository. The release process attaches the same file to each GitHub release as manifest.json. The script packages/interfold-contracts/scripts/genManifest.ts generates it from packages/interfold-contracts/deployed_contracts.json.

The manifest has two sections for each network:

Each network entry also has a chain_id and a mocks flag. The flag is true when the network uses a mock E3 program or a mock verifier, which accepts proofs without verification. The manifest in the repository sets mocks: true for Sepolia, because the Sepolia deployment records MockE3Program. It sets mocks: false for mainnet. See Verifiers in use on mainnet and Verifiers in use on Sepolia.

To compare your node configuration with the published manifest, run this command:

interfold config check

For an up-to-date Sepolia chain, the output has this form:

Deployment manifest: release <tag>
sepolia: up to date

The command reads the manifest.json asset of the latest GitHub release. It exits with an error when an address or a chain ID does not match. For the flags and the finding labels, see interfold config check.

Mainnet

Mainnet Ethereum mainnet, chain ID 1.

Mainnet contracts

Mainnet reference contracts

For the two routers, the manifest records block 26,156,286 as the deploy block. That is the first block of the v0.19 deployment. The router contracts have code from block 26,156,611 (BfvPkVerifierRouter) and block 26,156,612 (BfvDecryptionVerifierRouter).

Also used on mainnet

The manifest does not publish these two mainnet contracts, so interfold config check does not compare them. The addresses come from the mainnet deployment records in packages/interfold-contracts/deploy/protocol/. Each deploy block is the first block that has contract code at the address.

sUSDS is a third-party token. The Interfold does not deploy it. To confirm the token addresses on-chain, call getCiphernodeBondToken() on the BondingRegistry for FOLD. For the ticket collateral, call underlying() on the InterfoldTicketToken.

Verifiers in use on mainnet

The Interfold contract stores one verifier of each kind for each encryption scheme. The table shows the values for the BFV scheme (keccak256("fhe.rs:BFV")) at block 26,221,910 (18 October 2026). Each E3 keeps the verifiers that were set when it was requested.

• The ciphertext verifier checks an OpenVM proof for the guest image ID 0x126eb3ea8c2d24cbf8e89f7e41dd2f0be5050be7a28276f0bcd4cb0546acdf52. Read it with imageId(). The ciphertext verifier uses the OpenVmReceiptVerifier from the reference table to verify the proof.
• Each router has three routes (routeCount(), routeAt(index)). All routes point to BfvDecryptionVerifier or BfvPkVerifier contracts.
• mainnet-protocol.deployment.json records these verifiers. Its bfvVerifierRoutes field lists the three routes, with the BfvDecryptionVerifier and the BfvPkVerifier of each route.

At block 26,176,770 (12 October 2026), the contract owner ran the v0.19 cutover. It replaced the ciphertext verifier with an OpenVmBfvCiphertextVerifier and installed two new verifier routers. It also unregistered the earlier CRISPProgram and registered a new CRISPProgram.

The manifest.json asset of release v0.18.0 still marks mainnet with mocks: true. With that asset, interfold config check prints the mock-deployment note for mainnet, although the verifiers in use are not mocks. The manifest.json asset of release v0.19.0 lists the verifiers from before the cutover. The manifest in the repository lists the current verifiers.

Sepolia

Testnet Ethereum Sepolia, chain ID 11155111. The public key, decryption, and DKG verifiers are real. The ciphertext verifier and CRISP use MockOpenVmReceiptVerifier, which accepts every OpenVM receipt, so Sepolia does not verify compute proofs. CRISP uses MockCrispDataAvailabilityVerifier because Avail Turing is down. MockUSDC is the fee token. Anyone can mint it.

Sepolia contracts

Sepolia reference contracts

Also used on Sepolia

The manifest does not publish these Sepolia contracts, so interfold config check does not compare them. The addresses and deploy blocks come from two deployment records. The Interfold record is packages/interfold-contracts/deployed_contracts.json. The CRISP record is packages/crisp-contracts/deployed_contracts.json (opens in a new tab) in the CRISP repository.

CRISPProgram and the Honk verifiers on Sepolia come from the CRISP deployment for the circuits of @crisp-e3/sdk 0.28.0 and 0.28.1. Use 0.28.1: with 0.28.0, proof generation fails in Chromium-based browsers. availabilityFinalizationWindow is 0.

The fee token is MockUSDC, a test USDC with 6 decimals. Anyone can call its mint function. It is also the ticket collateral. To confirm it on-chain, call feeToken() on the Interfold contract. For the ticket collateral, call underlying() on the InterfoldTicketToken.

To get Sepolia USDC and FOLD, run interfold faucet --chain sepolia. You can also call faucet() on the Faucet contract, or call mint on MockUSDC. The Faucet sends 1000 FOLD and 1000 USDC to a wallet that holds less than 1000 of that token. The operator bond on Sepolia is 100 FOLD. FOLD transfers are restricted before the token generation event, and the Interfold team mints FOLD to operators.

Verifiers in use on Sepolia

Sepolia verifies the public key, decryption, and DKG proofs with real verifiers. The Interfold contract stores one verifier of each kind for each encryption scheme. The table shows the values for the BFV scheme (keccak256("fhe.rs:BFV")).

• The ciphertext verifier wraps MockOpenVmReceiptVerifier, which accepts every receipt. Read the receipt verifier with openVmVerifier() and the receipt identity with imageId(). The CRISP deployment set this verifier for BFV.
• Each router has six routes (routeCount(), routeAt(index)). The routes cover the insecure-64 preset (parameter set 0) and the secure-8192 preset (parameter set 2), each with the three committee sizes. Every route points to a BfvDecryptionVerifier or a BfvPkVerifier contract.
• sepolia-protocol.deployment.json records these verifiers. Its bfvVerifierRoutes field lists the six routes, with the BfvDecryptionVerifier and the BfvPkVerifier of each route.

Contract roles

The Interfold contract coordinates each E3. The two registries hold the ciphernodes and their collateral. The slashing and refund contracts handle faults and failures.

The main entry points are these functions:

For how to call request, see Requesting an E3. For the operator calls, see Registration.

Enums

The enums are in contracts/interfaces/IInterfold.sol.

E3Stage

For the full sequence, see E3 lifecycle.

FailureReason

The payer column shows who carries the cost of the failure, from contracts/lib/FailurePayerLib.sol. When the ciphernodes pay, the requester gets back the full service fee escrow. When the requester pays, the honest nodes get the value of the completed work, the protocol gets its share, and the requester gets the rest.

Only the CiphernodeRegistry or the SlashingManager of the E3 can call onE3Failed. Anyone can call markE3Failed after a deadline. During a grace period after the deadline, only the requester, the owner, and active committee members can call it.

CommitteeSize

Decryption needs T + 1 shares. The contracts store H and N for each size as the committee threshold. The values come from crates/committee/src/lib.rs.

Key events

Clients and ciphernodes follow these events. Each event is declared in the interface of its contract.

IInterfold.sol also declares InputPublished and CiphertextOutputPublished, and ICiphernodeRegistry.sol declares CommitteeRequested and CommitteePublished. The current contracts do not emit these four events.

Next steps