Following the 29 October attack, Binance reported approximately $6.3 billion in losses and around $3 billion frozen on-chain. On 31 October, the FBI attributed the attack to North Korea’s TraderTraitor activity.
Stablecoin issuers could immobilise funds through controls in their token contracts. Native BTC and ETH have no equivalent issuer-level freeze function, although recovery may still be possible through intermediaries or seizure of private keys. Reuters describes that distinction here.
For anyone building RWA infrastructure, this raises two separate questions:
- Who can restrict movement of the token?
- Who confirms the underlying right, and how can a contract read that confirmation?
ERC-8415 addresses the second question.
The design question
Whether a token represents an SPV share, a custodial claim or an individually registered asset, applications need to know which record governs the right it represents.
Where an authoritative register exists outside the token contract, the token can change hands before that register recognises the transfer. A warehouse register, securities register or other external ledger may operate on a different timetable from the chain.
A token can move before the authoritative register recognises the transfer. Applications need to see that difference.
ERC-8415 — Asynchronous Register Projection for NFTs makes that distinction explicit. The register remains the source of the recorded holding; the chain exposes a verifiable projection of its history.
The main interfaces answer different questions:
- ownerOf(tokenId) identifies the current ERC-721 owner.
- holderAsOf(tokenId, t) identifies the holder recorded by the projected register for a particular effective time.
- isFinalAsOf(tokenId, t) indicates whether a later conforming admission could still change that historical answer.
- openGapOf(tokenId), in the optional settlement interface, exposes an outstanding registration gap.
Ordinary token transfers can continue while registration catches up. Historical finality here concerns the stability of the projected answer; the legal effect of registration remains determined by the underlying arrangements.
What this enables at the application layer
Consider a sequence of trades: A → B → C.
The token may already belong to C while the register has only confirmed B. An application can settle A → B once that leg’s registration and contractual conditions are satisfied, while B → C remains unfinished.
If the later leg fails, the application can be designed to unwind the unfinished part without reopening the completed A → B leg. That requires the appropriate escrow, authorisations and trade terms. ERC-8415 supplies the registration evidence; the application supplies the remedy.
The same distinction matters after theft. An unauthorised token transfer does not, by itself, establish that the register recognises the recipient. The projection can expose a divergence between on-chain ownership and the recorded holder. Establishing that a theft occurred, restricting transfers and resolving the underlying right still depend on the relevant authorities and application mechanisms.
One terminology point: pending, accepted and rejected can be useful application labels, but they are not ERC-8415’s native three-state lifecycle. The protocol distinguishes admitted entries, open or closed gaps, and provisional or final historical answers.
Where it fits with other standards
ERC-3643 and ERC-7943 cover compliance checks, transfer controls and enforcement mechanisms, including freezing and authorised transfers.
ERC-8415 addresses a complementary question: what has the external register actually confirmed? Permission to receive a token and recognition by the register are separate facts.
ERC-8392 addresses another part of asset state: market sessions, valuation-source conditions, and issuance or redemption availability. Distinguishing an expected pause in updates from a failed feed reflects a similar need to make operational conditions readable by contracts.
These interfaces can give wallets, lending protocols and agents a more precise basis for deciding when to trade, release funds or accept collateral.
Status and implementation
- The proposal is submitted as ethereum/ERCs PR #2006, with specification status Draft.
- ERC8415-Kit provides reference components and an executable consumer example that reads the projection and acts in the same transaction. The specification and reference code are under CC0.
- The public integration report records 60 wallet test cases passing within their documented scopes, including Hoodi execution, API/native integration and controlled fault injection, plus an additional same-block ordering campaign.
Feedback wanted
I would particularly welcome feedback on three points:
- Composability: Is an ERC-721 extension the right starting point, or should register projections also have a standard binding to other token types?
- Trust: Which verification profiles are most useful in practice—a register’s own signature, an accountable attestor or a quorum—and what should consumers be able to inspect about that trust model?
- Consumer requirements: For lending protocols and agent tooling, what additional signals are needed beyond holder history, historical finality and an open registration gap? Freshness, deadlines, dispute reasons, or something else?
The detailed specification and earlier discussion are here: