RUJI Trade: Bringing a new upgradable liquidity model to THORChain

TLDR

• THORChain relies on active arbitrage to function.
• Arbitrage is currently inefficient and is costing THORChain via sub-optimal swap execution.
• Base Layer liquidity for the main trading pairs cannot be increased due to THORFi overhang.
• This means TVL in BaseLayer pools cannot scale unless RUNE price goes up.
• The drop in RUNE price in the aftermath of THORFi has caused TVL to drop materially leading to a decline in volumes while liquidity utilization remained stable.
• Rujira can use the endblock scheduler to effectively deploy App Layer liquidity into Base Layer pools, offering a new liquidity model for THORChain.
• This means THORChain can scale its TVL again, using much more capital efficient AMM strategies deployed on Rujira.
• This would lead to Base Layer pools better tracking market prices and offering more competitive quotes.
• Combined with THORChain rapid swaps, this would also lead to faster execution, reducing settlement time.
• We estimate there is ~$800m of monthly arbitrage volumes on THORChain, yielding around $3m of profits to external arbitragers.
• We can internalize a share of that as a new income stream for Rujira, while improving THORChain’s competitiveness on both price and time.

Context

Volumes on THORChain are driven by two type of events: (i) “Organic usage",  when users, via various frontends and integrators, use THORChain to swap tokens; and (ii) “Pure arbitrage”,  which occurs when the broader market price has moved but THORChain pool price hasn’t caught up yet. In both cases, this creates a dislocation between the pool price and the broader market price, and when the deviation is large enough, an arbitrage opportunity occurs. Looking at the share of Trade Assets volumes, we estimate arbitrage represents ~60% of THORChain volumes.

Every “organic” swap in the Base Layer Continuous Liquidity Pools moves the price away from the starting state and requires arbitrageurs to step in and rebalance the pool. The larger the swap relative to the size of the pool, the larger the deviation, per XYK pricing model.

Every large enough price change in the broader market also creates a price dislocation and an opportunity for arbitragers to rebalance the pool. The larger the TVL in the pools, the more arbitrage volumes can be facilitated.

Therefore, THORChain relies on active arbitrage to function, and on healthy TVL in Base Layer pools to maximize volumes and competitiveness.

TVL in Base Layer pools can no longer scale

THORChain has very successfully increased the capital efficiency of its Base Layer pools by introducing streaming swaps, a clever way to go around the limitation of XYK pricing by breaking down large swaps into smaller swaps executed across multiple blocks, trading speed of execution for better pricing while relying on arbitrageurs to rebalance the pools between each swap.

The daily Liquidity Utilization ratio (calculated as: Daily Volume / End of day TVL) went up from an average 0.15x pre Streaming Swap (April 2021 to August 2023), to an average 0.53x post streaming swap (September 2023 to January 2026); an impressive improvement.

This led to a belief among part of the community that TVL in Base Layer pools has no bearing on volumes. However, looking at the data tells us a very different story.

The below chart plots the Daily Liquidity Utilisation Ratio against Base Layer pools liquidity. If volumes were independent from TVL, you would expect to see the utilisation ratio to drop as the TVL grows. Or, we can see that the utilisation ratio has been consistent both across time and across various levels of TVL, from the highs above $500m to the lows sub $100m. This means volumes scale pretty much linearly with TVL: the higher the TVL, the higher the volumes and protocol revenue.

Liquidity is the key resource that allows THORChain to generate recurring revenue, it is the fuel required to make the rocket fly.

However, due to THORFi overhang, THORChain faces a key challenge: Base Layer TVL for the main trading pairs - including BTC, ETH, USDC and USDT - can no longer be increased via deposits. The only way for TVL in those pools to grow is for the RUNE price to go up. This constrains THORChain revenue growth and makes reliance on efficient arbitrages even more critical for swift execution.

Arbitrages are currently sub-optimal

