Inheriting oracle dependencies

L26 stamped one kind of edge: token → ORACLE_DEP → oracle. But L20's model A oracle attack needed something L26 never produced — a market that "consumes" the oracle. A lending market doesn't declare its oracle dependency anywhere on-chain; it just holds a collateral token that has one. The Oracle Bridger is the small, elegant pass that makes that implicit dependency explicit in the graph — and it does so with no RPC at all, just Cypher.

1 · The gap it fills

After L26, only tokens carry ORACLE_DEP edges. Yet L20's eligibility test for a model-A oracle cell was "a market that both consumes this oracle and holds T as collateral." Where does "consumes this oracle" come from for a market node? It has to be derived — propagated up from the collateral token to the market:

The bridger runs periodically (default 30 min), mirroring the batch pipeline's bridge_lending_market_oracles() / bridge_vault_oracles(). It is pure Neo4j computation — no RPC calls — which sets it apart from the RPC-heavy probes of L25/L26. It's a graph transitive-closure step, nothing more.

2 · The three inheritance paths

Each path is one Cypher MATCH … MERGE. Here's Path A, the lending-market case, in full:

MATCH (token)-[:LENDING_COLLATERAL]->(market)
MATCH (token)-[:ORACLE_DEP]->(oracle)
WHERE NOT EXISTS { MATCH (market)-[:ORACLE_DEP]->(oracle) }   // skip if already linked
MERGE (market)-[r:ORACLE_DEP]->(oracle)
SET r.source = 'oracle_bridge:lending', r.category = 'DEPENDS_ON', r.subcategory = 'ORACLE_DEP'

3 · The subtle part: ordering inside one transaction

Look at Path C again: a vault inherits the oracle of a market it allocates to. But a market only got its oracle from Path A. So Path C depends on Path A having already run. The code packs all three statements into one graphwrite.Request, applied in order inside a single transaction:

// one Request, statements applied A → B → C in one tx
req := &graphwrite.Request{
    Source:  "oracle_bridger",
    IdemKey: fmt.Sprintf("oracle_bridger:%s:%d", graphID, now.Unix()/intervalSecs),  // per-cycle bucket
    Cypher:  &graphwrite.CypherOp{Statements: []CypherStatement{ pathA, pathB, pathC }},
}

4 · Why this completes L20

Recall L20 had two oracle attack models. L26 supplied the upstream for model B (NAV / value-defining oracles). The Oracle Bridger supplies the upstream for model A (DeFi-borrow oracles):

• L20's emitOracleCellsViaToken walks markets that consume an oracle and hold T as collateral.
• "Consumes an oracle" = the market has an ORACLE_DEP edge — which, for a market, exists only because the bridger created it from the collateral token.
• So every per-(oracle, market) cell in L20 model A stands on an edge this pass wrote. No bridger, no market-level oracle cells.

What you can now do

• Explain transitive ORACLE_DEP: markets/vaults inheriting the oracles their collateral and assets depend on.
• Distinguish the bridger (pure-Cypher, no RPC, periodic graph closure) from the RPC-heavy discovery probes.
• Read the three inheritance paths and the WHERE NOT EXISTS anti-join idempotency idiom.
• Explain why the three statements run ordered in one transaction, and how the interval-bucketed IdemKey dedupes.
• Connect it to L20 model A — the market-level oracle edge that the per-(oracle, market) cells stand on.