ADR-029 Affiliate Revenue Share

ADR029 - Affiliate Revenue Share

Affiliates on THORChain earn money one way today: by charging the user a fee. That money flows in a single direction, from the user to the affiliate.

ADR029 introduces REVSHARE, a new route for that money to flow: from the protocol to the affiliate, funded by THORChain's own swap revenue instead of the user's.

Let’s dive in.

How Affiliate Fees Work Today

Today, an affiliate earns revenue in exactly one way: by charging the user an affiliate fee, a basis-point cut taken directly from the swap executed by the user.

That means the only way for an affiliate to make more money is to charge more. It's a simple model, but it puts the affiliate and the protocol on the same side of a trade-off: a higher fee grows the affiliate's revenue, but it also makes THORChain's quote less competitive. If that fee pushes the price out of line with other venues, the protocol doesn't just lose a few basis points, it risks losing the swap altogether.

What ADR029 Changes

ADR029 introduces REVSHARE which will flip that direction. Instead of taking more from the user, THORChain can pay a share of the swap revenue it earns, specifically the RUNE liquidity fees collected on a swap, back to the affiliate that routed it. That share is calculated after the swap settles, so it never factors into the quote the user sees, making the quote more competitive.

That gives THORChain's business development team a new lever to work with, alongside the standard affiliate fee. Instead of a partnership only working if the partner charges users enough to make it worthwhile, it can now be funded out of the protocol's own revenue too. In practice, that helps in a few concrete ways:

• Easier onboarding. A prospective partner no longer needs a competitive user-side fee just to make integrating THORChain worthwhile. A revenue share can make the partnership work even at a thin, or zero, fee to the user, which lowers the bar for bringing new integrators on board.
• More competitive quotes. Existing partners can afford to lower their user-side fee, since their earnings no longer depend on it alone. A lower fee means a better quote, and a better quote means THORChain wins more of the price-sensitive flow it would otherwise lose to a competing router.
• Volume scaling. A rev share only costs the protocol money if it doesn't bring in enough extra volume to offset it. The break-even is share / (1 - share): a 25% share needs roughly 33% more volume just to cover itself, and that's before counting the arbitrage volume extra flow tends to attract, so the real bar is likely lower.
• Pricing Strategy. Because payouts accrue per affiliate rather than attaching to any single quote, a partner can choose how to deploy its share, pooling it and spending it selectively on the routes where a cheaper price is most likely to win volume, for instance, rather than spreading it evenly across every trade. SwapKit's proposal, covered further down, is a concrete example of this kind of strategy.

In other words, sharing revenue with affiliates isn't just a discount on quotes or a goodwill gesture from the protocol. It opens the door to real business development and pricing strategy, led by affiliates working together with THORChain's BD team, and still fully under the supervision of the nodes. Also, it is worth noting that payouts still run automatically once a rate is approved, with no manual step from THORChain's marketing, dev, or treasury teams.

Technical Implementation

REVSHARE is gated by a new operational mimir, REVSHARE-<thorname>, set in basis points and capped at 5,000 (RevShareMaxBps), so the protocol can never share more than 50% of the liquidity fees attributed to a single affiliate.

Attribution follows the first affiliate named in the swap memo, strictly, with no fallback to a second name if the first has no rate set. Streaming sub-swaps roll up under that same affiliate, and fees accumulate per THORName over the course of a block.

At the end of each block, the network checks the REVSHARE rate for every THORName with accumulated fees. Where a rate is set, it pays out bps × accrued fee / 10,000 from the Reserve into the AffiliateCollector module, the same module that already handles the user-side affiliate fee and preferred-asset conversions described above. That payout comes off the top of protocol income (systemIncome) before the usual split across the dev fund, burn, TCY, marketing, POL, and the pendulum. No RUNE is minted, it's a redirection of income the protocol already earned.

Every THORName with attributed fees generates a rev_share event each block (thorname, owner, accrued_fee, bps, payout), even when its rate is zero, so indexers can track gross attribution independently of whether a payout happened.

Turning REVSHARE on for a given affiliate requires node operators to vote the mimir into place, as for any other network parameter. Nodes keep full control of the mechanism, and the expectation is that for each affiliate, the case for why that specific partnership is net-positive for the protocol will be made publicly before any votes.

The Merge Request: https://gitlab.com/thorchain/thornode/-/merge_requests/4779

SwapKit as a First Example

SwapKit is the first partner to put forward a concrete proposal for how it would use REVSHARE. Rather than shaving a small discount off every quote, its plan would let REVSHARE accrue into a pooled credit balance, then spend those credits selectively: on traffic through SwapKit's own widget and API, intro pricing for new integrations, or targeted subsidies to bootstrap a new chain or pool. Integrations already locked into fixed fee-split agreements with wallet partners would keep their existing pricing untouched.

By its own illustrative numbers, $100K in monthly THORChain liquidity fees from SwapKit-routed volume at a 10% share works out to $10,000 a month in spendable credit, with THORChain able to weigh in on where it gets spent. It's one proposal among what's expected to be several, still under community review, and its figures are illustrative rather than committed terms, but it's a concrete example of the kind of partnership REVSHARE is meant to enable.

Conclusion

With ADR029, THORChain introduces a new way to pay affiliates: out of the protocol's own revenue, not just the user's. That opens the door to cheaper quotes, easier partner onboarding, and more deliberate BD and pricing strategy, all under node control. SwapKit's proposal is the first test of what that can look like in practice, and it's a fair bet others will follow.