Drift Protocol Funding Rate Arbitrage: A Solana Perp Bot Guide
Build a Drift funding rate arbitrage bot on Solana: DLOB vs vAMM funding mechanics, hourly settlement math, delta-neutral hedging, and the gotchas that eat your edge.
Drift pays funding every hour, not every eight, and that single fact changes how you build a bot around it. On most perp venues you collect or pay funding three times a day, so a mispriced funding rate has hours to persist before it settles. On Drift, the clock runs 24 times faster, the rate is recomputed continuously from the mark-vs-oracle spread, and settlement happens through the protocol's settle_funding path rather than a bilateral transfer between longs and shorts. If you're used to CEX-style funding capture, you have to unlearn a few assumptions before the numbers work out.
This post is about capturing that funding, not about the cross-venue atomic arb we covered in the Drift CLOB and AMM piece — different edge, different failure modes. Here the trade is simpler in shape and nastier in execution: hold a delta-neutral position, collect funding on the perp leg, and don't let fees or slippage on the hedge eat the spread.
How Drift funding actually works
Drift runs a hybrid: a decentralized limit order book (the DLOB) filled by keepers, and a fallback virtual AMM (vAMM) that always quotes. Funding is derived from where the mark price sits relative to the oracle. Specifically, Drift tracks a time-weighted average of the mark premium over the funding period and divides by 24 to get an hourly rate:
funding_rate_hourly = twap(mark - oracle) / oracle / 24
The mark used here is the vAMM's price, which drifts (no pun) as the reserves get pushed by fills. When the perp trades rich to spot, longs pay shorts. When it trades cheap, shorts pay longs. The rate is capped — Drift clamps the hourly funding to a bound tied to the maintenance margin ratio, so you can't assume an insane premium will pay out linearly. On SOL-PERP that cap has historically sat around a few basis points per hour, which annualizes to something large but not unbounded.
Two things that bite people:
- Funding is on the base asset amount, quoted against the oracle, not against your entry. Your PnL from funding is independent of whether the position is up or down. Good — that's the whole point of delta-neutral.
- You only realize funding when it's settled. Unrealized funding accrues in your position's
last_funding_ratebookkeeping, but it doesn't hit your collateral until a keeper or your own bot calls settle. If you close before settling, the AMM nets it into your realized PnL, but you want to be explicit about when that happens.
The trade, concretely
Say SOL-PERP is trading at a persistent +0.008% hourly premium (longs pay shorts). You want to be the short that collects. But a naked short is directional, so you hedge the delta with spot SOL — buy the equivalent notional on Jupiter or Orca. Now you're flat on price and long the funding stream.
Worked example, $50k notional:
- Short 250 SOL-PERP at $200. Funding: 0.008%/hr × $50k = $4/hr, roughly $96/day gross.
- Hedge: buy 250 SOL spot. This costs a swap fee (~0.05–0.30% depending on route) plus price impact.
- Your break-even horizon is set by how long the funding takes to repay the round-trip hedge cost. At 0.10% total spot cost, that's $50/entry — recovered in about 12–13 hours of funding at the assumed rate.
That break-even math is the entire game. Fast funding is only an advantage if the rate stays positive long enough to clear your fixed entry costs. Rates on Drift mean-revert quickly precisely because funding is hourly, so a premium that looks juicy at snapshot time often decays before you've earned back the hedge. I size entries against a TWAP of the last several hours of funding, not the instantaneous rate.
Watching the rate without getting rate-limited
Pull funding from Drift's on-chain state via the TypeScript SDK's DriftClient and the perp market account's amm.lastFundingRate and amm.lastFundingRateTs. Don't poll the RPC every block for this — funding only updates once per hour per market, so a 60-second poll with a websocket account subscription on the market accounts is plenty. If you're running a fleet of these across markets, the account-subscription fan-out is where your RPC bill lives, and it's worth reading our notes on stake-weighted QoS and transaction priority before you pick a provider, because settle transactions during volatile funding windows compete with everyone else's.
const market = driftClient.getPerpMarketAccount(marketIndex);
const rate = market.amm.lastFundingRate; // scaled, BN
const oracle = driftClient.getOracleDataForPerpMarket(marketIndex).price;
const hourlyPct = rate.toNumber() / oracle.toNumber() / FUNDING_RATE_BUFFER;
Mind the scaling constants — Drift stores funding pre-scaled by a buffer precision, and getting the divisor wrong by an order of magnitude is the classic first-day bug that makes you think you found a 10x edge.
Where the edge leaks
The gross funding looks clean. The net rarely is. In order of how much they hurt:
- Hedge slippage and rebalancing. Your spot hedge and your perp drift out of delta as price moves and as you get partially filled. Every rebalance is another swap fee. Keep a delta band (say ±2% of notional) and only rebalance on breach, not on a timer.
- Perp taker fees on entry/exit. Taking liquidity off the DLOB costs. If you can rest maker orders and get filled by keepers, you flip that fee to a rebate, which materially changes break-even. Passive entry is slower but it's the difference between a strategy that clears costs and one that doesn't.
- Settle transaction cost and inclusion. Each
settle_fundingis a Solana transaction with priority fees. During a funding spike everyone's keepers and bots are hammering the same market, and dropped or delayed transactions are real — the mechanics in our QUIC throttling and transaction drops writeup apply directly. - Oracle staleness and liquidation. Delta-neutral doesn't mean liquidation-proof. Your perp leg has its own margin. A stale or lagging oracle can spike your maintenance requirement independently of your spot hedge, and the vAMM's mark can dislocate from spot during thin books.
Because funding flips sign fast, the biggest structural mistake is treating this as a set-and-forget carry. It's an active position. You're continuously deciding whether the current funding TWAP still clears your marginal cost of holding, and unwinding when it doesn't. Bots that hold through sign flips give back a week of collection in a day.
Building blocks worth reusing
The plumbing here overlaps heavily with other Solana perp and execution bots. The delta-neutral hedge leg is essentially a small market-making loop that keeps two venues balanced, and the settle/priority-fee side is the same infrastructure problem as any latency-sensitive Solana bot. If you're standing up the RPC, account-subscription, and transaction-landing layer, our low-latency Solana infra and data work is built for exactly this class of workload, and the MEV and arbitrage bot service covers the cross-venue hedging execution end to end.
If you want a Drift funding bot that actually nets positive after fees rather than one that looks great in a backtest and bleeds live, that's the kind of build our team ships.
Need a bot like this built?
We design, build and run trading bots on Solana, Hyperliquid and Polymarket.
Start a projectMore from the blog
Public vs Paid RPC: How to Run a Fair Benchmark
A fair comparison of public and paid RPC endpoints must account for quotas, workload, freshness and support guarantees.
Read articleRPC Benchmark Percentiles Explained: p50, p95 and p99
Why averages hide the latency spikes that break trading bots, wallets and production blockchain applications.
Read articleHyperliquid REST vs WebSocket Benchmark: What to Measure
A benchmark plan for Hyperliquid market data that separates request latency from streaming freshness and recovery.
Read article