If you've watched a pair that trades both on Binance's spot order book and in a Binance Liquidity Swap pool, the price gap between them is the obvious thing to chase. That gap is only part of the economics. Every hedge moves the pool's price, and the pool pays BNB incentives on conversion volume, so the gap alone won't tell you whether a cycle pays.
One of our trading strategies trades exactly this setup. Instead of folding everything into one number, we handle each piece at its own stage:
- A research threshold priced fees, pool impact and slippage before we traded.
- The engine sizes quotes by pool capacity and hedges each fill in the pool.
- Reports add rewards to realized trading PnL, and tuning uses that reward-inclusive result to adjust allowed impact and maker spread.
Each contribution stays visible along the way, which is what lets you tell whether the trading leg or the incentives are doing the work. Here's how each stage works and why we built it that way.
Two markets, one cycle
The strategy pairs a maker order on an order book with a hedge in a conversion pool. The book offers maker pricing, and the pool offers a quoted conversion price that moves with size.
What Liquidity Swap means here
Liquidity Swap is Binance's pool-conversion product. You convert one asset into another against a pool that holds base and quote liquidity, charges a swap fee and distributes BNB incentives.
It has nothing to do with perpetual swaps. There's no funding rate and no margin borrowing, so a position can't exceed the assets you hold. Whenever this article says "swap", it means a conversion in a pool.
How a cycle runs
The cycle has two legs. Leg 1 is a resting limit order on spot, so it fills as a maker. Leg 2 is an immediate pool conversion that hedges that fill, so the hedge always executes after the maker fill, never before it. Our trading engine runs the cycle like this:
- Quote the spot maker order, sized to what the pool can absorb, while inventory sits at its target.
- A fill pushes inventory away from the target.
- Withdraw the maker quotes and hand a rebalance instruction to the hedge leg.
- Convert in the pool until the target is restored, then resume quoting.
If you've built book-to-book arbitrage, this will look familiar. It's the same maker-then-hedge pattern we use elsewhere in market making and arbitrage, with a pool sitting on the hedge side instead of a second order book.
When the hedge is feasible
The pool quotes a price for any conversion, but a quote isn't the same as a usable hedge. The hedge is feasible only when the trade fits the pool, which means all of these have to hold:
- The pair has an eligible pool that our selection step kept.
- The pool holds enough liquidity for the size.
- The size falls between the pool's minimum and maximum conversion amounts.
- The resulting price impact stays within our allowed limit.
Checking these only after a maker fill is too late to control the quote that produced it. They have to shape its price and size before posting, which is where pair selection and sizing come in.
Sizing the quote for the hedge before posting it
Not every spot pair has a pool, and not every pool can absorb the size you'd like to trade. That's why selection and sizing happen before a quote goes out, so the quoted size is one the pool should be able to hedge.
Which pairs qualify
Our selection step joins spot tickers to pools by pair and carries each pool's liquidity into the output, so every candidate arrives with its depth attached. Depth is part of the candidate's identity from the start, rather than something checked after a fill. Two optional filters can then remove pools from the set:
- Wrapped assets, by default BETH, WBTC and BDOT.
- Pairs where both sides are stablecoins, by default drawn from USDT, BUSD, TUSD, USDC and DAI.
These are switches rather than fixed rules, so a given run can keep either group in.
How much the pool can take
Maker size is capped by what the pool can absorb within an allowed impact. The estimate takes pool base liquidity, adds quote liquidity converted to base at the ask, multiplies by the configured maximum impact and divides by two:
cap = (base liquidity + quote liquidity / ask) × max impact / 2
The cap scales with pool depth and with how much price movement we're willing to accept. Pools also enforce minimum and maximum conversion amounts. Maker sizing respects both and applies a 0.998 capacity factor, leaving a small margin below the pool's limit.
The minimum matters as much as the maximum. We test a spot maker against a pool instrument specifically for hedge-side minimum sizing, because a maker fill below the pool minimum would leave inventory we can't convert. The quote has to be large enough for the hedge as well as small enough for the pool.
What the spread has to cover
Before trading the strategy, we estimated the spread it would need as a sum of costs. That threshold covered fees, impact and slippage; BNB rewards weren't part of it.
Costs in basis points
Costs here are in basis points. One basis point is 0.01%, so 15 bp of modeled cost means 0.15% of the trade amount, or $1.50 on a $1,000 trade. Our NEAR/USDT research in May 2022 used these assumptions:
- 3 bp spot maker fee
- 6 bp swap fee
- 2 bp pool impact
- 4 bp swap slippage
They add up to 15 bp. The research's threshold expression added 1 bp of gain for a 16 bp threshold, while the separate parameter-search helper used a 2 bp minimum-gain default, giving 17 bp.
Prices for each leg
The model priced long and short directions with separate ratios, and chose bid or ask for each leg by its role: the resting maker order on one side, the immediate hedge on the other.
Both directional cost expressions use the spot maker fee, which matches a limit-order entry. A taker fee is defined alongside it but doesn't enter the formula. Rewards don't enter it either; they reach our decisions later, through reports and tuning.
Reconstructing what actually happened
A threshold is a forecast. Our reports rebuild the realized cycle from both trade histories, using the normalization and report pipeline described in trading data and reconciliation. The loader pulls spot fees, including maker rebates and BNB discounts, separately from pool fees, pool rewards and quote prices, so no single flat rate hides venue differences.
Merging the two streams
The report merges spot and pool executions in time order into one trade flow. Spot rows get zero pool rewards, because incentives come only from the pool side. Pool trade IDs become the shared trade-ID field, and USD volume stays split by venue.
Keeping spot and pool volume apart is what makes the later imbalance checks possible.
Sequence and imbalance checks
The expected rhythm alternates: a spot maker fill, then a pool hedge, then the next fill. Two adjacent rows from the same venue get flagged as a sequence error. That flag is a diagnostic only, since a clean alternating sequence doesn't prove each fill was hedged at the right size.
The pivot reports add further execution-quality fields across bots and markets:
- Spot/pool trade-count imbalance.
- Sequence-error percentage.
- Spot/pool volume imbalance.
- Our share of the venue's spot volume.
Like the sequence flag, these fields show where to look rather than what happened. Volume imbalance says spot and pool volumes diverged, not which fill went unhedged or what the leftover position is worth.
Timestamps
Two executions can share a timestamp, which breaks a time-indexed table. The report advances duplicates in 1 ms steps until each index value is unique.
The adjusted index exists only so the table can stay indexed by time. Any claim about timing or latency uses the original execution timestamps.
Trading PnL, rewards and residual inventory
Once the flow is reconstructed, the report splits the economics into separate streams before combining them. Inventory that hasn't been closed sits outside those streams and needs its own treatment.
How trading PnL is realized
Trade size is signed: positive for buys, negative for sells. The accumulator realizes PnL only when a trade reduces the current position, valuing the closing quantity against a stored position price. PnL is quote-denominated and converts to USD at a supplied quote/USD rate.
Our historical convention updates that stored price after every trade, additions and reductions alike, weighting by absolute trade amounts. A standard average-cost ledger changes the cost basis only when a trade adds to the position, keeps it unchanged on a partial close and resets it on a reversal.
So our per-bot trading PnL follows our report convention, not a standard average-cost figure. Because reductions also move the stored price, a bot's reduction history can affect its reported PnL, and comparisons between bots carry that caveat. The example below uses plain arithmetic instead, so every step stays visible.
Rewards and the basis-point view
BNB rewards accumulate in their own column. Reward-inclusive PnL is cumulative trading PnL plus cumulative BNB reward value, with a USD version alongside. Two ratios normalize these by spot USD volume and express them in basis points:
pnl/v: trading PnL alone.sum/v: the reward-inclusive total.
Pool volume is tracked separately and never used as the denominator. Every pair is measured per dollar of spot volume, the leg we actually quote.
Residual inventory
When a fill isn't fully hedged, part of the position stays open. That exposure still carries unrealized gains or losses as prices move, even though the realized trading-PnL accumulator hasn't recognized them. Rewards don't offset it either, so neither pnl/v nor sum/v reflects it until the position closes.
Volume imbalance flags that open exposure may exist. It isn't an exact hedge matcher, and it doesn't value the position. Reading a pair's report means checking imbalance first, then valuing any material residual separately before treating the totals as complete.
A synthetic example
Here are invented numbers for one pair over one reporting period, all in USD: $10,000 of spot volume, -$2 of trading PnL and $5 of BNB reward value. We'll assume the legs matched and no residual inventory needs valuing, so the report's realized figures cover this period.
Trading PnL per spot volume is -2 / 10,000 × 10,000 = -2 bp. Rewards contribute 5 bp. The reward-inclusive result is $3, or 3 bp.
trading PnL -2 bp ██ (below zero)
BNB rewards +5 bp █████
total +3 bp ███
The split says the trading leg loses and incentives carry it, which is exactly what you'd lose by storing only the sum.
From NEAR/USDT research to the tuning loop
The research gave us a threshold to start from. The reports and the tuning step tell us how to move it.
The research case
For the May 3-4, 2022 study, we pulled NEAR/USDT spot quotes and the matching pool quotes, aligned the two streams in time and ran our bid/ask model with leg 1 as a limit order and leg 2 as a market conversion.
Anything that study produced belongs to that pair, those two days and those cost assumptions. Projecting it into a return figure would need a reconciled operating statement for a defined period.
Where rewards enter
Rewards don't price individual quotes inside the engine. The engine sizes quotes from pool capacity and conversion limits, posts them at its configured maker spread and hedges each fill in the pool. Rewards reach those settings through a chain:
- The research threshold models maker fees, pool fees, impact and slippage.
- Reports add BNB reward value to realized trading PnL.
- Tuning reads each pair's reward-inclusive
sum/v. - Tuning proposes allowed-impact or maker-spread settings for the engine.
The engine executes settings; the economics behind those settings come from the reports.
One tuning decision
Our tuning notebook reads each pair's sum/v and proposes changes to two settings: allowed impact and maker spread. It works through the pairs in this order:
- Pairs inside the target band stay unchanged.
- Weak pairs get lower allowed impact where that's possible.
- Otherwise, the maker spread widens.
Take the synthetic pair at 3 bp and suppose that falls below the band. The first move lowers allowed impact. Through the sizing cap, that shrinks orders, so each hedge moves the pool less.
That's the tradeoff tuning has to weigh. Smaller orders also mean less incentive-bearing volume, while larger ones earn more rewards but consume more pool depth.
Checking the result
The report measures trading and reward contributions in the same basis-point units, which makes that tradeoff visible per pair. The next step we're building is a routine comparison between the change we expected and what the following reports show, so each adjustment either confirms the reasoning or sends us back to it.
Where to start with your own pair
If you're running or evaluating a similar book-to-pool setup, start with the split rather than the sum. Rebuild a pair's cycles from both trade histories, then check:
- Spot and pool volume imbalance, before trusting any total.
- Trading PnL and BNB rewards per spot volume, as separate basis-point figures.
- Whether your quoted sizes clear the pool's minimum as well as its impact cap.
Once those checks are in place, impact and spread become settings you can tune deliberately. Our reconciliation pipeline write-up covers how the reports are built, and the maker-then-hedge pattern article shows what this engine shares with our other strategies.