Crypto Research Workflow Template: A Copyable Evidence Ledger

Key takeaway: A good crypto research workflow leaves an audit trail. Define the asset and question, inventory claims, collect primary evidence, align dates and definitions, run market, protocol, security, token, and liquidity checks, record contradictory evidence, then set explicit invalidation and review triggers. The copyable template below is the working document; it does not produce a buy or sell instruction.

What is a crypto research workflow?

A crypto research workflow is a repeatable sequence for turning an asset or protocol question into a sourced, testable, updateable research record.

It should answer:

• What exactly did you research?
• Which claim or decision context set the scope?
• What evidence supports and contradicts each material conclusion?
• Which calculations can another reader reproduce?
• What remains unknown?
• What event makes the report stale?

This page owns the working document and evidence ledger. Use AI vs Manual Crypto Research to decide which tasks your agent can gather and which judgments must remain human. Use What to Check Before Buying Crypto for the concise evidence categories and the manual DYOR checklist for the exhaustive checklist.

Scope and assumptions: The template covers public research on fungible cryptoassets and protocols. Remove irrelevant modules rather than filling them with guesses. It does not determine personal suitability, position size, legal status, or tax treatment.

This is research, not financial advice. BlockMind does not tell you what to buy or sell, and its agent cannot trade, withdraw, approve, or move funds.

How to use this template

1. Copy the master template into a durable note.
2. Complete the scope before gathering evidence.
3. Give every material claim a stable ID.
4. Prefer primary sources and preserve retrieval dates.
5. Recalculate important formulas.
6. Keep observations separate from interpretations.
7. Require counterevidence and unknowns.
8. End with review triggers, not a permanent verdict.

Do not delete old conclusions when evidence changes. Append a dated revision so the reasoning remains inspectable.

The master crypto research template

Copy everything inside this block:

# [ASSET / PROTOCOL] RESEARCH RECORD

STATUS: Draft / Reviewed / Needs update / Archived
CREATED (UTC):
LAST VERIFIED (UTC):
OWNER:
REVIEWER:
NEXT CALENDAR REVIEW:

## 1. RESEARCH BRIEF

Exact asset:
- Name:
- Symbol:
- Chain/network:
- Contract or native identifier:
- Canonical website:
- Canonical repositories:

Question:
Time horizon:
Decision context:
Comparison set:
Out of scope:

Working hypothesis:
Evidence that would support it:
Evidence that would contradict it:

## 2. SOURCE AND DEFINITION RULES

Research timestamp:
Timezone:
Reference currency:
Price methodology:
Circulating-supply definition:
Volume methodology:
On-chain label provider and caveats:

Source priority:
1. Deployed state / signed primary record / official registry
2. Current official documentation or governance
3. Independent auditor, regulator, or methodology-led data provider
4. Reputable secondary analysis
5. Social commentary as a lead only

## 3. CLAIM LEDGER

| ID | Material claim | Claim owner | Evidence required | Status | Contradiction | Freshness |
|----|----------------|-------------|-------------------|--------|---------------|-----------|
| C-01 |              |             |                   |        |               |           |

Statuses: verified / partly verified / unverified / contradicted / stale

## 4. PROJECT AND RIGHTS

Problem and user:
Mechanism in plain language:
Tokenholder rights:
Where rights are enforced:
Legal entity / governance body:
Key dependencies and trust assumptions:

Actor and permission map:
| Actor | Power | Constraint | Failure mode | Evidence |
|-------|-------|------------|--------------|----------|

## 5. PRODUCT AND ADOPTION

Current shipped product:
Target user:
Usage metrics and definitions:
Retention evidence:
Fees / revenue and definitions:
Incentive-adjusted interpretation:
Competitors and switching costs:
What product success does NOT prove about the token:

## 6. TOKEN AND SUPPLY

Reference price and timestamp:
Circulating supply:
Unlocked supply:
Total supply:
Maximum supply / change authority:
Market cap calculation:
FDV calculation:

Allocation table:
| Class | Tokens/% | Recipient | Lock/vesting | Control | Source |
|-------|----------|-----------|--------------|---------|--------|

3/6/12/24-month supply bridge:
| Window | Unlocks | Emissions | Burns | Estimated new circulation | Assumptions |
|--------|---------|-----------|-------|---------------------------|-------------|