THORChain relies on active arbitrage to function. However, arbitrages are currently sub-optimal, with external arbitrageurs letting the prices in the Base Layer pools deviate substantially from the market prices. This comes at the cost of a worst execution for users who end up swapping at an average price often materially worse than the market price. This can be observed in the below charts, see the wild wicks when the streaming swaps start.

This is even observable on stable-to-stable swaps.

Our research shows an average price deviation of ~0.40% with swaps often exceeding the average by a significant margin. This might be due to the confirmation delays to move assets from/to CEXs to close the arbitrage loop, adding inefficiencies and increasing risk for arbitragers.

THORChain v3.12 upgrade brought us the onchain scheduler, a module allowing smart contracts on the App Layer to schedule a future execution of themselves. Importantly, this allows a smart contract privileged access to the start of the `endblock`. It means smart contracts can have a front seat to execute arbitrages and efficiently rebalance Base Layer pools using App Layer liquidity. The App Layer can be used to grow THORChain liquidity to support the Base Layer pools affected by THORFi, and thanks to smart contract expressiveness, can do that using various concentrated liquidity strategies that will be much more efficient than traditional XYK pools. It also allows to build up liquidity paired with stablecoin or BTC instead of RUNE, mitigating the reflexive nature of Base Layer pools, which is good to have when RUNE price goes up, but damaging when RUNE price goes down.

This, combined with THORChain's rapid swap feature, means Rujira could also improve settlement time for larger swaps, with the App Layer injecting liquidity into Base Layer pools on an as-needed basis.

This is a major opportunity for both Rujira and THORChain to improve both pricing and settlement speed of Base Layer swaps while internalizing a material source of profit currently captured by external arbitrageurs.

How would it work?

With the scheduler, we can make sure any arbitrage opportunity existing between the App Layer liquidity and Base Layer pools is captured every block. We will upgrade the Virtualization Strategy (VS) contract so it is able to query the current swap queues and inject a swap request into the swap queue that is perfectly sized because it knows that nothing else is gonna enter in the queue. The VS will place a quotes on RUJI Trade orderbook based on the price it can get on the App Layer for various sized, net of the liquidity fee it pays to the Base Layer (10 bps per leg currently) plus a `reserve_fee`which is effectively the target arbitrage profits on top of the Base Layer quote.

Now, where it gets very interesting is for the quote at the top of the book, the VS can size it based on the total size of the pending streaming swaps, net of any swaps in the other directions which will be matched by the new rapid swap feature of the Base Layer. Then, every block, the onchain scheduler will match any overlapping orders between the VS and the rest of the liquidity available in the orderbook, provided by the various AMM strategies and users orders living on the App Layer. Any arbitrage profits from matching overlapping orders are captured as protocol revenue.

Example

Imagine there is a large Base Layer swap looking to buy BTC with USDC, which is pushing the price of BTC in the Base Layer pool 0.40% above the ask price in the BTC/USDC pair on RUJI Trade orderbook.

Let’s make a few more assumptions:

• Assume we have a combination of capital efficient market making strategies (CCL and others to come) on the App Layer that are able to quote a fairly large size at the current ask price or very close to it.
• The fee for AMM strategies on RUJI Trade is 0.025% (with RUJI Trade v1.2, we have created a separate fee tier for AMM strategies currently set at 2.5bps).
• The amm fee is charged on both sides of the trade when the VS quote is matched with other AMM quotes, but the illustrative ask price from non-VS strategies is already net of the 2.5bps on the non-VS side.
• The liquidity fee for secured asset swaps on the Base Layer (SecuredAssetSlipMinBps) is 10 bps, so for a two-leg swap such as BTC<>RUNE<>USDC, the total Base Layer fee would be 0.20%.
• The VS targets a 0.10% profit (`reserve fee`) above the Base Layer price.

