Inside the Houdini Swap Debate: THORChain’s Treasury, Privacy and Revenue

THORSday Community Podcast #237 ft. CBarraford, KentonC137, Devel484 & BooneW | September 24, 2026 | Watch the full episode on YouTube

By Raynalytics

TL;DR

• The new Houdini Swap option in THORChain Swap triggered a wide community debate because its routes use centralized exchanges for transaction privacy. Chad described it as an optional service that operates outside THORChain's swap path, not a change to the protocol's decentralization model.
• The proposed commercial logic is to give the treasury a share of Houdini Swap fees, creating a possible external revenue source while THORChain Swap remains feeless. The Treasury, dev fund and marketing fund serve different purposes, a distinction that got blurred in the backlash.
• Kenton said THORChain marketing will still target THORChain volume and users, not private-route volume. The interface's primary job, he argued, is to make THORChain visible and competitive as its own product.
• Community concerns also focused on Rujira. Kenton said basic Rujira features on THORChain Swap, with the full experience remaining on RujiTrade, are still part of the plan but have not yet been prioritized.
• A separate proposal from Devel would add base-layer limit orders to improve quotes. It remains a proposal, designed to complement the AMM and Rujira rather than replace either.

1. The Houdini Question Is About Boundaries, Not a Protocol Rewrite

The immediate controversy was not whether people can seek privacy. It was whether an official THORChain interface should surface a service whose routes pass through centralized exchanges. Chad Barraford described Houdini Swap as offering what he called small-p privacy: a trade's origin and destination are not publicly linked, but the intermediary can still hold records. That is materially different from censorship-resistant privacy systems such as Monero or Zcash.

The integration does not send a user through THORChain first. A user who chooses the private tab leaves the normal THORChain Swap route and uses Houdini's own routing. In return, the treasury receives an agreed share of the resulting fees. The team framed that as an optional extra service, not an instruction to every user or a new protocol feature.

"We don't support privacy on THORChain, right? So you're just not going to swap through us." (Chad)

That distinction explains Chad's response to the volume-conflict concern. His view was that users who specifically want this kind of privacy would otherwise use a service outside THORChain anyway. Critics saw a different risk: the THORChain brand could absorb reputational damage if a centralized counterparty froze a transaction, even when the protocol itself never handled the trade.

The team did not dismiss that concern. The actual test is whether the interface can present the boundary plainly: Houdini's route is optional, off-chain and subject to Houdini's own service model. It should not be confused with a native THORChain swap or with the privacy properties of a shielded chain.

2. The Treasury Argument: Find Revenue Without Charging the Core User

Much of the disagreement came down to a basic funding question. Chad said the treasury is private capital raised in THORChain's early years, distinct from the reserve, dev fund and other buckets that people often group together. It has funded development, liquidity, infrastructure and ecosystem work, but it is also paying ongoing costs in a weak market.

The team is trying to avoid two alternatives. One would be withdrawing treasury liquidity from pools, which could make those pools shallower. The other would be adding an affiliate fee to THORChain Swap, making the official interface more expensive for every swapper. Chad said a dev-fund increase could be considered if required, but the discussion did not announce one.

"The primary goal is to get volume on THORChain, not on Maya, not on anywhere else, not on Houdini." (Kenton)

That is also the answer Kenton gave to claims that marketing money would be used to promote private routing. His stated sequence is to grow THORChain users and volume first, then use a stronger adoption story to support broader marketing and investor outreach. Houdini revenue, if it materializes, was presented as a treasury supplement that could be reinvested in the protocol, not the new target of the marketing fund.

The episode did not settle whether that trade-off will persuade the community. It did make the underlying choice clearer: accept a bounded, optional commercial integration, or fund the same costs more directly through the interface, pools or system-income allocation.

3. Rujira’s Place in the Official Interface Remains a Live Expectation

A community participant connected the Houdini backlash to a longer-running frustration: an outside service appeared in THORChain Swap while Rujira, THORChain's app layer, still lacks an equivalent interface presence. The point was not that Houdini and Rujira offer the same product. It was that product priority communicates whose work the official interface is designed to amplify.

