---
url: /academy-handbook/foundation/week-3/anchor-mission.md
---
# Week 3 — Anchor Mission

  

::: danger 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](./part-3-remix-lab.md), calling it, and
explaining what it stores and what changes when you use it.

::: important 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

::: steps

1. **Contract address** — the `0x` address from Remix

2. **Deployment transaction hash** — the transaction that created it

3. **One successful write transaction hash** — your `setMessage` call

   All three must be on Sepolia and must open on the explorer.

4. **Your source code**

   Paste it, or link a file in your GitHub repo from
   [Week 0 Part 1](../../getting-started/welcome-and-setup.md).

5. **Name one read function, one write function, and one event** in your contract

   One line each. Say which is which.

6. **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)*
     :::

::: tip 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.
:::

::: warning 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

* \[ ] Contract address, deployment hash and write transaction hash are all included
* \[ ] All three open on the explorer and are on **Sepolia**
* \[ ] My source code is included or linked
* \[ ] I named a read function, a write function and an event
* \[ ] I answered all three parts of question 6
* \[ ] If I used AI, I can explain what my contract does and what would break if it changed
* \[ ] **I have not included my recovery phrase or private key anywhere**

:::: details 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.

::: danger 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

::: tip 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](./part-2-solidity-minimum.md), 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](./part-3-remix-lab.md)
has a troubleshooting section, and the Telegram group has people who hit the same
error last week.