JIT-only MM

JIT-only market making means you do not keep a standing book. Instead of resting limit orders on the DLOB, you compete in JIT auctions (see Matching Engine for liquidity sources) by reacting to incoming taker orders in real-time.

Why JIT-only?

• No adverse selection from stale quotes: you only commit capital when you choose to fill
• Selective flow: you inspect each taker order and decide if it’s profitable to fill
• Capital efficiency: no capital locked in resting orders that may never fill
• Dynamic pricing: price each fill based on current oracle, inventory, and market conditions

Tradeoff: You need lower-latency infrastructure than DLOB MM (to react within the auction window), and you may miss fills in fast markets if your bot is slow.

Architecture overview

A JIT-only bot follows this loop:

Subscribe to auctions / orders

The AuctionSubscriber gives you a stream of active JIT auctions. Use commitment: "processed" for lowest latency.

import { AuctionSubscriber } from "@velocity-exchange/sdk";

import { AuctionSubscriber } from "@velocity-exchange/sdk";
 
const auctionSubscriber = new AuctionSubscriber({
  velocityClient,
  opts: { commitment: "processed" },
});
await auctionSubscriber.subscribe();

For even lower latency, subscribe to SWIFT to receive signed taker orders 100-500ms before they land onchain.

OrderSubscriber is a lower-level alternative to AuctionSubscriber. It streams all user order state changes rather than only active auction events. Most JIT bots use AuctionSubscriber because it surfaces only the orders that are currently in an open auction window. Use OrderSubscriber if you need visibility into the full lifecycle of orders (e.g., tracking when orders are placed, partially filled, or cancelled) rather than just reacting to active auctions.

import { OrderSubscriber } from "@velocity-exchange/sdk";

Compute auction prices (helpers)

Use getAuctionPrice to compute the current interpolated auction price at any slot. This tells you the worst price the taker would accept right now, so you need to offer a price at least this good.

import { getAuctionPrice, convertToNumber, PRICE_PRECISION } from "@velocity-exchange/sdk";
 
const currentSlot = await connection.getSlot();
const oracle = velocityClient.getOracleDataForPerpMarket(marketIndex);
const perpMarket = velocityClient.getPerpMarketAccount(marketIndex);
 
// Get the current auction price at this slot. Always pass the market's tick size
// (orderTickSize) -- it defaults to no rounding, which disagrees with the program's
// own price standardization on any market with tick_size > 1.
const auctionPriceBN = getAuctionPrice(takerOrder, currentSlot, oracle.price, perpMarket.orderTickSize);
const auctionPrice = convertToNumber(auctionPriceBN, PRICE_PRECISION);
 
console.log(`Auction price at slot ${currentSlot}: $${auctionPrice.toFixed(4)}`);

See JIT Auctions - Auction pricing for the full interpolation formula, and Orderbook & Matching - Tick size for why the tick size argument matters.

Fill as maker (atomic place-and-make)

This pattern places your maker order and fills against the taker in one transaction. You earn maker rebates and the taker gets filled, all atomic.

import {
  OrderType,
  PositionDirection,
  PostOnlyParams,
} from "@velocity-exchange/sdk";
 
// Build your maker order (opposite direction of taker)
const makerOrderParams = {
  orderType: OrderType.LIMIT,
  marketIndex: takerOrder.marketIndex,
  direction: PositionDirection.SHORT, // if taker is LONG
  baseAssetAmount: takerOrder.baseAssetAmount,
  price: velocityClient.convertToPricePrecision(myFillPrice),
  postOnly: PostOnlyParams.MUST_POST_ONLY,
};
 
// takerInfo: includes taker's public keys, user account, and the order to fill
const takerInfo = {
  taker: takerPubkey,                 // PublicKey of taker's user account PDA
  takerStats: takerStatsPubkey,       // PublicKey of taker's UserStats PDA
  takerUserAccount: takerUserAccount, // decoded UserAccount data
  order: takerOrder,                  // the specific Order to fill against
};
 
await velocityClient.placeAndMakePerpOrder(makerOrderParams, takerInfo);

Complete fill loop

Here’s a more complete example that ties the pieces together:

import {
  AuctionSubscriber,
  getAuctionPrice,
  getUserStatsAccountPublicKey,
  isSignedMsgOrder,
  isOracleValid,
  isVariant,
  convertToNumber,
  PRICE_PRECISION,
  BASE_PRECISION,
  OrderType,
  PositionDirection,
  PostOnlyParams,
} from "@velocity-exchange/sdk";
 
