Monero Gets a Soft Launch as THORChain's v3.20 Enters Testing and ADR31 Passes

THORSday Community Podcast #221 ft. CBarraford, KentonC137 & Patriotsounds | July 30, 2026 | Watch the full episode on YouTube

By Raynalytics

TL;DR

• v3.20 is in testing, and Chad hopes it is done this week or early next. It targets the exploit's second-order mainnet instability and carries the fix that would let more affiliates onto the dynamic fee model.
• ADR31 passed on option 1, and ADR27 passed with it. Minimum slip is now zero bps, so the Rujira app layer can arb pools tighter than the 10 to 20 bps band arbitrageurs hold today, once Rujira's side is switched on.
• Monero's code is essentially ready and the churn is the blocker. Zcash probably takes the next churn, with Monero after. Chad's separate churn-removal work would not cover $XMR, which brings its own signing algorithm.
• The plan settled on air is to launch Monero as a soft launch, an openly labelled beta period with its length still open, on what Denny called the most complicated chain client THORChain has added.
• Protocol-owned liquidity should switch on with v3.20, Chad hopes, and would pick its own pools by comparing depth against revenue. Gas assets are enabled by default, while stablecoins and ERC20s each need a node vote.

1. v3.20 Is in Testing, and It Takes the Post-Exploit Wobble With It

v3.20 is being tested now, and Chad hopes testing wraps this week or early next. From there, as he recalls the sequence: exchanges are notified, the release is cut, and community adoption follows roughly a week behind.

Much of the mainnet trouble since the exploit has not been the exploit itself but second-order damage from it, and v3.20 aims at that directly. Chad expects a good percentage of the instability to go away, not all of it.

The stable reserve is in the v3.20 code, but Chad wants more data analysis and simulations before he is confident in it, so he does not expect this release to activate it.

v3.20 also fixes the small bug currently gating additional affiliates on the dynamic fee model, and changes the protocol-owned liquidity Mimir from an economic setting to an operational one.

2. ADR31 and ADR27 Pass, and Minimum Slip Drops to Zero

Denny opened the show wearing a celebratory hat for what he called his Rujira boys: ADR31 passed on option 1, which last week's recap covered as continuing the Rujira relationship as it stands. Denny's read was that the nodes are overwhelmingly excited for the app layer.

ADR27, which passed alongside it, is the one with immediate mechanical consequences. Minimum slip is now zero bps. Arbitrageurs currently pull pools to within roughly 10 to 20 bps on either side of market, and with the floor gone, the app layer can push them as close to zero as is reasonably possible once Rujira's arbing code is switched on. Chad's understanding is that roughly half the income earned doing it would route back to the base protocol.

The dynamic fee model currently discounts swaps partly to absorb slippage. Take the slippage out and Chad thinks THORChain could raise its prices and theoretically hold the same volume.

CodeHans told him it would be done toward the end of the week.

"He's a dev like I'm a dev. So sometimes our timelines aren't exactly on point." (Chad)

Chad expects a week or two after it flips on before the effect is readable. Rujira also posted its highest trade volume day on record the day of recording, though Denny did not have the figure to hand. Live ADR vote counts sit on Ray's governance tracker on raynalytics.net.

3. Chad Wants Chain Launches to Stop Waiting on a Churn

Monero is, in Chad's words, pretty much ready to go. THORChain has not been able to churn for a while because of the instability around the exploit, and both Zcash and Monero need a churn to launch.

So Chad started writing a code change to take the churn out of adding a chain, with one carve-out: he said a chain bringing a new signing algorithm would still need a churn, and $XMR is exactly that. The change removes the churn for ordinary chains that reuse an algorithm THORChain already has.

The churn is fragile: every node has to be online and communicating inside a reasonable window, and one node fumbling it forces a retry. THORChain churns every three days, while Chainflip does it roughly once every seven months.

It also gets more fragile as THORChain grows. Every added chain is another way for a churn to fail, since a broken Litecoin means no transactions and no churn. Every added signing algorithm is another key: Monero needs its own private key, making three instead of two, DKLS would be a fourth, and Schnorr a fifth.

"If we lean towards the more secure route, we'll also lean towards a less reliability route. Those two things kind of push against each other." (Chad)

The insight underneath the change: you need one key per signing algorithm, not one per chain. From one public key you can derive an address on any chain sharing the same algorithm. Chad's illustration was the TON chain: if it uses an algorithm THORChain already holds a key for, and he guessed EdDSA without being sure, the network could derive a TON address today with none of the TON code written.

Chad rates the work as mid, not a lot of code but a lot of thinking, architecture and edge cases. The branch is most of the way through and needs a large amount of testing.

Zcash probably takes the next churn, unless stagenet testing turns up something significant. Monero follows.

4. Monero Gets a Soft Launch

Kenton has been flip-flopping on when to push Monero: promote it at launch and ride the momentum, or wait two months for the pool to stabilize and risk losing that window.

