Source validation
Check a crypto alpha claim against original evidence
Someone calls an integration crypto alpha. Is it a public announcement, working code or a product people can use? Those are separate claims. This guide follows a fictional integration announcement through its sources, deployment evidence and usage figures, showing which parts can be supported and which remain unresolved.
Educational research methods, without recommendations to buy, sell or hold an asset. Crypto assets can lose all their value. Read the risk disclosure.
By AlfaDAOPublished Updated
1. Write the exact claim before opening more tabs
Capture the original wording and separate its components: who is doing what, on which network, by when, and at what stage. Distinguish an announced intention, a limited pilot, a deployment, an available product and evidence of ongoing use. A claim that combines all five stages can appear persuasive while providing evidence for only one. Give each component its own status in the research note.
For a worked example, imagine a post saying a fictional application has completed a major integration and already serves thousands of users. Create two questions: is the integration available in the claimed environment, and what measurement supports the user count? Preserve the post’s publication time and a public link. Do not assume that a screenshot accurately reproduces the original source or the context that accompanied it.
2. Trace the source graph and disclose incentives
Follow each repost or summary backward until reaching the original announcement, repository change, contract record or dataset. Sketch the relationships if several articles all cite the same post. Five repetitions of one claim are one source chain, not five independent confirmations. A first-party announcement can establish what its publisher said; it does not automatically establish performance, adoption or a counterparty’s agreement.
Check whether the claimed partner has published a matching statement and whether the descriptions cover the same scope. Record sponsorships, token interests or referral incentives where disclosed, without guessing at undisclosed motives. An unanswered inquiry remains unanswered. Avoid publishing private messages or another person’s identity to make a public evidence packet look more complete; use material that can legitimately be inspected by the intended audience.
3. Reconcile a release with the actual deployment
Where the claim is technical, connect the announcement to a specific release, repository revision, network and deployment address. A file on a development branch is not, by itself, evidence that users are interacting with that code in production. GitHub’s permanent-link guidance provides a way to preserve the exact file revision being discussed. Record what further evidence is needed to connect it to a deployment.
If an explorer provides source verification, record the actual match type and the address it concerns. Etherscan distinguishes exact and similar matches, including differences in the treatment of constructor arguments. Source visibility helps inspection; it is not an audit endorsement. For a proxy or upgradeable product, identify the implementation relevant to the claim rather than assuming that the source currently displayed answers a question about an earlier version.
4. Test the measurement instead of accepting the label
For an adoption statement, ask for the metric definition, observation window, chain coverage, exclusions and reproducible method. Unique addresses, transactions, sessions and people are different quantities. A count of contract interactions does not become a count of independent customers merely because a graphic uses the word users. Distinguish a provider’s incomplete coverage from an observed absence of activity.
Apply the same care to permissions. A claim that the community alone controls a system needs evidence about administrative roles and upgrade powers. OpenZeppelin’s access-control documentation illustrates why ownership and role assignments deserve their own examination. Do not generalize its framework to every deployment: inspect the actual implementation, the controlling account and the point in time that the claim concerns.
Source references
5. Resolve each part of the fictional example separately
Suppose the original documentation describes a pilot restricted to five demonstration accounts. A repository revision adds integration code, but no published production deployment can be reconciled with it. The supplied activity graphic counts 1,200 transactions over a week and gives no unique-address calculation. These invented observations support a pilot announcement and code development, while leaving a production release unresolved and the claimed user figure unsupported.
The appropriate research note does not need to call every participant dishonest. It can explain exactly where the statement outruns its evidence and which source would change the conclusion: a verifiable production release, an accessible product scope, and a reproducible metric with an accurate label. If stronger evidence arrives, update those fields independently. A later deployment does not retroactively make the earlier production claim correct at the time it was made.
6. State what the evidence supports
Use a simple status vocabulary such as supported, contradicted or unresolved, and attach the status to a narrowly defined claim rather than to the whole project. Include original links, the observation time, competing explanations and the next check. Avoid numerical certainty scores unless there is an actual, explained method for interpreting them. Being the first to publish a confident judgment is not a substitute for a source trail.
Include the strongest objection and disclose relevant interests when sharing the review. If evidence changes, show what changed and when. A later correction should not erase an earlier unsupported claim or turn it into a successful prediction.