const MAX_POSITION = 100; // max 100 SOL position
const MIN_SPREAD = 0.02;  // minimum $0.02 edge required
 
const auctionSubscriber = new AuctionSubscriber({
  velocityClient,
  opts: { commitment: "processed" },
});
await auctionSubscriber.subscribe();
 
// Listen for auction events instead of polling
auctionSubscriber.eventEmitter.on("onAccountUpdate", async (takerUserAccount, pubkey, slot) => {
  for (const order of takerUserAccount.orders) {
    if (order.baseAssetAmount.isZero() || order.baseAssetAmount.eq(order.baseAssetAmountFilled)) continue;
    const userAccount = takerUserAccount;
 
    // Skip SWIFT orders if handling them via SwiftOrderSubscriber
    if (isSignedMsgOrder(order)) continue;
 
    const marketIndex = order.marketIndex;
    const perpMarket = velocityClient.getPerpMarketAccount(marketIndex);
    const oracle = velocityClient.getMMOracleDataForPerpMarket(marketIndex);
 
    // Check oracle validity. Note: MMOraclePriceData has no `isValid` field -- use the
    // `isOracleValid` AMM-fill-oriented validity gate against the market's guard rails.
    const oracleIsValid = isOracleValid(
      perpMarket,
      oracle,
      velocityClient.getStateAccount().oracleGuardRails,
      slot
    );
    if (!oracleIsValid) continue;
 
    // Check position limits
    const user = velocityClient.getUser();
    const position = user.getPerpPosition(marketIndex);
    const currentSize = position
      ? Math.abs(convertToNumber(position.baseAssetAmount, BASE_PRECISION))
      : 0;
    const fillSize = convertToNumber(order.baseAssetAmount, BASE_PRECISION);
    if (currentSize + fillSize > MAX_POSITION) continue;
 
    // Get current auction price (use slot from the event, not an RPC call).
    // Pass the market's tick size so this matches the program's own rounding.
    const auctionPriceBN = getAuctionPrice(order, slot, oracle.price, perpMarket.orderTickSize);
    const auctionPrice = convertToNumber(auctionPriceBN, PRICE_PRECISION);
    const oraclePrice = convertToNumber(oracle.price, PRICE_PRECISION);
 
    // Calculate our fill price (oracle + small edge)
    const takerIsLong = isVariant(order.direction, "long");
    const edge = MIN_SPREAD;
    const myFillPrice = takerIsLong
      ? oraclePrice + edge   // sell to long taker above oracle
      : oraclePrice - edge;  // buy from short taker below oracle
 
    // Check if our price is within the auction range
    const isCompetitive = takerIsLong
      ? myFillPrice <= auctionPrice
      : myFillPrice >= auctionPrice;
 
    if (!isCompetitive) continue;
 
    // Fill!
    try {
      await velocityClient.placeAndMakePerpOrder(
        {
          orderType: OrderType.LIMIT,
          marketIndex,
          direction: takerIsLong ? PositionDirection.SHORT : PositionDirection.LONG,
          baseAssetAmount: order.baseAssetAmount.sub(order.baseAssetAmountFilled),
          price: velocityClient.convertToPricePrecision(myFillPrice),
          postOnly: PostOnlyParams.MUST_POST_ONLY,
        },
        {
          taker: pubkey,
          takerStats: getUserStatsAccountPublicKey(velocityClient.program.programId, userAccount.authority),
          takerUserAccount: userAccount,
          order,
        }
      );
      console.log(`Filled ${fillSize} @ $${myFillPrice.toFixed(4)}`);
    } catch (err) {
      console.error("Fill failed:", err);
    }
  }
});

Practical filters

Apply risk and filtering checks before filling: oracle validity, position limits, toxic-flow detection, and (if you use both feeds) skip Swift-origin orders via isSignedMsgOrder() so you don’t double-handle. See Bot Architecture - Risk and filtering for shared patterns and code.

import { isSignedMsgOrder } from "@velocity-exchange/sdk";
 
// In your AuctionSubscriber callback, skip orders that came from SWIFT
// so your onchain handler and SWIFT handler don't both try to fill the same order.
auctionSubscriber.eventEmitter.on("onAccountUpdate", async (userAccount, pubkey, slot) => {
  for (const order of userAccount.orders) {
    if (order.baseAssetAmount.isZero()) continue;
 
    if (isSignedMsgOrder(order)) {
      // Already handled via SwiftOrderSubscriber callback -- skip here
      continue;
    }
 
    // Handle regular onchain auction
    await handleAuction(order, userAccount, pubkey, slot);
  }
});

