Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Wrapping non-mosaik feeds

audience: ai

A real MEV searcher is never limited to on-mosaik surfaces. Its edge comes from reading the mempool, off-chain price feeds, oracle networks, cross-venue depth, and a long tail of bespoke data sources — none of which speak mosaik natively. This chapter walks the compositional pattern for bringing those feeds inside the same substrate the rest of the searcher already uses: the feed organism.

The question this chapter answers: when an external feed is the searcher’s advantage, how is it folded into the same fingerprint-addressed substrate that everything else uses, without (a) hiding the feed behind an undocumented side channel, or (b) forcing every downstream consumer to re-implement the external integration?

Why a feed organism

The feed organism is not a protocol innovation. It is a shape 2 standalone organism the searcher stands up alongside the searcher agent itself, inside the same searcher-α coalition, whose job is to pull an external feed and commit its contents to a mosaik Stream. The searcher’s policy then reads the feed organism’s commits, not the raw external feed.

Three properties the detour buys:

  • Replayability. Every commit on the feed organism carries an evidence pointer (a hash of the upstream HTTP response, a signed oracle payload, a sequencer-attested block excerpt). A replayer can reconstruct what the policy saw at any past tick.
  • Uniform bonding. Downstream consumers — the searcher’s inference loop, the reputation organism, a shadow experiment committee — subscribe to the feed via the same Stream<T> surface every other mosaik organism exposes. No bespoke transport.
  • Measurements-pinned confidentiality. When the feed is commercial (a paid CEX API with a credential) or sensitive (an internal strategy snapshot), the feed organism runs in TDX with a Measurements set the searcher’s validator pins. The credential is sealed into the TDX image; the host cannot exfiltrate it.

The feed organism shape

use coalition::{OrganismRef, Organism};

const BINANCE_DEPTH_ORG: OrganismRef<'static> =
    OrganismRef {
        role:         "feed.binance-depth",
        stable_id:    const_blake3!(
            b"instance|searcher-α.feed.binance-depth|",
            UNIVERSE.bytes(),
        ),
        content_hash: Some(BINANCE_DEPTH_IMAGE_MRTD),
    };

// Appended to the coalition's organism list
// alongside SEARCHER_ORG from chapter 1.
const COA_ORGANISMS: &[OrganismRef<'static>] = &[
    SEARCHER_ORG,
    BINANCE_DEPTH_ORG,
];

The feed organism’s public surface is a single Stream<DepthSnapshot>. No wrapper struct; the organism is Feed<DepthSnapshot> (the usual mosaik-organism shape parameterised on the datum).

pub struct DepthSnapshot<'a> {
    pub venue:         &'a str,
    pub pair:          &'a str,
    pub tick:          AlmanacTick,
    pub bids:          &'a [(PriceQ64, QtyQ64)],
    pub asks:          &'a [(PriceQ64, QtyQ64)],
    /// blake3 of the original HTTP response body.
    pub evidence:      UniqueId,
    /// If the feed's upstream provides a signature
    /// (Binance does not; Chainlink does), fold it
    /// in; otherwise None.
    pub upstream_sig:  Option<&'a [u8]>,
}

The organism runs the external polling loop, writes each snapshot to its stream, and optionally seals the raw response body to a local content store for audit-time replay.

A searcher-α feed organism crate

searcher-alpha-feed-binance/
  Cargo.toml
  src/
    config.rs   # BinanceDepthConfig.content
    organism.rs # Organism::feed_binance_depth(&network, &Config)
    poll.rs     # the external HTTP loop
    bin/
      feed-binance-depth.rs

The poll loop is ordinary Rust: reqwest (or a pinned HTTP client), a retry policy, and a small translator from the venue’s depth shape to DepthSnapshot. The only mosaik-specific code is the commit:

pub async fn poll_forever(
    organism: Feed<DepthSnapshot<'_>>,
    content:  &BinanceDepthContent<'_>,
) -> anyhow::Result<()> {
    let client = http_client(content)?;
    loop {
        let resp = client.get(content.url).send().await?;
        let body = resp.bytes().await?;
        let evidence = blake3::hash(&body);

        let snapshot = parse_depth(&body)?;
        organism.publish(DepthSnapshot {
            venue: "binance",
            pair:  content.pair,
            tick:  organism.almanac().current_tick(),
            bids:  &snapshot.bids,
            asks:  &snapshot.asks,
            evidence: evidence.into(),
            upstream_sig: None,
        }).await?;

        tokio::time::sleep(content.interval).await;
    }
}

