Seraphis and Jamtis Monero Explained: The Next Protocol Leap

When the Monero Research Lab quietly merged the first audited Seraphis library branch into the testing fork in late 2025, it confirmed what protocol watchers had been tracking for nearly four years: Monero is preparing for the most invasive rewrite of its transaction layer since RingCT shipped in 2017. Seraphis is not a feature upgrade. It replaces the entire transaction protocol, the cryptographic proofs guarding sender ambiguity, and the addressing scheme users see at the wallet level. Jamtis, the addressing layer designed to ride on top of Seraphis, retires the subaddress format that has anchored every Monero wallet for half a decade.

This guide unpacks both — what they are, why the lead researchers (koe, jberman, UkoeHB) spent thousands of hours building them, what changes for everyday users, and how a no-KYC service such as MoneroSwapper handles the migration without forcing customers to relearn private spending. If you have ever sent or received XMR, the address you used will eventually be deprecated. Understanding the upgrade now is cheaper than scrambling on activation day.

Why Monero Needed Seraphis at All

Monero's current transaction protocol is a layered patchwork. The base proof, CLSAG, replaced MLSAG in the October 2020 hard fork and shrank ring signature size by roughly 25%, but it still operates on a fixed ring of sixteen decoys sampled from recent outputs. Sixteen-of-many sounds robust on the surface, yet statistical heuristics, timing analysis, and the so-called "EAE attack" (eve-alice-eve) chip away at sender anonymity in adversarial models. Researchers have published several peer-reviewed papers since 2019 showing how a well-funded analyst with broad mempool visibility can probabilistically deanonymize a non-trivial fraction of outputs.

The fungibility argument compounds the problem. Every CLSAG ring includes a real spend and fifteen decoys, but those decoys are themselves outputs from earlier transactions. If two transactions reference each other as decoys, and chain analysis can rule out one possibility, it sharpens probability against the other. The system is robust in aggregate but leaks at the margins. Seraphis closes this leak by widening the anonymity set dramatically while restructuring the proof so that membership and ownership are decoupled.

• Bigger anonymity set: Seraphis is designed to support membership proofs over 128 or 256 outputs (or more, depending on the curve and proof system chosen at activation), rather than 16. The math is logarithmic in proof size, so 128-of-many costs only marginally more bytes than 16-of-many under CLSAG.
• Cleaner separation of concerns: Today, a single CLSAG proof bundles "I own one of these outputs" with "I haven't already spent it." Seraphis separates these into a membership proof and a composition proof. Each can be optimized, audited, and upgraded independently.
• View-key surgery: The current view key reveals every incoming output to whoever holds it. Auditors, exchanges, and tax accountants all get the same firehose. Seraphis introduces tiered view keys, so a user can grant read-only access to receipts without exposing change outputs or self-spends.
• Plug-in proofs: The Seraphis architecture treats membership proofs as swappable. The current target is FCMP++ (Full-Chain Membership Proofs Plus Plus), which would let every output on the chain serve as a potential decoy. That is a step-function increase from sixteen.

None of this means CLSAG is broken today. It means the design space has moved on, the academic cryptography has matured, and Monero's research culture refuses to accept "good enough" when "provably better" is on the table. The cost is engineering complexity and a multi-year transition; the benefit is a privacy posture that survives the next decade of analysis tooling.

How Seraphis Reshapes Transactions

Seraphis is a transaction protocol, not a single primitive. To understand what changes, it helps to walk through what happens when you send XMR today and contrast each step with the Seraphis equivalent. The differences are subtle in user experience but profound under the hood.

From CLSAG to Composition + Membership Proofs

Under CLSAG, your wallet picks fifteen decoys from the chain, builds a ring of sixteen, and signs a proof asserting that one of those sixteen is yours and that you haven't double-spent. Under Seraphis, your wallet builds two distinct proofs. A composition proof says "I legitimately own one specific output in this set, and here is the matching key image to prove I have not spent it before." A membership proof says "the output I am referencing exists in this larger anonymity set on the chain." The two proofs are linked cryptographically but generated independently, which is what makes the anonymity set expandable later without redesigning the whole transaction format.

Key images themselves get a redesign. Today's key image is derived deterministically from the one-time output key and the spend key — a clever construction, but one that has been the focus of edge-case research for years. Seraphis introduces a new key image format that is forward-compatible with FCMP++, the membership proof system that Monero researchers hope will eventually allow the anonymity set to span the entire UTXO set of the chain.

Carrot: The Output Encoding Layer

Carrot is the output encoding scheme designed alongside Seraphis. Where today's outputs use a stealth address derived from the recipient's public view key and a transaction-specific shared secret, Carrot outputs add new fields for things like view-balance keys, internal-vs-external markers, and forward-secrecy hints. The practical upshot is that wallet scanning becomes faster (because internal outputs — change you send to yourself — can be identified without full decryption) and view-key auditing becomes safer (because the auditor sees only what the user authorizes).