Token utility and value-capture chain:
Supply discrepancies:

## 7. TEAM, GOVERNANCE, AND DEVELOPMENT

Team identity evidence:
Prior work and counterparty confirmation:
Conflicts and compensation:

Governance:
- Proposal threshold:
- Quorum/approval:
- Delegation concentration:
- Guardian/veto/admin powers:
- Execution history:

Repository-to-product map:
| Component | Repository | Review/test evidence | Release | Live version/address |
|-----------|------------|----------------------|---------|----------------------|

Maintenance concentration and security process:

## 8. SECURITY

Current deployments:
Proxy / implementation / admin:
Pause, freeze, mint, rescue, and upgrade powers:

Audit map:
| Auditor | Final report | Commit/scope | Findings unresolved | Current deployment match |
|---------|--------------|--------------|---------------------|--------------------------|

Bug bounty:
Testing / formal methods:
Dependencies / oracles / bridges:
Incident history and response:
Residual risks:

## 9. MARKET AND LIQUIDITY

Market regime:
Higher-timeframe structure:
Relative strength:
Spot participation:
Leverage/funding/open interest:

Liquidity tests (timestamped):
| Venue/route | Spread | 1% bid/ask depth | Small impact | Medium impact | Stress impact |
|-------------|--------|------------------|--------------|---------------|---------------|

Venue and LP concentration:
Quote-asset and access risks:

## 10. ON-CHAIN AND COMMUNITY

Holder/entity concentration:
Treasury and known wallets:
Exchange/whale flows with label confidence:
Internal-flow adjustments:

Community sample windows:
Support resolution:
Critical-question handling:
Contribution/governance output:
Incentive or coordinated-looking activity:

## 11. CATALYSTS AND FAILURE MODES

| Date/window | Event | Mechanism | Confirmation | Counterevidence | Source |
|-------------|-------|-----------|--------------|-----------------|--------|

Pre-mortem: Assume the thesis fails. Most plausible causes:
1.
2.
3.

## 12. EVIDENCE SUMMARY

Strongest supporting evidence:
1.
2.
3.

Strongest contradictory evidence:
1.
2.
3.

Unknowns that could change the conclusion:
1.
2.
3.

## 13. CONCLUSION

Observation summary:
Interpretation:
Confidence: low / medium / high, with reason
Structural invalidation:
What this report does NOT conclude:

## 14. MONITORING AND CHANGE LOG

Event triggers:
- Contract upgrade or admin change
- Material audit or incident
- Supply/unlock threshold
- Liquidity deterioration threshold
- Governance or team change
- Product/adoption threshold
- Thesis invalidation

Change log:
| Date | Claim/section | Old evidence | New evidence | Conclusion changed? | Reviewer |
|------|---------------|--------------|--------------|---------------------|----------|

## 15. SOURCE LEDGER

| ID | Source | Type | Published | Retrieved UTC | Supports | Archive/hash | Limits |
|----|--------|------|-----------|---------------|----------|--------------|--------|

The minimum viable workflow

When a full report is not justified, do not fake completeness. Use this 20-minute triage record:

Exact asset/contract:
Question and horizon:

1. Current product and token right:
2. Circulating/total/max supply definitions:
3. Next material unlock or emission:
4. Current deployment and privileged controls:
5. Audit-to-deployment match:
6. Liquidity at one relevant size across two routes:
7. Team/repository identity:
8. Strongest supporting evidence:
9. Strongest contradiction:
10. Unknown that blocks a conclusion:

Decision: stop / commission full review
Sources and retrieval times:

Triage should decide whether deeper research is worthwhile. It should not manufacture conviction from a shallow pass.

The source ledger: how to make evidence reusable

Every source should answer four questions:

1. Provenance: Who published or controls it?
2. Scope: Which asset, component, date, and definition does it cover?
3. Support: Which exact claim does it substantiate?
4. Limits: What can it not establish?

Example:

The CFTC recommends extensive research into token affiliates, rights, and how funds will be used (CFTC). A ledger turns that broad duty into traceable work.

The calculation sheet

Keep formulas next to inputs.

Valuation

