[Working Draft] Asynchronous Register Projection for NFTs

MichaelYip · September 10, 2026, 8:04am

I’ve been working on a draft called Asynchronous Register Projection for NFTs and wanted to put it up for discussion. No ERC number assigned yet — I’d like to get the scope and semantics right before pushing a PR. Would appreciate any feedback, especially on the historical-query behavior and how (or whether) this overlaps with existing standards.

Problem

An ERC-721 can trade faster than an external register updates. ownerOf(tokenId) tells you who holds the token now; it doesn’t tell you who the register had confirmed at a particular past instant.

The extension keeps those two views separate. Normal transfers proceed while a register update is still pending. The projection is just a time-indexed history of confirmed holders.

Proposed model

Each entry records a holder address, effective time, record commitment, previous commitment, registry reference and version. Versions are consecutive, effective times strictly increase, and a commitment can’t be reused within a token. An entry’s interval runs up to (but not including) the next entry’s effective time.

For a token with at least one entry, any instant at or after the first entry resolves to one recorded holder. Query before the first entry and it reverts. The result may still be provisional.

The core interface, IRegisterProjection, exposes:

currentEntry, entryAt, entryCount for walking the history
entryAsOf, holderAsOf for point-in-time lookups
isFinalAsOf — whether a later admission could still change that answer
registerId to identify the projected register

ERC-165 ID: 0x6309e170.

A concrete example

Say the first entry confirms Alice from time 100. Bob buys the token at 120. The register records Bob effective at 130, but the entry doesn’t land on chain until 150.

Before admission, ownerOf may already return Bob while holderAsOf(140) returns Alice provisionally. After admission, holderAsOf(140) returns Bob. Everything from 100 up to (but excluding) 130 is now final; 130 onward stays provisional until a later entry closes the interval.

A later entry can confirm the same holder. This matters: it lets historical instants become final even when the holder didn’t change.

Optional settlement interface

IProjectionSettlement (ERC-165 ID 0xf4a7d71b) adds a discoverable authority, a bounded settlement deadline, at most one open projection gap per token, and proof-verified admission.

Opening a gap does not freeze ERC-721 transfers. Settlement authority is separate from token ownership. Anyone can relay a proof; submitting one grants no special rights.

An admission checks that the remote state is finalized and the proof verifies under the declared profile. It binds the local chain and contract, token and settlement IDs, holder, snapshot, prior and next commitments, version and effective time. Proof consumption, remote-height advancement, entry admission and gap closure are atomic.

Three questions stay distinct:

Who was recorded at instant t? → holderAsOf
Can a later admission change that? → isFinalAsOf
Is a change in progress for that instant? → openGapOf, openedAt

Cancellation closes a gap but doesn’t make provisional history final.

Scope and trust assumptions

The proposal standardizes the projection and its query semantics. It doesn’t move tokens across chains, decide the legal effect of registration, or prescribe an app’s entitlement rules.

A proof establishes inclusion in accepted remote state, not the truth of the underlying register. You’re still relying on the registrar, the consensus or attestation model, the verification profile, and the authority’s policy. If the register stops issuing entries, recent instants can stay non-final indefinitely. Repeated supersession is a liveness concern too.

The full register stays off-chain, but holder addresses, commitments, references, times and proof material are public — commitments alone don’t give you privacy.