Every page on the site is reachable only by following links. Someone holding a transaction hash from a wallet, a NEAR hash from an explorer, or an address from a chat message has no way in, short of editing the URL by hand and knowing the grammar. A box in the chain header that takes whatever was pasted and opens the right page is the front door the site is missing.
The hard part: one string can be several things
Shape alone cannot decide, and CLAUDE.md already rules out deciding by shape ("An account is told from a hash by registry path, never by shape"). On this chain:
Pasted
Could be
0x + 64 hex
a block hash, an extrinsic hash (#48), an account id in hex, or a miner's reward preimage
64 hex, no 0x
a NEAR implicit account (ed25519)
0x + 40 hex
a NEAR implicit account (Ethereum address)
43–44 base58
a NEAR transaction hash
48–49 base58 starting qz
a Quantus SS58 address (prefix 189), checked by decoding it, never assumed
12D3KooW…
a telemetry node's peer id
digits
a block height (or a runtime spec_version, which is far smaller, so ambiguous only below a few hundred)
*.near, *.tg and other named ids
a NEAR account
So resolution is a lookup, not a guess.
What
GET /v1/chains/{chain}/search?q=<text> returns every route the string resolves to, each confirmed against data, not shape:
block: by height (at most the tip) or by hash, from block;
extrinsic: by hash, from chain_extrinsic.hash (#48);
account: a valid SS58 address, or hex that is a known account;
miner: a preimage this observer has attributed blocks to;
node: a peer id the telemetry feed knows;
runtime: a spec_version in the runtime history;
NEAR transaction: a base58 32-byte hash, offered as a candidate; the transaction page resolves it, since checking first would spend the public endpoint's rate limit on typing;
Intents account: a valid NEAR account id.
Each result carries its route and a one-line label ("block #180,029", "extrinsic 1 of block #180,029", "account qzmo…gqPf").
The header box:
One match: go straight there.
Several matches: a short list to choose from, each with its label. Choosing for the user is how a block hash would open as an account.
None: say what the input looked like and what was checked ("not a block, extrinsic or account this observer has indexed"). A "not found" with no context reads as the site being broken.
A miss on an extrinsic hash older than the #48 backfill says the backfill is still running, not that the transaction does not exist.
It sits in the chain header so it searches the chain being viewed. NEAR lookups need no chain, but the NEAR pages are chain-scoped (#44). Whitespace is trimmed and 0x is case-insensitive. The input never reaches a node verbatim: every candidate is validated by the same checks the routes use (valid_tx_hash, valid_account, SS58 decode).
It must work at phone width, keyboard first: Enter goes, Escape clears, and the result list is navigable by arrow keys.
Depends on #48 for extrinsic hashes; everything else can ship before it.
## Why
Every page on the site is reachable only by following links. Someone holding a transaction hash from a wallet, a NEAR hash from an explorer, or an address from a chat message has no way in, short of editing the URL by hand and knowing the grammar. A box in the chain header that takes whatever was pasted and opens the right page is the front door the site is missing.
## The hard part: one string can be several things
Shape alone cannot decide, and CLAUDE.md already rules out deciding by shape ("An account is told from a hash by registry path, never by shape"). On this chain:
| Pasted | Could be |
|---|---|
| `0x` + 64 hex | a block hash, an extrinsic hash (#48), an account id in hex, or a miner's reward preimage |
| 64 hex, no `0x` | a NEAR implicit account (ed25519) |
| `0x` + 40 hex | a NEAR implicit account (Ethereum address) |
| 43–44 base58 | a NEAR transaction hash |
| 48–49 base58 starting `qz` | a Quantus SS58 address (prefix 189), checked by decoding it, never assumed |
| `12D3KooW…` | a telemetry node's peer id |
| digits | a block height (or a runtime `spec_version`, which is far smaller, so ambiguous only below a few hundred) |
| `*.near`, `*.tg` and other named ids | a NEAR account |
So resolution is a **lookup**, not a guess.
## What
**`GET /v1/chains/{chain}/search?q=<text>`** returns every route the string resolves to, each confirmed against data, not shape:
- **block:** by height (at most the tip) or by hash, from `block`;
- **extrinsic:** by hash, from `chain_extrinsic.hash` (#48);
- **account:** a valid SS58 address, or hex that is a known account;
- **miner:** a preimage this observer has attributed blocks to;
- **node:** a peer id the telemetry feed knows;
- **runtime:** a `spec_version` in the runtime history;
- **NEAR transaction:** a base58 32-byte hash, offered as a candidate; the transaction page resolves it, since checking first would spend the public endpoint's rate limit on typing;
- **Intents account:** a valid NEAR account id.
Each result carries its route and a one-line label ("block #180,029", "extrinsic 1 of block #180,029", "account qzmo…gqPf").
**The header box:**
- **One match:** go straight there.
- **Several matches:** a short list to choose from, each with its label. Choosing for the user is how a block hash would open as an account.
- **None:** say what the input looked like and what was checked ("not a block, extrinsic or account this observer has indexed"). A "not found" with no context reads as the site being broken.
- **A miss on an extrinsic hash older than the #48 backfill** says the backfill is still running, not that the transaction does not exist.
It sits in the chain header so it searches the chain being viewed. NEAR lookups need no chain, but the NEAR pages are chain-scoped (#44). Whitespace is trimmed and `0x` is case-insensitive. The input never reaches a node verbatim: every candidate is validated by the same checks the routes use (`valid_tx_hash`, `valid_account`, SS58 decode).
It must work at phone width, keyboard first: Enter goes, Escape clears, and the result list is navigable by arrow keys.
Depends on #48 for extrinsic hashes; everything else can ship before it.
Related: #44, #48.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Why
Every page on the site is reachable only by following links. Someone holding a transaction hash from a wallet, a NEAR hash from an explorer, or an address from a chat message has no way in, short of editing the URL by hand and knowing the grammar. A box in the chain header that takes whatever was pasted and opens the right page is the front door the site is missing.
The hard part: one string can be several things
Shape alone cannot decide, and CLAUDE.md already rules out deciding by shape ("An account is told from a hash by registry path, never by shape"). On this chain:
0x+ 64 hex0x0x+ 40 hexqz12D3KooW…spec_version, which is far smaller, so ambiguous only below a few hundred)*.near,*.tgand other named idsSo resolution is a lookup, not a guess.
What
GET /v1/chains/{chain}/search?q=<text>returns every route the string resolves to, each confirmed against data, not shape:block;chain_extrinsic.hash(#48);spec_versionin the runtime history;Each result carries its route and a one-line label ("block #180,029", "extrinsic 1 of block #180,029", "account qzmo…gqPf").
The header box:
It sits in the chain header so it searches the chain being viewed. NEAR lookups need no chain, but the NEAR pages are chain-scoped (#44). Whitespace is trimmed and
0xis case-insensitive. The input never reaches a node verbatim: every candidate is validated by the same checks the routes use (valid_tx_hash,valid_account, SS58 decode).It must work at phone width, keyboard first: Enter goes, Escape clears, and the result list is navigable by arrow keys.
Depends on #48 for extrinsic hashes; everything else can ship before it.
Related: #44, #48.