A .NET Dinosaur in Web3. Day 16 - ERC-20 Token & ICO

A .NET Dinosaur in Web3. Day 16 - ERC-20 Token & ICO

😈 Day 4 of 7: Building Own Currency… Cryptocurrency! 

Day 4 it’s exactly give me some practice with build something cool and satisfied… and real. By the end of the session I had deployed my own cryptocurrency, run an ICO, transferred tokens between wallets and delegated spending rights between accounts. 

I think I will back to this day of challenge when I will start build my token for WishList Chain project. 

What Is ERC-20?

I little bit of theory: 

ERC-20 is an interface standard. Any smart contract that implements it must expose a specific set of functions: transfer, approve, transferFrom, balanceOf, allowance, totalSupply. Any DEX, any wallet, any protocol knows how to interact with your token automatically — because they know the interface.

The .NET analogy is exact: it's a C# interface. The standard is the contract. The implementation is yours.

Instead of writing the entire standard from scratch, we inherit from OpenZeppelin's battle-tested implementation:

import "@openzeppelin/contracts/token/ERC20/ERC20.sol";

contract MyToken is ERC20 {
    // All standard ERC-20 logic inherited
    // We add our own ICO mechanics on top
}

Multiply. Multiply. Multiply. Then — and only then — divide.

Maths in Solidity really surprised me. 

No floating point - ever.

It what we learned in previous challenge day. Just for remind… 

Solidity has no float, no double, no decimal. If you divide 1 by 3, you get 0. Not 0.333 — zero.

Every token has a decimals parameter. ETH and standard ERC-20 tokens use 18. That means "1 token" is stored as:

1_000_000_000_000_000_000  // 10^18

The minimum unit is called wei — the equivalent of a penny, except there are 10^18 of them per token. All financial logic operates in wei. If you want to mint 2.5 tokens, you write 2500000000000000000.

The rule: always multiply before dividing. Dividing first truncates to zero before the multiplication can recover anything.

// Correct — multiply first
uint256 tokensToMint = (msg.value * 333) / 1000;

// Wrong — divide first, then multiply by a truncated zero
uint256 tokensToMint = (msg.value / 1000) * 333;

SafeMath is dead. 

Pre-Solidity 0.8.0, every arithmetic operation required a library call: a.add(b) instead of a + b. This protected against overflow — when adding 1 to uint256 max wraps around to zero.

Since 0.8.0, the compiler checks automatically. Overflow reverts the transaction. The library is no longer needed and old tutorials that still use it are just showing their age.

approve — The OAuth2 of Web3

This was the most important concept of the day, because it's the foundation of DeFi.

approve(spender, amount) grants an external address (another contract, another wallet) the right to spend your tokens up to a limit. This is stored in the allowance mapping. The spender then calls transferFrom(owner, destination, amount) to act on that permission.

The .NET mental model: it's OAuth2 delegated access. The approve call is issuing a scoped token. The allowance mapping is the token store. transferFrom is the API call using that scoped token.

The tokens don't move during approve. The ledger only updates when transferFrom is called. The owner retains their balance the entire time — the contract just knows who is permitted to move it.

This same pattern is how staking contracts work: you approve the staking contract to spend your tokens, then the staking contract calls transferFrom to lock them.

The Approve Race Condition

There's a known vulnerability in the standard approve function worth understanding.

Scenario: you've approved a spender for 100 tokens. You change your mind and call approve(spender, 50). If the spender is watching the mempool, they can front-run your change — execute transferFrom for the original 100 before your reduction lands, then execute another transferFrom for 50 after it does. Result: they drained 150 instead of 50.

The fix: increaseAllowance and decreaseAllowance, which modify the limit atomically relative to the current value. OpenZeppelin provides both.

Testing in Console: Full Use Case

Before moving on, it's worth running the full token lifecycle manually in the Hardhat console. This is where the theory becomes tangible — you actually watch balances jump between mappings inside a deployed contract.

One important thing about viem in the Hardhat REPL.

The viem object returned by network.create() is not the full viem package — it's only Hardhat's internal helpers. So viem.parseEther() and viem.formatEther() don't exist on it. The fix:

const cViem = require("viem");
cViem.formatEther(balance);  // works
cViem.parseEther("500");     // works

Also: const declarations can't be redeclared in the same REPL session. If you get Identifier already declared, just use a different variable name.

Step 1 — Initialise clients and contract

const { viem } = await network.create();
const [owner, investor, friend] = await viem.getWalletClients();

const tokenAddress = "0x5FbDB2315678afecb367f032d93F642f64180aa3";
const token = await viem.getContractAt("MyToken", tokenAddress);
const cViem = require("viem");

Step 2 — Verify the pre-mint

const ownerBalance = await token.read.balanceOf([owner.account.address]);
console.log("Owner balance:", cViem.formatEther(ownerBalance)); // 50000

Step 3 — Investor buys tokens via ICO

const tokenAsInvestor = await viem.getContractAt("MyToken", tokenAddress, { client: { wallet: investor } });
await tokenAsInvestor.write.buyTokens([], { value: 2000000000000000000n });

const investorBalance = await token.read.balanceOf([investor.account.address]);
console.log("Investor balance:", cViem.formatEther(investorBalance)); // 2000

2 ETH × 1000 rate = 2000 MET. The math lands exactly because both ETH and MET use 18 decimals — no scaling needed.

Step 4 — Peer-to-peer transfer

await tokenAsInvestor.write.transfer([friend.account.address, cViem.parseEther("500")]);

const remaining = await token.read.balanceOf([investor.account.address]);
const friendBalance = await token.read.balanceOf([friend.account.address]);

console.log("Investor remaining:", cViem.formatEther(remaining)); // 1500
console.log("Friend balance:", cViem.formatEther(friendBalance)); // 500

Step 5 — Delegated spending: approve + transferFrom

This is the OAuth2 moment. Investor grants Friend a spending allowance:

await tokenAsInvestor.write.approve([friend.account.address, cViem.parseEther("300")]);

// Verify the allowance is recorded
const allowance = await token.read.allowance([investor.account.address, friend.account.address]);
console.log("Allowance:", cViem.formatEther(allowance)); // 300

Friend acts on that allowance — pulls 100 MET from Investor's balance:

const tokenAsFriend = await viem.getContractAt("MyToken", tokenAddress, { client: { wallet: friend } });
await tokenAsFriend.write.transferFrom([investor.account.address, friend.account.address, cViem.parseEther("100")]);

const finalAllowance = await token.read.allowance([investor.account.address, friend.account.address]);
const finalFriendBalance = await token.read.balanceOf([friend.account.address]);

console.log("Remaining allowance:", cViem.formatEther(finalAllowance)); // 200
console.log("Friend final balance:", cViem.formatEther(finalFriendBalance)); // 600

Final state:

• Owner: 50,000 MET (pre-mint)
• Investor: 1,500 MET (bought 2000, transferred 500)
• Friend: 600 MET (received 500 + pulled 100 via transferFrom)
• Remaining allowance: 200 MET

All ledger arithmetic balanced. The approve + transferFrom pattern is exactly how staking contracts work — the staking contract gets approved, then calls transferFrom to lock your tokens. Day 5 will use this exact flow.

What's Next

Day 5: Staking — locking tokens in a contract to earn rewards over time. The approve + transferFrom pattern from today is exactly what makes it work.

GitHub: github.com/alena-dev-soft

Follow the journey on Telegram: t.me/dotnetToWeb3

Stage: Dinosaur 🦕 — going deeper into the bedrock. Day 4 of 7.