THORChain is Close to v3.20: FROST, DKLS, SwapKit Rev-Share and Dynamic Fees

THORSday Community Podcast #225 ft. CBarraford, KentonC137, patriotsounds & ol3gpetrov | August 13, 2026 | Watch the full episode on YouTube

By Raynalytics

TL;DR

• The v3.20 approval vote was expected that day or the next, with adoption and release expected within one to two weeks. It includes post-exploit migration fixes, a Maya Protocol TSS fix already tested upstream, and the path to resume churns.
• THORChain's cryptography direction is FROST for Schnorr-capable chains, including Bitcoin through Taproot, and DKLS for ECDSA chains. Both still need library work that preserves identifiable aborts before the protocol can leave GG20 behind.
• Three additional stablecoins were still short of consensus as TOR anchors. Chad's case is diversification: a broader basket should be more resilient to a single stablecoin depeg.
• ADR29 rev-share was at 58.9% approval with no votes against. SwapKit would recycle its share into discounted quotes, aiming to win external wallet flow rather than merely discounting volume THORChain already has.
• ShapeShift remains the dynamic-fee pilot. THORChain took about 34% of its July swap volume, but Chad still treats it as a small sample until v3.20 lets the experiment expand to a larger affiliate.

1. v3.20 Is at the Vote Gate, Then the Churn Can Restart

THORChain is close to the practical update everyone has been waiting for. Chad Barraford said v3.20 was nearly ready for its approval vote, likely that day or the next, and he expected rollout within one to two weeks once operators adopted it.

The release bundles work that accumulated after the exploit: migration repairs, as well as a TSS-related fix discovered and tested first by Maya Protocol. Because Maya shares THORChain's code lineage, the team brought the tested change across rather than waiting for the same issue to surface independently.

"We should be putting out the post to vote on v3.20 probably today or tomorrow." (Chad)

The immediate consequence is bigger than a version number. Once v3.20 is adopted, the protocol can unpause churns, which are still the gate for launching Zcash and Monero. Chad also wants to remove that dependency for ordinary future chain launches. A chain that uses a signing algorithm THORChain already supports should not need the whole network to churn just to receive an address. $XMR is the exception because its implementation requires a new signing algorithm and a new private key.

That work matters because every additional chain adds both more code and more external systems that must behave during a churn. A halt or issue on any connected chain can complicate moving funds from old vaults to new ones. The direction is to keep churn as a security and validator-set process, not let it remain the bottleneck for unrelated operations.

2. FROST and DKLS Are the Path Away From GG20

The security discussion returned to the destination set out in the earlier v3.20 and Monero recap: move away from GG20, but do it without losing the accountability a permissionless validator set needs.

FROST is the preferred direction for Schnorr signatures. Chad described it as a simpler construction with a smaller attack surface, making it the natural target for Bitcoin through Taproot and potentially EVM chains through a smart-contract layer. The team is evaluating existing FROST libraries, including the possibility of learning from Chainflip's implementation, but made no commitment to use it.

For chains that require ECDSA, DKLS is the counterpart. THORChain engaged a specialist cryptography team in late 2025 to adapt DKLS with identifiable aborts. That feature is crucial here: when a node disrupts key generation or signing, the protocol needs evidence of who caused the failure so it can slash or remove the operator. A closed set of trusted signers may not need that, but THORChain does.

"FROST would be probably the top priority in the sense of what's most valuable to the protocol." (Chad)

The planned division is straightforward: FROST where Schnorr works, DKLS where ECDSA is required, and a gradual retirement of GG20. A two-of-two vault using two different cryptographic schemes remains a longer-term idea, not a decision. The first job is to deploy tested, accountable replacements. Monero already uses a FROST variant, but it is Monero-specific and cannot simply become the general Bitcoin or EVM solution.

3. TOR Anchors Need Votes, and Chad Wants Votes to Stop Stalling

Three stablecoin additions to the TOR anchor basket were still sitting around the low-50% range, short of the two-thirds consensus they need. Neither host had heard a substantive case against them.

Chad's argument is not that every stablecoin is perfect. It is the opposite. $USDC, $USDT and other long-lived stablecoins have all depegged at some point, but the basket is designed around the unlikely event that all credible anchors fail together. Kenton said more anchors create a broader price reference and reduce dependence on any one asset.

"The more coins you add, even if they're not the greatest stablecoins, that still gives you a better, broader, wider image." (Chad)

The slower problem is governance participation. Chad is prototyping a required-voting mechanism for ADRs: once one-third plus one of operators have voted, the remaining operators would need to vote before they can re-enter after a churn. The aim is not to force a yes vote. It is to end the limbo where a proposal receives neither a decision nor a clear objection.

For now, the near-term ask is simpler: operators should double-check their Mimir votes actually registered. The team suspects some may believe they voted when the transaction never landed.