That means there is a total cost of 0.325% for an arbitrage, meaning we need a price deviation greater than 0.325% for the VS to quote at a price that overlaps the quotes from other strategies and triggers an arbitrage. In our example, the price deviation is 0.40%, so there is a 0.075% net profit to capture as protocol revenue on top of the 10bps captured by the VS. In that situation, the flow of funds would be:

1. The VS quotes to buy (bid) quantity X BTC at Base Layer pool price minus 32.5bps (20bps liquidity fee for the Base Layer + 2.5bps AMM fee + 10bps target profit).
2. Other AMM strategies on the App Layer quote to sell (ask) quantity Y BTC at 40bps below Base Layer pool price.
3. The onchain scheduler matches the overlapping orders with quantity MIN(X, Y) and captures 7.5bps of arbitrage profits as protocol revenue + 2x 2.5bps AMM fee.
4. The VS borrows the corresponding USDC amount from the Lending Vault and uses it to fill the quote on the App Layer side, receiving MIN(X, Y) BTC minus 2.5bps AMM fee.
5. The VS injects a swap request into the swap queue to sell the acquired BTC for USDC on the Base Layer at the inflated price minus 0.20% liquidity fee.
6. At the start of the following block, the VS uses the proceeds from the Base Layer swap to repay the USDC loan.
7. The VS keep the balance (~0.10%) as profit.

Because the arbitrage will be automatically executed at the end of each block, it won’t let the prices of the Base Layer pools drift away over several blocks as it is often happening at the moment. The matching of orders will be executed as soon as the price deviation is greater than the total cost, likely with an arbitrage profit lower than the 7.5bps in our example in many cases. This should result in better average execution prices for THORChain’ users.

This will become particularly interesting once we add the Dynamic Liquidity Strategy (DCL) strategies, a new highly capital efficient AMM strategy that will be able to quote fairly large sizes very close to the enshrined oracle price, This means the price on RUJI Trade orderbook should always be very close to the market price (at least on one side of the book), which means that arbitrages between Base Layer and App Layer will always be resetting the price of the Base Layer pools closer to the market price. This also means that the App Layer liquidity will automatically be used to partake in “pure arbitrage” volumes, per our earlier classification.

Now, imagine that the total swap size is 1m USDC for BTC, and THORChain has broken down the execution of that swap into 1,000 sub-swaps of 1,000 USDC each, streamed over ~1 hour. The upgraded version of the VS should be able to quote a bid for the full $1m equivalent in BTC as quantity X, and if we can scale the liquidity on the App Layer so that there is an equivalent ~$1m quantity Y on the ask side, then the Base Layer swap could be fully executed in a single block instead of 1 hour. The VS would inject the full swap size into the swap queue, and with rapid swap, the two opposite orders would be matched in the same block. Even with less liquidity, we can do partial matching and increase settlement time for Base Layer swaps.

All of the above can be done with smart contracts and liquidity on the App Layer, without requiring any change to the Base Layer. THORChain’s quotes will directly benefit from Base Layer pools being more accurately priced, without requiring changes to the API. However, we will need to work with Nine Realms to find a way factor in the impact of the App Layer liquidity on settlement speed.

Looking into the data

Ignoring the constraint of how much liquidity is available on the App Layer, the potential price improvement for THORChain is still difficult to quantify as it would require comparing price impact inside one block vs. price deviation over several blocks and we don’t have that level of data granularity. However, looking at 1-minute candles, we observe deviations >0.40% happening over 30% of the time, with deviation exceeding 1% happening ~7% of the time. With this new liquidity model, the Base Layer prices should be brought back towards the market price (as measured by the enshrined oracle) every block, preventing such large deviations from happening.

We analysed a sample of 8 high-volume pairs, looking at 1-minute candle based on actual THORChain swaps data between 30-Sep-2025 and 10-Nov-2025 (~40 days), equivalent to ~57k datapoints per pair. We compared the close of the THORChain Base Layer candle price to the enshrined oracle price at the time of the close.