The policy, running inside the searcher agent organism, then reads Feed::<DepthSnapshot>::depth(&network, &BINANCE_DEPTH_CFG) and folds the snapshots into its observation window alongside the on-mosaik streams from market-reads.

TDX for commercial credentials

When the feed’s upstream requires a paid credential (a Binance API key, a Kaiko client id, a Chainlink subscription), the credential is sealed into the feed organism’s TDX image. BinanceDepthContent (the feed organism’s Config.content) folds the expected TDX Measurements; consumers bond against that Measurements set; the host running the feed organism cannot read the credential at runtime.

Shape, sketched:

pub struct BinanceDepthContent<'a> {
    pub url:            &'a str,
    pub pair:           &'a str,
    pub interval:       Duration,
    /// Credential-handling policy — which TDX-sealed
    /// slot the credential is read from. Declared
    /// parameters only; the credential itself never
    /// appears in the Config.
    pub credential_slot: CredentialSlot,
}

The credential lives in the TDX-sealed side of the image (see ai/compute.md — TDX is declared, not implicit); the policy the image enacts is pinned by the image’s Measurements.

How consumers trust the feed

The point of running the feed organism in TDX is not just to hide the credential. It also answers “why should I believe the price this organism commits is what Binance actually served?”

A searcher that needs accurate Binance prices, but does not want to trust the feed operator, bonds its TicketValidator against the expected image Measurements the feed’s BinanceDepthContent folds. The Measurements match means the running binary is the one whose source the searcher has read. The source can be audited for two properties: it fetches from the declared URL and it passes the response body through to the commit without altering it. Every commit also carries evidence: blake3(response_body), so a late auditor comparing the committed bids and asks against the original response body can detect tampering after the fact.

What the composition does not rescue is Binance itself. The feed can prove “this is what Binance served at this tick”; it cannot prove “Binance’s body reflected the actual top-of-book”. A searcher that wants defence in depth bonds against several venue feeds (see Feed-of-feeds below) and reconciles.

This is the attestation-fabric pattern from ai/emergent-coordination.md — pattern 4 applied to an external data source. The fetcher is the costly signal; the published Measurements plus the auditable source code are what let consumers bond to it without trusting the operator.

Feed-of-feeds — composite feed organisms

A searcher that needs a composite view — say, “best bid across five venues” — stands up a second organism that subscribes to several per-venue feed organisms and commits a fused stream:

const BEST_BID_ORG: OrganismRef<'static> =
    OrganismRef {
        role:         "feed.best-bid",
        stable_id:    const_blake3!(
            b"instance|searcher-α.feed.best-bid|",
            UNIVERSE.bytes(),
        ),
        content_hash: Some(BEST_BID_IMAGE_MRTD),
    };

// Its Config.content references the per-venue
// feed organism stable ids it aggregates over.
pub struct BestBidContent<'a> {
    pub venues: &'a [UniqueId],
    pub pair:   &'a str,
}

This is a composite organism in the sense of contributors — composite organisms: its Config fingerprint folds the references of the per-venue feeds it spans. Downstream consumers see one stream instead of N.

Honest limits

  • Feed honesty. The feed organism cannot make Binance honest. It can prove “this is the body Binance served at this tick”; it cannot prove “Binance’s body reflects the actual top-of-book”. The searcher’s trust in the feed is a trust in the upstream plus the TDX seal on the credential handling; the substrate does not rescue a misbehaving external API.
  • Latency. Wrapping a feed through a mosaik commit adds one write-side round-trip to the feed’s native latency. For feeds where the decision latency is pico-seconds the wrapping is inappropriate; the searcher either consumes the feed directly from its policy process (and loses auditability) or accepts the added hop.
  • Rate limits. The feed organism is one point of upstream credential use. If the searcher’s strategy requires N parallel reads, that is one feed organism serving N subscribers — not N copies of the feed organism. Scaling is the operator’s problem, not the substrate’s.

Market-maker variant — differences at wrapping

  • Heavier on external feeds. Market-makers depend more on off-chain depth than MEV searchers do. The feed-organism catalogue tends to be larger: multiple CEX depths, on-chain DEX oracle feeds, funding-rate streams, volatility indices.
  • More TDX-sealed credentials. Commercial depth feeds almost always require a paid credential; sealing into TDX is essentially mandatory if the market-maker does not want to leak the key to its own host.
  • Faster polling cadence. Market-makers poll much faster than MEV searchers do; the feed organism’s Interval parameter is correspondingly smaller, and the stream’s downstream consumers must be built for the throughput.

Cross-references