Concepts
Canonical verification
A contract is a canonical Robinhood Stock Token deployment only if the Robinhood Stock Token registry lists that address for that chain. StockSync checks exactly that, and nothing else.
A matching ticker, token name or logo proves nothing: anyone can deploy a contract that copies them.
What StockSync checks
- The address is 0x followed by 40 hexadecimal characters. Mixed-case addresses must carry a valid EIP-55 checksum; all-lowercase addresses are accepted.
- The registry is searched for a deployment with that address on the requested chain.
- If you pass an expected ticker, the matched token is compared with it.
Verdicts
A not-canonical verdict carries a reason:
address-not-in-registry: no chain in the registry lists the address.registered-on-other-chain: the address is a Stock Token deployment on a different chain.registeredChainIdssays which.
Inactive tokens remain canonical. Check the token’s status separately.
Not verified is not malicious
not-canonical means StockSync cannot confirm the address is a Robinhood Stock Token. It is not a
finding that the contract is malicious, and no StockSync surface describes it that way. Treat it as
“do not use this address as a Stock Token”, not as a security verdict about the contract.
From the CLI
Without --strict, the command exits 0 whenever the check completes. With --strict, it exits
6 unless the address is canonical for the expected ticker, which makes it safe to use as a gate in
deployment scripts.
From an agent
The MCP tool verify_stock_token takes address, an optional expectedSymbol and an optional
chain. Its result includes status, a boolean canonical, the matched token, and an
explanation written for the model to relay. The server’s instructions tell agents that only this
tool establishes canonical status.
From the SDK
freshness is the registry response the verdict was based on. Verdicts are only as current as that
response, which StockSync reuses for up to one minute.