Capstone: Build And Deploy A dApp On A Testnet

The Brief

This capstone asks you to build one small decentralized application, or dApp, from idea to a live demo on a test network. A dApp has two parts: a smart contract that holds the rules and state, and a web page that lets people use it through their wallets. You will use the tools from the previous weeks: Solidity from week 6, tokens from week 7, security habits from week 10, and the use-case test from week 11.

Keep the project small. A good capstone does one thing and does it correctly. Examples: a tip jar that records who sent how much and a note; a simple crowdfunding pot with a goal and a deadline; a class attendance badge that mints one token per participant; a voting contract with one vote per address and a closing time. Choose a project that fits within a few hours of focused work. A finished small project teaches more than an unfinished large one.

Your deliverables are four things: a deployed and verified contract address on Sepolia, the source code in a repository, a simple web page that calls the contract, and a five-minute live demo with a short written design note of about one page.

Plan The Scope

Begin with a single sentence: who uses this, what do they do, and why does a blockchain help? Apply the test from week 11. If a normal database would serve better, change the idea or explain honestly what the chain adds, such as a public record that nobody can edit or a payment that releases by rule.

Then list the contract's state, its functions and its events. State is the data the contract stores. Functions change it. Events announce changes to the outside world and let your web page show history. Decide who may call each function, because access control (week 10) is the most common source of bugs. Write the list on paper before you write code. Three to five functions are enough.

Name the trust assumptions in one short list. Who holds an admin key? Can anyone upgrade or pause the contract? What happens if the owner disappears? A clear list shows that you understand your own design.

• Purpose: one sentence, passes the need-a-blockchain test.
• State, functions, events: three to five functions at most.
• Access: who may call each function.
• Trust: admin keys, upgrades, and failure cases.

From Idea To Demo

1. One sentence scope
2. Design on paper
3. Write and test locally
4. Deploy and verify
5. Demo in five minutes

Keep each step small and finish before adding features.

Contract Planning Sheet

Part	Question
State	What data is stored?
Functions	Who may change it?
Events	What should the page show?
Trust	Who holds an admin key?

Fill this in before writing code. Source: Course planning guide

Build The Contract

Write the contract in Remix or in a local tool such as Foundry or Hardhat. The slides show a reference tip jar of about twenty lines. Study it, then adapt it or write your own. Use a fixed Solidity version, such as ^0.8.20, so that arithmetic reverts on overflow. Use require with short messages to reject bad input. Emit an event for every state change that outsiders care about.

Apply the security checklist from week 10 while you write. Update state before sending ether. Protect sensitive functions with an owner check. Keep the contract small, and use OpenZeppelin building blocks when you need tokens or ownership logic instead of writing them again. Avoid loops over unlimited lists, because gas grows with the list.

Test before you deploy. In Remix, run each function with normal input and with input that should fail, from the owner account and from another account. In Foundry or Hardhat, write the same cases as automated tests, and add at least one test that tries to break your own rules. Tests are part of your grade because they show how you know that the code works.

Deploy To Sepolia And Verify

Switch your wallet to the Sepolia test network and fund a deployer account with test coins from a public faucet. Compile with the exact version in your pragma, choose the Injected Provider environment in Remix, and deploy. Copy the contract address and the transaction hash. Open both on the Sepolia block explorer and confirm that the code and the creation transaction appear.

Verification publishes your source code on the explorer so anyone can read it and match it to the deployed bytecode. Most explorers accept the source file, compiler version and settings, and some tools do this for you automatically. A verified contract is a signal of good faith. Without it, users must trust bytecode they cannot read.

Use a fresh wallet that holds only test coins for this work. Never connect the wallet that holds real assets to a course project. If you use a private key in a script, keep it in an environment variable and keep it out of the repository.

Connect A Web Page

The web page can be a single HTML file. It needs three things: a button to connect the wallet, a way to call a contract function, and a place to show results. The library ethers.js, version 6, wraps these tasks. A BrowserProvider connects to the wallet that the browser exposes, a signer represents the connected account, and a Contract object is built from the address and an interface description called the ABI.

Read-only calls cost nothing. Calls that change state ask the wallet for a signature and cost test gas. After sending a transaction, wait for it to be mined before you update the page, and show the user the transaction link so they can verify it. Handle errors in plain words: a rejected signature, the wrong network and insufficient funds are the three most common cases.

