# Digital Asset Reliability Checklist — Protocol 001 Version: 1.0.0 Published: 2026-08-12 Status: Experimental / active Canonical: https://awesomedigitalassets.com/protocols/digital-asset-reliability-checklist-001 License: CC BY 4.0 for the original checklist text This worksheet helps a researcher preserve evidence, unknowns, and failure conditions before relying on a digital asset or platform. It does not certify an asset as safe and does not predict price, performance, legality, solvency, security, or future availability. ## Evidence labels - P — Primary: authority, filing, governing term, code, or first-party operating record. - I — Independent: credible third-party reporting, research, review, or analysis. - S — Self-asserted: issuer, promoter, or vendor claim without sufficient external support. - U — Unknown: no reliable evidence found, or available sources materially conflict. For every item, record: source URL; publisher; document date; access date; relevant support; label; confidence; what the source can support; what it cannot support; contradiction; and next verification action. ## 01 — Identity and claim Question: What exactly is being evaluated, and what is it claimed to do? - [ ] Canonical name, network, contract address, or other unique identifier - [ ] Issuer or responsible entity and canonical documentation - [ ] Plain-language holder rights, intended use, and source of promised benefit - [ ] Native, wrapped, bridged, staked, or tokenized versions distinguished Stop if the asset is identifiable only by ticker, official sources conflict, or the claim depends on guaranteed returns. ## 02 — Entity and accountability Question: Which people or organizations must perform, and can their claims be verified? - [ ] Legal name, jurisdiction, leadership, affiliates, and operating history - [ ] Registration or license claims checked in the authority’s own database - [ ] Conflicts, related-party roles, governing terms, and contact route - [ ] Correction, complaint, enforcement, insolvency, and litigation history Stop if a required counterparty cannot be identified, impersonation cannot be ruled out, or “regulated” has no named authority and verifiable record. ## 03 — Rights, control, and custody Question: Who can move, freeze, mint, burn, upgrade, recover, or lend the asset? - [ ] Private-key model, custodian, wallet type, recovery, and user responsibilities - [ ] Administrator keys, multisignature policy, signers, timelocks, emergency powers - [ ] Segregation, commingling, rehypothecation, subcontractors, bankruptcy treatment - [ ] Insurance 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. ## 04 — Backing and redemption Question: What supports the claim, and how can a holder actually redeem or exit? - [ ] Reserve assets, location, encumbrances, and responsible institutions - [ ] Holder’s legal claim; direct redemption distinguished from market sale - [ ] Eligible redeemers, minimums, fees, timing, suspension, and loss allocation - [ ] Audit or attestation date, scope, standard, preparer, exceptions, limitations Pause if proof-of-reserves language is treated as equivalent to a financial-statement audit, or a backed asset lacks inspectable redemption and reserve terms. ## 05 — Technology and operations Question: Which systems have to work, and how are failures detected and handled? - [ ] Network, contracts, bridges, oracles, front ends, APIs, wallets, off-chain dependencies - [ ] Code, deployment identifiers, upgrade path, reviews, and review scope - [ ] Incident history, status reporting, disclosure policy, monitoring, response owner - [ ] Concentration, availability, privacy, transaction, interoperability limits Pause when an audit logo has no report and scope, dependencies are unnamed, or an upgrade authority can materially change the claim without notice. ## 06 — Economics, liquidity, and exit Question: How are supply and incentives created, and what happens when many holders leave? - [ ] Issuance, allocation, vesting, unlocks, emissions, fees, burns, dilution - [ ] Venue/counterparty concentration, observed liquidity, withdrawal conditions - [ ] Direct redemption versus secondary-market dependence under stress - [ ] Beneficiaries of demand, issuance, fees, liquidations, governance Pause if supply, insider control, withdrawal restrictions, or the practical exit path cannot be explained with dated evidence. ## 07 — Fraud and communication signals Question: Does the offer rely on urgency, secrecy, impersonation, or untestable claims? - [ ] Domain and channel confirmed independently from the message or promoter - [ ] No guaranteed return, risk-free claim, advance crypto demand, or recovery fee - [ ] Specific explanation of fund use and how value is expected to arise - [ ] Transaction, geography, counterparty, and source-of-funds red flags reviewed Stop for guaranteed profits, requests to share secrets, unexpected payment instructions, or pressure to act before independent verification. ## 08 — Failure, recovery, and monitoring Question: What would break the current conclusion, and how would anyone know? - [ ] Insolvency, reserve loss, exploit, key loss, halt, depeg, capture scenarios - [ ] Detection, responsible party, communication, containment, and recovery - [ ] Loss allocation and promises, dependencies, or rights that may not survive - [ ] Review date, change triggers, unresolved questions, evidence refresh plan Do not issue a conclusion without explicit unknowns, invalidation conditions, and a dated plan to revisit material evidence. ## Decision Choose one. There is no “safe” result. - [ ] Stop — reject the claim because a hard stop is present or primary evidence contradicts it. - [ ] Hold — pause because material evidence is missing, stale, self-asserted, or conflicting. - [ ] Continue bounded evaluation — evidence is traceable and no hard stop is present; declare scope, exposure limit, review date, and failure plan. ## Required conclusion ### Demonstrated ### Claimed ### Unknown ### Invalidation conditions ## Limits This protocol is educational and general. It does not replace legal, tax, accounting, security, or investment review. Public evidence may be incomplete, manipulated, or outdated. An audit, attestation, license, or registration is evidence with scope, not a warranty. Absence of a known red flag is not evidence that an unknown risk is absent. ## Citation 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 Do not cite the protocol as proof that a particular asset or platform is reliable.