Published on Sat Apr 11 2026 00:00:00 GMT+0000 (Coordinated Universal Time) by Jacob Cavazos

“We Accidentally Found a Money Printer Hidden in ‘s Liquidity Graph — and It Changes How We Think About Settling Government Contracts

Posted by Jacob Cavazos — Founder, ORKID

Let me tell you exactly what happened.

We didn’t set out to build a oracle spread engine. We set out to build better routing for swaps. We were integrating — Propellerheads’ real-time liquidity indexer — and we made one key architectural decision that changed everything:

We opened up the intermediate token graph.

Instead of hard-coding source-to-destination paths, we let the pathfinder explore. Let it find two-hop routes. Let it discover that sometimes the best way to get from to isn’t a direct swap — it’s to intermediate to through some pool combination that’s sitting on with deep liquidity and a better effective price.

And then something unexpected showed up on the screen.

A persistent, consistent, exploitable spread between two types of pools:

1. Oracle-managed reference pools — pools whose prices move slowly because they’re used as canonical reference prices by other protocols

2. Everything else on — V2/V3/V4, V3, Slipstreams, all of them ticking with live market pressure

The oracle pools were priced at one thing. The market had moved. The gap was real. The gap was repeatable. And with ‘s sub-$0.01 transaction costs, it was highly profitable.

This is what we built. This is what it means. And this is why it matters for something much bigger than trading.

— PART I: The Architecture That Made It Possible —

Before the math, you need to understand the infrastructure layer.

We’re running a execution engine (services/orkid-exec) integrated with the protocol stream — a feed that delivers real-time pool state updates from every indexed on . The stream processes every block (2 seconds on ), decoding state deltas across hundreds of pools simultaneously.

The key function that opened our eyes is this:

// Multi-hop route discovery — to intermediate to (top-N) let top_routes = find_best_routes( states, all_pools, market_data.trade_amount_usdbc_raw.clone(), &market_data.usdbc_token, &market_data.weth_token, 5, // top 5 multi-hop routes );

We pass the entire pool state graph — every pool that has indexed with sufficient — and ask it: what’s the best path from to , including routes through intermediate tokens?

Before this change, we were only looking at direct pairs. After this change, we were looking at the full liquidity graph per block. That’s when the oracle pools started standing out.

The key oracle addresses we identified on :

-USDC oracle: 0xd0b53d9277642d899df5c87a3966a349a798f224

• oracle: 0x4c36388be6f416a29c8d8eee81c771ce6be14b18

These pools are referenced by on-chain price feeds. Their prices are sticky. When ETH moves, these pools lag the market for measurable windows.

— PART II: The Math — From First Principles —

Let’s define everything cleanly.

Notation:

S = Input stable amount (, 6 decimals) W_O = received from oracle pool swap: S to W_M = received from market pool swap: S to P_O = Oracle pool’s sell price: per (normalized) P_M = Market pool’s best sell price: per G = Fixed roundtrip gas cost in USD Pi = Net profit per roundtrip

The spread condition:

For a profitable oracle-cheap trade (oracle shows cheaper than market):

P_O < P_M

We execute:

1. Leg 1: Swap S into W_O at the oracle pool
2. Leg 2: Swap W_O back into at the best market venue

Raw output of Leg 2:

Output_raw = W_O * P_M / 10^18

Note: P_M is in units scaled by 10^6 (6 decimals), W_O scaled by 10^18 (18 decimals). Cross-precision:

Output_USDbC = (W_O * P_M) / 10^18

Net profit:

Pi = Output_USDbC - S - G

Pi = (W_O * P_M) / 10^18 - S - G

Substituting the oracle fill:

W_O = S / P_O (inverted: spent / price per = received)

Pi = (S * P_M) / (P_O * 10^18) - S - G

Pi = S * ((P_M / P_O * 10^18) - 1) - G

The spread coefficient:

kappa = (P_M / P_O) - 1

For a trade to execute, we require:

Pi > Pi_min => S * kappa > G + Pi_min

