Wallets, Security And Custody

Keys, Not Coins

In week 2 you learned that a private key signs messages and a public key lets others check the signature. In weeks 3 and 5 you saw that an address comes from a public key and that a transaction is valid when the right key signs it. This week turns that theory into daily practice. A wallet is software or hardware that stores private keys and signs transactions for you. The coins and tokens remain on the chain. Whoever controls the key controls the assets.

That single fact explains most of this week. There is no password reset for a lost key and no bank to reverse a signed transaction. The same property that removes the middleman makes you the security department.

Seed Phrases

Wallets do not make you memorize a long random number. Most use a standard called BIP-39 to turn the secret into a list of 12 or 24 ordinary words, the seed phrase or recovery phrase. From this phrase the wallet derives all your private keys in a fixed, repeatable way. Anyone who has the words can recreate every account, on any compatible wallet, from anywhere.

Treat the phrase as the master key. Write it on paper or stamp it in metal, and store it in a place that you control, such as a safe. Keep at least one backup in a different location, in case of fire or flood. Never type it into a website, never store it in a notes app, a photo, a cloud drive or an email, and never read it out to anyone. No real wallet company, exchange or support agent ever needs it. A request for the phrase is a scam without exception.

A useful test before you trust a wallet with real value: restore it from the phrase on a second device, using a small balance. If the restore works, your backup works.

Seed Phrase Lengths

Words	Entropy bits
12	128
15	160
18	192
24	256

Phrases come from a fixed word list and encode your master key. Source: BIP-39

Custody Models

Custody means who holds the keys. In a custodial service, such as an exchange, the company holds the keys and you hold a claim against it. This is convenient and offers account recovery, but you carry the company's risk. Hacks, bankruptcies and frozen withdrawals have affected customers of exchanges in the past. In self-custody you hold the keys yourself. That removes the company risk and adds personal responsibility.

A hardware wallet is a small device that keeps the private key inside a secure chip. The key never leaves the device. Your computer builds a transaction, sends it to the device, you check the details on the device screen and confirm with a button, and the device returns the signature. Even if your computer has malware, the key stays out of reach. Buy hardware wallets directly from the maker, and check that the device arrives sealed and sets up its own new phrase.

For larger amounts or for groups, a multisignature wallet requires several approvals, for example 2 of 3 keys. Safe is a widely used contract wallet of this kind. It protects against the loss or theft of a single key, and it suits teams and treasuries. Newer approaches, called smart accounts, add features such as spending limits and recovery by trusted contacts. Each one trades some simplicity for resilience.

• Custodial: easy and recoverable, but you trust the company.
• Self-custody: you hold the keys and the responsibility.
• Hardware wallet: key stays inside the device.
• Multisignature: several approvals needed to spend.

Custody Models

Model	Who holds the keys	Main risk
Exchange account	The company	Company failure or freeze
Software wallet	You, on your device	Malware, phishing
Hardware wallet	You, on a dedicated device	Lost backup, fake device
Multisignature	Several parties	Coordination and key loss

No model removes risk; each moves it. Source: Course summary

Phishing And Scams

Most losses in crypto come from tricking people, not from breaking cryptography. Phishing uses a fake website, a fake message or a fake support agent to make you sign something harmful. Common forms include a copy of a real site reached through a sponsored search result, a message offering a free token claim, a direct message from a 'helper' on social media, and an urgent email warning that your account is at risk.

Signatures need care. A request to connect a wallet only shares your public address. A request to sign a transaction can move funds. A request to approve a token (week 7) can allow a contract to spend your tokens later. Some wallets also display off-chain signature requests, such as permits, that grant spending rights without a visible transaction. Read what you sign. If a screen is unclear, stop and reject it.

Address poisoning is another trick. An attacker sends a tiny transfer from an address that looks similar to one you use, hoping you copy it from your history. Always verify the full address, not only the first and last characters. A habit of sending a small test transaction before a large one catches many mistakes.

If you suspect you approved something harmful, use a revoke tool such as Revoke.cash to view and cancel token allowances for each network. Do this regularly, and use a separate wallet for experiments with small balances.

Common Smart Contract Bugs

Contracts are public and cannot be quietly patched, so bugs are costly. The most famous is reentrancy. It occurs when a contract sends ether to another address before it updates its own records. The receiving contract can run code at once and call the sender again, while the old balance is still recorded. The 2016 attack on The DAO used this pattern and led to a major dispute and a change in Ethereum's history.

