Developers

Everything you need to implement, test, and contribute to the L3RS-1 standard.

Quickstart

Get up and running with the L3RS-1 reference implementation in three steps.

1. Install

npm install @l3rs/reference-impl

Add the reference implementation package to your project.

2. Import

import { constructAssetId, applyStateTransition, AssetState } from '@l3rs/reference-impl'

Import the functions you need directly — no class instantiation required.

3. Verify canonical vector

const assetId = constructAssetId(
  '0279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798',
  1740355200,
  '0000000000000001'
)
// → '593f0dfb3da2fb8e8e21059e26f4a1875e9059a6d9d634e3065541e6c193506a'

All six language implementations must produce this exact output for §2.2 Asset_ID construction.

Resources

GitHub Repository

Specification source, reference implementation, and community contributions.

Open

SDK — 6 Languages

Reference implementation in TypeScript, Python, Go, Rust, Java, and Solidity. CROSSCHAIN conformance class. Zero runtime dependencies.

Open

SDK API Reference

Full API reference for all six language implementations — TypeScript, Python, Go, Rust, Java, and Solidity.

Open

Conformance Test Suite

Automated tests for validating your implementation against L3RS-1 normative requirements.

Open

Issue Tracker

Report bugs, request features, and track the status of open issues.

Open

Interactive Tools

Browser-based tools for exploring compliance rule evaluation, asset state transitions, and CID hash computation.

Open

Invariants Reference Poster

Printable reference card for all eleven L3RS-1 protocol invariants with formal notation, grouped by theme, including transfer pipeline.

Open

Reference Implementation

The L3RS-1 reference implementation is the canonical example of a conformant asset engine. It implements every normative requirement in the specification and serves as both a development aid and a validation baseline.

The reference implementation is open source, published under a permissive license, and available on the L3RS-1 GitHub repository.

Compliance Test Suite

The conformance test suite validates that an implementation correctly enforces all deterministic state transitions, compliance invariants, identity binding requirements, and governance override controls defined by L3RS-1.

Passing the full test suite is a prerequisite for L3RS-1 conformance certification. The suite is continuously updated as the specification evolves.

Canonical serialization

All hash computations in L3RS-1 are performed over a canonical serialization of the relevant object. Implementations that deviate from the canonical form will produce different hashes and fail certificate verification. This is one of the most common sources of conformance failures.

Rule 1 — Field ordering: Fields must be serialized in the exact order defined by the canonical schema. Reordering fields produces a different hash.
Rule 2 — String encoding: All strings must be UTF-8 encoded with no normalization-dependent ambiguity.
Rule 3 — Integer representation: Fixed-width integers must be unsigned big-endian at declared width. Variable-width integers must be minimally-sized unsigned big-endian with explicit length prefixing.
Rule 4 — No unknown fields: In strict mode, unknown fields must be rejected for any object used in hash computations.
Rule 5 — Canonical JSON: If JSON encoding is used, apply canonical JSON rules — no insignificant whitespace, stable key ordering, stable number formatting.
Rule 6 — Hash function: let H = ser(object). H must be computed over the canonical serialization. Any implementation deviation from the serialization canon invalidates conformance.

Canonical serialization specification → Section 13.11 of L3RS-1 v1.0.0 (PDF)

Implementation Profiles

Implementation profiles adapt the L3RS-1 specification to specific deployment environments. Each profile defines how normative requirements map to a given ledger architecture.

Profile A: Smart Contract VM Environments

For EVM-compatible or similar smart contract chains. Asset logic is implemented as an immutable core contract. Compliance must execute before balance mutation. Governance is enforced via threshold signature or multisignature mechanism. Gas or execution cost must remain bounded as declared.

Profile B: Account-Based Public Networks

For account-based public chains. Balances stored in canonical mapping structures. Nonce-based replay protection enforced. Cross-chain metadata stored as immutable hash reference. External bridge contracts must not modify compliance or governance configuration.

Profile C: Object-Oriented State Models

For ledgers using object-oriented state. Asset implemented as a state object with immutable metadata fields. Transfer requires compliance object validation. Governance override is a privileged state transition requiring quorum validation. Object references must be deterministic and verifiable.

Profile D: Permissioned Financial Networks

For regulated institutional networks. Compliance may execute at application layer but must remain deterministic. Validators enforce compliance prior to consensus inclusion. Governance authorities registered in network configuration. Legal Mirror anchored to jurisdiction registry. Validators must not bypass compliance or override quorum requirements.

Profile E: Sovereign Digital Settlement Networks

For central bank and sovereign deployments. Jurisdiction field corresponds to sovereign authority. Legal Mirror references official legal registry. Governance authority corresponds to statutory body. Reserve interface integrates with central treasury or custodian system. Override authority follows statutory quorum where applicable.

Profile F: Hybrid Public-Private Architecture

For deployments combining permissioned issuance with public liquidity. Issuance on permissioned layer, liquidity on public layer. Cross-chain certificate preserves compliance and governance integrity throughout. Origin chain remains canonical legal authority. Must not weaken downgrade resistance.

Developer Documentation

L3RS-1 implementations must enforce deterministic behavior at every layer of the asset lifecycle. Given identical inputs and state, any conformant implementation must produce identical outputs regardless of the underlying ledger technology, deployment environment, or application framework.

The specification adopts a compliance-first design philosophy. Regulatory constraints are normative requirements that must be satisfied before an asset can transition between states. Implementers should treat the conformance test suite as the authoritative validation of correctness.

For questions about implementation details, edge cases, or interpretation of normative requirements, use the issue tracker or participate in the Technical Members mailing list.