Deploy and explain your own contract
About 964 wordsAbout 3 min
Sepolia only
Deploy to Sepolia only. Never deploy an Academy exercise to mainnet, and never use a wallet holding real funds.
What you're doing
Deploying your contract from Part 3, calling it, and explaining what it stores and what changes when you use it.
The deployment is the easy part
You already did it in Part 3. What we are checking is that you can say what your contract remembers, what changes when someone calls it, and what it cannot protect against.
That last one matters most. Anyone can deploy a contract. Knowing its limits is the difference between having followed instructions and having understood them.
You may use the provided Guestbook unchanged, make a small modification yourself, or make one with AI assistance. None receives extra credit for more code. AI assistance is allowed. Using AI is not a reason to send a submission back; being unable to explain the submitted contract is.
What to submit
Contract address — the
0xaddress from RemixDeployment transaction hash — the transaction that created it
One successful write transaction hash — your
setMessagecallAll three must be on Sepolia and must open on the explorer.
Your source code
Paste it, or link a file in your GitHub repo from Week 0 Part 1.
Name one read function, one write function, and one event in your contract
One line each. Say which is which.
Three short answers
- What state does your contract store? (1–2 sentences)
- What changes when the write function is called? (1–2 sentences)
- Name one limitation or security consideration. (1–2 sentences)
Expected length
Roughly 200–300 words, plus the three links and your source code. Optional: up to eight image or PDF uploads — a screenshot of your deployed contract in Remix is welcome, not required.
On question 6c
Any real limitation counts. Some honest examples from this exact contract:
- anyone can call
setMessage— there is no permission check - the current message can be overwritten, while the transactions that changed it remain part of the chain's history
- this version has no upgrade mechanism, so fixing a bug would mean deploying a new version
- storing long text costs more gas than you would expect
You are not expected to find a clever exploit. You are expected to notice that your contract has limits, and to name one.
Submission checklist
For reviewers — what "completed" looks like
Two or three minutes. Verify a real deployment and real understanding — not code quality, and not whether they extended the contract.
| Item | Standard |
|---|---|
| 1–3 | All three open on Sepolia. The contract address matches the deployment transaction's created contract, and the write transaction targets that same address |
| 4 | Source is included and is consistent with the submitted Guestbook and demonstrated behaviour. Exact source-to-bytecode verification is only expected if the learner verified the contract on Etherscan |
| 5 | Correctly identifies which is read, which is write, and names an event. A public state variable counts as a read function — that is correct, and worth acknowledging if they spot it |
| 6a | Names the actual state — the message, and ideally the visitor and count |
| 6b | Accurately describes the state change: message changes, lastVisitor changes, visitCount increments and the event is emitted where relevant. Gas and signature context is useful supporting understanding, but is not required unless the learner question asks for it |
| 6c | Any genuine limitation. Missing access control, immutability, public data, gas cost. Accept anything real |
Send it back if: any link is broken, points to mainnet, or the addresses do not correspond; the submitted source clearly does not correspond to the demonstrated contract; question 5 confuses read and write; or 6b describes the write without any sense that state changed.
Do not send it back for: using the Part 3 contract unmodified, an unpolished answer that is correct, imperfect English, or not verifying the source on Etherscan — that was optional.
If a recovery phrase or private key appears
Reject immediately. Tell the member their wallet is compromised and to create a fresh one. Do not repeat the phrase in your feedback.
If this gets rejected
Rejection means resubmit — it is not a fail
No deadline, no penalty. You will be told the one thing to fix.
The three most common rejections at Week 3:
| What happened | The fix |
|---|---|
| The contract address and the deployment transaction do not match | On the explorer, open the deployment transaction and copy the address from its Created Contract field |
Question 5 calls a public variable "not a function" | It is a read function — Solidity generates one for you. Part 2, State tab |
| 6c says "it is secure" or leaves it blank | Every contract has limits. Start with: who is allowed to call your write function? |
Stuck on the deployment rather than the writing? Part 3 has a troubleshooting section, and the Telegram group has people who hit the same error last week.