Tokenization review checklist
=============================

A practical review from asset definition and program rules to issuance, redemption, and operational evidence.

1. Define the underlying relationship
Write what one unit represents and who is responsible for the underlying service or asset. Identify the source documents and the unresolved questions. A token label should not substitute for an explanation of the program or imply rights that have not been established.

2. Separate the identities
Record the underlying asset, program version, network, and token reference as distinct linked records. Treat test and production instances separately. Keep historical identities when a contract changes rather than overwriting the earlier reference and breaking the meaning of old observations.

3. Document the permitted actions
Specify who may request, approve, submit, investigate, and change program settings. Distinguish technical authority from operational responsibility. Determine which policy questions require qualified review before implementation and keep the resulting decision separate from an address or token metadata label.

4. Version the supporting evidence
Link each issuance decision to the policy and document versions that applied at the time. Preserve the evidence behind the decision without publishing private documents in token metadata. Access to a token record should not automatically grant access to every linked file.

5. Review the issuance lifecycle
Keep the business request, approval, submission attempt, and observed result distinct. Define evidence for every state change. Give the original request a stable identity so a timeout does not cause a retry to create another issuance without checking whether the first attempt already took effect.

6. Separate balances from entitlements
Identify the authoritative source for an observed token balance and for any off-chain eligibility or service decision. Show unresolved mismatches instead of choosing whichever value looks more convenient. An on-chain observation should not automatically certify that an off-chain obligation has been fulfilled.

7. Plan redemption and exceptions
Describe how a redemption request relates to token retirement and to the promised service or settlement. Assign an owner to incomplete or conflicting states. Preserve the investigation and resolution history so the team can explain why the current record differs from the earlier one.

8. Exercise failure and recovery
Test a duplicate request, missing observation, incorrect metadata change, unavailable signer, and interrupted external service. Record what remains safe, what must stop, and what users are told. Review the recovery procedure before introducing production authority rather than improvising after a failure.

Reference design checklist, not certification.
Read the full guide: https://digitalassetapi.com/blog/tokenization-api-design/