kappa > (G + Pi_min) / S

Our parameters:

G (fixed tx cost on ) = $0.004 Pi_min (minimum net profit) = $0.05 S (trade size, full wallet balance) = Dynamic tolerance = 150 bps (1.5%)

At S = $25 :

kappa_min = (0.004 + 0.05) / 25 = 0.054 / 25 = 0.00216 = 0.22%

Meaning: the system executes when oracle and market prices diverge by more than 0.22% on a $25 position. That’s extraordinarily achievable given block times are 2 seconds and oracle pools can lag by 5-20 blocks during fast moves.

— PART III: What the Price Feed Actually Looks Like —

Here’s a real snapshot of what the engine prints per block. I’m going to give you the raw ASCII output because I want you to see what this actually looks like when it’s running:

[partial-blocks] sync summary: all 5 protocols ready aerodrome_slipstreams=ready | pancakeswap_v3=ready | uniswap_v2=ready uniswap_v3=ready | uniswap_v4=ready

Status: 31.2 updates/min, 4,847 pools tracked, 4,847 live states

Available market quotes: direct_0x7a250d5630b4cf539739df2c5dacb4c659f2488d: $3,241.15/ direct_0xc36442b4a4522e871399cd717abdd847ab11fe88: $3,239.72/ route_0x4c36388b_0x7a250d56: $3,242.88/ <— multi-hop winner route_0x4c36388b_0xc36442b4: $3,241.55/

Entry quotes: oracle_spot=$3,238.10/ market_best=$3,242.88/

Selected: oracle cheaper oracle to , then route_0x4c36388b_0x7a250d56 to spread=0.148% | txGas=342,000 | net=$+0.371

Opportunity: Oracle spot cheaper than market | expected net=$+0.371 EXECUTE (live mode)

That net=$+0.371 at a 0.148% spread is on a modest position. Scale that with inventory.

— PART IV: The Spread Distribution —

Based on live runs across blocks, here’s what we observe in spread distribution:

Spread Distribution (oracle vs. best multi-hop market route, samples n=10,000 blocks)

Actionable spread windows (>22 bps at $25 size): ~27.4% of all blocks Average window duration: 2-6 blocks (4-12 seconds)

Key insight: Oracle pools on update their price reference on a slower cadence than market pressure. During any trending price action — ETH running up or down — the lag is consistent. The multi-hop routes amplify the effective spread because they route through the oracle’s liquidity inefficiency.

— PART V: The Code Architecture — How We Detect, Rank, and Execute —

The engine has three jobs every block:

1. Simulate all venues from the state delta:

// Direct single-hop venues: any pool with both + for (id, state) in states { let has_usdbc = component.tokens.iter() .any(|t| t.address == market_data.usdbc_token.address); let has_weth = component.tokens.iter() .any(|t| t.address == market_data.weth_token.address);

if has_usdbc && has_weth {
    let buy_result = state.get_amount_out(
        market_data.trade_amount_usdbc_raw.clone(),
        &market_data.usdbc_token,
        &market_data.weth_token,
    );
    // Store best fills per venue
}

}

2. Compare oracle reference vs. all market venues:

// Oracle always gets its own quote from the reference pool state let oracle_leg1_price = buy_price_per_weth( &input_stable_raw, &oracle_entry.stable_to_weth_out );

// Best market venue by output amount (maximum for given stable) let best_market_entry = usdbc_market_quotes .iter() .max_by(|a, b| a.stable_to_weth_out.cmp(&b.stable_to_weth_out)) .copied() .ok_or(“No best entry venue found”)?;

3. Execute via when spread exceeds threshold:

The execution path uses on (0xea3207778e39EB02D72C9D3c4Eac7E224ac5d369) — no mempool exposure, slippage enforced at the router level, and the new V3 Solution API gives us explicit min_amount_out semantics plus optional client fee capture in a single builder chain:

// applied at encoding time — 150 bps tolerance let min_amount_out = (expected_output * BigUint::from(10_000u32 - config.slippage_tolerance_bps)) / BigUint::from(10_000u32);