Host the page for the demo from your computer with a simple local server, or publish it as a static site. It does not need to be pretty. It needs to work, to show the connected network, and to display what the contract stored.

dApp Architecture

1. Web page
2. Wallet signs
3. Sepolia node
4. Smart contract
5. Events back to the page

The page reads the chain directly and asks the wallet to sign writes.

Rubric

The project is scored out of 20 points. Each of the five criteria receives 0 to 4 points. Reviewers use the same table so that feedback is consistent.

A score of 4 means the work is complete and thoughtful, 3 means solid with small gaps, 2 means partly done, 1 means a weak attempt, and 0 means missing.

• Purpose and fit (4 points): clear one-sentence purpose, honest use-case test, sensible scope.
• Contract quality and safety (4 points): correct logic, access control, events, week 10 checklist applied, tests present.
• Deployment and verification (4 points): live on Sepolia, source verified, address and transaction shared.
• Web interaction (4 points): wallet connects, at least one read and one write work, errors are handled.
• Demo and explanation (4 points): clear story, honest trust assumptions, answers questions, finishes in five minutes.

Capstone Rubric

Criterion	Points
Purpose and fit	4
Contract quality and safety	4
Deployment and verification	4
Web interaction	4
Demo and explanation	4

Total of 20 points; each criterion scores 0 to 4. Source: Course rubric

Demo Script And Review Checklist

The demo runs five minutes, plus three minutes of questions. Spend the first minute on the problem and why a chain helps. Spend two minutes on a live walk-through: connect the wallet, read the current state, send a transaction, show the new state and the event on the explorer. Spend one minute on the code: show the three most important functions and the access rule. Spend the last minute on trust assumptions, one risk you found, and what you would change next. Keep a recorded backup of the demo in case the network is slow.

After each demo, the peer reviewer completes the checklist below. Reviewers state what works first, then name up to two improvements, each with a concrete suggestion. The aim is to help each other ship safer software, and a calm, specific tone helps most.

• Can I say in one sentence what this dApp does and why it needs a chain?
• Is the contract verified, and does the explorer show the transaction I just saw?
• Does every state-changing function have a clear access rule?
• Does the code update state before external calls, and does it emit events?
• Do tests cover a failing case, not only the happy path?
• Are the admin powers and failure cases written down?
• Does the page show the network and handle a rejected signature?
• Is no private key or seed phrase anywhere in the repository?

Key Terms

dApp

A decentralized application made of a smart contract and a front end that talks to it through a wallet.

Testnet

A network that works like the main chain but uses coins with no real value, such as Sepolia.

Faucet

A service that gives free test coins so you can pay gas on a test network.

ABI

The Application Binary Interface, a description of a contract's functions and events that front ends use to call it.

Provider and signer

A provider reads from the chain, and a signer is an account that can sign and send transactions.

Contract verification

Publishing source code on an explorer so it can be matched to the deployed bytecode.

Event

A log entry emitted by a contract that outside tools can read to follow what happened.

Trust assumption

A condition you must rely on for the system to behave as claimed, such as an admin key staying safe.

Rubric

A table of criteria and point values used to score work consistently.

Exercise: Capstone Project Steps

1. Write your one-sentence purpose, run the week 11 test, and list three to five functions with their callers. Get a quick peer opinion before you code.
2. Write the contract in Remix with a fixed pragma. Add events and access checks, and run normal and failing calls from two accounts.
3. Fund a fresh test wallet from a Sepolia faucet, deploy the contract, and save the address and transaction hash.
4. Verify the source on the Sepolia block explorer and confirm that the Contract tab shows your code.
5. Create index.html with a connect button, one read call and one write call using ethers.js version 6. Run it from a local server and test it end to end.
6. Write the one-page design note, rehearse the five-minute demo twice, and prepare a recorded backup.

Further Reading

• Solidity documentation, Solidity team, docs.soliditylang.org
• ethers.js v6 documentation, Richard Moore, docs.ethers.org
• The Foundry Book, Paradigm and contributors, book.getfoundry.sh
• Ethereum developer documentation, Ethereum Foundation, ethereum.org/developers
• Mastering Ethereum, Andreas M. Antonopoulos and Gavin Wood, O'Reilly Media