Denny's answer was to announce it and be honest that there could be bugs. Chad supplied the phrase that settled it: soft launch. A beta period, caution advised, in a term everyone already understands.

Denny called this the most complicated chain client THORChain has added, and the team has been testing it for over a month.

"This is the jungle. No one's ever done this." (Denny)

Monero locks UTXOs, and Chad was not sure whether the lock runs 20 blocks or about 20 minutes. Either way, no other chain THORChain supports does it. He thinks THORChain consolidates once it holds more than 8 or 13 UTXOs and would have to check the code to confirm what Monero does by default, but applying the same logic there would lock all those funds at once, and an outbound could arrive with nothing spendable behind it.

He said the existing logic might be good enough. If it is not, his fallback is lazy UTXO consolidation: cap how many UTXOs a single spend may use, then work through successive batches until there is enough.

Chad expects arbitrage not to be the worry, since it happens mostly internally rather than on the layer 1. Organic volume is. Worst case is a backlog of outbound transactions, which THORChain Swap could reflect in its outbound time estimate. He thinks that is more likely than not, and would still rather let the network's own data name the real problem than build for it now.

On wallets, Trezor support is now live on THORChain Swap and open for testing, prioritized partly because Kenton called it one of the more popular Monero wallets.

Denny's longer ambition is that THORChain becomes Monero's center of liquidity and sets the real price of $XMR. Chad put a floor of six months on that, probably more, and listed what it needs: chain stability, depth in the pools, and more wallets integrating. He would not call it crazy. Continued $XMR delistings from centralized exchanges only make the case easier.

5. Protocol-Owned Liquidity Returns, and It Picks Its Own Pools

POL should kick in with v3.20, Chad hopes, since its Mimir moved from economic to operational. He believes that makes it votable but would have to check the code to verify. If it is, Kenton noted, nodes could vote it on and back off if they disagreed. The percentage then goes to a node vote: 5%, 20%, 80%, whatever the community sets.

POL compares a pool's depth against its revenue and favors low depth and high revenue over deep and quiet. It is self-correcting, because as a pool deepens, clearing that revenue-to-depth bar gets harder and the allocation moves on.

Chad does not think anyone can add liquidity to the Bitcoin pool, protocol or otherwise, so $BTC and some other assets would not be eligible.

"I want the liquidity to go to Solana, Zcash and Monero, to build those smaller pools. Bitcoin's got enough." (Chad)

Gas assets are enabled by default. Non-gas assets are not, deliberately: Chad did not want protocol income automatically invested into every ERC20 on the network. Stablecoins and specific ERC20s would each need a node vote. He expects $USDC and $USDT to pass without argument, while a more divisive token would draw real debate. Kenton flagged TRON $USDT as one he wants moving.

Chad thinks the allocation runs daily but was not certain without rechecking the code. He expects Solana or Monero to take the early allocations, assuming Monero carries the highest volume in its opening days.

The treasury typically seeds a new pool with about $100k. Kenton asked whether Monero warrants more; Chad said probably not, especially with POL there to supplement, and it is the treasury's call. Kenton's firm ask was that POL be on before Monero goes live.

6. Dynamic Fees Add Another 0.7% at ShapeShift

ShapeShift is still the only affiliate with dynamic fees switched on. Maybe one or two more follow once v3.20 lands, which Chad expects in a week or two.

Chad went back for a baseline. In May, 5.6% of ShapeShift's total swap volume routed to THORChain, with the vast majority of the rest going to Chainflip. June came in around the same 5 to 6%, though he called June a weak data source given how much of it THORChain spent offline after the exploit. The two months agree, which he called consistent.

Last week's July figure was significantly up, but Chad suspected an anomalous $RUNE trader sat inside it, so he pulled a fresh chart with one more week of data. On that longer read, THORChain's share is up another 0.7%, with NEAR Intents and Chainflip down 0.7%. He called it not very much, slightly up rather than significant.

The sample is small, deliberately: Chad puts ShapeShift at roughly $5 million a month in volume, and THORChain picked it rather than testing an experimental feature on SwapKit or another large affiliate first.

7. ADR29 Rev-Share, and Why SwapKit Would Get the Experiment

ADR29 would let a partner take a percentage of THORChain's fees instead of charging its own affiliate fee on top. The vote is still in progress.

Kenton relayed Scorch's questions from the governance discussion as he remembered them: could this be net negative? Why give away fees, and what is the proof it worked?

Kenton answered in two parts. For new providers the math is trivial, because their current volume is zero, so anything they bring is additive. For existing partners he agreed with the objection: hand rev-share to the partners THORChain already has and revenue drops 10 to 20% instantly. He does not think they should.

SwapKit is the proposed exception, mechanically rather than sentimentally. Under the design, it would not keep the rev-share: it would put the money into discounting future trades, which is the dynamic fee model again, pushed out from the core of the protocol to the edge where the real-time information is better. Chad's condition for any existing partner is a number attached.