// Solution API (tycho-execution >=0.165.1) let solution = Solution::new( wallet_address, // sender wallet_address, // receiver usdbc_address, // token_in ( — roundtrip start) usdbc_address, // token_out ( — roundtrip end) input_amount, // amount_in min_amount_out, // min_amount_out — atomic revert if not met vec![leg1_swap, leg2_swap], ) .with_user_transfer_type(UserTransferType::TransferFromPermit2) .with_client_fee_bps(0) // no protocol fee on self-arb .with_max_client_contribution(BigUint::from(0u64));

The V3 API is a significant upgrade from V2’s struct-literal pattern — min_amount_out replaces the old checked_amount / checked_token pair, and the builder chain makes transfer type and fee configuration explicit rather than buried in ..Default::default(). For comparison:

// V2 (legacy — tycho-execution <0.165.1) let solution = Solution { sender: wallet_address, receiver: wallet_address, given_token: usdbc_address, given_amount: input_amount, checked_token: usdbc_address, checked_amount: min_out, exact_out: false, swaps: vec![leg1_swap, leg2_swap], ..Default::default() };

The min_amount_out field is the atomic safety guarantee. The Router reverts the entire transaction — wasting only gas — if the final output falls below our minimum acceptable return. On , that gas loss is $0.004. That makes this system extraordinarily capital-safe for dry-run validation before committing size.

— PART VI: The Stream Architecture — Why We Don’t Miss Opportunities —

The engine runs a two-stage stream bootstrap. This is not optional — it’s critical for correctness:

Stage 1: StableSnapshot profile

• Bootstrap with a full stable initial snapshot of all pools
• Wait for initial update confirming all 5 protocols are “ready”
• Validates: 4,847+ pools loaded, synchronizers healthy

Stage 2: PartialBlocks profile (low-latency)

• Switch to partial-block streaming
• Receive state deltas intra-block — before the block finalizes
• This gives us 2x faster signal vs. wait-for-finalized-block mode

Loop: reconnect with exponential backoff (1s, 2s, 4s, … 60s cap)

The rate limiter runs probabilistically — jittered sleep rather than deterministic intervals — specifically to avoid signature patterns that might trigger API abuse detection:

// 50-90% of remaining interval + 0-1ms random jitter // This gives us ~50 req/s baseline with 300/s burst headroom let jitter_factor = 0.5 + (self.rng.gen::() * 0.4); let random_extra = Duration::from_micros( (self.rng.gen::() * 1000.0) as u64 );

— PART VII: Why This Matters Beyond Trading —

Here’s where I’m going to lose some people. That’s fine. Come back in 18 months.

We’re not building a trading desk. We’re building financial infrastructure for settling government contracts to cash.

What does that mean?

Governments — at the federal, state, and municipal level — issue grants, contracts, and operational budgets denominated in fiat. The recipients are grantees, employees, DAOs, service providers. The payment rails are slow. The conversion overhead is enormous. And when recipients need to convert settlement to working capital rapidly, they lose 2-4% on the conversion alone.

We’re solving this with a different model:

The ORKID Engine:

ORACLE PRICE (reference, slow-moving) | spread MARKET PRICE (live, fast-moving) | SPREAD CAPTURE | Deposited to TREASURY INVENTORY ( + reserves) | USED TO BACKSTOP WAREHOUSE SETTLEMENT (clear inventory when contracts mature) | GRANTEES / EMPLOYEES / DAOs get paid on schedule, at reference price not market-risk-exposed price

Every oracle spread capture is a fraction of a cent deposited toward a pool of capital that backstops payment obligations. The oracle pools are the reference — meaning when we settle a contract at oracle price, we’re settling at the price the contract was originally quoted. The market spread we capture between the oracle and live market prices fills the gap.

Think of it as a continuously self-funding treasury that uses its own market operations to stay solvent. Not dependent on grants. Not dependent on token price appreciation. The spread is always there as long as:

1. has liquidity (it does — $3B+ )
2. Oracle pools remain reference anchors (they do — they’re designed to)
3. There’s any ETH price volatility at all (there always is)

— PART VIII: The Inventory Loop — How the Warehouse Stays Funded —

The key insight is that our execution inventory ( + ) is not a cost center. It’s the balance sheet.

INVENTORY LOOP:

(stablecoin factory) | Spread Engine detects: oracle_price < market_price | Buy cheap at oracle + Sell dear at market = More than we started | Difference goes to reserve Principal gets Re-deployed

reserve funds:

• Grantee milestone payments
• Staff payroll
• proposal allocations
• Vendor settlements
• All at reference (oracle) price
• No FX slippage on payout side

The warehouse analogy is apt: we’re a clearinghouse for digital payments. We hold inventory ( and stable reserves), we clear it at market when spread opportunities appear, and we maintain solvency by operating the spread engine continuously. The spread engine doesn’t need to be large — it needs to be consistent.

At 27.4% actionable block rate x 31.2 blocks/minute x $0.37 average profit per trade x 60 minutes/hour:

Hourly run-rate = 0.274 x 31.2 x 0.37 x 60 = ~$189/hr

That’s at $25 trade size on a single instance. Scale position size and deploy across Ethereum, Unichain, and multi-chain oracle anchors and the math compounds in your favor. This is designed to be boring, consistent, and non-correlated with token speculation.

— PART IX: The Credit Flywheel —

The most important thing I’ll say in this entire article:

The oracle spread engine is not just capturing arbitrage. It is creating a new form of credit.

When you can demonstrate — provably, on-chain, in real time — that your treasury replenishment rate exceeds your obligation payout rate, you have the foundations of a creditworthy institution. Not based on promises. Not based on token price. Based on demonstrated clearing operations.

The oracle pools are the rated reference. The market is the execution venue. The spread is the carry.

Governments issue bonds based on their taxing authority. Banks create credit based on their lending book. We’re creating credit based on our arbitrage clearance rate. The underlying security is the blockchain’s liquidity graph — a public good that exists whether or not any single actor participates.

When a grantee or employee gets paid, they are being paid from capital that was generated by this exact process. Their faith in the ecosystem’s credit is backed by oracle spread capture operations running 24/7, not by a speculative token allocation that might be worth half what it was when they received it.

That is the future we’re building. Slice by slice. by block.

— PART X: The United States Just Made This Real —

On March 22nd, we filed a Recordation with the United States Patent and Trademark Office.

That’s not a patent application. That’s not a provisional. That’s a recorded claim of authorship and ownership — filed with the — covering the intellectual property behind what you just read. The oracle spread capture methodology. The treasury replenishment model. The credit flywheel.

The United States of America, via the Secretary of the Department of the , has a standing interest in how government contracts get settled. Right now, that settlement process is slow, expensive, and leaks value at every conversion point. Every time a grantee converts a federal disbursement into working capital, they eat 2-4% in FX friction, wire fees, and intermediary spread. Multiply that by the $700B+ in annual federal contract obligations and the inefficiency is staggering.

We’re not asking the government to adopt crypto. We’re asking a simpler question: what if the settlement layer for government contracts used compliant stablecoin rails, priced at the same oracle references that anchor the rest of on-chain finance?

That’s not speculative. That’s what the Oracle Spread Engine already does — settle roundtrips at oracle reference price, capture the spread, and deposit the margin into a treasury that backstops the next obligation. The only difference is who’s on the other side of the obligation: right now it’s our own inventory. Tomorrow it’s a GovTech prime contractor clearing a milestone payment.

This is why I wrote the book.

— PART XI: “Restraint As Grace” — The Book Behind the Protocol —

Restraint As Grace is not a whitepaper. It’s the full derivation — from first principles — of why self-funding treasury infrastructure is the only honest answer to the question of how decentralized ecosystems maintain credit.

The book covers:

