Why Canonical Contract Addresses Matter for Stock Tokens and LP Positions

ERC-20 metadata is permissionless. Anyone can deploy a token named after a public company, reuse a familiar symbol and publish a convincing logo. The same is true for an LP-like token that implements balanceOf and transferFrom. A user interface that searches by symbol can therefore display a counterfeit asset with no connection to the intended issuer or market.

Canonical identity is a tuple: network, contract address and authoritative source. All three matter. The right address on the wrong chain may have no code or unrelated code. The right symbol at a different address is a different token. An authoritative list that has not been checked against current bytecode may be stale.

Robinhood's contract page tells developers to use its listed addresses to identify canonical Stock Tokens and warns that a matching ticker at another address is not a Robinhood Stock Token. Its asset API also provides per-chain deployment addresses. These primary sources are stronger than community token lists or search-engine results.

For liquidity protocols, the factory or manager is the identity root. Uniswap publishes deployment addresses by network. A V2 pair should be returned by the configured factory for its exact token pair. A V3 or V4 position should be owned and described by the configured canonical position manager.

An address record should be followed by a live code check. Confirm that code exists on the intended chain, then inspect immutable or public wiring such as factory, pool manager or implementation address. Record the runtime code hash for the release. These checks catch wrong networks, incomplete deployments and contracts whose interfaces look correct while their dependencies differ.

Proxy contracts require an additional layer. The proxy address may stay constant while the implementation changes. Monitoring therefore needs both the user-facing proxy and its current implementation, upgrade authority and timelock. A source-verified proxy with an unreviewed implementation is not a fully understood system.

A locker cannot delegate identity checks to its front end because users can call contracts directly. For V2, the contract should verify the candidate pair's factory and tokens, then ask the immutable factory for the canonical pair. The transfer occurs only after all values match. This prevents a fake ERC-20 from being presented as official liquidity.

For NFT positions, the locker should accept transfers only from the immutable manager and only during an expected lock operation. That narrows the callback surface and prevents unrelated NFTs from becoming confusing or unrecoverable deposits. Canonical manager allowlisting also makes fee-collection behavior predictable enough to enforce principal invariants.

A release manifest should bind chain ID, address, deployment transaction, block number, runtime hash, compiler metadata and source-verification state. Interfaces read from that manifest rather than duplicating addresses across components. If evidence is missing, the transaction path stays disabled.

Wallet discovery follows the same principle. Explorer indexes are useful candidate sources, but current ownership and canonical identity are settled onchain. Reconciling indexed data with live reads avoids stale positions while limiting expensive broad chain scans.