JP Demos Live Monero on THORChain: 7 Nodes, Real Funds, First Swap Works

Ray

2026-05-14 — 11 min read

Podcast

Guide

THORChain Podcast #198: Live Monero Demo ft. jpthor & KentonC137 | May 14, 2026 | Watch the full episode on YouTube

By Raynalytics

TL;DR

JP ran a live Monero demo on a 7-node THORChain chainnet with real funds, executing the first end-to-end decentralized $RUNE to $XMR swap with full vault auditability across signing and non-signing nodes.
The implementation uses a deterministic view key (SHA-512 of "thorchain view key") plus on-chain key images and per-transaction signing keys to make every Monero inbound, outbound, and vault balance publicly auditable.
Monero runs as a Rust sidecar alongside Bifrost, built on Luke Parker's Serai signing stack and the Monero Oxide wallet library, plumbed into THORChain by Boone.
JP and Chad disagree on running multiple Asgard vaults versus a single vault for Monero, a question to be resolved before the mainnet rollout.
The code is functional today, but mainnet is gated on more stress testing. When it ships, expect a guarded launch with small pools.

Where things stand (June 2026): This recap revisits JP's live demo from May 14. In the weeks since, Chad Barraford confirmed on THORSday #209 that Monero now works end-to-end on the chainnet test environment, with real $XMR swaps, liquidity adds and removes, and churns all confirmed. A live $XMR launch is targeted for roughly a month after THORChain's trading restart, barring a bug that forces a v3.20 change, with Zcash ($ZEC) one to two weeks behind. Mainnet is not live yet.

Introduction

This was not a typical podcast episode. JP joined Kenton and ran a fully live Monero implementation on a real-fund chainnet: seven nodes churning, two Asgard vaults, key gens, key signings, the works. By the end of the call, JP had executed the first end-to-end decentralized $RUNE to $XMR swap, audited the transaction with a key image and a signing key, and confirmed his receiving wallet got paid. This was THORChain producing the proof that years of Monero integration work actually delivers.

What follows is a recap of the architecture, the audit primitives, the live result, and the open questions still on the table before mainnet.

1. The Live Demo: Seven Nodes, Real Funds, Real Swap

JP began by tearing down his existing chainnet and redeploying it from scratch. The deploy spooled up seven THORChain nodes and one genesis vault, then churned into a six-active-node, two-Asgard-vault configuration. He added 0.5 $XMR and 500 $RUNE to each active vault, waited for confirmations, then fired off a 100 $RUNE to $XMR swap back to his own Monero wallet.

It worked. The signing nodes generated the transaction, produced a key image and a transaction signing key, propagated those to the non-signing nodes for verification, then settled the outbound. JP pasted his recipient address and the transaction key into a Monero block explorer's proof-of-payment tool and confirmed receipt.

"Real money, real funds. I love it when a plan comes together." (JP)

Across all seven nodes, signing, non-signing, and standby, the reported $XMR balance converged. The on-chain vault state matched the actual Monero wallet state, and gas accounting was correct. After the swap, the protocol began an unhalted churn, generating two new Asgard vaults and migrating funds in multiple rounds without breaking auditability.

2. How THORChain Audits Monero Without a Privacy Backdoor

The core challenge with Monero on a transparent chain is making the vault state verifiable, since Monero hides addresses and amounts by default. JP's solution rests on three primitives.

Deterministic view key. Every THORChain Monero vault uses the same private view key, derived from SHA-512("thorchain view key"). It is global and public, so anyone can see inbounds to any THORChain Monero vault and confirm the amounts. Standard Monero wallets never expose their view key. THORChain's vaults do, by design.

Key images. A view key alone does not reveal when outputs are spent. For every inbound, THORChain kicks off a key image ceremony, essentially a 2/3 threshold ceremony similar to a key signing ceremony. The resulting key image is stored on-chain. When that key image later appears as spent on the Monero blockchain, anyone can audit the vault's debits.

Transaction signing keys. For every outbound a signing subset produces, they also generate a transaction signing key and propagate it to the non-signing nodes. Plug the transaction key plus the recipient address into a Monero proof tool, and the destination and amount are verifiable. This is how the rest of the network confirms the signers did what they were supposed to, and did not reroute funds.

Put together, these three primitives let anyone audit every Monero inbound, every spent output, and every outbound on every THORChain vault, in real time. As Kenton summarized it on the call:

"THORChain doesn't become more private by adding Monero. THORChain is actually bringing more publicity to the Monero transactions that occur on THORChain. Anything private has to happen on the Monero chain itself." (Kenton)

JP agreed:

"THORChain actually honestly doesn't know that Monero is a privacy chain. THORChain thinks Monero is just literally Bitcoin." (JP)

The audit model is what makes the integration possible. Without it, JP noted, the nodes could just steal.

3. Architecture: A Rust Sidecar Built on Serai and Monero Oxide

Monero is the first chain client where THORChain runs a dedicated sidecar process alongside the Go-based Bifrost. The sidecar is written in Rust because it needs to host the FROST signing engine for Monero, and because the entire Rust Monero stack is more mature than any Go equivalent. Bifrost orchestrates: it tells the sidecar when to key gen, when to key sign, with what amount and to what address. The sidecar executes.

The foundation is Luke Parker's work. Luke, the lead developer of Serai, built both the modular FROST stack THORChain depends on for threshold key generation and signing, and Monero Oxide, the Rust-based Monero wallet library THORChain uses for everything from view key derivation to vault address generation to transaction construction, decoy selection, and fee computation.

"All the Monero stuff is based on Luke's work. We just kind of plumbed it into THORChain's semantics." (JP)

Boone did the plumbing. JP credited Boone explicitly for taking Luke's libraries and adapting them to THORChain's Bifrost architecture.

