Back to portfolio
Technical & SecuritySimulated project
Protocol Engineer portfolio brief
A simulated technical & security exercise for Protocol Engineer. Treat it as realistic practice, not real client or protocol work.
6 deliverables6 tools referenced3 linked interview questions
Objective
Contribute to a client or protocol repository
Expected deliverables
Protocol implementationSpecification updateBenchmark reportTest harnessUpgrade planIncident analysis
Recommended workflow
- Contribute to a client or protocol repository
- Write a design and testing note
- Demonstrate how the change affects correctness, performance, and upgrades
- 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
- Rust, Go, C++, or protocol language
- Implement consensus, networking, execution, storage, or state-transition logic in the protocol's production language.
- GitHub
- Review source, manage branches and pull requests, run tests, and leave implementation or security decisions in a traceable history.
- testing and simulation frameworks
- Reproduce protocol scenarios, test invariants and upgrades, and compare behaviour under load or adversarial conditions.
- profilers
- Measure CPU, memory, I/O, latency, and hot paths before making performance claims or optimisations.
- network tooling
- Inspect peer connections, messages, latency, bandwidth, and failure behaviour across distributed nodes.
- formal specifications
- Describe state transitions, invariants, and assumptions precisely enough for engineering and research review.
What a strong submission shows
- A meaningful open-source contribution
- A small distributed-systems project
- A benchmark and design note
- A protocol bug analysis
Weak submission patterns
- Application code relabeled as protocol engineering
- Benchmark charts with no method
- Forked node software with no understood change
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
What safety or liveness property does this component preserve?
How would you roll out a change that may split client behavior?
Describe a performance optimization you would reject because it weakens correctness or operability