Context
Account.nameReferences (#1962, PR #2292) returns the Names whose indexed addr() record points at an Account, with an optional where: { coinType } filter. It does exact coinType matching.
The gap
Under ENSIP-19/11, a Name's default EVM record (coinType = DEFAULT_EVM_COIN_TYPE = 0x8000_0000) is the fallback address for every EVM chain that lacks a chain-specific record. Today:
| Query |
Behavior |
where omitted |
All records, incl. default ones as ordinary rows → a Name with only a default record appears ✓ |
where: { coinType: DEFAULT_EVM_COIN_TYPE } |
Names whose default record points here ✓ |
where: { coinType: <specific EVM coinType> } |
Exact match only → a Name with only a default record is not returned, though it resolves here on that chain ✗ |
So the gap is chain-scoped queries don't fall back to the default record. The no-filter view (Portal's actual /addr/$addr/resolution UX) already surfaces default-record names, so this is a refinement for scoped consumers, deliberately deferred from the initial PR to keep v1 literal/exact.
Why it's not a one-liner
Correct ENSIP-19 semantics are "addr(CT) if present, else addr(DEFAULT)". A naive coin_type IN (CT, DEFAULT) returns a Name via its default even when its CT-specific record points elsewhere (an override) → false positive. Proper expansion:
(direct CT matches)
UNION
(DEFAULT matches WHERE NOT EXISTS a CT-specific record for that node)
…plus dedup, plus rules for which coinTypes the default covers (the 0x8000_xxxx EVM space; coinType 60 is a spec nuance).
Also
- Document the exact-match default behavior on the
AccountNameReferencesWhereInput.coinType field when/if this is implemented or explicitly left as-is.
- Note:
NameReference.match (indexed ENSIP-19 reverse shortcut) already does a reverse-side default fallback; the asymmetry with the forward filter is intentional for v1.
Deferred from #1962 / #2292.
Context
Account.nameReferences(#1962, PR #2292) returns the Names whose indexedaddr()record points at an Account, with an optionalwhere: { coinType }filter. It does exact coinType matching.The gap
Under ENSIP-19/11, a Name's default EVM record (
coinType = DEFAULT_EVM_COIN_TYPE = 0x8000_0000) is the fallback address for every EVM chain that lacks a chain-specific record. Today:whereomittedwhere: { coinType: DEFAULT_EVM_COIN_TYPE }where: { coinType: <specific EVM coinType> }So the gap is chain-scoped queries don't fall back to the default record. The no-filter view (Portal's actual
/addr/$addr/resolutionUX) already surfaces default-record names, so this is a refinement for scoped consumers, deliberately deferred from the initial PR to keep v1 literal/exact.Why it's not a one-liner
Correct ENSIP-19 semantics are "
addr(CT)if present, elseaddr(DEFAULT)". A naivecoin_type IN (CT, DEFAULT)returns a Name via its default even when its CT-specific record points elsewhere (an override) → false positive. Proper expansion:…plus dedup, plus rules for which coinTypes the default covers (the
0x8000_xxxxEVM space; coinType 60 is a spec nuance).Also
AccountNameReferencesWhereInput.coinTypefield when/if this is implemented or explicitly left as-is.NameReference.match(indexed ENSIP-19 reverse shortcut) already does a reverse-side default fallback; the asymmetry with the forward filter is intentional for v1.Deferred from #1962 / #2292.