Ferveo

• Name: Ferveo
• URL: https://nikkolasg.github.io/ferveo/
• Category: weighted-validator threshold-encryption protocol / encrypted-mempool baseline / Tendermint-coupled fair-ordering primitive
• Summary: Ferveo is a mechanism note, not a project note. The useful thing here is the coupling: stake-weighted DKG, epoch-scoped threshold keys, proposer commitment to ciphertext order before reveal, and decryption-share release tied directly to Tendermint-style finalization. That makes it a clean baseline for encrypted-mempool and fair-ordering comparisons.
• What it does:
  • Runs a publicly verifiable distributed key generation process once per epoch so a weighted validator set can derive a threshold public key and corresponding private-key shares
  • Lets pending transactions be encrypted to that epoch key so proposers commit to ciphertext order before transaction contents are revealed
  • Couples decryption to consensus finalization by requiring validator signatures on a block to include valid decryption shares for that block’s encrypted transactions
  • Uses threshold-decryption and blinded-share machinery meant to keep weighted-share generation and verification practical for many validators
  • Includes an explicit invalid-ciphertext path rather than hand-waving malformed encrypted transactions away after the proposer has already seen them
  • Exists mainly as a paper, repository, and docs set rather than as a marketed standalone production network
• Key claims:
  • The important architectural choice is dependence on an underlying synchronizing consensus layer such as Tendermint. Ferveo is not trying to be a free-floating threshold-encryption service.
  • Validator weight maps directly into key-share weight, so encrypted-ordering policy stays coupled to the same stake distribution that already governs consensus.
  • The strongest reusable mechanism is the liveness coupling: decryption is not a later courtesy step. It is bound to finalization because validators must provide decryption shares as part of the signing flow.
  • Ferveo is also useful because it keeps a real failure mode visible. The docs specify aggregated handling for invalid ciphertexts instead of pretending malformed encrypted transactions disappear cleanly.
  • The privacy boundary is narrow and worth saying plainly: Ferveo hides transaction contents while they are pending, not after execution. Once decrypted, payloads become public.
  • The strongest caveat from the primary sources is maturity. The repository explicitly says the library is under development and not ready for production use.
• Whitepaper: Ferveo has a canonical paper — https://eprint.iacr.org/2022/898 — plus curated source notes in ../../whitepapers/ferveo-primary-sources-2026-05-13.md.
• Sources:
  • https://nikkolasg.github.io/ferveo/
  • https://github.com/anoma/ferveo
  • https://raw.githubusercontent.com/anoma/ferveo/main/README.md
  • https://raw.githubusercontent.com/anoma/ferveo/main/book/src/overview.md
  • https://raw.githubusercontent.com/anoma/ferveo/main/book/src/assumptions.md
  • https://raw.githubusercontent.com/anoma/ferveo/main/book/src/dkg.md
  • https://raw.githubusercontent.com/anoma/ferveo/main/book/src/tpke.md
  • https://raw.githubusercontent.com/anoma/ferveo/main/book/src/tx.md
  • https://eprint.iacr.org/2022/898

Internal linkages

• Best comparison reads: shutter-network, blocklock, and fairblock.

• Keep the lens narrow: validator weighting, decryption timing, invalid-ciphertext handling, and dependence on the parent consensus layer.

• Last reviewed: 2026-06-15 UTC