Research methods
A crypto research journal: questions, evidence and revisions
A research journal preserves what you thought before an outcome and the evidence you had at the time. Use it to investigate an application, governance decision or adoption claim. The example below shows why keeping the original question matters when later results are disappointing or incomplete.
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. Frame a question with an observation window
Use a question that a future reviewer could answer from defined evidence. Replace the protocol is gaining traction with a narrower question about a named deployment, activity measure and time window. Record the network, relevant contracts, scope exclusions and why the question matters. Give the note an identifier so later revisions can refer to the same investigation without silently changing its subject.
Choose a review event or closing date before collecting only the most favorable observations. The period should fit the question, not a desired result. A note about a released integration needs different evidence from a note about recurring use. Record what the measurement cannot establish, including off-chain behavior, beneficial ownership and future financial performance. This boundary makes an incomplete conclusion more informative than an overly broad success label.
2. Build an evidence ledger that survives revisions
Give each source an entry containing its original URL, access time, author or publisher where disclosed, and the particular assertion it supports. For chain observations, include the network, block number or hash, query parameters, units and coverage limits. Ethereum’s JSON-RPC reference documents block and log queries that can anchor reproducible observations. A changing latest-state response should not be presented as a permanent historical snapshot.
For repository evidence, pin the file revision instead of relying on a branch link. GitHub documents permanent links to a specific commit, because a branch can later show different content. Preserve that distinction when comparing a promise with a released implementation. Store public excerpts or snapshots only where permitted, and do not copy restricted member documents into a public research journal. A source ledger should help someone verify a claim without exposing material they are not authorized to read.
3. Write the interpretation rules before the outcome
Create separate fields for the working hypothesis, the strongest alternative explanation, the observation that would contradict it and the information that would leave it unresolved. Avoid flexible criteria such as meaningful adoption unless the note defines how that phrase will be assessed. These fields can describe a process outcome, such as an implementation being deployed, without predicting a token price.
The Center for Open Science explains how preregistration distinguishes a plan made in advance from analysis developed after seeing results. A personal journal is not automatically a registered study or statistical validation, but the transparency principle is useful: preserve the original plan, then label later explorations as later explorations. If the question changes, create a revision with a reason rather than editing away the earlier criterion.
Source references
4. Work through a hypothetical review without moving the goalposts
Imagine a fictional application review with a 30-day window. The original hypothesis says the mean daily number of distinct initiating addresses during the final seven complete UTC days will exceed 200, after excluding a fixed, documented list of service addresses. The number 200 is an arbitrary teaching threshold, not a benchmark for a good project. The note explicitly does not call those addresses unique people or paying customers.
An early week averages 230 addresses, but the final seven-day average is 180 with complete coverage under the stated query. The recorded outcome is that the specified hypothesis was not supported. Keeping the earlier high observation as context is reasonable; replacing the final-week rule with the best observed week is a different analysis. If the provider lost several days instead, the outcome would be unresolved rather than a fabricated zero or a confident failure.
5. Review the reasoning as well as the result
After the observation window closes, record the outcome, the evidence available and the explanation for any missing data. Ask whether the method would have detected evidence against the original idea. A correct observation reached through unreliable attribution can still require a weak-method flag; an unsuccessful hypothesis can come from a careful process. Keep those assessments separate so a favorable narrative does not excuse a broken measurement.
Look across the journal for selection effects. Did only the most exciting ideas receive follow-up? Were unresolved notes dropped from the summary? Were many alternative thresholds tried but only one reported? List every scoped note in a review period, including abandoned and contradicted ideas. Without a complete and consistently defined sample, a percentage labeled research accuracy can create more confidence than the record supports.
6. Share an entry that someone else can challenge
A compact public entry can follow this order: question, scope, original hypothesis, sources, observation method, result, strongest objection and next review trigger. Include dates for the actual research and later revisions, without inventing a historical track record. A peer should be able to point to a specific assumption or reproduce a calculation rather than agree with the tone of the conclusion.
When someone finds an error, record the correction and keep the earlier version identifiable. Include abandoned and unresolved notes in later summaries. Otherwise the journal can end up showing only the ideas that appeared to work.