The standard defense is the checks-effects-interactions order: first check conditions, then update your own state, then make external calls. A reentrancy guard from OpenZeppelin gives a second layer of protection. Other frequent bugs include missing access control, where anyone can call an administrative function, and unchecked return values from external calls. Integer overflow was once common, and Solidity 0.8 now reverts on it by default. Price manipulation through weak oracles (week 8) and the use of tx.origin for authorization round out the usual list.

• Reentrancy: update state before external calls.
• Access control: protect every sensitive function.
• Unchecked calls: always handle failure.
• Weak oracles: never trust a single thin pool.

A Reentrancy Attack

1. Attacker calls withdraw
2. Contract sends ether first
3. Attacker code calls withdraw again
4. Balance not yet updated
5. Funds drained

The fix is to update the balance before sending ether.

Testing, Audits And Bounties

A good defense has several layers. First come unit tests that cover normal use and failing cases. Fuzz testing sends many random inputs to find surprising breaks, and tools such as Foundry make this easy. Static analyzers such as Slither flag known risky patterns. For critical logic, formal verification proves that a property always holds.

An audit is a structured review of the code by an outside security team. The team reads the code, tests it and writes a report that lists findings by severity. An audit reduces risk, and it also has limits. It covers one version of the code at one point in time, it can miss bugs, and it says nothing about future upgrades or about the economic design. When you read a report, check which version was reviewed, which findings were fixed and which remain open.

Bug bounty programs pay outside researchers who report flaws responsibly. Timelocks delay privileged changes so users can exit. Together with tests and audits, they form a practical safety culture. Use the same one for your capstone in week 12.

A Personal Security Routine

Good habits are short and repeatable. Keep a small hot wallet for daily use and a hardware wallet for savings. Keep the system and browser updated, and use a separate browser profile for crypto. Bookmark the sites you use instead of searching for them each time. Enable two-factor authentication on exchange and email accounts, and prefer an authenticator app or a hardware key to text messages. Read every signature request. Review your approvals monthly. Practice recovery before you need it.

Finally, keep a plan for your family or partner. Write down, in a safe place, where the backups are and how to use them. Security that nobody can recover after an emergency fails in its own way.

Key Terms

Wallet

Software or hardware that stores private keys and signs transactions on your behalf.

Seed phrase

A list of 12 or 24 words from which a wallet derives all of its private keys.

Self-custody

Holding your own private keys instead of letting a company hold the assets for you.

Hardware wallet

A dedicated device that keeps the private key in a secure chip and signs without exposing it.

Multisignature

A wallet that requires approval from several keys before it can spend.

Phishing

A fake site, message or person that tricks you into revealing secrets or signing a harmful request.

Reentrancy

A bug where an external call lets an attacker re-enter a function before the contract has updated its state.

Checks-effects-interactions

A coding order that checks conditions, updates state, and only then calls other contracts.

Audit

An outside review of contract code that reports findings by severity for one version of the code.

Exercise: Break And Fix A Vault, Then Practice Recovery

1. In Remix, create Vault.sol with the vulnerable withdraw function from the slides and an Attacker contract that calls withdraw again from its receive function.
2. Deploy both on a local Remix VM, deposit 1 ether from two different accounts, and run the attack from the Attacker contract. Record the vault balance before and after.
3. Fix the Vault by setting the balance to zero before the external call, and re-run the same attack. Confirm that it now fails.
4. Create a fresh test wallet with MetaMask or Rabby, write its seed phrase on paper, then restore it in a second browser profile and confirm the address matches.
5. Open Revoke.cash with your test address and read the list of approvals. Revoke one if any exists, or note what an unlimited approval looks like.
6. Write a one-page personal security plan: which wallet for daily use, which for savings, where the backups are, and what you check before signing.

Further Reading

• BIP-39: Mnemonic code for generating deterministic keys, Marek Palatinus, Pavol Rusnak and co-authors, Bitcoin Improvement Proposals
• Mastering Ethereum, chapter on security, Andreas M. Antonopoulos and Gavin Wood, O'Reilly Media
• Smart Contract Security Field Guide and SWC Registry, Consensys Diligence
• OpenZeppelin Contracts documentation: Security and ReentrancyGuard, OpenZeppelin, docs.openzeppelin.com
• Solidity documentation: Security Considerations, Solidity team, docs.soliditylang.org