> For the complete documentation index, see [llms.txt](https://blockchain-journal-hope-mabuza.gitbook.io/blockchain-journal-hope-mabuza-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://blockchain-journal-hope-mabuza.gitbook.io/blockchain-journal-hope-mabuza-docs/smart-contracts/week-2-erc-20-standards-wallet-tooling-and-testnet-deployment..md).

# Week 2 : ERC-20 Standards, Wallet Tooling, and Testnet Deployment.

#### Day 8 <a href="#day-8" id="day-8"></a>

**Setting the Tone for the Week**

* MetaMask is already set up from last week so I'm starting ahead of where I was. My goal this week is to be more efficient with my work and carve out some time to practice what I picked up at my first ABC session. Last week was mostly about understanding the "why" behind blockchain, this week feels like it's going to get more hands on and technical.

***

#### Day 9 <a href="#day-9" id="day-9"></a>

**Breaking Down the ERC-20 Standard**

* ERC-20 is a rulebook that token developers must follow in order to create a token on Ethereum. It needs to have the following 6 mandatory functions:

1. `totalSupply()` -> returns the total number of existing tokens.
2. `balanceOf(address)` -> returns token balance of given address.
3. `transfer(address, uint256)` -> transfers tokens to given address.
4. `approve(address, uint256)` -> approves a spender to use tokens on your behalf.
5. `allowance(address, address)` -> returns the remaining approved amount.
6. `transferFrom(address, address, uint256)` -> transfers tokens on behalf of another address.

Note: `transferFrom` only works when access has been granted because we never share private keys and access is always limited to what was approved.

* It should also emit the following events, because apps need to be able to listen for notifications when tokens are transferred or approved:

1. `Transfer` -> emitted when tokens are transferred.
2. `Approval` -> emitted when a spender is approved or denied.

***

#### Day 10 <a href="#day-10" id="day-10"></a>

**Why approve and transferFrom Exist Separately**

* If ERC-20 only had a single `transfer` function, a smart contract could take tokens immediately without your control, which could lead to fraud. By separating it into `approve` and `transferFrom`, you first set the maximum amount a contract is allowed to spend, and then the contract can only transfer tokens after your approval. This ensures that contracts cannot take more than you allow and protects your remaining balance. It's a simple pattern but it's doing a lot of work in terms of keeping users safe without them even realising it.

***

#### Day 11 <a href="#day-11" id="day-11"></a>

**Creating My First Token**

* Today I created my first token, the BCDE token. When I saw 1 million tokens sitting in my wallet I genuinely felt rich for a second before remembering it's not real money. What was actually interesting though was understanding why creating a token that already exists makes it less valuable. If anyone can spin up the same token, there's nothing unique or scarce about it, and value on the blockchain comes from scarcity and trust. That pushed me to think about creating something of my own rather than copying an existing one. Deploying it and seeing it show up live was still a cool moment, even if the balance meant nothing.
* Transaction hash: `0xf11b4c054d11d908927b99e2dbc0a453e5fc8ad022e69e0b6192562ee7e1384a`

***

#### Day 12 <a href="#day-12" id="day-12"></a>

**Assessment Day, Wins and Blockers**

* The assessment went fine overall. I was able to complete the smart contract and get all the tests passing, which felt good. The issue came with setup, getting Hardhat configured on my PC was where things fell apart and I ended up deploying and verifying on Remix instead. The bigger blocker was Etherscan verification. The contract had a constructor that takes an argument and I couldn't figure out how to pass that in during verification, so it stayed unverified.
* That caused a knock-on problem when I tried to send tokens to Peter. Importing the token into MetaMask didn't work and I think the unverified contract was the reason. It was frustrating but it also showed me how connected these steps are, if one part of the deployment process breaks, it can block everything after it. Next time I'll sort out the Hardhat setup first and make sure I understand constructor arguments before deploying.

***

#### Day 13 (ABC) <a href="#day-13-abc" id="day-13-abc"></a>

**Chainlink Oracles and Secure Randomness**

* Great session today. We learned how to use the Chainlink oracle to generate random words, which we'll be using for random numbers in the next assignment. An oracle is basically a bridge between the blockchain and the outside world, it brings in real world data that the blockchain on its own cannot access.
* What made this interesting was understanding why you can't just generate random numbers inside a smart contract. Everything on the blockchain is public and follows fixed rules, meaning someone could predict or manipulate a random number before it's finalised if it was generated on-chain. Chainlink solves this by generating the random number outside the blockchain and then delivering it to the contract in a way that can still be checked and trusted. It keeps things secure and also costs less in gas fees compared to trying to handle randomness yourself. Looking forward to actually building with it.

***