"If we give you 20%, we want to see 30% improvements or something like this." (Chad)

Nobody knows the answer, SwapKit included, which is why he calls it an experiment: small, low risk to the protocol, and switched off if it does not work. He wants community approval before trying it. He also likes a side effect: a working rev-share would make SwapKit reliant on THORChain, because Chainflip and NEAR Intents do not currently offer the same thing.

8. Why an Engaged Community Beats a Bigger Market Cap

An audience question asked why $TAO is being lined up ahead of $HYPE, $TON or $LINK, if bigger assets mean more volume.

Kenton accepted market cap and volume as a starting point. What matters more is whether the chain's community is engaged and wants to be on THORChain, because that community brings volume with it. Bittensor is engaged, and $TAO is not listed on any other DEX, which would make THORChain the first. Add a large cap whose users are indifferent, Hyperliquid being his example, and he expects little more than some traders and some arb volume.

Same for the smaller privacy coins: Dash, Firo and Zano all have communities that want in, and Kenton expects more activity from those engaged communities than from randomly added tokens.

Chad's read matched. Zcash was added because competitors were doing real volume in it, which is the market telling you the value is there. Monero was added because it is Monero. $TAO has real support behind it, if not quite as much.

"It's not an exact science. You just kind of lick your finger and put it up in the air to get a vibe check to decide what's next." (Chad)

Chad added that the process is not political, and market cap is one attribute among several. Kenton expects $HYPE, $TON and $LINK eventually, and said he and StarSquid both want a lot more chains. The churn has been holding the queue up.

9. Chad's Plan to Put Huginn on Mainnet Watch

Two Huginn threads, both early.

The first is documentation. Chad has just started wiring it up: Huginn will read the docs against the codebase and open a code change when it finds a discrepancy, so the docs stop drifting behind fast-moving code.

The second he has wanted for a long time and kept deferring behind the dynamic fee model. A model cannot watch mainnet in real time, because it is too much data and would cost far too much, which Chad called completely impractical. So in his design, mathematical heuristics would do the watching and post to Discord when something looks anomalous, whether slow block times, strange prices or odd logs. Huginn would read that channel, open a thread on the event, run a deep analysis, and post its report where developers, node operators and community members all see the same data at the same time.

Chad named the failure mode: false positives. His example was Huginn hallucinating that the Bitcoin pool is empty, with a co-host adding the Dev Discord screenshot landing on Twitter while the pool sits perfectly fine. The thread is the mitigation, because technical node operators can look and say so publicly. He does not think false positives can ever be eliminated, since today's AI is non-deterministic in much the way humans are.

Huginn does already re-audit. Whenever a new model ships, Chad points it at the codebases again, and it re-reviews any file changed since its last pass and opens a GitLab issue when it finds something significant.

Separately, THORChain is working on being legible to AI agents. A community question about the Robinhood talks brought it up, and Kenton pointed to Robinhood's agent-facing interface: he said IBEC, who works on THORChain Swap with Unstoppable Wallet, could build something comparable. Chad has a developer assigned to AI work and handed over the MCP server code he wrote for Badlands, an unlaunched THORChain project, which already reads THORNode and Midgard data. He is asking for community ideas, on Discord rather than Twitter or Telegram, and floated an online AI developer conference with $RUNE for the top three entries.

What to Watch

• v3.20 shipping: testing wraps this week or early next, Chad hopes, then exchanges are notified, the release is cut, and community adoption follows about a week behind, he thinks. Maybe one or two more affiliates join the dynamic fee model once it lands, which would finally give it a larger sample.
• Zcash first, Monero second: Zcash probably takes the next churn, unless stagenet testing turns up something significant, then Monero as an openly labelled soft-launch beta.
• POL's percentage: if v3.20 turns POL on as hoped, a node vote sets the allocation percentage, with likely follow-up votes to enable stablecoins and specific ERC20s.
• ADR29 and TOR anchors: both votes are still in progress. If the community approves ADR29, watch the SwapKit trial against Chad's condition of returning more than it costs, with a switch-off if it misses. On TOR anchors, adding more stablecoins for valuing TOR, his default is yes.
• Huginn's mainnet watch: still a design rather than a deployment. Expect false positives when it does land, since Chad does not think they can be eliminated.
• Possible Bitcoin forks, and a Discord gap: Kenton flagged talk of one or two Bitcoin forks, his read being that they concern data and ordinals in blocks, which he put at about half right. As the code stands, forked coins in THORChain's Bitcoin pool would most likely be burned, and Chad would only spend engineering time rescuing them if the amount justifies it. Separately, the community Discord is closing with a few channels expected in the dev Discord, so THORChain Swap ticket support may pause for a week or two.
• Next up: Depouch joins on Saturday. Next Thursday is a Rujira focus with Pragmatic Monkey and CodeHans while Chad is on vacation.

More THORChain data, check out raynalytics.net

Follow Raynalytics for more Weekly Analytics and Podcast recaps.