Capstone: Design A Decentralized Application Or Community Protocol

What The Capstone Asks Of You

Eleven weeks have given you a toolbox: the contrast between centralized and decentralized designs, distributed systems basics, peer-to-peer networks, consensus, decentralized storage, identity, zero-knowledge privacy, DAO governance, mechanism design, interoperability, and community institutions. The capstone asks you to use some of these tools to solve one real problem for a defined group of people.

You may choose one of two paths. The first is a decentralized application: a working prototype or a detailed design for software that runs without a single owner, such as a shared registry, a voting tool, a local-first notes app, or a storage-backed archive. The second is a community protocol: a written set of rules, roles, and tools that a group uses to coordinate, such as a charter, a funding process, and a dispute procedure. Both paths end with a demo and a peer review.

The goal is a sound design that you can explain, not a large codebase. A small, honest project beats an ambitious one that cannot be shown. Aim for about twelve hours of work spread across the week, and give yourself a clear stopping point.

The Project Brief

Write a brief of one to two pages before building anything. The brief keeps the work focused and gives reviewers something to check against. It answers seven questions in plain language.

Keep each answer short. Two or three sentences are enough. If you cannot answer a question, that points to the next thing to research.

• User: who exactly will use this, and in what situation?
• Problem: what goes wrong for them today?
• Why decentralized: which single owner or trusted party do you remove, and why does that help?
• Components: which tools from the course do you use, and for what?
• Trust assumptions: who must be honest for this to work?
• Threats: how could a bad actor attack or game it?
• Success measure: what result tells you it works?

Choosing Components From The Course

Treat the course as a menu, then pick the fewest items that solve the problem. Each addition costs complexity and adds new risks, so justify every choice with a sentence that links it to the user's need.

For data storage, decide between a chain, a decentralized storage network, or a local-first design with sync. For identity, choose between keys, decentralized identifiers, and proof of personhood. For privacy, consider commitments or zero-knowledge proofs only when a specific fact must be proven without revealing a secret. For decisions, choose a voting rule that fits the group size and Sybil risk, and consider delegation or quadratic methods when influence needs balancing. For outside facts, specify the oracle and the cost of lying. For communication, choose between a chain, a federated protocol, and relays.

A useful test is the spreadsheet question from earlier weeks: could a shared spreadsheet with a trusted administrator solve this? If yes, explain what decentralization adds, such as censorship resistance, member ownership, or independence from one company. If the honest answer is nothing, simplify the design.

Documenting Trust And Threats

Every system trusts someone or something. The strongest designs state this plainly. Create a short table with four columns: component, who must behave honestly, what happens if they do not, and the mitigation. For a voting app, the rows might include the identity provider, the coordinator who tallies, the front end that users load, and the chain that records results.

Then run a simple threat pass with four attacker types. A single dishonest insider tests your permissions. A group of colluding members tests your voting rules. A wealthy outsider tests your costs, such as buying votes or flooding the system with fake accounts. A failing service tests your fallbacks, such as what happens when a relay, an oracle, or a bridge stops working.

End with a failure plan in three lines: how you would notice a problem, who can pause or repair the system, and how users can leave with their data. This plan shows judgment and often earns more respect from reviewers than a perfect feature list.

Trust Table, Filled Example

Component	Honest party	If not	Mitigation
Front end	Host	Bad UI	Open build
Coordinator	Tally node	Bias	Proof
Identity provider	Issuer	Fake users	Several issuers

Add a row for every component you choose. Source: Course template

Building The Prototype Or The Protocol

For an application, build the smallest end to end path. A user performs one action, the system records it, and another user sees the result. Use free tools: a local test chain, a testnet, IPFS or a similar network for files, and a short front end or command line interface. Keep a README with setup steps so that a reviewer can run the project in ten minutes.

For a community protocol, write the artifacts a group would use. Include a charter with purpose, roles, and decision rules, a process for proposals and funding, a conflict procedure with steps and timing, and an exit procedure. Test the protocol by running a mock decision with classmates and recording where people hesitate. Revise the text based on what you see.

