SwapKit Rev-Share Week One: Early Data Looks Promising, v3.21 and Monero Next

THORSday Community Podcast #243 ft. CBarraford, KentonC137 & Patriotsounds | October 15, 2026 | Watch the full episode on YouTube

By Raynalytics

TL;DR

• One week into the SwapKit Rev-Share trial, Chad said about $430 of discounts lined up with almost $2,000 of protocol revenue, a 4.6x return, while stressing that the sample is small and may not scale.
• v3.21 was on release candidate 6 with final stagenet checks running. $XMR changes for THORNode ride in v3.21, and any remaining Bifrost patches could follow quickly in v3.21.1.
• Tether briefly froze THORChain's Tron $USDT vault address before reversing it, prompting a debate over whether protocol-owned liquidity should favor permissionless assets.
• The devs are weighing whether Huginn, which has already added about 1,300 unit tests and new testing frameworks, should count as one of the two approvals a code change needs.
• Dynamic fees will move from daily to volume-based measurement windows, THORNode code now runs about 3x faster, and 2-second blocks and a FROST rollout are back on the table.

1. SwapKit Rev-Share's First Week: Early Data Looks Promising

Rev-Share has been live with SwapKit for about a week, and Chad screen-shared Ray's SwapKit Revenue Share dashboard to walk through the first results. THORChain kicks back 20% of the revenue it earns from SwapKit-routed swaps into a credit bucket. SwapKit then spends that bucket to discount future quotes and win trades it might otherwise lose. As the hosts clarified, SwapKit does not keep the money: the intent is to spend all of it on better quotes, and SwapKit earns from the extra volume it routes.

So far SwapKit has spent only about $430 of the just under $3,000 accrued. Over the same period, swaps carrying those discounts generated almost $2,000 for the protocol, a 4.6x ratio that had been 3.7x the day before. The discounted swaps totalled slightly over $1 million in volume across 302 swaps, and the dashboard's volume view showed roughly double the baseline over 8 days. Chad assumed that volume was trade SwapKit would not have won otherwise, but said he does not know that for sure. SwapKit is also scaling up slowly while it waits for v3.21 to fix a few THORName issues.

"For every $1 we give SwapKit and they spend that to discount quotes, we get back $4.60 effectively." (Chad)

The number Chad is watching is 5x. The protocol already earns more than it gives back below that line; 5x is where SwapKit's bucket becomes self-funding. Because SwapKit receives 20% of the extra revenue, any return above 5x refills the bucket faster than SwapKit can spend it, a flywheel where the discounts fund themselves. If the ratio stalls near 4.6x, Chad agreed that raising the share to 25% would move that point down to 4x. If it climbed toward 10x, the share could instead fall to 10% or 15%. His caution was just as clear: the bucket has so far been applied selectively, and returns could shrink as spending scales into the thousands.

The bigger question is reach. SwapKit is integrated with wallets such as Trust Wallet and Ledger, where it competes with other providers, and THORChain currently wins only a single-digit percentage of SwapKit's trades. The agreement is exclusive in both directions for this feature, so THORChain cannot run the same program with another aggregator, and SwapKit cannot run it with Chainflip or NEAR Intents. Dividing volume by swap count, the hosts put the average discounted swap at about $3,400, the larger trade sizes where THORChain tends to quote well. This builds on the launch covered in last week's recap.

2. v3.21 Is Nearly Cut, With Monero Close Behind

Chad said every pull request for v3.21 had been merged and the release was on release candidate 6, with final stagenet tests underway. During the show, the hosts relayed a team update that the core stagenet tests had passed and the last chain checks were finishing. Chad expected the release to be cut that day or the next, followed by node voting to adopt it. The release had been held back a few days so it could carry as many Monero changes as possible.

Chad said the THORNode changes needed for $XMR are expected in v3.21, while some Bifrost-specific patches may land in v3.21.1. That split matters because a patch release can be cut at any time, while a full release takes far more testing and coordination. Much of the $XMR work has been handled by Zly Dev and the team. Getting Monero live on mainnet is one of Chad's primary short-term goals.

"You better believe we want the same damn thing you do." (Chad)

Chad also hopes to remove the churn as a requirement for adding most new chains in v3.22 or v3.23. For chains using key types THORChain already supports, vaults only need to derive and publish new addresses from existing public keys; chains needing new cryptography, like Monero, would still require more. Progress is tracked on devops.thorchain.org.

