Flint: plug-and-quote Solana spot infra for market makers
Flint.trade is on-chain prop AMM infrastructure for Solana spot: market makers plug quoting logic, refresh fair+offset ladders cheaply, match aggregator flow pro-rata, while Flint handles gas, priority fees, and transaction landing.
devrels.xyz/a/190short linkFlint: plug-and-quote spot infrastructure for Solana market makers — an on-chain prop AMM layer where you run quoting logic and Flint runs execution plumbing (gas, priority fees, transaction landing) so you can sit in front of aggregator taker flow without rebuilding a full Solana ops stack.
Site: flint.trade. Do not confuse with flint.gg (unrelated gaming identity product).
Related: Jupiter (aggregator routing) · Phoenix (perps CLOB) · Imperial (perps router). Flint is the spot MM infra counterpart: you supply prices; the network’s aggregators supply flow.
The problem Flint targets
Solana concentrates a huge share of DeFi spot volume, and aggregators (Jupiter and peers) are how most retail and bot flow finds liquidity. Professional market makers who already quote CEX or other L1s often hit the same wall onboarding Solana:
- Landing transactions reliably under congestion
- Priority-fee games and failed sends
- Rewriting full on-chain order state every time fair moves
- Wiring each venue/aggregator integration from scratch
Flint’s pitch: you bring the quoting brain; they operate the prop AMM + submission path so quotes stay live where aggregator volume already is.
System shape
Aggregators (taker flow)
│
▼
Flint on-chain prop AMM
· per-market USDC vault + account
· each maker’s isolated mini-book
· pro-rata match across makers
· synthetic cross at match time
▲
│
Maker quoting process
(oracle offsets / ladders / risk)
│
Flint client + landing service
(builds txs, pays fees, reports fills)Makers connect a fast server with their strategy. Flint materializes an on-chain book from those quotes and handles submission. Matching is on-chain and inspectable — allocation and fills are not a pure dark off-chain pool.
Market model
USDC-quoted legs
Each listed token has a single market account and vault. Inside that market, every maker maintains an isolated USDC-quoted mini-book. Pricing surface is intentionally simple for non-Solana-native desks: think in USDC, not exotic quote assets per pair.
Synthetic crosses
Cross pairs are derived per maker by linking two enabled USDC legs at match time, e.g.:
JTO/SOL ≈ JTO/USDC ÷ SOL/USDC (for that maker)Makers enable legs and risk; Flint composes the product quote when flow needs the cross — without forcing a separate physical JTO/SOL book if the USDC legs already exist.
Pro-rata fills
Multiple makers quote side by side. Flow is shared pro-rata: sharper pricing still earns priority, but a single tick of latency does not automatically zero everyone else out. More makers → deeper composite book → more aggregator-attractive size.
Quoting API (maker-facing)
Flint exposes a client library oriented at cheap quote refreshes. Instead of cancelling and replacing every level, makers typically set a fair and an offset ladder (size + staleness per rung). Moving fair shifts the whole book; offsets stay put.
Documented styles on the site:
- Oracle offsets — fair + spread ladder (primary demo)
- Explicit orders
- Linear distribution
Illustrative Rust shape from their marketing docs (API names may move):
use flint_api_client::quoting::{OffsetSpec, QuoteBuilder, RiskParams};
let l = |price_offset: f64, size: f64, staleness: u8| OffsetSpec {
price_offset,
size,
staleness,
client_order_id: None,
post_only: false,
};
let ladder = vec![
l(0.05, 4.0, 1),
l(0.10, 7.0, 2),
l(0.15, 10.0, 3),
// ...
];
// Install strategy: fair + ladder + risk
QuoteBuilder::new()
.oracle_offset("SOL", |b| {
b.with_fair((154., 154.))
.with_spread(ladder.clone(), ladder)
.with_risk(RiskParams {
per_slot_decay_factor: Some(0.99),
..Default::default()
})
})
.commit(&mut core)
.await?
.landed()
.await?;
// Later: cheap fair bump shifts the whole book
QuoteBuilder::new()
.oracle_offset("SOL", |b| b.with_fair((155., 155.)))
.commit(&mut core)
.await?;Risk params (e.g. per-slot decay) let makers bound how aggressively size survives as slots pass — important when oracle moves faster than you want to leave stale size at old levels.
Aggregator distribution
Flint’s commercial path is pre-integration with aggregators so MM liquidity is reachable without each maker negotiating routing. Status called out on the site (verify live before you depend on it):
- Live: OKX DEX, Titan
- In progress: Jupiter, DFlow
Until Jupiter is live end-to-end, treat “aggregator flow” as a growing set rather than universal coverage — still the right architecture if your desk’s edge is quoting, not Solana mempool ops.
Maker console
Product marketing shows a mainnet console: NAV, 24h volume/fills, volume-by-pair, per-market views — aimed at monitoring inventory drift, spread distribution, and quote behavior in one place. Expect this to be the day-two surface after the API is wired.
Why this is interesting for Solana builders
- Aggregator teams / RFQ edges: another professional liquidity source with on-chain match rules and USDC inventory.
- Wallet / terminal builders: you usually still route via Jupiter et al.; Flint improves the MM side of the book those routers hit.
- Desks new to Solana: lower fixed cost than running private landing fleets + custom CLOB integrations for every venue.
- Protocol designers: prop AMM + pro-rata + synthetic crosses is a different design point from pure constant-product pools or full CLOBs (Phoenix-style).
Honest gaps
- Public docs subdomain was thin at research time — most detail is on the marketing site and private onboarding; pin API crates/URLs with the team before production.
- Aggregator coverage is incomplete until Jupiter/DFlow flip to live.
- Prop AMM still means inventory and adverse-selection risk — Flint removes landing toil, not market risk.
Practical start
- Read flint.trade end-to-end (System / How / API / FAQ) and confirm current aggregator badges.
- Request maker access / API credentials from the team (standard path for prop venues).
- Implement oracle-offset SOL/USDC with tiny size; verify
commit→landedand fill reports. - Add a second USDC leg and test a synthetic cross under controlled size.
- Wire console alerts on inventory drift and staleness before scaling capital.
Resources
- flint.trade
- Flint on DevRels
- Context: Jupiter · Phoenix
Bottom line
Flint is Solana spot market-making infrastructure: USDC mini-books, synthetic crosses, pro-rata multi-maker fills, cheap fair+offset quote updates, and hosted landing — pointed at aggregator flow so desks can quote without reinventing Solana execution. Watch Jupiter integration status, treat onboarding as permissioned MM infra, and measure edge on inventory and adverse selection once the API is live in your hands.
Keep reading
One order ticket, multi-venue perps execution, optional lending boost, and a public Trading API — how Imperial’s router works for traders and integrators.
The Bot API costs zero. The real bill is RPC, streaming, landing fees, hosting that never sleeps, and the engineering that keeps keys and uptime honest. Three budgets, line by line.
A technical field guide to the six Solana program classes that absorb almost every serious transaction: System for accounts and SOL, Token for balances, ATA for deterministic addresses, Token-2022 for extensions, market programs for price discovery, and conditional escrow for vaults, lending, perps, and multisigs.
Get new articles in your inbox
Technical deep-dives on Solana tooling, infrastructure, and ecosystem. No noise.