In both paths, version your work and note what you chose not to build. A clear 'not now' list shows scope control. Place a short roadmap at the end of your brief with the next three steps you would take if the project continued.

The Demo Script

The demo lasts five minutes and follows a fixed shape, so that the audience can follow without effort. Practice it twice with a timer. Prepare a recorded backup in case a live demo fails, since networks and testnets sometimes misbehave.

Say less and show more. Name the user at the start, so the room has a person to picture. Keep the screen readable and move at a slow pace.

• Minute 0 to 1: the user, the problem, and your one sentence promise.
• Minute 1 to 3: a live walk through the main path from start to finish.
• Minute 3 to 4: the trust table and the top threat, with your mitigation.
• Minute 4 to 5: what you would do next, one risk that remains, and a question for the room.

Capstone Path

1. Write the brief
2. Pick few components
3. Fill the trust table
4. Run a threat pass
5. Build or test the smallest path
6. Give the demo

Each step produces a short written artifact for review.

Rubric And Review Checklist

Each project is scored out of 20 points across five criteria worth four points each. A score of four means complete and clear, three means mostly clear with small gaps, two means partial, one means present but weak, and zero means missing.

The criteria are: Problem and user, where the user and need are specific. Design choices, where components match the problem and each choice is justified. Trust and threats, where assumptions and attacks are named with mitigations. Working demo or tested protocol, where the main path runs or a mock decision was tested. Communication, where the brief, demo, and answers to questions are clear and honest about limits.

Reviewers also use a checklist of ten yes or no items. Is the user named? Is the problem concrete? Is decentralization justified? Does the project use few components? Is the trust table present? Are attacks considered? Is there a failure plan? Can the demo be run again from the README? Does the presenter state what remains unsolved? Does the project respect user privacy and exit? Reviewers write two strengths and two suggestions in full sentences. Feedback should focus on the work, not the person, and each suggestion should be something the author can do next.

Capstone Rubric

Criterion	Points	Key question
Problem and user	4	Is the user specific?
Design choices	4	Is each choice justified?
Trust and threats	4	Are attacks and fixes named?
Working demo	4	Does the main path run?
Communication	4	Is it clear and honest?

Scores run from 4 complete down to 0 missing, for a total of 20. Source: Week 12 rubric

Key Terms

Capstone

A final project that combines the skills from a whole course.

Project brief

A short document stating the user, problem, design, trust assumptions, and success measure.

Trust assumption

A condition that must hold, such as an honest coordinator, for a system to work.

Threat model

A structured list of who might attack a system and how.

Failure plan

A set of steps for noticing problems, repairing the system, and letting users leave.

Community protocol

A written set of rules, roles, and processes a group uses to coordinate.

Rubric

A scoring guide listing criteria and levels of achievement.

Minimum viable design

The smallest design that solves the user's core problem.

Exercise: Produce Your Capstone Package

1. Write your one to two page brief answering the seven questions: user, problem, why decentralized, components, trust, threats, success measure.
2. Create the trust table with four columns and at least four rows, then add a three line failure plan.
3. Build the smallest working path, or run a mock decision for a protocol, and record what you learn.
4. Write a README with setup steps and test that a classmate can run it within ten minutes.
5. Write your five minute demo script using the four-part shape, then practice twice with a timer and record a backup.
6. Review one peer's package with the rubric and the ten item checklist, and write two strengths and two suggestions.

Further Reading

• The Mythical Man-Month (chapters on scope and planning), Frederick P. Brooks Jr., Addison-Wesley, 1975
• Mastering Ethereum, Andreas M. Antonopoulos and Gavin Wood, O'Reilly, 2018
• Governing the Commons, Elinor Ostrom, Cambridge University Press, 1990
• Local-first software: You own your data, in spite of the cloud, Kleppmann, Wiggins, van Hardenberg, McGranaghan, Onward! 2019
• Ethereum Developer Documentation, Ethereum Foundation, ethereum.org/developers