ERC8415-Kit: Reference Implementation Now Public (CC0)

ERCs
, , , ,
1

TL;DR: Alongside the ERC-8415 proposal (Asynchronous Register Projection for NFTs), we’ve made ERC8415-Kit publicly available under CC0 1.0 Universal. It is one implementation of the spec — adopting ERC-8415 does not require using it, and independent implementations are welcome.

What the Kit provides

The Kit is a practical starting point for building and testing ERC-8415 integrations:

  • An append-only projection engine for the register-confirmed holder record
  • Proof-profile verification and atomic admission
  • Temporal query APIs (holderAsOf, isFinalAsOf, openGapOf, entryAt, …)
  • JavaScript and Python SDKs
  • A shared conformance test suite (151 tests, including 20 mandatory conformance tests)

npm run verify runs the full suite with no runtime dependencies.

The core distinction

The central design choice of ERC-8415 is unchanged, and the Kit preserves it exactly:

The tradeable token position (ownerOf) and the register-confirmed holder are separate records.

These two sequences can diverge in flight and must be queried separately:

Question Answered by
Historical holder resolution The projection (holderAsOf)
Whether that answer is final Finality (isFinalAsOf)
Whether a settlement is in flight Open gaps (openGapOf, openedAt)

The Kit records what happened; it does not adjudicate legal title, guarantee eventual alignment, or prescribe remedies such as cancellation, escrow, or refunds. Those are matters for the transaction terms between parties.

Scope and limitations

To set expectations clearly:

  • The specification defines conformance; the Kit is one implementation. Interoperability is determined by the conformance tests, not by this codebase.
  • Adopting ERC-8415 does not require using our software or services. Independent implementations are explicitly welcome.
  • The current code is reference infrastructure for development and integration testing. On-chain deployment (Stage 3), durable storage, and production deployment evidence remain outstanding work — see the repo’s Current Status and DELIVERY-EVIDENCE.md.

Why we’re publishing it

We’re publishing the Kit to lower the cost of adoption and to make implementation choices open to inspection, testing, and improvement. Conformance should be demonstrable from shared tests, not assumed from a single codebase.

Feedback & contributions

We welcome:

  • Technical review of the projection model and verification engine
  • Integration feedback from teams building against ERC-8415
  • Contributions, particularly around developer interfaces and cross-implementation conformance

If you’re working on an independent implementation, we’d especially like to compare notes on the conformance suite so implementations can interoperate.

Related: see the ERC-8415 proposal thread for the normative specification and semantic model.

1 Like
ERC-8415: Asynchronous Register Projection for NFTs
2

Hey. I’m interested in the RWA side of this — particularly how an application would use the historical holder record for income distributions.

Suppose the asset terms assign a payment to the register-confirmed holder at a specific record date. The token has already moved from user 1 to user 2 but holderAsOf still returns user 1 provisionally at that date.

Would you consider adding an integration example showing how the application waits for that historical answer to become final before paying? What would let it proceed if no further ownership change occurs?

I understand that payout rules belong outside ERC-8415. An example showing how confirming entries support this workflow would make the boundary much easier to understand.

3

Good point—that’s the exact gap the wallet layer is built to solve.

Missed dividends (anything occurring during the gap) are paid out retroactively to holderAsOf(recordDate) once finalization finishes. Because holderAsOf is temporal and append-only, the recipient is completely deterministic:

  • dividend-time < finalization-time: Pays User 1

  • dividend-time ≥ finalization-time: Pays User 2

We’re putting together an integration example covering missed-dividend payouts soon—I’ll drop a link here once it’s live.

1 Like