My progress
Menu

Blockchain and Trust Infrastructure Engineer · Focus area 3: Smart contracts

BC7: Writing smart contracts in Solidity

Goal: explain what a smart contract is and isn't, write Solidity with the right types, visibility and storage, control who can do what with modifiers, custom errors and events, handle ether safely, and use Hardhat to compile, test and deploy, knowing where Rust and other languages fit.

You'll need: BC5, Module 17 (JavaScript Basics), Module 23 (Functions and Scope), Module 27 (TypeScript Foundations), and the SakhiKosh practice kit (contracts/SakhiFund.sol, hardhat.config.js, docs/FORMATS.md).

Where this is used: tokens, payments and escrow, voting, registries, multi-signature wallets and lending protocols are all smart contracts, and Solidity is the most widely used language for writing them.

How it differs: an ordinary backend can be patched tonight if there's a bug. A deployed contract's code can't be changed, anyone can call it, and every mistake is public and may move real money, so contracts are kept small and written carefully.

Time: reading about 3 hours · practice (the Try it tasks) about 3 hours · assignment about 4 hours.

Lessons

  1. 1What a smart contract is, and isn'tReading 15–25 minutes, plus practice✓
  2. 2Solidity basics: types, storage and functionsReading 15–25 minutes, plus practice✓
  3. 3Who may do what: modifiers, errors and eventsReading 15–25 minutes, plus practice✓
  4. 4Handling ether safelyReading 15–25 minutes, plus practice✓
  5. 5Tools, versions and other languagesReading 15–25 minutes, plus practice✓

🛠️Assignment: SakhiFund's first version

  1. Read the starter's contracts/SakhiFund.sol and list every function, its visibility and who should be allowed to call it.
  2. Add totalDeposits, custom errors and events from docs/FORMATS.md.
  3. Replace the tx.origin check with an onlyAdmin modifier using msg.sender, and add setPaused with whenNotPaused.
  4. Rewrite withdraw with checks, effects, interactions, and check the result of call.
  5. Run npm run test:contract and note which tests pass now (at least 1, 2, 4, 6 and 7).

Self-check before you finish:

✅Module check

Explain in a few sentences, in your own words:

What should a well-written smart contract look like?

Show a good answer

A good answer mentions: code and storage at an address that runs only when called, is deterministic and public, and can't be changed; current Solidity with suitable types, immutable values and minimal storage; access checks on msg.sender with modifiers, custom errors and events; ether handled with checks, effects and interactions, checked call results, pull payments and records that match the balance; and pinned compilers, automated tests, verified source, and awareness of Vyper and Rust.

📚Official references

Official documentation and guidance for this module's topics, chosen on 2 November 2026. Tools, laws and standards change, so check the current version before you rely on a detail. If a link has moved, search the same site.

📝Module quiz

10 questions · 10 marks each · 100 marks in all · pass mark 70% · retry as often as you like ·

1. A group wants its contract to "send everyone a reminder SMS before each meeting". What's the problem?

Why each option is right or wrong

  • “Contracts can only send messages to other contracts, not to phones in another country” (Incorrect): They can't send SMS anywhere.
  • “The SMS would cost too much gas to send each month” (Incorrect): Gas isn't the issue.
  • “The members' phone numbers would need to be stored as uint256” (Incorrect): Phone numbers shouldn't be on-chain at all.
  • “Contracts can't reach outside the chain or wake themselves” is correct.

    Use an app off-chain for reminders.

    • Contracts: run only when called.

📖 Revise: Lesson 1: What a smart contract is, and isn't

Question ID sp-blockchain-07-q1 · Report a mistake in this question
2. A contract pays out when a crop price reaches a level, using one website's price. What's the main risk?

Why each option is right or wrong

  • “The website's price will be in the wrong currency for the chain” (Incorrect): Conversion is a detail.
  • “Contracts can't compare two numbers at all” (Incorrect): They can.
  • “The payout can only run once a year” (Incorrect): There's no such limit.
  • “A wrong price from that one source triggers payments by mistake” is correct.

    Use several independent sources.

    • Name: oracle risk.

📖 Revise: Lesson 1: What a smart contract is, and isn't

Question ID sp-blockchain-07-q2 · Report a mistake in this question
3. A learner stores each member's full deposit history in an array in the contract. What goes wrong as it grows?

Why each option is right or wrong

  • “Nothing, since storage on a blockchain is free to write” (Incorrect): Storage writes are the costliest common operation.
  • “The array starts deleting the oldest entries by itself to make room” (Incorrect): Arrays don't do that.
  • “Old entries become encrypted after a while” (Incorrect): Nothing is encrypted.
  • “Costs rise and reading it all may need more gas than allowed” is correct.

    Store balances and emit events for history.

    • Kit: the Deposited event.

📖 Revise: Lesson 2: Solidity basics: types, storage and functions

