Mainnet deployment records are stale, and `config check` reports mainnet as a mock deployment

[hmzakhalid]

Summary

The repository records do not match the mainnet deployment, and interfold config check warns mainnet operators without cause.

Evidence (checked 2026-09-25)

• getCiphertextVerifier(keccak256("fhe.rs:BFV")) on mainnet Interfold returns 0x80D217d3b2e16fF2ecc178cC75655C773895c549, a Risc0BfvCiphertextVerifier with imageId() 0x9d3e21fd7cc08e629cb467e5ca6bfc8e1a645b483bfd91b6b1648ced259110fc. CiphertextVerifierSet history: the mock 0xB568…9297 at block 25,788,974, 0x40a1…ff2c at 25,813,839, and 0x80D2…c549 at 26,004,622.
• getDecryptionVerifier and getPkVerifier return the routers 0xA66C…eEa7 and 0x7CD1…63d1. Their routes point to real BfvDecryptionVerifier and BfvPkVerifier contracts (bytecode matched against the artifacts).
• mainnet-protocol.deployment.json still lists the mock ciphertext verifier and the first decryption and pk verifiers. No file in the repo records 0x80D2…c549, its image ID, or the routers. 0x40a1…ff2c appears only in examples/CRISP/.../deployed_contracts.json.
• deployments/manifest.json sets mocks: true for mainnet, because deployed_contracts.json lists MockE3Program (genManifest.ts:95-100). On-chain, e3Programs(MockE3Program) is false and CRISPProgram is enabled.
• crates/cli/src/config.rs:141-146 prints mainnet is a mock deployment - proofs are accepted without being verified for that flag.

Suggested direction

Record the live verifiers and the image ID, regenerate the manifest, and base mocks on the enabled programs and the live verifiers.

[hmzakhalid]

One more stale record: deployments/manifest.json publishes slashing_manager 0x974E865B1BB24AF2a9ef8204AdEA9251Cc7C5FD9, but the live contracts use 0x753109Ee36Dc65cC178875AddA30C6433e5bEEe4 (Interfold.slashingManager(), CiphernodeRegistry.slashingManager(), and BondingRegistry.slashingManager() all return it). PR #2026 updates the manifest. The other manifest entries (Interfold, CiphernodeRegistry, BondingRegistry, E3RefundManager, InterfoldTicketToken) match the live wiring.

[hmzakhalid]

Rechecked on 2026-09-30. Partly fixed.

Fixed on main:

• chore(docs): add Reference pages [skip-line-limit] #2030 documents the live verifiers, the routers and the image ID in docs/pages/reference/contracts.mdx:108-113.
• fix(ops): reset-data guard, docker state, upgrade test [skip-line-limit] #2026 fixed the SlashingManager address in deployments/manifest.json.

Still open:

• deployments/manifest.json:70 still sets mocks: true. packages/interfold-contracts/scripts/genManifest.ts:168 derives it from the listed mock addresses, so interfold config check still prints the proof-bypass warning (crates/cli/src/config.rs:140).
• mainnet-protocol.deployment.json:35 still holds the first verifier bindings, with no record of the current ones.

Published release asset: interfold config check downloads the manifest.json of the latest release (crates/cli/src/manifest.rs:136-153).

• The latest stable release is v0.18.0 (published 2026-09-24). Its manifest.json still lists the mainnet slashing_manager as 0x974E865B1BB24AF2a9ef8204AdEA9251Cc7C5FD9.
• So config check reports a config with the live address as stale.
• The source fix in fix(ops): reset-data guard, docker state, upgrade test [skip-line-limit] #2026 reaches operators only once a stable release with a corrected manifest is published. Old CLIs read that asset too, so no node upgrade is needed for the check itself.

One more stale record, checked on mainnet:

• E3-2's program (getE3(...).e3Program) is 0x53FCdb21E73A461CfE6c64B19855204384B91BA3, with imageId() 0x9d3e21fd…10fc. The dashboard already uses this address (packages/interfold-dashboard/src/lib/chain.ts:107).
• examples/CRISP/packages/crisp-contracts/deployed_contracts.json:526 still records CRISPProgram 0x847A22303639017bcDB7F7E49EEa4a4629c1169f. The governance repo's contracts/.env.mainnet.install:158 has the same address, and its CRISP_INSTALL_DATA (:169) embeds it.
• Regenerate the install data before the next install.