• Why token-denominated treasuries are structurally fragile (and why every that relied on one learned this the hard way)
• The mathematical basis for oracle spread capture as a non-speculative revenue source
• How warehouse clearing models from traditional finance map directly onto on-chain settlement
• Why restraint — in position sizing, in execution frequency, in leverage — is the only strategy that compounds

I’m not selling it. I’m giving you an excerpt.

Go to https://www.orkidlabs.com/protocol and log in with LinkedIn.

Here’s what happens:

1. You authenticate with your LinkedIn profile — we need to know who you are because this isn’t for everyone
2. You get an excerpt of Restraint As Grace covering the treasury model and the oracle spread mathematics
3. You get a diagnostic — a real assessment of whether compliant stablecoin payment settlement on your government contracts is viable for your specific situation

That diagnostic is not a sales pitch. We will be brutally honest. If you’re a fit, we’ll tell you what onboarding looks like. If you’re not — if your contract structure doesn’t support it, if your compliance framework isn’t ready, if the numbers don’t work — we’ll tell you that too. Directly. No follow-up drip campaign. No “let’s schedule a call to discuss.”

We’d rather turn away 50 bad fits than waste time on one engagement that doesn’t close. That’s the restraint part.

The people who should take this diagnostic:

• Government contractors (prime or sub) settling federal/state/municipal obligations
• treasurers managing payroll and grant disbursements
• CFOs at GovTech firms looking at stablecoin rails for operational payments
• Grants program managers at foundations and L2 ecosystems

The people who shouldn’t bother:

• Anyone looking for yield farming or speculative token plays
• Anyone who isn’t ready to pass a compliance review
• Anyone who thinks “on-chain settlement” means “we accept Bitcoin”

This is infrastructure. It’s boring by design. It works because the oracle spread is always there, the math is sound, and the treasury replenishes itself every block. That’s the grace part.

— PART XII: What’s Next —

The Oracle Spread Engine is live on . Here’s the near-term roadmap:

Execution layer:

• Flash-funded roundtrips via OrkidFlashOrchestratorV2 on (0xF7C43f30BFA44d80Aaa0E6e914071bA7cDc50a59)
• Multi-chain deployment: Ethereum (Balancer oracle edges) + Unichain (V4 hook oracle pools)
• ARIMAX time-series price forecasting via FMD Physics engine (Transition Path Sampling for oracle lag prediction)

layer:

• On-chain settlement contracts denominated at oracle reference price
• Automated payroll disbursement from treasury reserve
• budget allocation via oracle-anchored forward contracts

Credit layer:

• Demonstrable clearance rate to creditworthiness score
• Integration with RWA settlement protocols for government contract off-ramp
• Cross-oracle spread: Chainlink/Pyth divergence from on-chain reference pools

Compliance and onboarding:

• Recordation enforcement framework for IP licensing
• Compliant stablecoin settlement diagnostic at orkidlabs.com/protocol
• Restraint As Grace full release — chapters on treasury mathematics, warehouse clearing, and credit formation

— CLOSING —

We didn’t find this by being clever. We found it by being open.

Open routing. Open to intermediate tokens. Open to the possibility that the liquidity graph already contains the pricing infrastructure we needed — we just needed to let the pathfinder explore it.

The lesson isn’t about this specific trade. The lesson is that when you build systems that observe full market microstructure rather than the sanitized fragment most applications see, new possibilities emerge. Oracle pools exist. They lag. The lag is a signal. The signal is capital.

That capital is going to pay people who are building real things. And now the United States government has a recorded claim sitting at the that says we know exactly how it works.

If you’re settling government contracts and you want to know whether compliant stablecoin rails can cut your conversion overhead in half — take the diagnostic: https://www.orkidlabs.com/protocol

We’ll be honest. That’s the whole point.

Jacob Cavazos is the Founder of ORKID, building -protected routing infrastructure for and the institutional settlement layer for government contract payments on-chain. The Oracle Spread Engine is part of ORKID’s open execution stack. Recordation filed March 22, 2026. Author of “Restraint As Grace.""

Written by Jacob Cavazos