Understand reviewed project identity

Start with the deployed contract #

Any token contract on Robinhood Chain can receive contract reads and address-based explorer and market lookups. Start with Token discovery to inspect a token that has no reviewed project profile.

The project identity method adds a specific comparison between a deployed contract and its reviewed published sources. Names, symbols, discovered links and market listings cannot establish that match on their own.

Check a reviewed project profile #

The optional profiles in projects.json specify the exact chain, contract, website token section, GitHub profile and account links used by this identity method. A profile configures the check; it does not prefill a successful result.

You can run the scanner for an address without a profile. Its contract, explorer and market lookups still run. The reviewed project identity check explains that it is outside coverage, while retaining any other evidence collected.

Read the published evidence #

For the current observation, the scanner fetches the reviewed website and GitHub profile. Both must publish the exact contract and Robinhood Chain claim, and both must carry the expected links between the project website, GitHub and X accounts. A conflicting or missing required claim prevents that source from matching.

The X profile itself is not queried. Its link is supporting context obtained from the website and GitHub. Account existence, a follower count or a copied token symbol cannot establish identity.

The report records each source URL, retrieval time, discovered addresses, matching fields and any conflict or unavailable response. When a response body can be read, a SHA-256 hash identifies the content checked.

Understand the classification #

A deployed contract with an exact issuer-registry match is classified as an issuer Stock Token. A deployed contract with both reviewed project sources matching is classified as a project token. When neither requirement is established, it remains unclassified.

Registry absence does not establish a project token. A failed source does not fall back to the profile’s earlier review. The report keeps any usable evidence and explains what prevented classification.

Conflicting issuer-registry entries or overlapping issuer and project identities leave the classification unclassified for review. Published project claims can still match when RPC is unavailable, but the report cannot classify a project token until it establishes deployed code at a consistent block.

Keep the identity claim in scope #

The project may control its website, GitHub and X account. Agreement between those sources ties their published claims to the checked contract; it does not supply an independent endorsement or prove who controls the contract today. A content hash is a record of the response body, not a publisher signature.

Project identity does not establish reserves, ownership rights, token utility, code safety, liquidity or an execution price. Those claims require their own supported sources and methods. PeelSignal does not add an oracle mapping or a market quote because a project identity matches.

Read the panels alongside project identity #

The four panel labels keep their existing meanings. Contract provenance checks issuer Stock Token identity, so a project token can show Unrecognized there while its separate project identity evidence matches. Canonical is reserved for the issuer method.

Price and exposure checks explain their applicability and missing reviewed methods. Not confirmed always concerns personal eligibility; it does not mean a product has failed to launch.

Handle changed or unavailable sources #

If a reviewed source changes its address, chain or account links, the next check records the mismatch. A timeout, refused connection, unreadable response or unsupported page structure prevents a complete identity match. The scanner does not silently accept an old review or search for a more favorable source.

Open the source details, compare the public claims and retry when a temporary outage has cleared. For a changed profile or an unsupported project, follow Source review. The scanner does not accept user-supplied URLs.

Allow for source request limits #

GitHub’s public REST API permits 60 unauthenticated requests per hour per originating IP. Visitors can share that server quota. A rate-limit response makes the source unavailable for the observation; the scanner respects the supplied retry or reset time instead of substituting an earlier match. See GitHub’s rate-limit documentation .

An operator can configure GITHUB_READ_TOKEN on the server for the fixed reviewed GitHub API endpoint. The token is never sent to the project website or stored in a receipt. This configuration does not change identity rules or guarantee that the source will always be available.

Keep the evidence and its time #

A receipt preserves contract metadata, classification, check applicability and outcomes, project evidence, policy and project coverage versions, source times and expiry. It stores extracted claims and hashes, rather than a full archived page. Schema v3 also records automatic token discovery.

Recheck creates a new receipt. Earlier v1 and v2 receipts remain unchanged and cannot acquire later discovery evidence retroactively. See Receipts for sharing and Machine-readable files for the schemas.