How a token learns its price feed

L20 hinged on a node attribute: T.attrs.value_defining_oracle. "If this marker is set," we said, "a bad NAV drains the whole supply." But we never asked the obvious question: how does the system know USTBL's price is set by a particular Chainlink feed in the first place? Nothing on-chain says "this token trusts that oracle." This lesson is the subsystem that figures it out — binds the token to its feed, prices it, and stamps the marker L20 depends on.

1 · The binding problem

There's no oracle() getter on these tokens pointing at the feed. So the NAVLinkRefresher (navlink_refresher.go) bridges the gap the same way a human would — by symbol:

It fetches Chainlink's published feed registry, loads focus tokens keyed by symbol from the graph, and intersects them (matchBindings — a pure function). A feed whose Symbol matches a focus token's symbol becomes a candidate binding. If a symbol matches several feeds (or vice versa), all combinations are produced — the binding isn't trusted yet.

2 · From whitelist to cross-source — a design evolution worth studying

Symbol-matching is fuzzy: a registry update adding a wrong-symbol feed could auto-bind and stamp a wrong price. How do you trust a binding? The answer changed, and the why is instructive:

3 · Reading the feed (the EVM details that matter)

For each confirmed binding, three RPCs read the feed (navlink_chain.go): aggregator(), latestRoundData(), decimals(). Three decisions are worth your attention:

• Bind to the PROXY, not the aggregator. Chainlink admin can repoint the aggregator behind the proxy; the proxy is the stable identity, so the oracle node and ORACLE_DEP reference it.
• Staleness gate. If updatedAt is older than the threshold, skip the stamp and count it (navlink.feeds.stale) — a stale NAV is worse than no NAV. Defensive decoding even handles a (hypothetical) negative answer rather than silently mangling it.
• decimals() is 8 for NAVLink feeds; NavlinkPriceUSD(answer, decimals) scales the raw int256 to USD.

The admin angle — closing the loop with L25

// ReadNavlinkProxyOwner — the on-chain admin who can publish arbitrary NAV
owner := callOwner(proxy)   // owner(), NOT accessController()

4 · The write-back — and what it sets in motion

writeStamps emits one idempotent graphwrite per cycle:

MATCH (t:Entity {id:$tok, graph_id:$g})        // MATCH not MERGE — never stub a delisted token
MERGE (o:Entity {id:$proxy, graph_id:$g})       // the oracle node = the feed PROXY
SET t.usd_price=$p, t.usd_price_source='navlink', t.price_updated_at=$ts
MERGE (t)-[:ORACLE_DEP]->(o)                    // the dependency edge L20's eligibility reads

Two things follow, and both connect to lessons you've done:

• The marker L20 needs. This binding + the ORACLE_DEP edge + the stamped price are exactly what make a token a value-defining-oracle target — the trigger emitValueDefiningOracleCells fires on.
• A price-dirty ripple (L24). After publishing, it SADDs the token to price-dirty:{chain}, so the PriceDirtyDrainer recomputes every HOLDS edge's USD value at the new price — the refresher pattern from L24, feeding the dollars L19–L21 consume.

What you can now do

• Explain the binding problem: no on-chain link from RWA token to NAV feed, solved by registry symbol-matching.
• Contrast the old whitelist gate with the cross-source check, and articulate the curation-vs-correctness trade-off + the verifier safety net.
• State why discovery binds the proxy (not the aggregator), how the staleness gate works, and why owner() (not accessController()) is the admin selector.
• Describe the idempotent write-back (MATCH token, MERGE oracle + ORACLE_DEP, SET price) and the price-dirty ripple.
• Connect this to L20 (it stamps value_defining_oracle), L25 (the owner becomes the attributed admin), L24 (price refresh), and L23 (the verifier).