Carrot also encodes "Janus protection" by default. A Janus attack is when a malicious sender constructs an output that lets them later prove which of two recipient addresses received the funds. The current Monero protocol mitigates this with a subaddress check, but Carrot bakes prevention into the output format itself, eliminating an entire class of bugs at the cryptographic level rather than the wallet-policy level.

Transaction Size and Fees

Critics often ask whether Seraphis means bigger transactions and higher fees. Honest answer: probably yes, modestly, in the short term — and probably no, eventually. Initial Seraphis proofs are larger than CLSAG, perhaps 1.5x to 2x depending on the configuration chosen at activation. But Monero's dynamic block size means fees scale with congestion rather than raw byte count, and Bulletproofs+ already shrank range proofs aggressively in 2022. Once FCMP++ lands and the anonymity set expands to chain-wide scale, the byte cost per unit of privacy plummets compared to today.

Jamtis: The Addressing Layer You Will Actually See

Seraphis is the engine. Jamtis is the dashboard. Most users will never read a composition proof, but every user will copy and paste a Monero address. Jamtis redesigns that address — and the keys behind it — so that the privacy gains of Seraphis are reflected in how wallets, exchanges, and merchants interact with the network.

Current Monero addresses are 95 characters of base58 starting with "4" for mainnet primary addresses or "8" for subaddresses. They encode a public spend key and a public view key, and that's essentially it. Jamtis addresses are slightly shorter or comparable in length (the final format is still being finalized at protocol level) but encode significantly more structure: an address index, a flag for the address type (main, exchange, integrated, or "auxiliary"), and authentication tags that prevent certain phishing and substitution attacks.

The view-key tiering deserves special attention because it solves a real-world pain point. Today, if you give your view key to an accountant, they see every output you have ever received — including change from your own spending, payments between your own subaddresses, and any auxiliary income. Jamtis lets you grant only the specific tier the auditor needs. A "find-received" key reveals incoming payments without amounts. A "view-incoming" key reveals incoming payments with amounts but not change. A "view-balance" key reveals the spendable balance for compliance reporting without unmasking individual transactions. Only the "view-all" key, which the user holds privately, sees everything.

For services like MoneroSwapper that need to confirm a customer's deposit without learning their broader wallet history, the new tiered structure means cleaner integrations and stronger privacy by default. The swap service can verify "you sent the agreed amount to the agreed address" without ever having visibility into the customer's full balance, change pattern, or other inbound activity. This matters because every byte of metadata a privacy-preserving service does not collect is a byte it cannot be subpoenaed for, leaked through, or socially engineered out of.

If you can describe a privacy upgrade in a single sentence, it is almost certainly too simple. Seraphis and Jamtis together are a system: proofs, encoding, addresses, key hierarchy, and wallet UX all moving in coordination. Treat them as a package, not a feature list.

Migration Path: How to Prepare Your Wallet

The Seraphis hard fork is not yet scheduled at the time of writing; the Monero Research Lab and core team are deliberately conservative about activation dates, preferring "ready when ready" over calendar deadlines. Past Monero hard forks have given users between two and six months of notice, and Seraphis will almost certainly fall on the longer end of that range given the complexity. Here is a practical preparation checklist that holds regardless of the exact activation week.

1. Audit your seed format. If your wallet still uses the legacy 25-word seed, consider migrating to a 16-word Polyseed-backed wallet before the upgrade. Polyseed is forward-compatible with Jamtis derivation paths; the legacy seed will require a wallet-side conversion step at fork time.
2. Update your wallet software at least twice before the fork. The Monero GUI, CLI, Feather Wallet, and Cake Wallet teams typically ship multiple pre-fork releases. Track the official Monero release notes and your wallet's changelog from the month before activation — do not rely on auto-updates alone, since some wallets gate major upgrades behind manual confirmation.
3. Practice a full restore from seed on a spare device. Before any major protocol upgrade, the single most valuable risk control is verifying that your written seed actually restores your funds. Spin up a clean Monero CLI or Feather Wallet on a separate machine, restore from seed, and confirm the balance matches. Do this twice. Do this every six months even outside of upgrades.
4. Identify and reduce your subaddress sprawl. Users who have used dozens of subaddresses for organizational purposes (one per counterparty, one per merchant, etc.) will have a slightly more complex migration. Consolidating funds to a smaller set of subaddresses before the fork — and labeling each one clearly in your wallet — makes the post-fork mental model much simpler.
5. Document your view-key sharing relationships. If you have shared your view key with an accountant, exchange, or audit tool, write down who has it and why. After Jamtis activates, you will likely want to rotate those relationships to use the new tiered keys instead of the legacy full view key.
6. Watch for "post-fork sweep" guidance. Past Monero upgrades have occasionally required users to "sweep" outputs from the old format to the new format before they become spendable. The Monero core team will publish explicit instructions if this is required for Seraphis; do not act on rumors from forums or social media.

For users of no-KYC swap services, the operational impact is usually minimal. A well-designed service abstracts the protocol transition: you give it the address, it gives you XMR, and it handles the Seraphis-vs-pre-Seraphis output formats on the backend. MoneroSwapper, for example, treats the protocol version of the destination address as a routing decision rather than a customer-facing complication. Customers can keep using the same workflow they always have.