Question ID sp-blockchain-07-q3 · Report a mistake in this question
4. What does immutable do in address public immutable admin;?

Why each option is right or wrong

  • “It hides the admin's address from people reading the chain” (Incorrect): Nothing on-chain is hidden.
  • “It makes the admin unable to call any function in the contract” (Incorrect): It only fixes the value.
  • “It lets the admin be changed by any member in an emergency” (Incorrect): It can't be changed at all.
  • “The value is set once in the constructor and can't change” is correct.

    It's also cheaper to read.

    • Compare: constant, fixed in the code.

📖 Revise: Lesson 2: Solidity basics: types, storage and functions

Question ID sp-blockchain-07-q4 · Report a mistake in this question
5. A contract checks tx.origin == admin. The admin calls a "free airdrop" contract, which then calls this one. What happens?

Why each option is right or wrong

  • “The check fails, since the airdrop contract is the one making the call” (Incorrect): That's msg.sender; tx.origin is still the admin.
  • “The network blocks contracts calling other contracts” (Incorrect): It allows it.
  • “Nothing happens, since airdrops can't call admin functions” (Incorrect): Any contract can call public functions.
  • “The check passes, and the attacker's contract acts with the admin's authority” is correct.

    Use msg.sender for authorisation.

    • Kit: the Phisher contract.

📖 Revise: Lesson 3: Who may do what: modifiers, errors and events

Question ID sp-blockchain-07-q5 · Report a mistake in this question
6. An app shows "Error: 0x3f1a..." when a member's deposit is refused. What contract feature helps the app explain it?

Why each option is right or wrong

  • “Longer function names that describe what each one does” (Incorrect): Names don't explain refusals.
  • “A public variable holding the last error message as text” (Incorrect): That's costly and unreliable.
  • “Removing all errors from the contract, so that no deposit can be refused at all” (Incorrect): Some deposits should be refused.
  • “Custom errors such as NotMember() that the app can decode” is correct.

    The app maps each to a plain sentence.

    • Kit: Project 3's test 7.

📖 Revise: Lesson 3: Who may do what: modifiers, errors and events

Question ID sp-blockchain-07-q6 · Report a mistake in this question
7. A withdraw function sends ether with call, then reduces the member's balance. What's wrong?

Why each option is right or wrong

  • “call can't send ether, only data” (Incorrect): It sends both.
  • “Balances must be reduced in a separate, later transaction, after the money has arrived” (Incorrect): In the same one, before sending.
  • “Nothing, as long as the member is trusted by the group” (Incorrect): Contracts can be members, and anyone can be careless.
  • “The receiver can call back in before the balance changes” is correct.

    Update records before sending.

    • Order: checks, effects, interactions.

📖 Revise: Lesson 4: Handling ether safely

Question ID sp-blockchain-07-q7 · Report a mistake in this question
8. A contract sends ether with call and ignores whether it worked. A member's address refuses payments. What happens?

Why each option is right or wrong

  • “The payment is retried automatically until it goes through” (Incorrect): Nothing retries it.
  • “The member's address is removed from the contract” (Incorrect): Nothing removes it.
  • “The ether goes to the admin instead of the member” (Incorrect): It stays in the contract.
  • “The record says they were paid, but no ether arrived” is correct.

    Check ok and revert if it's false.

    • Kit: Project 1's test 5.

📖 Revise: Lesson 4: Handling ether safely

Question ID sp-blockchain-07-q8 · Report a mistake in this question
9. A team can't verify its deployed contract on an explorer. What's the most likely cause?

Why each option is right or wrong

  • “Explorers only verify contracts with fewer than ten functions” (Incorrect): There's no such limit.
  • “The contract was deployed on a weekend” (Incorrect): Timing doesn't matter.
  • “Verification needs the admin's private key” (Incorrect): It needs source and settings, not keys.
  • “The exact compiler version and optimiser settings weren't recorded” is correct.

    Pin them in the project, and keep deployment records.

    • Kit: hardhat.config.js.

📖 Revise: Lesson 5: Tools, versions and other languages

Question ID sp-blockchain-07-q9 · Report a mistake in this question
10. A Solidity developer moves to writing Solana programs. What carries over?

Why each option is right or wrong

  • “The exact Solidity code, which runs on Solana without any change to the contract at all” (Incorrect): Solana programs are written differently, often in Rust.
  • “Nothing at all, since the chains share no ideas” (Incorrect): Many ideas are shared.
  • “Only the gas prices, which are the same on both” (Incorrect): Fees work differently.
  • “The concepts: storage, access control, events and careful testing” is correct.

    Each chain's model still needs learning.

    • Language: Rust, usually with Anchor.

📖 Revise: Lesson 5: Tools, versions and other languages

Question ID sp-blockchain-07-q10 · Report a mistake in this question

ProLearners Assist