The below charts show the distribution of absolute price deviation over the period for a selection of pairs (BTC/USDT, ETH/USDC, BNB/USDC and BSC.USDT/USDC).

We summarised the data in more detail in the below tables, looking at the distribution of Absolute Price Deviation and Estimated Net Arbitrage Profit by percentile. The arbitrage profits are estimated using the same 0.325% cost assumption as in the example above, plus adding another 0.025% to cover the AMM fee for the DCL strategy + a 5bps spread for LPs providing liquidity, bringing the minimum required price deviation to 0.40% to have an arbitrage.

The first table shows an average price deviation of ~0.40% across the sample, which is coincidentally the threshold above which profitable arbitrage opportunities arise per our trading costs assumptions. The average deviation at the 90th percentile stands at ~1.23%, meaning there are high profit arbitrage opportunities roughly 10% of the time. We can also observe that deviations are overall fairly consistent across pairs, with an average in the 0.3-0.5% range, and with higher volume tokens and stablecoins (BTC, ETH, RUNE and BSC.USDT) at the lower end of that range.

The second table shows the distribution of estimated profit per arbitrage within the subset of profitable opportunities. Profitable opportunities tend to arise ~32% of the time across the sample, with again lower frequency on higher volumes pairs, signalling more competition and better trading conditions on those. The median profit across the sample is at ~0.26% while the average stands at ~0.50%, indicating disproportionate upside as we move towards the tail of the range.

Quantifying the opportunity

Looking at historical THORChain volumes, we can use the share of Trade Assets volumes as a proxy for arbitrage volumes, the underlying assumption being that Trade Assets are mostly used by arbitragers. Trade Assets have consistently represented ~60% of total THORChain volumes.

Looking at the last 6 months, total THORChain volumes have been at ~$1.4bn average per month, of which ~58% have been estimated arbitrage volumes, so ~$0.8bn per month. Assuming an average profit of ~0.35% per arbitrage (taking the midpoint between the median and the average of the sample), that’s an estimated ~$2.9m of arbitrage profits captured every month. That’s the total size of the opportunity based on current volumes and price deviations.

If we were to internalize part of that, we would execute those arbitrages much more frequently, targeting a lower average price deviation to pass on some of those gains to end users and make THORChain pricing more competitive. Let’s assume we target ~0.175% profit per arbitrage (of which ~0.10% from the VS margin and 0.075% from arbitrage between the VS and the other AMM strategies on the App Layer per our earlier example).

There will also be a constraint on the App Layer liquidity side that will limit the share of arbitrages the App Layer can capture (the more TVL in AMM strategies and in the Lending vaults required by the VS to quote, the more arbitrage volumes can be processed on RUJI Trade).

There might also be external arbitragers able to price more aggressively (e.g. because they have access to lower fees and better liquidity on some CEX) that will continue to capture a share even if liquidity on the App Layer wasn't a constraint.

Assuming ~$1.4bn in monthly volumes, assuming Rujira capture somewhere between 10% (low) to 50% (high) of the total arbitrage volumes, and targeting an average net arbitrage profit of ~0.175%, that would be ~$140k to $720k of additional monthly revenue from arbitrage profits. The portion coming from arbitrage between the VS and other AMM strategies will be distributed as protocol revenue, and the portion coming from the VS reserve fee will be retained inside the contract and periodically be sent to the Ecosystem Fund to build protocol-owned liquidity, which in turn will allow to facilitate more volumes and fees.

Rujira will also accrue value from the 2.5bps AMM fee charged on each side every time orders from the VS are matched with orders from other AMM strategies. This could represent another $40k to $210k in monthly revenue on top of any arbitrage profits, bringing the total to ~$190k to $925k per month.

THORChain will accrue value from the 10bps per leg liquidity fee charged to the VS (`SecuredAssetSlipMinBps`) which could represent $160k to $820k revenue per month based on the above scenarios.

Disclaimer: Those estimates are for illustration only, based on assumptions that may not prove to be accurate, and actual results may differ materially from those outlined here. Don’t make decisions based on that, do your own research and make your own assessment.