THORChain also runs a fork of the Monero TS wallet library, published on the THORChain GitHub, which adds 255-byte TX extras. That is the change that lets THORChain memos ride alongside Monero transactions. Any wallet integrating Monero with THORChain needs roughly three lines of code to adopt the same pattern, and 255-byte memos are already valid on the Monero base layer, JP noted, which most integrators do not realize.

4. Handling Monero's Quirks

Monero behaves differently from Bitcoin in ways the implementation has to absorb.

10-block lock per UTXO. Every Monero output is locked for 10 blocks after receipt, roughly 20 minutes. The signers track lock state per UTXO and refuse to sign until the spendable balance is available. THORChain does not see the lock directly; it just schedules the outbound and the signers say "talk to me in nine blocks." If one vault is fully locked, THORChain reschedules the transaction to the other active vault. Streaming swaps are not affected, JP confirmed, because Chad recently shipped a feature that begins the streaming swap clock as soon as the deposit kicks off confirmation counting.

Gas budget. Monero gas accounting is hard, so THORChain hardcodes a 120,000-unit budget per outbound, about 42 cents at current prices. Real transactions usually come in closer to 4 cents, so there is a roughly 10x buffer. Simple, predictable, slightly overpaid.

Zero-output change. Every Monero transaction must have two outputs (the real destination plus a dummy from a decoy ring). When THORChain does not actually need a change output, it produces a zero-amount second output and ignores it on the receiving side. This applies to consolidations, migrations, and any one-recipient outbound.

Consolidation strategy. JP proposes consolidating 10 UTXOs down to 5 at a time rather than larger batches. Gas scales linearly with UTXOs, and so does signing time. Keeping consolidations bounded keeps both manageable.

Birthday-based scanning. Each Monero vault saves its creation block height on-chain. Sidecars scan from that birthday forward rather than from Monero genesis. A rescan mode lets any node rebuild its sidecar inventory from scratch by pulling addresses, birthdays, key images, and the view key from THORChain itself. JP says he has tested it ad nauseam.

Old vault refunds. If someone sends Monero to a retired vault, THORChain cannot auto-refund because it cannot identify the sender address. The funds flow to the latest active vault instead, available for a manual treasury refund if the sender produces their transaction private key to prove ownership.

5. Single Vault or Multiple? An Open Debate

The most consequential open question from the episode: should THORChain run one Monero vault or many?

JP's position is to run multiple Asgard vaults, the same way Bitcoin and Ethereum work today. Multiple vaults give the network redundancy when 10-block UTXO locks tie up one vault's spendable balance, and they limit the impact of any single signer set going offline. The trade-off is more key gens, more key image ceremonies, and unproven scalability of FROST Monero across all 100 nodes simultaneously.

Chad's position is to run a single vault. With one vault, every node is a signer, which lets the implementation skip the multi-vault key image generation overhead and simplify the protocol surface area.

Kenton pushed back on the disconnect directly, telling JP that he and Chad clearly need to sort this out: Chad is saying one vault, JP is saying multiple. JP indicated multiple is more aligned with how the other chain clients already work, and that moving to a DKLS-based ECDSA TSS library could eventually make single-vault designs viable. He will continue the conversation with Chad before mainnet, and Kenton suggested running both configurations on mainnet for a few weeks each to observe behavior. The decision is open.

6. AI-Assisted Development, and the "Vibe Coded" Question

JP addressed criticism that the Monero implementation is "vibe coded" head-on. His view: AI tooling (Claude, Codex, GPT 5.5) lets him work an order of magnitude faster than five years ago, when the team spent a year building the original Bitcoin Bifrost. Tasks that used to require hand-grepping logs across 100 nodes now take minutes when AI can crawl them.

But the workflow is not hands-off. JP described it as juggling, with constant supervision required: one slip and the whole thing crashes down. He uses separate AI conversations per stack component and trains each with project-specific skills.

"The code only works if it's correct. If it didn't work, then you would not see these correct numbers. Gas accounting would be wrong, the balances wouldn't match." (JP)

Kenton's framing: it does not matter whether the code starts as vibe-coded or hand-written. What matters is whether it gets reviewed, tested, and verified to work. By that test, the Monero implementation is human-approved code regardless of how the first draft was produced.

7. Future-Proofing for FCMP++ and Carrot

An audience question raised the upcoming Monero hardfork, which introduces FCMP++ (Full-Chain Membership Proofs Plus Plus) and the Carrot addressing protocol. Carrot adds outgoing view keys, forward secrecy, and other privacy and usability features while maintaining backward compatibility with existing Monero addresses.

JP's expectation is that the upgrade should be plug-and-play for THORChain. Luke Parker's Serai and Monero Oxide stacks will absorb the changes upstream. When the hardfork ships, THORChain will pause Monero trading, upgrade its sidecar dependencies, and unpause, with no expected protocol-level rework on THORChain's side and no expected long downtime.

What to Watch

More stress testing on chainnet. JP planned to run automated scripts that throw every edge case at the implementation: bad memos, wrong gas, old vault refunds, mismatched routing. If solvency holds after sustained abuse, the path to mainnet is clear.
JP and Chad converging on vault architecture. Single vault or multiple is unresolved and material. Watch for a follow-up between them.
Chainnet to stagenet to mainnet rollout. The chainnet code is the mainnet code, and the deploy pattern is identical. Mainnet is a confidence question, not a code question.
A guarded launch when live. Expect small pools and small trades at first. JP and Kenton both flagged that Monero could need several months on mainnet before it is fully battle-tested.
FCMP++ and Carrot hardfork handling. Monero's hardfork is on the near-term horizon. The plan is a brief THORChain pause for sidecar upgrades, then resume.