中文版 · Blockchain learning guide · Previous article
Blockchain learning · Article BC071
A digital asset can be individually identified, restricted from transfer and still represent an entitlement equivalent to another entitlement for a particular purpose. Another asset can be transferable yet unsuitable as a substitute for a different numbered object. These properties should be described separately.
The useful design question is not simply “fungible or NFT?” It is: interchangeable within which class, divisible into what units, transferable under which rule, and identified at which level? The answers describe different aspects of the record and the represented claim.
This lesson classifies fictional museum passes, service credits, numbered-object records and a workstation credential. There are no purchases, prices or real token deployments. The exercise is about specifying behavior before selecting an interface or making claims about value and rights.
Choose your reading route
In this guide
- 1. State the substitution question precisely
- 2. Separate the other three axes
- 3. The classification rule for this lesson
- 4. Design A: two serial-numbered admission passes
- 5. Design B: uniform whole service credits
- 6. Design C: records for two particular objects
- 7. Design D: an account-bound workstation credential
- 8. Change one rule and see which answer changes
- 9. A token-type identifier can identify a class
- 10. Do not confuse permission to move with ease of exchange
- 11. Exercises with answers
- 12. Common questions
- 13. Sources and further reading
- Sections 1–3 define four independent questions and the classification method.
- Sections 4–7 apply them to four fictional designs.
- Sections 8–10 change rules and connect the results to standards carefully.
- Sections 11–13 provide exercises, common questions and sources.
Back to contents · Next section
1. State the substitution question precisely
Fungibility concerns interchangeability within a defined class. For this exercise, we ask whether replacing one entitlement with another preserves the specified service under the supplied rules. That is a narrower question than whether every observer would assign both the same market price.
Two unused passes may provide the same general admission on the same day. A pass for another day may not substitute for today’s entry. A used pass may have a distinct identifier and a recorded history while no longer providing the unused pass’s admission right.
Always name the class and comparison purpose. “These passes are interchangeable for this holder’s stated admission task” is precise. “All items with this symbol are interchangeable” may hide differences in expiry, location, eligibility or the issuer’s obligation.
This lesson does not revisit the psychology of treating money differently because of mental labels; that is covered in Mental Accounting. Our question concerns explicitly different or equivalent rules in a digital record system.
Back to contents · Next section
2. Separate the other three axes
Divisibility asks what quantities or parts the system permits. A balance of ten whole service units may be split into four and six. That does not mean the smallest unit can be cut into halves. A record for a particular object may be indivisible under its own rules.
Transferability asks whether a record or entitlement can move between holders and under which conditions. A rule might permit transfer to an eligible account, prohibit it while locked or forbid it entirely. Transfer permission does not tell us whether another item would be an equivalent substitute.
Identity asks what the identifier distinguishes. It might identify one unique record, a class containing many units or a transaction that moved quantities. A unique transaction identifier does not make every unit moved by that transaction a different kind of entitlement.
Keep all four answers in the design card. A single label such as “digital asset” does not specify them, and a long identifier is not a complete statement of the asset’s behavior.
Back to contents · Next section
3. The classification rule for this lesson
Each fictional design gives an intended use and exact rules. We classify the represented entitlement separately from the technical identity of its record. This distinction is especially important when individually tracked records provide equivalent services.
Our pass example does not redefine ERC-721 token identifiers as fungible. An individually tracked token remains a distinct token record. We are asking a separate application-level question: do two records, under the supplied terms, give the same admission result for the stated holder?
ERC-721 defines an interface for tracking distinct tokens, including querying the owner of a token identifier. Its specification was created on 24 January 2018 and is marked Final. That record model is useful, but does not itself determine every real-world entitlement attached to a token. ERC-721 specification
For every example, assume the fictional issuer follows the supplied application rules. We make no claim about enforceable legal rights, genuine physical ownership or actual availability of a commercial service. Those would require additional evidence beyond the classification exercise.
Back to contents · Next section
4. Design A: two serial-numbered admission passes
Holder H has two unused passes, P1 and P2. Each permits one general admission to the same venue on DayD. Neither has a special seat, priority entry, extra benefit or different expiry. Both are eligible for H’s stated admission task.
The system tracks P1 and P2 by distinct serial numbers. Under the supplied rule, H may choose either pass for one admission with the same service result. They are therefore interchangeable for this defined entitlement comparison, despite having different record identities.
Each pass is indivisible: the system accepts a whole unused pass for one admission and then marks that pass used. It does not recognize half a pass as half an admission.
Before use, the default design permits transfer to another eligible holder. The rule is conditional, not a promise that any arbitrary destination can receive a usable pass. After use, no remaining admission right is transferable in this model.
Now add P3, which grants admission on DayE instead. P3 cannot substitute for DayD admission. The visible word “pass” is not enough to place it in the same class as P1 and P2.
The design card therefore says: equivalent DayD admission rights within the supplied unused class; whole-pass granularity; conditional pre-use transfer; unique serial identity for each record. Each phrase answers a different question.
Back to contents · Next section
5. Design B: uniform whole service credits
A service-credit class C grants one identical catalogue-processing unit per credit. All credits in this class have the same issuer, service conditions and validity period. Holder H has a balance of ten base units.
The system permits allocation of four units to eligible holder J and six to H. The arithmetic is 10 = 4 + 6. Every base unit provides the same specified service, so substitution within this class does not change the service entitlement.
However, the smallest permitted quantity is one base unit. A requested half-base-unit allocation is outside the supplied quantity model. Splitting a balance into integer parts is not the same as dividing the smallest unit without limit.
The design records balances by class and holder; it does not give each base unit a separate serial identity. The transaction recording the four-unit transfer can still have a unique identifier. That identifier distinguishes the action, not a new service class for those four units.
Display conventions are a separate matter. ERC-20 includes optional decimals metadata for presenting quantities. A displayed decimal notation does not change the underlying integer amount represented in the contract. The standard was created on 19 November 2015 and is marked Final. ERC-20 specification
Our toy uses whole base units with no display conversion. It does not assume that every credit, token or application chooses the same granularity or validity conditions.
Back to contents · Next section
6. Design C: records for two particular objects
O7 and O8 are records referring to two different specified museum objects. The task is to identify the record associated with Object7. Substituting O8 does not satisfy that task, even if both records use the same interface and both objects belong to the same collection.
Each record has its own identity and is indivisible under the supplied rules. The designated controller field may change to another eligible account through an authorized transfer. Transferability therefore exists without making O7 and O8 interchangeable for the object-specific task.
This is not a claim that control of O7 automatically transfers physical possession, copyright or legal title to Object7. The teaching rule only describes the record and its designated controller. Any further entitlement would need a separate, justified relationship to the relevant documents and institutions.
Suppose a designer proposes splitting O7 into ten share records. That creates a new design question. What does each share represent? Who can act on the original record? How do the shares combine? The act of issuing share records does not physically divide Object7 or make the answers automatic.
A useful design card does not resolve that proposal merely by adding the word “fractional”. It specifies the new claim and rules before classifying its units. The lesson’s original O7 record remains indivisible unless the model is explicitly changed.
Back to contents · Next section
7. Design D: an account-bound workstation credential
Credential K records a stated calibration result for workstation H. It is bound to H’s designated account and has no permitted transfer to another account in the supplied design. It is one intact credential with a specific subject and claim.
When the task is to inspect H’s stated result, a credential about workstation J cannot substitute for K. Nor does copying its image create a valid credential about J. The subject relationship is part of the meaning.
ERC-5192 specifies a minimal locking interface extending ERC-721: when its locked status is true, the relevant token-transfer functions must reject transfer. It was created on 1 July 2022 and is marked Final. We use that as an example of transfer behavior being explicitly specified, not as proof that every credential uses this standard or remains permanently locked. ERC-5192 specification
A transfer restriction also does not establish that H was actually calibrated correctly. The truth of the claim, the issuer’s authority and the evidence behind it remain separate questions. A nontransferable false statement is still false.
Similarly, the restriction does not automatically describe account recovery, revocation or reissuance. Our card supplies no such mechanisms. A real design would need to define them if they are part of its intended operation.
Back to contents · Next section
8. Change one rule and see which answer changes
Return to P1 and P2, both unused and already held by H. Introduce a transfer lock that prevents either pass moving to another holder, while leaving H’s admission eligibility and the identical DayD service unchanged.
Transferability changes. For H’s specified admission comparison, the two unused entitlements remain equivalent. Their serial numbers also remain distinct, and neither pass becomes divisible. This is a controlled example of changing one axis without changing all the others.
Now instead mark P1 used while P2 remains unused. The comparison changes: P1 no longer provides the remaining admission that P2 provides. It is no longer in the unused-pass class. Identity persists, but the state-dependent entitlement differs.
A third change replaces P2’s DayD validity with DayE. That also changes the relevant class for a DayD task, without requiring a new conclusion about how long its serial number is or whether the interface can display it.
For credits, changing the allowed destination list affects transferability. Changing the service each credit provides can affect interchangeability. Changing display formatting alone need not alter the underlying units at all. State which rule changed before inferring which property changed.
Back to contents · Next section
9. A token-type identifier can identify a class
ERC-1155 supports multiple token types within one contract, with an identifier selecting a token or type and quantities associated with it. Its specification was created on 17 June 2018 and is marked Final. The standard can represent different configurations, so one contract address does not force every identifier to have the same meaning. ERC-1155 specification
Imagine a fictional multi-type record where type 5 represents DayD admission units and type 6 represents DayE units. A holder may have quantity two of type 5 and quantity one of type 6. The type identifier distinguishes classes; the quantity states how many units of a class are held.
It would be wrong to infer that every unit of type 5 has a separate unique-unit identity merely because the type has a number. It would also be wrong to merge types 5 and 6 into three interchangeable DayD admissions.
This conceptual example is not an implementation guide or a conformance claim. The next lesson examines native assets and contract-interface evidence more closely. Here, the important habit is to ask what level an identifier names before reasoning from its uniqueness.
Back to contents · Next section
10. Do not confuse permission to move with ease of exchange
Our designs say whether a transfer is permitted by the supplied rules. They do not establish that anyone wants the item, that a market exists or that an exchange could occur at a particular price or time.
That distinction keeps transferability separate from liquidity. A transferable numbered record can still have no available counterparty. A uniform class can still have access restrictions or lack a useful market. The broader concept is covered in How Liquidity Works.
Likewise, identical interface names do not establish identical issuer obligations. Two credit classes from different issuers may have the same displayed symbol and integer balance format while granting different services. A classification needs the actual rules and context, not merely the shape of a response.
This is why the design matrix comes before a technology label. Decide which service or claim exists, how quantity works, which changes are allowed and what identity must be preserved. Then evaluate whether an implementation expresses those requirements and what external evidence remains necessary.
Back to contents · Next section
11. Exercises with answers
Exercise 1: unique serials
P1 and P2 have different serial numbers but identical unused DayD admission rights for H. Must their service entitlements differ because their serials differ?
Answer: No. Record identity and entitlement equivalence are separate. Their records remain distinct, while either satisfies the specified admission task.
Exercise 2: another day
P3 permits DayE admission. Can it replace P1 for a DayD task merely because both are called passes?
Answer: No. Validity day is part of the defined class and service conditions.
Exercise 3: split the balance
H has ten whole service-credit base units. Is allocation of four and six permitted? What about half of one base unit?
Answer: Four plus six is permitted and conserves ten. Half a base unit is outside the supplied granularity rule.
Exercise 4: lock the passes
Both unused passes remain with H, but transfers to other holders are disabled. Which property changes, and which stated equivalence remains?
Answer: Transferability changes. H can still choose either pass for the same DayD admission under the unchanged eligibility rules. This is not a universal claim about market value.
Exercise 5: transfer a numbered record
O7’s controller can change. Does that make O8 a substitute for the Object7 record?
Answer: No. Transferability does not remove the object-specific identity required by the task.
Exercise 6: two type identifiers
A holder has two units of type 5 for DayD and one of type 6 for DayE. How many DayD admissions are supplied?
Answer: Two, not three. The third unit belongs to a different class.
Exercise 7: bound credential
K cannot transfer away from H’s designated account. Does that prove the calibration statement is true or specify recovery after account loss?
Answer: Neither. Transfer rules, claim truth and recovery mechanisms are separate; the last two need their own evidence or specification.
Exercise 8: unique transaction
A four-credit transfer has a unique transaction identifier. Does that turn the four units into four distinct service types?
Answer: No. The identifier describes the action. The credits retain their supplied class rules.
Back to contents · Next section
12. Common questions
Are all uniquely numbered records economically unique?
No conclusion about economic value follows from numbering alone. A serial can distinguish records that provide equivalent services under a defined comparison. Token-record identity should still be described accurately.
Does fungibility imply unlimited divisibility?
No. A class can have interchangeable whole units and a fixed smallest quantity. The allowed quantity representation is a separate rule.
Does nontransferability prove personal identity?
No. It describes a permitted state transition or its absence. The relationship between an account and a real person or workstation requires separate evidence.
Can properties change over time?
Yes, under a specified state transition. A pass can become used or expire; a transfer lock can change if the design permits it. The classification should identify the relevant state and rules rather than treat every property as permanent.
Back to contents · Next section
13. Sources and further reading
Sources were checked on 12 October 2026. All four designs and their rights descriptions are fictional, not representations of actual legal entitlements.
- ERC-721: distinct token identity and owner tracking; created 24 January 2018, Final.
- ERC-20: quantity-based interface and optional display metadata; created 19 November 2015, Final.
- ERC-5192: explicit locked-transfer behavior; created 1 July 2022, Final.
- ERC-1155: multiple token types and quantities; created 17 June 2018, Final.
- Mental Accounting and Liquidity: distinct background topics about financial labels and ease of exchange.
A precise digital-asset description answers four questions separately: what substitutes for what, what can be divided, what can be transferred and what the identifier actually identifies.