4. ADR29 Gives SwapKit a Measurable Rev-Share Experiment

ADR29, the revenue-share proposal, stood at 58.9% approval at recording, with no votes against. It still needed roughly two-thirds consensus. The design lets an affiliate receive a percentage of THORChain's liquidity fees, but the SwapKit proposal is not a conventional payout.

SwapKit would put the credited amount back into price discounts. Oleg Petrov explained that the accounting system is already in final testing: it indexes THORChain-routed transactions, tracks each fee credit, and applies the balance to quotes where SwapKit can reduce or remove its own affiliate fee. A public balance endpoint and shareable BigQuery data are planned so the experiment can be audited.

"For every dollar that we receive from THORChain, we spend it all in deeply discounted quotes." (Oleg)

The target is flow SwapKit does not currently win, especially through wallet marketplaces such as Ledger. That distinction is central. This is not intended to subsidize existing THORChain swaps inside SwapKit. It is meant to improve the quote enough to take external flow from competing providers, sending the incremental volume through THORChain.

The group discussed starting around 20%, with 10% to 30% as the plausible range. The right metric is net fee income, not the percentage alone. If a larger credit wins enough additional volume to raise THORChain's net revenue, it is working. If it lowers income or fails to move share, it can be switched off.

5. Dynamic Fees Need a Larger Sample Than ShapeShift

The existing dynamic-fee pilot remains limited to ShapeShift. Chad said THORChain held roughly 34% of ShapeShift's routed swap volume in July, ahead of Chainflip at around 33%. August data was noisier because a small number of unusually large trades pushed other providers higher, while THORChain remained ahead of Chainflip.

The result is encouraging, but not conclusive. ShapeShift's volume is small enough that one or two swaps can materially move a monthly share. That is exactly why it was the safe place to begin, rather than deploying an unproven model first at a larger affiliate such as SwapKit.

"Everything I've seen so far is quite positive, I would say." (Chad)

v3.20 carries the fix required to enroll another affiliate. That is when the test can graduate from a useful signal to a more meaningful dataset. Rev-share follows the same logic at a different layer: instead of the protocol adjusting a fee, the aggregator uses its richer quote and execution data to decide when a discount may win a trade.

6. Monero Is Tested, but Its Soft Launch Still Depends on the Churn

Monero has been tested alongside v3.20 and appears to be working. It still cannot launch until v3.20 goes out and the protocol churns again. Zcash is first in the queue, then $XMR can follow soon after.

The soft-launch framing remains the right one. Monero's 10-block, roughly 20-minute output lock changes the usual UTXO-management assumptions. In a worst case, a large share of the vault's UTXOs could be temporarily unavailable for outbound signing. Chad thinks the current logic may be sufficient, but the team has a fallback: consolidate only when an outbound needs more value, instead of proactively consolidating many UTXOs at once.

"Monero is a new beast. It's structurally different than every other UTXO chain we've ever seen." (Chad)

The consequence would be delayed outbounds, not lost funds, and the team can ship a targeted patch quickly if mainnet activity proves the concern real. The key is to let the live network reveal the actual failure mode rather than spend scarce engineering time solving a hypothetical one.

7. A Small-P Privacy Feature Is an Idea, Not a Roadmap Item

The most speculative discussion came at the end. Denny joined the discussion as Chad described an early concept for optional "small-p privacy" on THORChain: encrypt routing information so the public cannot trivially connect a swap's inbound and outbound addresses, while node operators retain the ability to decrypt the memo and respond to lawful requests.

It would not be Monero-like privacy or a mixer. Chad explicitly ruled out building a service intended to conceal transactions from government scrutiny, citing both regulatory uncertainty and the risk to developers and operators. The narrower case is personal safety: for example, preventing a merchant data leak from linking a home address to a public wallet with a large $BTC balance.

The proposal has no design, timeline, partner, or vote. It is a question for the community about demand, complexity, and whether potential premium fees justify the work. Chad said he will keep thinking through it only if there is interest.

What to Watch

• v3.20 adoption: the approval vote was expected immediately, with rollout estimated at one to two weeks. Its success clears the restart of churns and the next affiliate expansion for dynamic fees.
• FROST and DKLS research: watch for the library review and how THORChain will preserve identifiable aborts while moving off GG20.
• TOR anchors and ADR29: both still need operator participation. Live vote status is on Ray's governance tracker on raynalytics.net.
• SwapKit rev-share: if ADR29 passes, the experiment should be judged on net fees and external wallet flow, not on the headline percentage alone.
• $XMR launch: Monero remains a soft launch after Zcash and the next churn, with outbound behavior and UTXO locks the main live-network questions.
• Privacy feedback: the encrypted-routing idea is exploratory. It needs a real use case and a credible design before it becomes work on the roadmap.

More THORChain data, check out raynalytics.net

Follow Raynalytics for more Weekly Analytics and Podcast recaps.