Multi Token Standard

01 Claim ledger

What the paper is allowed to say

Each row is a sentence already in the study. The status is the same on every row: a model claim, not a live measurement.

1. Claim 01 · Paper model

   The defect

   A game or a marketplace that issues hundreds of ERC-20 or ERC-721 contracts pays deployment and approval costs on every one.

2. Claim 02 · Paper model

   The rule

   One contract holds many ids. Each id can be fungible or not, by how many copies exist. A batch transfer moves several ids in one call. A receiver hook tries to stop tokens being sent to contracts that cannot hold them.

3. Claim 03 · Paper model

   How it is put together

   Ids share a contract. Batching is the point. The receiver must accept, or the send reverts, when the receiver is a contract.

4. Claim 04 · Paper model

   Where the claim stops

   The standard does not define rarity, rights, or reserves.

02 Three cuts

Observation, model, falsifier

A desk does not stop at the summary. Each claim is cut three ways, using only this study's own assumptions and checks. Nothing here is a new figure.

1. 01 The defect

   Observation

   What the study says

   A game or a marketplace that issues hundreds of ERC-20 or ERC-721 contracts pays deployment and approval costs on every one.

   Model

   What has to hold

   The standard does not define rarity, rights, or reserves.

   Falsifier

   What would retire it

   Does the recipient implement the receiver hook?

2. 02 The rule

   Observation

   What the study says

   One contract holds many ids. Each id can be fungible or not, by how many copies exist. A batch transfer moves several ids in one call. A receiver hook tries to stop tokens being sent to contracts that cannot hold them.

   Model

   What has to hold

   Semi-fungible is a usage, not a third legal category the EIP creates.

   Falsifier

   What would retire it

   Does the recipient implement the receiver hook?

3. 03 How it is put together

   Observation

   What the study says

   Ids share a contract. Batching is the point. The receiver must accept, or the send reverts, when the receiver is a contract.

   Model

   What has to hold

   Semi-fungible is a usage, not a third legal category the EIP creates.

   Falsifier

   What would retire it

   Does the recipient implement the receiver hook?

4. 04 Where the claim stops

   Observation

   What the study says

   The standard does not define rarity, rights, or reserves.

   Model

   What has to hold

   The standard does not define rarity, rights, or reserves.

   Falsifier

   What would retire it

   Does the recipient implement the receiver hook?

03 Sequence

One action, as an operating tape

1. 01Mint balances against ids.
2. 02safeBatchTransferFrom moves many.
3. 03The receiver's hook returns a selector or the transfer fails.
4. 04Does the recipient implement the receiver hook?

04 Load-bearing

The argument, and where a pitch drops it

1. Why it is still on the desk

   The cut

   An inventory system that deploys a new contract per item has not used this, and should have a reason.

   Why it carries weight

   If this cut is skipped, the paper's name is being used without the mechanism that makes the name mean anything.

   Where it is dropped

   A later client, parameter or reward formula is a different object from this paragraph.

2. After the text

   The cut

   Games and some exchanges adopted it. The hook is the part integrators forget.

   Why it carries weight

   If this cut is skipped, the paper's name is being used without the mechanism that makes the name mean anything.

   Where it is dropped

   A later client, parameter or reward formula is a different object from this paragraph.

05 Register

What has to be true

• Model · Not re-measured

  The standard does not define rarity, rights, or reserves.

• Model · Not re-measured

  A hook that always accepts can still be a bad wallet.

• Model · Not re-measured

  Semi-fungible is a usage, not a third legal category the EIP creates.

06 Divergence

What happened after the paper

Games and some exchanges adopted it. The hook is the part integrators forget.

A later client, parameter set, or reward formula is a different object. Cite this paper for the mechanism. Cite a primary release for the network. This desk has not re-run the proof.

07 Pre-mortem

What to check before you use the idea

1. Kill test 1Does the recipient implement the receiver hook?
2. Kill test 2Which ids are meant to be fungible?
3. Kill test 3What does a balance of an id mean outside the contract?
4. 0 of 3 marked on this browser. A mark is a reading note, not a pass, a rating, or a recommendation.

08 Anatomy

The paper, in the order a builder needs

09 Lexicon

Terms, opened into the record

Batch transfer

One call that moves several ids.

Receiver hook

A callback that lets a contract refuse tokens it cannot handle.

10 Repository

Every linked record on this page

Underlined words open a page that already exists: a concept, a protocol profile, a failure record, or another paper. If a word is not underlined, this desk does not have a record for it.

11 Related

The next papers, as theses

• ERC-721 · 2018

  Non-Fungible Token Standard

  Each token id has an owner. Transfer moves that id. An optional metadata URI points at a description. The standard does not say the description is true, or that the object exists off-chain.

• ERC-20 · 2015

  Token Standard

  A token contract exposes total supply, balance, transfer, and allowances. Wallets and exchanges can integrate one interface.