3. Tether Froze the Tron $USDT Vault, Then Reversed It

Tether recently froze the address THORChain uses for its Tron $USDT pool. Chad suspects the freeze happened partly because THORChain's external addresses look like ordinary wallets rather than smart contracts. He first saw it when Devel posted in the THORChain mainnet channel, and it took three to four hours to reach the team. With help from Randy, he spoke with Tether's CEO, who was apologetic and had it fixed quickly.

The episode put the exposure in context. The pool held about $200,000, while the freeze covered about $1.45 million, which Chad assumed was largely $USDT arriving from the malicious party that triggered it rather than LP or protocol funds. In a worst case, only the stablecoin side, about $100,000, would be lost. The $RUNE side could be redeployed through the protocol-owned liquidity (POL) module into other pools. Kenton added that THORChain Swap already stops trading when a pool is paused, but this pool was not paused, so the team is adding monitoring of the Tether and Circle blacklists to block affected swaps automatically.

Denny used the incident to revisit a post he made in the dev Discord. POL currently goes to the pools with the best depth-to-revenue performance. He floated always sending some flow to the best-performing permissionless asset, or letting nodes redirect it. Kenton disagreed: $BTC to $USDT is the largest trading pair in the world, and stablecoin pools need to keep growing for THORChain to pull volume off centralized exchanges. Denny granted that his proposal trades economic efficiency for protection against an event that may never happen, and that $XMR would likely win POL flow for a long time anyway.

"I'm willing to sacrifice some efficiency to make sure THORChain is as robust as possible." (Denny)

Chad argued a deliberate freeze would be self-defeating for any issuer: every DeFi protocol would have to reconsider the asset, LPs would pull out, and the issuer could face legal claims from LPs whose funds it froze. The POL routing question was left open. For background on POL, see the recap covering its launch.

4. Dynamic Fees Will Measure by Volume, Not by Day

Chad has been reviewing the dynamic fee model and said it is not as effective as he would like. The first version was deliberately kept as a plain minimum viable product, so real-world data could show what works before the design was refined. The problem that data revealed is sample size: on many affiliate pairs there is not enough volume to tell whether a fee change in bps actually caused more or less volume.

The fix Chad wants is to change the epoch, the window the model studies. Today it compares fees and volume day against day, and a day with only 10 trades says little. Instead, the epoch would close once a set amount of volume has passed through, with $100,000 or $1 million used only as illustrative figures. Quiet pairs would collect data over a longer period, while a busy pair like $BTC might need only an hour. The aim is more signal and less noise.

That change is one of several Chad wants in v3.22. In the meantime, the team may leave the current model running for roughly another two weeks to keep studying how it moves. Earlier results are covered in the dynamic fees recap.

5. Should Huginn Count as a Code Approval?

The devs are debating whether Huginn should be able to approve pull requests. Merging a THORNode change currently requires two human approvals. Huginn reviews every pull request and every later commit and is, by Chad's count, the top commenter, but its approval does not count toward a merge. The proposal is to require Huginn plus one human. Chad said no one on the team is arguing to remove humans, devs hold valid views on both sides, and he wants the security team's input before anything is decided.

Chad's case is speed. He said AI has lifted coding efficiency by only about 1.3x to 1.4x, because the slowest part of the life cycle, the human steps, has not sped up. He added that humans and AI both make mistakes, so the real question is which is more likely to, and how severe the mistake would be.

"The thing that is super slow is always me. It is always the human." (Chad)

Huginn's role is already growing. Beyond reviews, it runs continuous security audits, fixes issues it finds under human oversight, and has added about 1,300 unit tests (roughly 70,000 lines of code), along with new fuzz, mutation and accounting testing frameworks. Chad would let it run self-directed improvement loops only on tests and on performance work that can be verified by replaying thousands of mainnet blocks and checking that every block's app hash is identical. He would not trust it with open-ended feature work at this stage. The approach was first outlined in last week's recap.

6. A 3x Faster THORNode Brings 2-Second Blocks Back Into View

Chad said THORNode's code is now about three times faster after AI-driven optimization work, merged the day before and expected in v3.21. A large part of that came from pprof profiles supplied by Liquify, which Chad described as an X-ray of a live daemon showing where code spends its time and memory. He still needs a Bifrost profile from an active validator, and the hosts relayed that Devel aimed to provide one the next day. Any operator can help by enabling pprof through an environment variable, and Chad said the profiles contain no private keys. A faster Bifrost should lower the CPU and memory validators need.