A balancing act

There are four levers we will be able to play with to further improve arbitrage efficiency and pricing of Base Layer pools:

• THORChain’s `SecuredAssetSlipMinBps`, the minimum liquidity fee paid on Base Layer swaps, controlled by THORChain Node Operators via Mimir vote and assumed at 10bps for each leg. This is half of the arbitrage costs in our assumptions and could easily be halved. SlipMinBps for Trade Assets was set at 5bps for most of THORChain history. Once the pieces are in place, we would encourage THORChain to experiment with lowering the `SecuredAssetSlipMinBps`and monitor the impact on volumes and Base Layer prices.
• Virtualization Strategy reserve fee, currently set at 10bps. The current pricing algorithm of the VS is fairly naive, it doesn’t take into account the pending swaps in the swap queue, meaning we need to factor in some extra margin in case other swaps inside the block lead to a worse than expected outcome. Once we upgrade the VS, we could lower this parameter.
• RUJI Trade AMM fee, currently set at 2.5bps. Once we will have set a baseline, we will be able to play with this parameter to see if further lowering the value leads to sufficient additional volumes to offset the impact on protocol revenue (will need to be determined empirically).
• LP fees, for LPs providing liquidity at a price very close to the oracle price. We have assumed 0.05% for the oracle-based market making strategy but this could be lowered if the increase in volumes more than compensate for the loss of revenue per unit of volume (same as above). There will also be liquidity from Custom Concentrated Liquidity (CCL) strategy available to arbitrage against, so it’s likely that the arbitrage contract will be able to source liquidity at a better price than 0.05% from oracle on average.

There will be a lot of surface to test various parameters and try to find an optimum between volumes, Base Layer pricing and revenue.

Next steps

To get started, we need:

• The current version of the VS ⇒ Already live; and quote sizes will increase as the liquidity in the Lending vaults increases.
• Custom Concentrated Liquidity (CCL): Similar to Uniswap v3 model, allowing users to provide liquidity for a given pair in a custom range with a custom level of fee and spread. ⇒ Already live testing on mainnet for RUNE/BTC and wBTC/BTC pairs, it will allow us to get started with arbitrages.
• Enable automatic arbitrage between various liquidity sources on RUJI Trade using the onchain scheduler ⇒ Live testing since this morning for RUNE/BTC.

There are other key items that we will need to be tackled to achieve the full vision:

• Getting two more types of concentrated liquidity strategies live. DCL in particular will be key to keep prices more aligned with “true” market price and allow the App Layer to partake into “pure arbitrage” when market prices deviate from pool price due to external market movement:
  • Dynamic Concentrated Liquidity (DCL): Novel automated market making strategy that will use tracking orders to provide liquidity tightly around the enshrined oracle price.
  • Average Down / Profit Up (ADPU): Another novel automated market making strategy, tracking individual users Average Entry Price (AEP), progressively averaging down when the strategy is under water and taking profit when current price is above AEP.
• Upgrade the Virtualization Strategy to allow it to size its quotes more accurately.

Once we have those building blocks in place, we will work with Nine Realms to upgrade the Base Layer quote API to reflect the impact of App Layer liquidity on execution time for a given size.

Closing thoughts

Using the Virtualization Strategy to internalize part of the arbitrage volumes and profits is a very exciting opportunity that could make a material difference in terms of revenue for Rujira. It provides a path for THORChain to scale liquidity again and do it with more capital efficient strategies, and without reflexivity to RUNE price.

This should meaningfully improve pricing and settlement time for Base Layer swaps and allow THORChain to quote more aggressively.

It showcases the synergistic alignment between THORChain and Rujira beyond revenue sharing, where the activity on the App Layer benefits the operation of the Base Layer. This is a new liquidity model for THORChain. This is how the App Layer can support the Base Layer competitiveness and help THORChain win.