A Practical Example: Receiving a Swap Under the New Model

Consider a typical scenario from mid-2026, assuming Seraphis has activated by then. A user in Germany wants to swap Bitcoin for Monero without KYC. They go to a swap service such as MoneroSwapper, paste their Jamtis receiving address (generated by an updated wallet like Feather or the official Monero GUI), and send Bitcoin to the deposit address provided.

Behind the scenes, the swap service routes the Bitcoin through its liquidity pool, acquires Monero, and constructs a Seraphis transaction sending the agreed amount to the user's Jamtis address. The transaction includes a composition proof, a membership proof drawing from a 128-output (or larger) anonymity set, and a Carrot-encoded output that the user's wallet can identify in a single scan pass. The user sees the funds in their wallet within the usual 10-to-20 minute confirmation window.

What changed from the user's perspective? Nothing visible. What changed under the hood? The anonymity set grew by an order of magnitude, the output encoding now resists Janus attacks at the protocol level, and the swap service never received a key that would let it learn anything about the user's broader Monero activity. The system did more privacy work, transparently. That is the goal of a well-executed protocol upgrade: invisible to the user, demonstrably stronger to the auditor.

For users coming from outside the Monero ecosystem — Bitcoiners curious about privacy, or new privacy-coin adopters — the Seraphis era will likely be their first exposure. They will never know what life was like with sixteen-of-many ring signatures, just as today's users rarely remember the pre-RingCT days when transaction amounts were public on chain. That is how protocol upgrades should feel: a quiet improvement that becomes the new baseline.

FAQ

When will Seraphis and Jamtis activate on Monero mainnet?

No firm date has been announced. The Monero Research Lab and core team have repeatedly stated that activation depends on completion of cryptographic audits, library hardening, wallet integration across major implementations, and at least one full testnet cycle. Public estimates from contributors in late 2025 ranged from late 2026 to mid-2027, but the project's culture explicitly rejects calendar-driven shipping for security-critical upgrades. Watch the official Monero release notes and the Monero Research Lab meeting logs for authoritative timing.

Will my current Monero address still work after the upgrade?

Yes, for a transitional period. Hard forks in Monero have historically included backward-compatible address handling so that funds sent to legacy addresses still arrive. Over the longer term, wallet software will encourage users to migrate to Jamtis addresses, and eventually new wallets may stop generating legacy addresses entirely. There is no immediate "deadline" risk for funds held in current addresses, but you will want to update your wallet software around fork time.

Does Seraphis change Monero's tail emission or supply schedule?

No. Seraphis is a transaction-layer protocol upgrade. It does not touch monetary policy. Tail emission of 0.6 XMR per block continues unchanged. The total emission curve, the block reward dynamics, and the RandomX proof-of-work algorithm are all separate from Seraphis and are not affected by the upgrade.

Will Seraphis break compatibility with hardware wallets like Trezor and Ledger?

Hardware wallet vendors will need to update their firmware to support the new proof formats and key derivation paths. Historically, both Trezor and Ledger have shipped Monero firmware updates aligned with hard fork timelines, though sometimes with a lag of weeks or months. Users relying on hardware wallets should not upgrade their device firmware blindly at fork time — instead, wait for explicit confirmation from the vendor that the new firmware supports the active Monero protocol version, and keep a software-wallet backup capability for the transition window.

How does Seraphis compare to other privacy projects' approaches?

Zcash uses zk-SNARKs for fully shielded transactions, which offer stronger theoretical privacy but historically required a trusted setup ceremony and have far lower adoption (most Zcash volume is transparent). Mimblewimble chains like Grin use a fundamentally different model based on output aggregation, which sacrifices some auditability for compactness. Seraphis stays within Monero's existing model — ring signatures and stealth addresses — but pushes the design to its practical maximum. The tradeoff is engineering complexity in exchange for no trusted setup and a smooth user experience continuous with today's Monero.

Can I swap into Jamtis addresses on MoneroSwapper before the fork activates?

No, because Jamtis addresses are not yet generatable by current production wallets. Once the protocol activates and major wallets like the Monero GUI, Feather, and Cake Wallet roll out Jamtis support, swap services will accept the new address format alongside legacy addresses during the transition window. Until then, your existing Monero address continues to work normally for all swap activity.

Conclusion

Seraphis and Jamtis represent Monero's commitment to staying ahead of the analysis curve rather than reacting to it. The upgrade is not flashy, will not produce a price-pump narrative, and will not dramatically change what users do day to day. What it will do is push the privacy floor of the network significantly higher, give users finer-grained control over what they reveal and to whom, and lay the cryptographic groundwork for the next decade of Monero development. If you hold XMR or use it for everyday privacy-preserving payments, take the next six to twelve months to update your seed format, refresh your wallet software habits, and verify your restore process. When the fork lands, you want it to be a non-event. To start using Monero today with a no-KYC, no-account swap service that will handle the Seraphis transition transparently, head over to MoneroSwapper and exchange your existing crypto for XMR in minutes.