Back to portfolio
Research & DataSimulated project
Protocol Researcher portfolio brief
A simulated research & data exercise for Protocol Researcher. Treat it as realistic practice, not real client or protocol work.
6 deliverables6 tools referenced3 linked interview questions
Objective
Choose one mechanism and map actors, incentives, states, and failure modes
Expected deliverables
Protocol deep diveMechanism analysisAssumption mapGovernance reviewRisk memoTechnical presentation
Recommended workflow
- Choose one mechanism and map actors, incentives, states, and failure modes
- Read the deployed implementation, not just the whitepaper
- Publish a review with unresolved questions
- Review the result against the rubric, then package it as a case study.
Constraints and safety
- Use only public sources or clearly simulated data.
- Never include seed phrases, private keys, or wallet secrets.
- Redact private user, company, security, legal, or compensation information.
- State every assumption you make.
Tools in practice
- GitHub
- Inspect technical source material and maintain versioned work connected to protocol deep dive and mechanism analysis.
- protocol docs
- Draft, review, and maintain protocol deep dive and mechanism analysis, with owners, source links, and change history.
- governance forums
- Publish or track proposals, voting windows, delegate discussion, quorum, and execution status while preserving the official record.
- Dune or data tools
- Test protocol or token assumptions with onchain and market data, document definitions, and separate observed behaviour from interpretation.
- Python or notebooks
- Test protocol or token assumptions with onchain and market data, document definitions, and separate observed behaviour from interpretation.
- diagramming tools
- Map system components, data flow, trust boundaries, and failure paths so reviewers can challenge the model before implementation or publication.
What a strong submission shows
- A mechanism review
- An upgrade or governance proposal analysis
- A protocol dependency map
- A risk memo grounded in code and docs
Weak submission patterns
- Whitepaper summaries with no critical analysis
- Confident claims based only on dashboards
- Technical diagrams that do not explain assumptions
Review rubric
- Accuracy of claims and sources
- Relevance to the target role
- Decision quality and trade-offs
- Completeness of the deliverable
- Clarity of communication
- Honest limitations and next steps
Present it as a case study
- Explain the problem, sources, decisions, ownership, constraints, output, review, and what you would change.
- Show the final artifact before the process notes.
- State what you owned and what belonged to other people.
- Label the work as simulated, and keep any real contribution clearly separate.
Interview questions this project helps you answer
How would you evaluate a mechanism that works only when actors remain rational?
What is the difference between implementation risk and mechanism risk?
Which evidence would you prioritize when documentation and deployed behavior diverge?