Digital Asset
Reliability Checklist
What should be checked before relying on a digital asset or platform? Start with identity, rights, counterparties, control, custody, backing, technical dependencies, exit conditions, fraud signals, and the failure plan.
A reliable claim is traceable, not merely convincing.
Do not begin with price, popularity, or a composite score. Identify the exact asset or service; map the rights and obligations; verify the people, entities, custody model, reserves, and critical systems; then write down how the claim can fail.
This protocol never certifies an asset as safe. Its output is an evidence ledger, explicit unknowns, hard stops, and a dated decision about whether further evaluation is justified.
A research method should be testable and revisable.
Public guidance about digital assets often names individual risks without giving readers a durable way to preserve evidence, contradictions, and unknowns. Protocol 001 turns those questions into a repeatable worksheet with explicit stop rules and a required conclusion format.
The version number makes later changes visible. The method should improve only when documented use, new primary evidence, or a material failure reveals a better question or threshold—not because a convenient conclusion is preferred.
Eight checks. Four evidence labels. No safety grade.
For every claim, retain the URL, publisher, document date, access date, quoted or paraphrased support, and the conclusion it can—and cannot—support.
Authority, filing, governing term, code, or first-party operating record.
Credible third-party reporting, research, review, or technical analysis.
Issuer, promoter, or vendor claim without sufficient external support.
No reliable evidence found, or available sources materially conflict.
Identity and claim
What exactly is being evaluated, and what is it claimed to do?
Evidence to retain
- Canonical name, network, contract address or other unique identifier
- Issuer or responsible entity and the canonical documentation
- Plain-language holder rights, intended use, and source of any promised benefit
- Differences among native, wrapped, bridged, staked, or tokenized versions
Stop if the asset is identifiable only by ticker, official sources conflict, or the claim depends on guaranteed returns.
Entity and accountability
Which people or organizations must perform, and can their claims be verified?
Evidence to retain
- Legal name, jurisdiction, leadership, affiliates, and operating history
- Registration or license claims checked in the named authority’s own database
- Conflicts, related-party roles, governing terms, and a usable contact route
- Correction, complaint, enforcement, insolvency, and litigation history
Stop if a required counterparty cannot be identified, impersonation cannot be ruled out, or “regulated” is asserted without a named authority and verifiable record.
Rights, control, and custody
Who can move, freeze, mint, burn, upgrade, recover, or lend the asset?
Evidence to retain
- Private-key model, custodian, wallet type, recovery process, and user responsibilities
- Administrator keys, multisignature policy, signers, timelocks, and emergency powers
- Segregation, commingling, rehypothecation, subcontractors, and bankruptcy treatment
- Insurance language with provider, coverage, exclusions, limits, and beneficiary
Stop if anyone asks for a seed phrase or private key. Pause if custody, ownership, lending, or recovery terms are missing or contradictory.
Backing and redemption
What supports the claim, and how can a holder actually redeem or exit?
Evidence to retain
- Reserve assets, reserve location, encumbrances, and responsible institutions
- Holder’s legal claim and the difference between direct redemption and market sale
- Eligible redeemers, minimums, fees, timing, suspension rights, and loss allocation
- Audit or attestation date, scope, standard, preparer, exceptions, and limitations
Pause if proof-of-reserves language is presented as equivalent to a financial-statement audit, or if a backed asset has no inspectable redemption and reserve terms.
Technology and operations
Which systems have to work, and how are failures detected and handled?
Evidence to retain
- Network, contracts, bridges, oracles, front ends, APIs, wallets, and off-chain dependencies
- Source code, deployment identifiers, upgrade path, security reviews, and review scope
- Incident history, status reporting, disclosure policy, monitoring, and response owner
- Known concentration, availability, privacy, transaction, and interoperability limits
Pause when an audit logo has no report and scope, critical dependencies are unnamed, or an upgrade authority can materially change the claim without notice.
Economics, liquidity, and exit
How are supply and incentives created, and what happens when many holders leave?
Evidence to retain
- Issuance, allocation, vesting, unlocks, emissions, fees, burns, and dilution
- Venue and counterparty concentration, observed liquidity, and withdrawal conditions
- Direct redemption versus secondary-market dependence under normal and stressed conditions
- Who benefits from demand, issuance, fees, liquidations, or governance decisions
Pause if future supply, insider control, withdrawal restrictions, or the practical exit path cannot be explained with dated evidence.
Fraud and communication signals
Does the offer rely on urgency, secrecy, impersonation, or claims that cannot be tested?
Evidence to retain
- Official domain and channel confirmation independent of the message or promoter
- No guaranteed return, risk-free claim, advance crypto demand, or recovery-fee demand
- Specific explanation of how funds are used and how value is expected to arise
- Transaction, geography, counterparty, and source-of-funds red flags where relevant
Stop for guaranteed profits, requests to share secrets, unexpected payment instructions, or pressure to act before independent verification.
Failure, recovery, and monitoring
What would break the current conclusion, and how would anyone know?
Evidence to retain
- Named failure cases: insolvency, reserve loss, exploit, key loss, halt, depeg, or governance capture
- Detection signal, responsible party, communication path, containment, and recovery plan
- Who bears loss and which promise, dependency, or legal right may not survive failure
- Review date, change triggers, unresolved questions, and evidence that must be refreshed
Do not issue a conclusion without explicit unknowns, invalidation conditions, and a dated plan to revisit material evidence.
The protocol has no “safe” result.
Reject the claim
A hard-stop signal is present, identity cannot be verified, secrets are requested, or the central promise is contradicted by primary evidence.
Pause and verify
Material evidence is missing, stale, self-asserted, or conflicting. Record what would resolve the uncertainty and do not treat absence of proof as proof.
Bounded evaluation only
Required evidence is traceable and no hard stop is present. Continue only within a declared scope, exposure limit, review date, and failure plan.
End with four blocks, not one score.
- Demonstrated: claims supported by inspectable, dated evidence.
- Claimed: statements that still depend on the interested party’s account.
- Unknown: missing or conflicting evidence that could change the decision.
- Invalidation conditions: events or discoveries that would break the current conclusion.
What Protocol 001 cannot establish
- It does not predict price, performance, legality, solvency, security, or future availability.
- It does not replace jurisdiction-specific legal, tax, accounting, security, or investment review.
- Public evidence can be incomplete, inaccurate, manipulated, or outdated after collection.
- An audit, attestation, license, registration, or long operating history is evidence with scope—not a warranty.
- Absence of a known red flag is not evidence that an unknown risk is absent.
- The checklist is experimental. Categories and thresholds change only through a dated version and change log.
How to reference this protocol
Awesome Digital Assets Editorial Desk. “Digital Asset Reliability Checklist — Protocol 001.” Version 1.0.0, August 12, 2026. https://awesomedigitalassets.com/protocols/digital-asset-reliability-checklist-001
When applying the checklist, cite the protocol version and preserve your own evidence ledger. Do not cite the protocol as proof that a particular asset or platform is reliable.
Protocol history
Initial experimental release. Eight reliability checks, four evidence labels, three decision states, hard-stop rules, limitations, worksheet, and evidence-ledger download.
Sources used to design Protocol 001
- Use Caution When Buying Digital Coins or TokensU.S. Commodity Futures Trading Commission ↗
- Crypto Asset Custody Basics for Retail InvestorsInvestor.gov / SEC staff ↗
- Caution With Alternatives to Financial Statement AuditsInvestor.gov / SEC staff ↗
- Crypto Assets — RisksFINRA ↗
- Digital Asset and Crypto Trading Website Fraud AlertCFTC and SEC staff ↗
- Virtual Assets Red Flag IndicatorsFinancial Action Task Force ↗
- Deposit Insurance and Crypto CompaniesFederal Deposit Insurance Corporation ↗
- Blockchain Networks: Token Design and Management OverviewNational Institute of Standards and Technology ↗
This open protocol is educational and general. It is not financial, investment, legal, tax, accounting, or security advice. CC BY 4.0 applies to the original checklist text; cited sources retain their own terms.