fix(frontend): warn instead of blocking on incomplete token listings

[jayteemoney]

Summary

Follow-up to #31. That PR merged with a behaviour that blocks exactly the case the token selector exists to serve.

classifyToken marked a listing unusable when it had no symbol, or when the registry reported a supply of zero, and unusable rows are rendered non-selectable. A team that deploys a token and streams in the same session can hit a supply of zero that has simply not been indexed yet, and is then told the token cannot receive a stream.

Both cases are now non-blocking warnings, rendered in neutral grey in the result list and repeated at the confirm step where the user is actually deciding.

What changed

• Missing ticker → warning. The symbol is display metadata; asset name and decimals come from the chain, and the resolver can supply the symbol via get-symbol.
• Reported supply of zero → warning. Supply lags and is a hint. A transfer that cannot execute fails loudly on-chain and costs a fee; it cannot send value to the wrong place.
• unusable now has exactly one producer: no asset name. That is not a warning but the absence of an identity — the row cannot say which asset it describes, so there is nothing to resolve.
• New warnings field on DiscoveredToken, threaded through classifyAll / dedupeByContract / RegistryCandidate.
• Guarded the impersonation lookup against an empty symbol, so a token with no ticker cannot match an empty curated-symbol key. An impersonator that is also incomplete still reports as an impersonator.

Safety

Unchanged. assetName and decimals still come from the chain in verifySelection, and the transaction builder consumes the resolved values — toSelection reads decimals/symbol off result.resolved, never off the registry row. Classification only decides what the user is told; verification decides what they can spend.

Impersonators keep their existing red badge, principal-to-principal comparison, and explicit confirm step.

Verification

• npx vitest run — 191 passed (48 in token-registry.test.ts, up from 43; five new cases covering each warning, the empty-symbol impersonation guard, and that a warned token still verifies normally).
• frontend tsc --noEmit — clean.
• frontend npm run build — clean.
• frontend npm run lint — 14 errors / 4 warnings, byte-identical to the pre-existing baseline; no new findings.

Note: the Run test suite checks are currently red across every branch, including main. The cause is not code — GitHub reports The job was not started because your account is locked due to a billing issue. Verification here was done locally.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
stackstream	Ready	Preview	Oct 2, 2026 1:41pm UTC