Lesson 3 — ERC-20, and Why It Fails for a Security

The token interface that runs the whole industry — and the one missing line of logic that makes it legally unusable for a tokenized fund. This lesson loads the question that ERC-3643 answers.

Why this, now? ERC-20 is the substrate everything else is compared against. To evaluate Marketnode's permissioned-token design (and to interview people who'll build it) you must be able to say, precisely and confidently, "here is what a standard token does, and here is the exact gap that disqualifies it for a regulated security." Vague hand-waving here is the tell of someone who's read blog posts but never shipped.

What "ERC-20" actually is

ERC-20 is not code — it's an interface: a small, agreed list of function and event signatures that a token contract must expose.¹ Because every wallet, exchange, custodian, and block explorer is written against that interface, any contract that implements it is instantly compatible with the entire ecosystem. That interoperability — not the code — is the value. It's the USB-C of fungible value.

The approve / transferFrom dance

Member	What it does
`totalSupply()`	How many tokens exist.
`balanceOf(owner)`	How many a given address holds. (`view` — free.)
`transfer(to, amount)`	Move your own tokens to `to`.
`approve(spender, amount)`	Authorise `spender` to move up to `amount` of your tokens.
`allowance(owner, spender)`	How much `spender` is still allowed to move. (`view`.)
`transferFrom(from, to, amount)`	A spender moves someone else's tokens, within their allowance.
`event Transfer` / `Approval`	Emitted on every move/approval so off-chain systems can follow along.

This two-step pattern confuses everyone at first, so pin it down. transfer is for "I move my own tokens." But how does a contract (a DEX, a settlement contract) move tokens on your behalf? It can't hold your key. So:

You call approve(exchangeContract, 100) on the token. → token storage records: exchange may spend up to 100 of mine.
Later, the exchange calls transferFrom(you, buyer, 100) on the token.
The token checks the allowance, moves the tokens, and decrements the allowance.

Two takeaways for an architect: (1) allowances are why "connect wallet → approve" is step one of every DeFi interaction; (2) over-broad approvals are a top attack vector — users granting unlimited allowance to a malicious contract is how wallets get drained. "How do you scope and revoke approvals?" is a sharp interview probe.

Events: the only way on-chain talks to off-chain

Recall from Lesson 2 that contracts are passive and can't call out. Events are the escape hatch: a contract emits a cheap log entry (e.g. Transfer(from, to, amount)), and off-chain services subscribe to it. This is how an exchange credits your account seconds after an on-chain transfer, and how Marketnode's back office would learn that shares moved. Events are write-only, one-directional, and the canonical on-chain → off-chain bridge. Remember them for the architecture lesson.

The fatal gap for a security

Look at what transfer checks: do you have the balance? That is the only gate. ERC-20 was designed so that any address can receive any token, permissionlessly, with no veto. For a utility token, that openness is the whole point. For a regulated security, it is disqualifying:

You cannot let arbitrary wallets hold a security. Securities law requires the issuer/transfer agent to control who may own shares (KYC/AML, accreditation, jurisdiction limits, lock-ups), to freeze holdings under court order, and to force-transfer or recover shares (lost keys, legal succession). ERC-20 has no hook for any of this. There is no place to ask "is this recipient eligible?" before the transfer, and no privileged party who can intervene after.

The Marketnode lens

A security must…	ERC-20 provides…
Restrict transfers to eligible, KYC'd holders	Nothing — transfer only checks balance
Enforce jurisdiction / lock-up / accreditation rules	Nothing — no rule hook at all
Freeze an account (sanctions, court order)	Nothing — holders are sovereign
Force-transfer / recover (lost key, succession)	Nothing — no privileged operator
Tie a wallet to a verified legal identity	Nothing — addresses are anonymous

Retrieve it (don't peek)

From memory. Q3 interleaves Lesson 2.

1. Why is a plain ERC-20 unsuitable for representing fund shares?

Correct. transfer gates on balance alone — there is no hook to check KYC, jurisdiction, lock-ups, or to freeze/recover. That's the disqualifier.

Reconsider. The core problem is permissionless transfer: ERC-20 checks only that you have the balance, with no way to restrict who may receive or to intervene afterward.

2. What is the purpose of the approve / transferFrom pattern?

Correct. It delegates spending: you approve a limit, and a spender (often a contract) later pulls tokens via transferFrom within it.

Reconsider. Moving your own is plain transfer; notifying off-chain is an event. approve/transferFrom exists to delegate spending to a third party within a limit.

3. Your back-office system needs to know the instant fund shares change hands on-chain. What does it consume?

Correct. Contracts are passive and can't call out (Lesson 2) — they emit events, and off-chain services subscribe. That log is your reconciliation feed.

Reconsider. A contract can't push callbacks. It emits Transfer events; off-chain systems subscribe to that log to stay in sync.

Primary source

The actual standard, short and worth reading once: EIP-20: Token Standard. For a gentler framing, Ethereum.org — ERC-20. (Out of scope: the many ERC-20 extensions like permit/EIP-2612 — you need the base interface and its limits.)