Token Identity Checklist for Crypto Creator Briefs

Identify the asset before approving the words

Names, logos and symbols are useful labels, but they do not uniquely identify every crypto asset. A project can have deployments on several networks, while an unrelated asset may use a similar name. A creator brief needs to specify which deployment the content describes, including whether it is live, a test environment or an old version.

For an EVM token contract, retain the full network identifier and contract address from the project’s official record. For a native asset, use the appropriate native identifier rather than demanding a token contract that does not exist. Other ecosystems use their own forms of asset identification; ask the product owner to supply the correct reference instead of converting everything into an Ethereum-style address.

CAIP-19 provides a structured asset-identification scheme built on a chain identifier and an asset reference. Its specification remains labelled Review. It can inform a technical record, but a campaign team should not describe its use as a certification or claim that every platform accepts the same encoding.

Separate identity from the claims around it

Keep these questions separate in the review. A matching contract address can resolve which asset a screenshot shows without supporting a claim about reserves, yield or security. An audit logo can identify a firm without demonstrating that its report covers the version on screen.

A creator should be able to describe an unresolved issue narrowly. “The supplied report does not identify this deployment” is an evidence gap. It is not proof of misconduct. Escalate the gap to the named product reviewer and hold the affected wording rather than publishing an accusation.

Use one source record for the whole creative package

Put the identity reference in the crypto creator campaign brief and assign a version. The script writer, editor and publisher should all work from that version. A correct spoken name does not repair a screen capture, thumbnail or destination showing a different deployment.

Use the full technical identifier in the controlled reference. A short excerpt can help a viewer distinguish an on-screen item, but the publisher should compare against the full record. Never replace the real reference with a shortened address merely to make the layout tidy.

Check agreement between official sources

Start from a known official domain or a reference supplied through the established project contact. Follow its link to the documentation and relevant explorer record. Check the requested network, identifier and lifecycle state across those sources. A search result with the right logo is not sufficient evidence by itself.

Record exactly what the reviewer checked and when. A screenshot can preserve what a source displayed at that moment, while the source URL lets another reviewer inspect it again. Neither should disappear into a chat message with no connection to the asset being approved.

If the official site and documentation disagree, stop the affected claim or destination. Ask the responsible owner to resolve the conflict in the official record, then record the resolution. Do not silently select whichever source makes the planned message easier to publish.

Avoid copying private material into the public record. A campaign worksheet can reference controlled verification without including private keys, recovery phrases, personal account details or confidential contracts. The creator needs permitted public facts and a safe recording setup.

Work through a migration before filming

In this invented example, a product is moving an issued token from contract A to contract B. The brief calls B current, the documentation still links to A, and the planned screen recording uses an older interface. The article supplies no real address and makes no recommendation about an asset.

The reviewer identifies three separate problems: the public source conflicts with the brief, the recorded interface can show the wrong deployment, and the caption lacks a clear effective point for the change. A generic instruction to use the new ticker would fix none of them.

Request the official migration notice, the network and full identifiers, the status of each deployment and the intended timing. The product owner resolves the documentation mismatch. The producer records the approved environment. The publisher checks the final caption and destination against the same record immediately before release.

If the migration has not taken effect, describe the present state and the announced future state separately, with the project’s conditions attached. If the team cannot substantiate the timing, omit the claim. Preserve the old asset’s context rather than relabelling old footage as a current demonstration.

Carry the reference through editing and publication

Use the crypto claim-review ledger for factual wording beyond identity. Mark where an identifier or network appears in the spoken explanation, screen capture, caption, description, thumbnail and linked page. Review each actual surface that a viewer can receive, including cutdowns that omit the opening context.

Test the destination as the audience will encounter it. Confirm that the live page matches the approved purpose and that a redirect has not moved the visitor elsewhere. Keep participation terms and eligibility questions with the appropriate owner; a creator’s source check cannot settle them for an individual viewer.

Retain the final asset version and publication URL. If the project changes later, the identity record should identify the affected placements. Update or retire stale content through the agreed correction path instead of hoping that an audience will discover a later reply.

Set a narrow acceptance decision

A release decision should name the exact creative version, record version and sources it covers. “Token verified” is too broad. A useful acceptance entry might state that the shown network and identifier matched the official source at the recorded check time, while a proposed audit claim remains withheld.

Recheck when a deployment, source, interface or destination changes before publication. An unchanged file can still describe changed product facts. Assign a person who can pause the affected placement and a person who can obtain the corrected record.

The completed handoff should leave the creator able to explain the intended product accurately and the publisher able to identify when that explanation needs review again. It should not turn the creator into an auditor, an investment adviser or a guarantee that the project is safe.