Просмотр новости
Найдите то, что Вас интересует
Спутники
РН
SpaceX
Роскосмос
NASA
СпутникиРНSpaceXРоскосмосNASA
An NFT collection cannot prove on-chain how many of one item within it will ever exist.
A collection typically holds many items — item kinds, ticket classes, art series — each with its own intended edition size. The issuer publishes those sizes in metadata. Nothing enforces them, and nothing lets another contract check them. tokenURI points at a server the issuer controls: a JSON file claiming "maxSupply": 100 can be rewritten, and a contract cannot fetch or parse it in any case.
The cap exists as a promise. I would like it to be a constraint.
This comes out of putting a live game’s items on-chain. Two properties the game already relied on turned out to have no representation in ERC-721: what a token is, and how many of that kind may ever exist.
An identifier does not say what the token is
In ERC-721 a token is a number and an owner. Nothing on-chain distinguishes a Flame Sword from a Blue Potion. Yet most of a game’s rules are stated in terms of item rather than instance — what a recipe consumes, what a set bonus counts, what an exchange accepts.
Projects work around this in ways that do not interoperate. Some pack the item into the upper bits of tokenId under a private scheme, which bounds both ranges and requires every reader to know the layout. Others expose a getter under whichever name they picked — itemId, classId, category, series — so every consumer writes a bespoke adapter. I have seen a deployed system declare a three-function interface — ownerOf, transferFrom, and its own such getter — purely so one contract could read another’s classification.
The cap and the item are one mechanism
A cap has to be charged against something. The contract must know at mint time which item a new token belongs to, and must expose that association afterwards so the count can be audited. Recording the item is what makes the cap enforceable; exposing it is what makes the cap verifiable.
Reading the item then turns out to be useful on its own — a marketplace can group by it, a lending protocol can price by it, an index can weight by it. But the reason to standardise it is that supply enforcement requires it.
Where a per-item cap is registered with a contract that prices a collection against a fungible token, the cap becomes a term in a pricing formula. A cap the issuer can quietly raise reprices everyone’s holdings. That is the constraint I think an interface standard should be able to express, and a counterparty should be able to verify.
Where existing standards fall short
Standard
Limitation
ERC-721
No items, so nothing to classify by and no per-item cap to enforce. Collection-wide supply says nothing about the scarcity of one item.
ERC-1155
Has per-id supply, but tokens sharing an id are indistinguishable — balanceOf(owner, id) returns a quantity, so two of them cannot be approved or transferred independently or carry different provenance. No edition number, no individual identity, no standard cap.
ERC-3525
Provides slot plus value, but its core feature is splitting and merging value for financial instruments. No supply cap semantics, and fractionalising a game item or a ticket is meaningless.
ERC-3440
Closest existing behaviour — caps a limited edition run and fixes it on set. But the cap is one run per contract: a collection holding a thousand kinds of item needs a thousand contracts. Its subject is artist signatures for provenance, and it exposes no way to ask which kind a token is.
ERC-7496
Puts arbitrary traits on-chain, so an issuer could store a kind under a trait key. Traits are mutable by design and carry no supply accounting, so a cap stored as a trait is a number the issuer can rewrite — the same guarantee metadata already fails to give.
ERC-8041
Fixed supply plus mint numbering, but at collection scope and specific to ERC-8004 Agent NFTs. Exposes its configuration through events rather than getters, so a contract cannot read it.
The shared gap is level. Where a cap exists at all, it covers the contract. This proposal puts it one level down: one contract holds many items, each with its own enforced cap.
Interface
interface IERC8417 /* is IERC721, IERC165 */ {
event ItemCreated(uint256 indexed itemId, uint256 maxSupply);
event TokenMinted(uint256 indexed tokenId, uint256 indexed itemId);
function tokenItemId(uint256 tokenId) external view returns (uint256);
function itemExists(uint256 itemId) external view returns (bool);
function itemMaxSupply(uint256 itemId) external view returns (uint256);
function itemSupply(uint256 itemId) external view returns (uint256);
function itemTotalMinted(uint256 itemId) external view returns (uint256);
function itemBurnedCount(uint256 itemId) external view returns (uint256);
}
Edition numbers — a token’s position within its item, for implementations that need “42 of 100” on-chain — are an optional extension rather than core, so an implementation that does not need them pays no storage per token:
interface IERC8417Edition /* is IERC8417 */ {
function tokenEdition(uint256 tokenId) external view returns (uint256);
}
Two cap semantics that are requirements, not implementation choices
The cap bounds cumulative mints rather than circulating supply. If burning returned capacity, an issuer could mint, burn and mint again indefinitely under a cap advertised as fixed. itemTotalMinted is the value checked against itemMaxSupply; itemSupply and itemBurnedCount are exposed separately so a consumer can see both.
The cap is write-once. A cap that can be raised after creation is worth no more than the metadata it replaces. Lowering is equally unsafe — it can be set below itemTotalMinted, breaking the invariant retroactively.
What this does not guarantee
Worth stating plainly, because it bounds the claim.
This bounds cumulative mints per itemId. It places no bound on how many items an issuer creates. An issuer that has exhausted one item’s cap can create a second item that is materially identical and mint under that one. A consumer treating an item as a proxy for a kind of thing is relying on the issuer’s taxonomy, not on this standard. What becomes verifiable is narrower and exact: for a given itemId, the cap was fixed at creation and no mint has ever exceeded it.
Open questions
Feedback most welcome on these five. Each is a point where the design could reasonably have gone the other way.
Sentinel encoding. maxSupply == 0 means “item not created” and type(uint256).max means practically unlimited. This removes the need for a separate created flag and keeps the mint guard a single comparison with no exemption. Is overloading zero acceptable, or should existence live in its own storage flag?
Burned tokenId reuse. Neither this proposal nor ERC-721 reserves a burned tokenId, so an identifier can be minted again under a different item. Caps stay sound, but a consumer caching tokenId → itemId can go stale. I chose to document the caveat and point consumers at TokenMinted rather than forbid reuse, since forbidding it costs storage and ERC-721 itself does not. Should the standard reserve burned identifiers instead?
Edition as an extension. The core guarantee is complete without edition numbers, so they are optional. But an optional getter is one consumers cannot rely on. Is the storage saving worth the fragmentation?
tokenId assignment. Implementations may assign sequentially or accept a caller-specified tokenId. Caller assignment lets a system align with an identifier space that already exists off-chain; sequential is simpler. The standard takes no position. Should it?
Three supply getters. itemTotalMinted is derivable as itemSupply + itemBurnedCount. It is exposed explicitly because that derivation is the exact place implementers get the cap check wrong, and because an implementation that enforces the cap correctly already stores all three. Is the redundancy justified, or should the standard expose the minimum set?
Full draft with specification, rationale, test cases, reference implementation and security considerations: ERCS/erc-8417.md
5 posts - 3 participants
Read full topic
| # | Наименование новости | Тональность | Информативность | Дата публикации |
|---|---|---|---|---|
| 1 | ERC-8414: Token-Bound Task Tenders | 0 | 10.19 | 05-09-2026 |
| 2 | ERC8415-Kit: Reference Implementation Now Public (CC0) | 0 | 13.08 | 17-09-2026 |
| 3 | ERC-8415: Asynchronous Register Projection for NFTs | 0 | 7.17 | 10-09-2026 |
| 4 | ERC-8419: Know-Your-Agent (KYA) Framework | 0 | 13.66 | 19-09-2026 |
| 5 | ERC-8423: ERC-721 Burn Record Extension | 0 | 4.76 | 18-09-2026 |
| 6 | "Module: A Reusable State-Machine Framework for NFT Capabilities (Ownership Module v0.5 → v1.0)" | 0 | 12.53 | 27-09-2026 |
| 7 | ERC: AI Agent Proof-of-Safety Attestation & Transaction Guard Standard (IAgentTransactionGuard) | 0 | 15.4 | 13-09-2026 |
| 8 | ERC-8410: Portable Execution Plan Artifact | 0 | 10.4 | 04-09-2026 |
| 9 | ERC-8409: Signed Service Payment Quotes | 0 | 6.38 | 03-09-2026 |
| 10 | Load Leveling: Why ERC-8415 Decouples Settlement Speed from Off-Chain Registry Throughput | 0 | 12.11 | 13-09-2026 |