getMMOracleDataForPerpMarket is the recommended oracle getter for market makers: it returns the dedicated MM oracle price when it’s active, fresh, and close enough to the exchange oracle, and transparently falls back to the exchange oracle otherwise. It has no isValid field — that’s not part of MMOraclePriceData. It does carry isMMOracleActive (whether the market has an MM oracle configured at all — not a full validity signal) and confidence. For an actual go/no-go validity check, use isOracleValid(market, oracleData, oracleGuardRails, slot) from math/oracles, which is the same AMM-fill-oriented gate the program itself uses for confidence, staleness, and volatility.

Key fields:

• oracle.price: current oracle price as a BN in PRICE_PRECISION (1e6) units
• oracle.isMMOracleActive: whether this market has a live MM oracle feed (not a validity signal on its own)
• oracle.confidence: price confidence interval, BN in PRICE_PRECISION (1e6) units

import { convertToNumber, isOracleValid, PRICE_PRECISION } from "@velocity-exchange/sdk";
 
const perpMarket = velocityClient.getPerpMarketAccount(marketIndex);
const oracle = velocityClient.getMMOracleDataForPerpMarket(marketIndex);
const slotSubscriberSlot = slotSubscriber.getSlot(); // don't poll connection.getSlot() per fill
 
// Always guard against stale or unhealthy oracle data before quoting off it
const oracleIsValid = isOracleValid(
  perpMarket,
  oracle,
  velocityClient.getStateAccount().oracleGuardRails,
  slotSubscriberSlot
);
if (!oracleIsValid) {
  console.warn("Oracle invalid for market", marketIndex, "-- skipping");
  return;
}
 
const oraclePrice = convertToNumber(oracle.price, PRICE_PRECISION);
const confidence = convertToNumber(oracle.confidence, PRICE_PRECISION);
 
console.log(`Oracle price: $${oraclePrice.toFixed(4)}, confidence: ±$${confidence.toFixed(4)}`);
 
// Optionally widen your spread when confidence is low
const minSpread = Math.max(0.05, confidence * 2);

Using JIT Proxy (JitterSniper / JitterShotgun)

Instead of building fill logic from scratch, use the @velocity-exchange/jit-proxy library which handles auction timing, transaction building, and retry logic. Not yet published to npm — build it from packages/jit-proxy in the monorepo until it is.

import { JitterSniper, PriceType } from "@velocity-exchange/jit-proxy";
 
// The constructor field is still `driftClient` (typed as `VelocityClient`) --
// @velocity-exchange/jit-proxy hasn't renamed it yet. `jitProxyClient` (a
// `JitProxyClient` wrapping the JIT proxy program) is also required; omitted here
// for brevity.
const jitter = new JitterSniper({
  auctionSubscriber,
  driftClient: velocityClient,
  slotSubscriber,
  jitProxyClient,
});
 
await jitter.subscribe();
 
// The jitter handles auction timing automatically
// You just need to configure pricing and filters

See the JitMaker bot for a complete production example using JitterSniper/JitterShotgun with:

• Per-market subaccount isolation (1 subaccount per market)
• Volatility-based fill rejection (isMarketVolatile)
• DLOB-aware pricing (excludes own orders from best bid/ask calculation)
• Configurable target leverage and aggressiveness

Gotchas

• Don’t poll getSlot() per auction: the example above calls getSlot() for each auction, which is expensive at scale. Instead, use a SlotSubscriber to cache the current slot and read from it synchronously.
• isSignedMsgOrder filtering: if you also subscribe to SWIFT, onchain auctions for SWIFT orders will appear in AuctionSubscriber too. Use isSignedMsgOrder(order) to skip them in your onchain loop (handle them in SWIFT callback instead). See SWIFT API.
• One subaccount per market: JIT fills can conflict if two markets try to use the same subaccount simultaneously. The JitMaker enforces 1:1 subaccount-to-market mapping.
• Fill rate tracking: track your fill success rate per market. If it drops below ~20%, your pricing or latency may need adjustment.

Related

• JIT Auctions - Auction mechanics, pricing formula, and timeline
• SWIFT API - Receive orders 100-500ms faster via offchain WebSocket
• Bot Architecture - Priority fees, health monitoring, graceful shutdown
• DLOB MM - Resting order approach (can be combined with JIT)
• @velocity-exchange/jit-proxy  - JIT proxy SDK with JitterSniper and JitterShotgun