Kenton said the plan has not changed. The proposed shape is a basic and pro split: basic Rujira actions inside THORChain Swap, with deeper functionality linking to RujiTrade. He said he and the Rujira team had already discussed the user flow, but time and stability work had pushed it behind other priorities. He also noted that the app layer still has production issues to resolve.

"THORChain first, right? That's what we have to focus on." (Kenton)

The conversation also separated interface access from quote liquidity. The participant asked whether Rujira's concentrated liquidity could help THORChain win more quotes. That is a technical question distinct from adding a tab or skin. Chad said the team was not trying to integrate a competing limit-order service, while Devel described his base-layer proposal as a different mechanism for improving the cross-chain swap path.

The useful standard is not symbolic parity. It is whether a given integration helps THORChain win routes, improve execution or make the ecosystem more usable, without obscuring where the underlying liquidity and risk sit.

4. Revenue Share and Dynamic Fees Move From Theory to Measurement

The show also covered two experiments aimed at winning more routes without simply cutting fees for everyone. Chad said the team was close to enabling a revenue-share arrangement with SwapKit. The proposed arrangement would use a portion of the revenue generated through SwapKit to improve selected quotes, with exclusivity on both sides during the test.

Chad set the basic test plainly: if the protocol gives up 20% of the revenue on that flow, it needs at least a 20% increase in routed volume to break even. He expected the team to monitor the result over weeks rather than declare success at launch. No outcome was available during the recording.

"We need to basically compete for every basis point we can get to be competitive." (Kenton)

Dynamic fees are the other lever. The code has behaved as designed so far, Chad said, but the team still needs more useful data to distinguish a genuine pricing benefit from normal market noise. Symbiosis, Edge Wallet and Gem Wallet were named as possible future test venues. That was a discussion of possible enrollment, not confirmation that any of them had been activated.

The common principle is measurement. Better quotes can create more volume, but a lower fee only helps if the extra flow and revenue are real. The episode repeatedly returned to that condition rather than treating an integration, a fee change or a dashboard as proof by itself.

5. Devel Revisits Base-Layer Limit Orders

The final section returned to Devel's base-layer limit-order proposal, previously covered in depth after Podcast #217. The idea is deliberately different from THORChain's current limit swaps. A limit swap still travels the AMM curve and targets an average execution price. Devel's proposed limit order would rest at a fixed price inside the swap path.

When a swap reaches that price, it would stop moving along the AMM curve, match the resting order at the fixed price, then continue along the curve if necessary. Devel said the AMM remains the sole price-discovery mechanism. The design is post-only, so an order can add liquidity but cannot move the pool price or take liquidity away.

"It's not a separate order book." (Devel)

The first version would be intentionally narrow: trade or secured assets, $RUNE-denominated single-pool orders, a proposed 2% active band around market price and one-block activation. It would not initially cover cross-pool routes such as $USDT to $BTC. Devel's estimate was that the core matching logic is simple enough to test at scale, while the full implementation still needs transaction handling, API work and extensive review.

For swappers, the possible benefit is lower slippage on the portion filled against a resting order. For arbitrageurs, the proposal shifts the job from reacting after a pool move to posting liquidity ahead of time. Boone stressed that the AMM must remain the dependable liquidity of last resort. The code is not live. Devel said it can be gated on or off, tested privately and subjected to stagenet and adversarial testing before any mainnet decision.

What to Watch

• Houdini disclosure and usage: whether the optional private route is presented clearly enough for users to understand that it is not a THORChain-native privacy system.
• Treasury revenue: whether Houdini's fee share becomes a meaningful outside contribution, without changing the marketing focus or adding an affiliate fee to THORChain Swap.
• Rujira access: whether the discussed basic Rujira experience reaches THORChain Swap, and whether its liquidity can help quote competitiveness.
• Fee experiments: SwapKit revenue-share results, any subsequent dynamic-fee tests and the volume data needed to assess them.
• Base-layer limit orders: feedback on Devel's proposal, the bounded first scope and evidence from private testing before a governance or mainnet step.

More THORChain data, check out raynalytics.net

Follow Raynalytics for more Weekly Analytics and Podcast recaps.