Open Ledger Runtime Standard

This repository provides a reference implementation of the Open Ledger Runtime Standard.

Any implementation (in any language, on any infrastructure) is considered compliant if it satisfies the MUST/SHOULD/MAY requirements defined in this standard.

Status

• Version: 0.1 (draft)
• Scope: normative specification for governance-neutral ledger runtime behavior.

Conventions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this standard are to be interpreted as described in RFC 2119.

Scope

This standard defines the minimum, testable requirements for a ledger runtime that provides deterministic accounting, auditable execution, and governance- neutral policy application. It specifies:

• Ledger semantics and invariants.
• Governance neutrality and decision package handling.
• Security and auditability expectations.
• Observability requirements for operational integrity.
• API compatibility and versioning principles.
• Deployment model constraints (on-prem, self-host, air-gapped).

Non-goals are listed in STANDARD/NON_GOALS.md.

The standard does not require centralized servers, permissions, or licenses to deploy or operate.

Terminology

• Ledger runtime: the execution engine that applies validated operations and emits immutable records.
• Operator: an organization or team that deploys and runs the system.
• Participant: an account holder or integration that submits operations.
• Decision package: a machine-readable, signed governance input applied by the runtime without discretionary interpretation.
• Governance registry: an append-only log of decision packages and checkpoints.
• Audit log: a tamper-evident record of execution and security-relevant events.

Conformance

An implementation conforms to the Open Ledger Runtime Standard if it:

1. Implements all MUST/REQUIRED statements in this document and the linked standard sections.
2. Publishes a verifiable version identifier for the runtime build.
3. Exposes the required operational endpoints and metrics.

Non-conforming features MAY be implemented, but they MUST NOT weaken the requirements or alter defined semantics.

The ledgerd runtime in core/ledger is a reference implementation, not the only valid runtime. Implementations MAY use different languages, storage engines, or deployment models if they satisfy the normative requirements.

Ledger Semantics (Summary)

The runtime MUST:

• Apply operations deterministically and in a well-defined order.
• Record double-entry transactions where debits and credits sum to zero.
• Preserve idempotency for write operations that accept an idempotency key.
• Reject invalid units of account and invalid amounts (empty or malformed).
• Emit an immutable audit log entry for every accepted state transition.

Units of account are deployment-defined. The standard does not mandate or imply issuance of a currency.

Governance Neutrality (Summary)

The runtime MUST:

• Accept decision packages as external, signed inputs.
• Apply decision outcomes mechanically, without discretionary policy.
• Support advisory mode that records governance signals without blocking ledger writes.

Strict enforcement mode MAY be enabled by operators and MUST be explicit. Details are specified in STANDARD/GOVERNANCE_NEUTRALITY.md.

References

Normative specification documents:

• STANDARD/PROTOCOL_OVERVIEW.md
• STANDARD/LEDGER_MODEL.md
• STANDARD/TRANSACTION_SEMANTICS.md
• STANDARD/ERROR_MODEL.md
• STANDARD/CRYPTO_AND_KEYS.md
• STANDARD/AUDIT_LOGGING.md
• STANDARD/GOVERNANCE_NEUTRALITY.md
• STANDARD/REGISTRIES.md
• STANDARD/WIRE_FORMAT.md
• STANDARD/SECURITY_MODEL.md
• STANDARD/THREAT_MODEL.md
• STANDARD/OBSERVABILITY.md
• STANDARD/API_CONTRACT.md
• STANDARD/DEPLOYMENT_MODEL.md
• STANDARD/COMPATIBILITY.md
• STANDARD/NON_GOALS.md
• STANDARD/CONFORMANCE.md

Non-normative guidance:

• STANDARD/ENGINEERING_MANIFESTO.md

Non-normative reference implementation guidance:

• docs/operations/runbook.md
• docs/architecture/overview.md