feat(frontend): let teams stream their own SIP-010 token

[jayteemoney]

Follow-up to #30. The create-stream selector was a hardcoded list of four curated tokens, so a team could not stream its own token without a code change — even though stream-manager.clar is permissionless and #30 already made uncurated tokens safe to resolve.

Why search, not a list

Hiro's token metadata API indexes every SIP-010 token (~5.6k), but a flat dropdown of that is not shippable. symbol=sBTC returns 32 contracts including buttcoin-stxcity and sBTC-mock-vpv-10. Sampling the default listing order showed 0% usable rows in the first few hundred — no symbol, no name, no supply.

So the shape is three entry paths in trust order: curated tokens pinned first, then search over the registry, then a contract id.

Discovery is separate from trust

verifySelection in lib/token-registry.ts is the single gate from a suggestion to a transaction:

• decimals and assetName are re-proven on-chain by the existing resolver. The registry's values are never used for a post-condition.
• I verified the registry's decimals against get-decimals on 25 indexed tokens: 25/25 agreed. But "has always agreed" is not a property a payment should depend on, and an indexer is one deploy behind the chain forever.
• A resolver failure is unverifiable — never a fallback token. Regression-tested against the exact bug fix: resolve token metadata from chain instead of assuming sBTC #30 fixed.

Because the gate is one-directional, the registry can be wrong, stale, or fully down without any path to a misdirected payment.

How users get a contract id

Not by typing it. A team puts /dashboard/create?token=SP….contract-name in its docs or Slack and the recipient clicks it. That resolves from the chain, so it also works for tokens deployed minutes ago that the registry has not indexed, and when the registry is down.

Worth noting: the registry's /search endpoint returns contract_id and token_number with no asset identifier at all, so the asset name for a post-condition cannot come from there even in principle. That path therefore takes only cosmetics from the registry and everything load-bearing from the chain.

Friction: warn, never block

• An impersonator — any contract claiming a curated symbol — is flagged explicitly, listed below the real one, and shows the canonical contract id alongside it for comparison.
• Unverified tokens are selectable, since blocking would defeat onboarding, but require an explicit confirm that displays the full principal.
• The full principal is always visible with a copy button. A mistyped-but-real contract id resolving to a different token is only catchable by seeing the whole string.
• Zero supply is unselectable. Unknown supply is not — a deep-linked token carries no supply figure, and treating unknown as zero would make every unindexed token unusable, which is exactly the case that path exists to serve.

Verified against mainnet

[curated     ] USDA   asset=usda        dec=6
[curated     ] sBTC   asset=sbtc-token  dec=8
[impersonator] sBTC   asset=sBTC        dec=6   !! impersonates SM3VDXK3…sbtc-token

Disagreement between listing and contract downgrades to unverified and is refused: "Token listing reports 2 decimals but the contract reports 6."

Verification

• 186 tests pass (43 new, network-free)
• npx tsc --noEmit clean
• npm run build clean
• lint unchanged at the pre-existing 14 errors / 4 warnings

Not addressed here

Multi-asset contracts (sBTC, ALEX) still have no disambiguating read-only function. They work via their curated entries, but a new multi-asset token would need a contract-side identifier. The registry cannot solve this — it indexes only one asset per such contract.

[vercel]

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

Project	Deployment	Actions	Updated
stackstream	Ready	Preview	Oct 2, 2026 12:36pm UTC