The Roadmap: Seraphis, Jamtis & FCMP++

The Roadmap: Seraphis, Jamtis & FCMP++

Where the protocol is heading: full-chain membership proofs via curve trees that replace ring signatures, the Seraphis transaction protocol, and the Jamtis addressing scheme.

A contributor should know not just how Monero works today but where it's going, because much active research and engineering targets the next protocol generation. Three names dominate that roadmap: Full-Chain Membership Proofs (FCMP++), the Seraphis transaction protocol, and the Jamtis addressing scheme. (Names and details evolve — treat this as the shape of the direction, not a frozen spec.)

The Limitation They Address

Today's privacy rests on ring signatures with a fixed, small ring (currently 16). That caps the anonymity set per input at 16 and forces the fragile decoy-selection problem. The endgame is to make the anonymity set the entire chain while keeping proofs small and verification fast.

FCMP++: Full-Chain Membership Proofs

Instead of "the real input is one of these 16," FCMP++ proves "the real input is one of all outputs that have ever existed" — without revealing which. The mechanism is a curve tree: a Merkle-tree-like structure whose nodes are elliptic-curve commitments, built over the set of all outputs. A spender proves, in zero knowledge, a membership path from a leaf (their output, re-randomized) up to a public root, plus the usual spend authorization and linkability (a key-image analogue) to prevent double-spends.

  • Anonymity set = whole chain, eliminating decoy selection and ring-size debates.
  • Uses a cycle of curves (curve trees need a second curve whose scalar field matches the first's base field) to make the recursive proofs efficient.
  • Still no trusted setup; proofs are designed to stay compact and batch-verifiable.

This is arguably the biggest privacy upgrade since RingCT, and a lot of current cryptography and review effort goes into getting it sound and performant.

Seraphis: the Transaction Protocol

Seraphis is a redesigned transaction protocol (an abstraction layer for spend authorization and membership) that is compatible with full-chain membership proofs and improves several things at once:

  • A cleaner separation between membership (which output is being spent, hidden in a large set) and ownership/authorization (you may spend it), making it easier to swap in FCMP-style proofs.
  • Much-improved multisig ergonomics and security over today's MLSAG/CLSAG-based scheme.
  • Better support for advanced key structures (see Jamtis).

Jamtis: the Addressing Scheme

Jamtis is a new address/key hierarchy designed for Seraphis. Goals contributors should know:

  • More key tiers than today's view/spend split — e.g. distinct keys for finding outputs, generating addresses, and spending — enabling safer delegation (a third party can scan without any ability to link or spend).
  • Faster scanning and stronger resistance to address-linking attacks (a structural answer to issues like Janus).
  • Cleaner support for things like payment IDs/anonymous payments done right, and for light-wallet scanning that doesn't hand over spend authority.

What This Means If You Want to Contribute

The live codebase is C++ (the monero daemon and wallet), with cryptography in the research repos and proof systems prototyped and reviewed before consensus changes. To work on this you'll need: comfort with the Ed25519 group and its cofactor pitfalls, the CLSAG and Bulletproofs+ constructions, the wallet-side checks that enforce privacy, and a willingness to read the Monero Research Lab papers and the FCMP/Seraphis specs directly. Now take the contributor quiz — you should be able to answer all of it.

Comments

Log in or create a free account to comment.

No comments yet — be the first.