The Other Standard

Both tables are `internal`, so nothing outside reads them directly. Two public view functions sit on top instead. Line 36 does two jobs in one breath: it assigns the lookup into `owner`, then requires that the result is not the zero address, so an id nobody minted reverts rather than quietly returning nothing.

Line 39 is the one worth pausing on. A fungible token's balance is an amount; this one is a count. Three tokens owned is three, not three of something divisible. The same function name as the last file, the same return type, a different meaning underneath.

Two more tables, and both are approvals. Line 49 maps a token id to a single address: permission for one specific token. Line 51 is the nested mapping you have met before, owner to operator to a bool: permission over everything that owner holds, now and later.

A fungible token needed one approval table, because approving an amount covers every unit alike. Once tokens have identities, one table is not enough. You either name the item or you name the person, and this file keeps a table for each.

A short detour up to the metadata block. Name and symbol you know. Line 25 is new: a complete signature, `public view virtual returns (string memory)`, and then a semicolon. No braces, no body, nothing underneath it at all.

That is a requirement, not an implementation. Every collection points at different pictures, so this file refuses to guess and makes whatever inherits it supply the answer. The `abstract` marker back on line 6 is what allows a function to be left open like this.

Two functions, one for each table. `approve` on line 66 looks the token's owner up first, then requires on line 69 that the caller is that owner or is already an operator for them, and only then writes the new address into line 71.

`setApprovalForAll` on line 76 needs no lookup and no check at all. A caller can only ever grant permission over their own holdings, which is why `msg.sender` sits in the outer key on line 77 and there is nothing left to verify.

Three checks, then four writes. Lines 87 to 94 require that `from` really is the owner, that `to` is not the zero address, and that the caller is the owner, an operator, or the address approved for this one id. Both approval tables, consulted in a single condition.

Then the state changes, and one of those lines uses a word you have not met. Function first: a statement that clears a stored value back to the default for its type, which for an address is the zero address. The name: delete. Tap the three lines that change the world.

Two more functions, and they differ only in one trailing parameter. Both begin by calling `transferFrom`, on lines 116 and 132, so the move itself is exactly the one you just read. Everything after that call is the part worth slowing down for.

`to.code.length == 0` asks whether there is any code at the recipient's address. An ordinary wallet has none, so the condition is satisfied and the transfer stands. If there is code, the contract is asked a question instead, and the require holds it to the answer it gives.

Scroll to line 220 and a second contract is sitting there, holding one function. Function first: a function that another contract calls back on you after handing you something, so that you can say whether you accepted it. The name: callback.

Line 229 returns `ERC721TokenReceiver.onERC721Received.selector`, and lines 120 and 121 require exactly that value back. The password is the name of the question. How one contract reaches into another is Act three's business; recognising this courtesy is enough for today.

One more courtesy between contracts, two lines of reading after the last. A caller hands over a four byte identifier and asks whether this contract implements the standard that identifier names. Line 147 answers yes to exactly three of them and no to everything else.

The third, on line 150, is the metadata interface, and it is the reason line 25 exists at all. A contract claiming that identifier is promising there is a tokenURI to call. The claim and the unwritten function are one commitment, made twice.

Two internal functions, and between them every token that will ever exist begins and ends. `_mint` requires a real recipient and an id nobody holds yet, adds one to the count on line 164, and writes the owner on line 167.

`_burn` runs those writes backwards and adds a fourth: line 184 clears the per-token approval, the same way a transfer does. Nothing keeps the two tables level except these functions writing both, every single time.

Every line is lit. Three events, two strings, one unwritten signature, four mappings, a constructor, two setters, three transfer functions, an interface answer, mint and burn, two safe mints, and a small second contract holding one callback.

But you could have told a fungible token from this one at line 31. Everything that followed added detail; nothing that followed changed the answer. The tables decide what a contract can be asked, and the functions only decide who is allowed to ask.

So here is the skill this lesson leaves you with. Open an unfamiliar token and read its mappings before anything else. Which way the key and the value point tells you what kind of thing the contract is keeping track of, and it tells you in a single line.

Now be exact about what that flip settles and what it leaves open.

Four tokens read, and the vocabulary did not change once: contract, mapping, event, constructor, require, virtual, internal, abstract. Every word in this file is a word you already had before you opened it. Only one of them was arranged differently.

That is what a standard is. Not new machinery, but an agreement about how the machinery is arranged, so a wallet that has never heard of a collection still knows to ask line 35 who owns id seven.