The speedup will not shorten block times on its own, but Chad expects it to make them more stable after recent instability. It also gives him more confidence to revisit a year-old pull request that moved THORChain from 6-second to 2-second blocks. He pulled back then because many mimir settings run every set number of blocks and mainnet's reaction was hard to predict, but modern AI tools could help verify the change before it ships. Faster blocks could let arbitrageurs track prices more closely, and Chad expects Rujira, which is working toward perps, would welcome them. The hosts added that shorter blocks might eventually make room to raise the 120-node limit.

Chad also flagged an upcoming Cosmos SDK upgrade that will move THORChain to v4.0, and asked the community not to read the version jump as a major feature release. He would not leave the Cosmos SDK unless forced, and said THORChain could take over maintenance if the Cosmos Labs team ever stepped away.

7. FROST Will Roll Out One Vault at a Time

Chad said work on a FROST implementation has started, and he expects it to be finished next week or the week after, followed by integration into Bifrost. The plan is to move away from GG20 toward newer cryptography with a smaller attack surface, building on the work covered in the v3.20 recap.

The rollout would start small: one smaller chain, on one of THORChain's six vaults. If that vault hits a signing bug, outbound transactions would be reassigned to a working GG20 vault, slowing mainnet a little without breaking anything. As confidence grows, more vaults would move over each churn, then more chains. Initially FROST would replace GG20, but Chad said GG20 could return as half of a 2-of-2 multisig, so breaking THORChain's cryptography would require breaking both schemes at once.

DKLS is still planned, just second. FROST comes first because $BTC can use it through Taproot, and $BTC makes up a larger share of TVL. Some chains, such as Bitcoin Cash, lack Taproot and cannot use FROST. Chad ranked FROST, then DKLS, then GG20 by how unlikely each is to have an implementation flaw. Separately, Soda Labs completed a full audit of THORChain's code, done largely by hand, and the team is patching what it found. Chad said none of the issues were serious.

8. A Proposed Public Test of Quotes Versus Fills

The hosts said they keep hearing from wallets that some swap services give attractive quotes but poor fills. Kenton floated publishing an objective report rather than calling anyone out, and Chad suggested how to run it: use marketing funds for real swaps, have Ray run them across providers, and publish the quotes, outputs and transaction hashes so anyone can verify them on-chain. Kenton offered to pay to distribute the results. He also gave Ray a shout-out, saying Ray has never said no to anything he asked.

The design discussion was specific: 30 to 50 swaps per size for a statistically meaningful sample, at sizes from about $500 to $50,000, across 10 to 12 providers including THORChain and Maya Protocol. Kenton plans to start the provider list from the routes Ledger Live displays. Concurrent swaps would use separate pools so they do not affect each other, and the group discussed open-sourcing the tooling so anyone can rerun the test. Chad also said aggregators could one day adjust quotes for providers that consistently overquote.

"We have the moral authority to do that." (Chad)

Kenton's other priority is wallet coverage on THORChain Swap. After a week of bug fixes, the next targets are Trezor, Rabby and Brave Wallet, one of the more popular Zcash wallets. Trezor is the priority so it is ready before Monero goes live. New wallets will be left to settle before more are added, but Kenton believes broader wallet support could matter more than new features.

What to Watch

• Whether the SwapKit Rev-Share return reaches 5x, where the credit bucket refills itself, as SwapKit scales spending after v3.21 adoption, and whether the 20% share changes.
• The v3.21 cut and node vote, and whether $XMR follows quickly in v3.21.1.
• v3.22 changes to dynamic fees, plus churn-free chain additions in v3.22 or v3.23.
• Whether the Huginn approval change is adopted after security-team input.
• The Bifrost pprof profile, a revived 2-second block pull request, and the Cosmos SDK upgrade to v4.0.
• The first FROST vault on mainnet, and the Soda Labs audit patches.
• Kenton's quarterly report, expected next week, and whether the quote-versus-fill test goes ahead.
• Schedule changes: no podcast on Saturday, October 17, Zodl on Friday, October 23, and Moca on Saturday, October 31, when the Saturday show moves an hour later.

More THORChain data, check out raynalytics.net

Follow Raynalytics for more Weekly Analytics and Podcast recaps.