Market cap = price × circulating supply
FDV = price × maximum supply
Circulation ratio = circulating supply / maximum supply

Use Market Cap vs FDV for definitions and scenario limits.

Unlock impact

Unlock ratio = scheduled tokens / current circulating supply
Net scheduled change = unlocks + emissions − burns

Separate scheduled, releasable, claimed, transferable, and circulating amounts.

Liquidity

Spread % = (ask − bid) / midpoint × 100%
Sell impact % = (midpoint − average simulated execution) / midpoint × 100%

Concentration

Top-N share = balances controlled by top N relevant entities / eligible supply

Exclude burn, bridge, exchange, pool, staking, and protocol contracts only when the research question and methodology justify exclusion.

A worked hypothetical workflow excerpt

This is a fictional example. It is not a real asset analysis or recommendation.

Question: Does “Meridian Protocol” have independently verifiable product traction that could create token demand over 12 months?

Claim ledger excerpt:

Evidence summary:

• Support: actual product, growing transaction count, fee token role
• Counterevidence: user methodology opaque, sponsored usage weakens direct token demand, audit mismatch
• Unknown: retention after incentives end

Conclusion:

Meridian has verifiable usage and a token role, but the strength of value capture is uncertain because sponsored transactions reduce mandatory demand. User count and current audit coverage remain unresolved. Review after the incentive program ends and after a current-implementation audit.

The workflow does not force a yes/no outcome when evidence is mixed.

How AI should fit into the workflow

Your agent is useful for:

• Gathering and normalizing public sources
• Extracting claims from long documents
• Recalculating transparent formulas
• Comparing current and older pages
• Monitoring named triggers
• Formatting the ledger and change log

Keep human control over:

• Scope and materiality
• Source independence
• Interpretation of incentives and people
• Risk tolerance and personal decisions
• Final verification of decisive evidence

NIST’s AI Risk Management Framework emphasizes governance, mapping context, measurement, and management, while its AI Resource Center highlights testing, evaluation, verification, and validation (NIST AIRC). Those concepts translate well here: define the context, test the output, and preserve accountability.

Use How to Verify AI Crypto Analysis before moving any AI-generated sentence into the verified column.

Workflow quality checks

Before marking a report reviewed:

• The exact asset and current contract are unambiguous
• Every material conclusion maps to claim IDs and sources
• Dates, units, and definitions align
• Important formulas were recalculated
• Current deployments map to code and audit scope
• Liquidity tests state size, pair, venue, and time
• Transfers are not described as intent without evidence
• Strongest counterevidence is present
• Unknowns are visible
• Review dates and event triggers are set
• A second reader can reproduce the decisive steps

Limitations and counterevidence

• A complete template can encourage box-checking; remove irrelevant sections and deepen material ones.
• Public evidence may be incomplete or revised.
• The workflow cannot guarantee safety or predict price.
• More data can increase noise if the question is poorly scoped.
• AI can reproduce source errors or generate plausible but unsupported claims.
• A reviewer can share the original author’s bias.

The workflow improves traceability, not certainty.

Using the template in BlockMind

Save the copied template in your Notebook so it receives a stable NB-number and can be updated over time. Ask your BlockMind agent to populate the mechanical fields with current sources, preserve unknowns, and create monitoring conditions for material triggers. Its research capabilities, on-chain intelligence, and browser can support different evidence layers.

Example request:

“Create a research record for [asset] using this template. Complete the source and claim ledgers first, stop any claim from becoming verified without direct evidence, show formulas and timestamps, and ask me to judge the final interpretation.”

The Bottom Line

The best crypto research template is not the one with the most fields. It is the one that makes weak evidence, conflicting definitions, calculations, counterevidence, and staleness impossible to hide.

Copy the workflow, scope the question, preserve the claim and source ledgers, separate observation from interpretation, and set the events that reopen the work. Research earns trust when another reader can reproduce it and when future evidence can change it cleanly.

Sources

• CFTC — Use Caution When Buying Digital Coins or Tokens
• NIST — AI Risk Management Framework
• NIST — AI Resource Center
• Ethereum.org — Smart Contract Security and Audit Limits
• CoinMarketCap — Market Capitalization Methodology
• EUR-Lex — Markets in Crypto-Assets Disclosure Categories