What You Will Be Able To Do

• Scope a project with a clear user.
• Choose and justify components.
• Document trust assumptions and threats.
• Deliver a five minute demo.
• Review a peer against a rubric.

Two Paths

• Decentralized application: prototype or detailed design.
• Community protocol: charter, process, and tools.
• Both end with a demo and a peer review.
• About twelve hours of work.

Example Ideas

• Local-first notes app with encrypted sync.
• Neighborhood tool library with member votes.
• Open-source grant round with quadratic matching.
• Verifiable archive of a community's documents.

The Brief: Seven Questions

• User and problem.
• Why decentralized.
• Components from the course.
• Trust assumptions and threats.
• Success measure.

1 user   2 problem   3 why decentralized
4 components   5 trust   6 threats
7 success measure

The Spreadsheet Test

• Could a spreadsheet with an admin solve this?
• If yes, name what decentralization adds.
• Examples: censorship resistance, member ownership.
• If nothing, simplify the design.

Choosing Components: Data And Identity

• Data: chain, storage network, or local-first sync.
• Identity: keys, decentralized IDs, personhood.
• Pick the fewest tools that solve the problem.
• Justify each with the user's need.

Choosing Components: Privacy And Decisions

• Privacy: commitments or ZK only when needed.
• Voting rule fits group size and Sybil risk.
• Delegation or quadratic methods balance influence.
• Oracles need a cost of lying.

Trust Table

• List each component.
• Name who must behave honestly.
• State what happens if they do not.
• Write the mitigation.

component | honest party | if not | mitigation
front end | host       | bad UI | open build
coordinator | tally node | bias  | proof

Threat Pass

• Dishonest insider tests permissions.
• Colluding group tests voting rules.
• Wealthy outsider tests costs and Sybil defenses.
• Failing service tests fallbacks.

Failure Plan

• How will you notice a problem?
• Who can pause or repair?
• How can users leave with their data?
• Write it in three lines.

Building The Smallest Path

• One user action, one record, one visible result.
• Use a local chain, testnet, or file network.
• Write a README that runs in ten minutes.
• List what you chose not to build.

Protocol Path: Test With People

• Draft charter, proposal process, and dispute steps.
• Run a mock decision with classmates.
• Note where people hesitate.
• Revise the text from what you saw.

Demo Script

• Minute 0 to 1: user, problem, promise.
• Minute 1 to 3: live walk through the main path.
• Minute 3 to 4: trust table and top threat.
• Minute 4 to 5: next step, open risk, question.

Rubric

• Problem and user: 4 points.
• Design choices: 4 points.
• Trust and threats: 4 points.
• Working demo or tested protocol: 4 points.
• Communication: 4 points.

Review Checklist

• Is the user named and the problem concrete?
• Is decentralization justified, with few components?
• Are the trust table, threats, and failure plan present?
• Can the demo run again from the README?
• Does it respect privacy and allow exit?

Recap And What Comes Next

• Scope small and name the user.
• Choose few components and justify each.
• State trust assumptions and failure plans.
• Keep learning: join a community and ship.

Questions And Exercise

• Exercise: produce your capstone package.
• Review one peer with the rubric and checklist.
• Share your demo recording with the group.