Attributing a contract to a protocol

The graph knows a contract is a vault, has an admin, holds a token. One thing it can't read off-chain: which protocol does this contract belong to? There's no protocol() getter. Yet grouping contracts by project — "these 40 nodes are all Aave" — drives the admin panel, rule scoping, and cost attribution. Project inference is the small heuristic that derives it, and studying it is a lesson in knowing when a dumb string match is the right tool.

1 · Three signals, in a precedence cascade

InferProject (pkg/enrichment/project.go) consults three sources, in descending order of trust, and returns on the first hit:

All three are plain strings.Contains matches — no RPC, no graph traversal, no ABI parsing. It's the cheapest stage in the whole pipeline, which is precisely why it runs as a quick label pass rather than an on-chain probe.

2 · Specificity ordering — the correctness trick

Substring matching has an obvious trap: "curve" is a substring of a "crvusd" contract's nametag, and both are real but different canonical projects. The fix is purely structural — the pattern lists are ordered most-specific-first, and the first match wins:

var knownProjects = []projectPattern{
    {"metamorpho", "morpho"},      // before the generic "morpho"
    {"morpho",     "morpho"},
    {"atoken",     "aave"},        // before the generic "aave"
    {"variabledebt", "aave"},
    {"crvusd", "curve-finance"},  // before "curve"
    {"curve",  "curve-finance"},
    // …~50 patterns total
}

This is the same "order is load-bearing" discipline you saw in L19's cap pipeline and L20's cell dedup — here it's what keeps a specific token from being swallowed by its protocol's generic prefix.

3 · Canonical slugs — this is a parity constraint

Every inferred value is piped through NormalizeLabelAPIProject before it's returned. Why does that matter? Because the realtime indexer and the Python batch pipeline both write a project field, and they must produce the byte-identical slug or the parity harness (L23) flags a mismatch:

// the patterns already encode canonical slugs; normalization is defence-in-depth
{"sushi": "sushiswap"}, {"curve": "curve-finance"}, {"maker": "sky"}, {"eigencloud": "eigenlayer"}

4 · The reserved-generic filter — refusing to guess

Some labels look like attribution but aren't a protocol. "stablecoin", "dex", "lending", "erc20-token", "safe", "mev-bot" — all describe a kind, not a project. Inference returns empty for these rather than stamping a meaningless BELONGS_TO:

var projectReservedSortedBy = map[string]bool{
    "token-contract": true, "stablecoin": true, "dex": true,
    "lending": true, "oracle": true, "bridge": true, // …treated as no-match
}

5 · What it produces and who reads it

The inferred slug becomes the project field, a BELONGS_TO edge to a protocol node, plus project_source (nametag / contract_name) and project_category (defi / infra / uncategorized) — stage 10 of the L24 pipeline. Downstream it's the grouping key for: the admin panel (L17, "show me everything in Aave"), rule scoping (L12, rules that target a protocol), and the cost-allocation model (attributing on-chain signal to the customer who controls a protocol). It's the connective tissue that turns a flat node set into protocols.

What you can now do

• Explain why project attribution is a label heuristic — there's no on-chain protocol field to read.
• Walk the precedence cascade (nametag → contract name → labels_slug) and justify the trust order.
• Explain specificity ordering + first-match as the fix for substring collisions like crvusd vs curve.
• Describe canonical-slug normalization as a parity constraint, and what rebrands/vendor-drift it encodes.
• Explain the reserved-generic filter, the heuristic's accepted imprecision, and who consumes the project field.