Meridian Protocol Specification

The open protocol for attested energy-compute dispatch and settlement.

This document defines the Meridian protocol — its design principles, operational primitives, federation operating rules, and integration requirements. Meridian is MIT licensed. No single participant owns the protocol. The chain is the authority.

Status: Draft v0.1  |  PATENTS PENDING  |  General Reasoning, Inc. Active Development
Section 01

Introduction

Meridian is the market operating system for decentralized energy-compute markets. It defines a minimal, auditable-by-construction protocol for three operations — registration of capacity, dispatch of generation to load, and settlement of the completed transaction — each of which produces an immutable Meridian Attestation Record.

The Meridian protocol is not a marketplace operator. It is not a utility. It is not a clearinghouse. It is a set of rules that govern what a valid operation looks like, what record that operation must produce, and what conditions must be met before the next operation in sequence may occur. The participants are sovereign. The chain is the authority.

Meridian is designed to run as a federation — a set of participants, each attesting their own capacity and role, each operating under a shared protocol they cannot individually override. The federation has no operator. It has a protocol.

Foundational Invariant

No dispatch may occur without a valid registration CU. No settlement may occur without a valid dispatch CU. The chain enforces sequence. Sequence is authorization.

Section 02

Design Principles

Auditable by Construction

Every Meridian operation produces an Attestation Record before it is considered complete. The audit record is not a retrospective receipt — it is the gate through which the operation passes. An operation that does not produce an Attestation Record did not happen in the Meridian sense.

No Single Owner

The protocol is MIT licensed. No participant, including General Reasoning, Inc., may claim ownership of the federation or override the protocol rules by operator action. Changes to the protocol are governed by the federation operating rules defined in this specification.

Minimal Primitives

Meridian defines exactly three primitives: Capacity Attestation, Dispatch, Settle. All market behavior is composed from these. The protocol does not define pricing, forecasting, optimization, or matching algorithms — these are application-layer concerns that participants may build on top of the protocol. The protocol defines only what must be attested and in what order.

Sovereign Chains

Each federation participant or domain deployment may operate its own attestation instance — its own sovereign chain. The Meridian protocol specifies CU structure and reference requirements; it does not require a shared chain. Federation participants attest to each other by Attestation Record reference, not by shared custody of a ledger.

Domain Terminology

The base protocol uses generic terminology (Capacity Attestation, Dispatch, Settle, CU). Domain deployments may substitute domain-specific language over the base terms. A Meridian energy deployment may surface "capacity attestation," "dispatch signal," and "settlement close." The underlying CU structure is identical. The terminology layer is configuration, not protocol.

Section 03

Terminology

CU Meridian Attestation Record. An immutable, hash-chained record produced by the Meridian attestation layer. Every Meridian primitive produces exactly one Attestation Record on completion. An Attestation Record that does not exist means the operation did not complete.
Generation Node A federation participant that attests capacity to produce or deliver energy — SMR output, solar-plus-storage, microgrid, or other firm or intermittent generation asset.
Load Node A federation participant that attests capacity to consume energy — AI compute cluster, advanced manufacturing cell, data center, industrial campus.
Registration Record The CU produced by a completed Capacity Attestation operation. It is the participant's capacity claim of record. All subsequent Dispatch Records that involve this participant reference its Registration Record.
Dispatch Record The CU produced by a completed Dispatch operation. It references the Registration Records of both the generation node and the load node involved in the match. It cannot exist without valid prior Registration Records.
Settlement Record The terminal CU on a transaction. It references the Dispatch Record and closes the chain for that transaction. A transaction is not settled until its Settlement Record exists.
Federation The set of participants operating under the Meridian protocol. The federation has no operator. Membership is established by a valid Registration Record.
Sovereign Chain A attestation instance operated by a single participant or domain deployment. Participants may run their own chain. Federation interoperability is achieved by Attestation Record reference, not shared custody.
Primitive 01

Register — Capacity Attestation

01 / REGISTER Register

Register is the first operation in every Meridian transaction chain. A participant — generation node or load node — attests their capacity to the federation. Registration establishes what the participant claims to have before any dispatch occurs. The Registration Record is the participant's founding record in the federation.

Registration is not a one-time operation. A participant may register multiple capacity assets, each producing its own Registration Record. Each CU is a discrete capacity claim and may be referenced independently in subsequent Dispatch operations.

A Registration operation must include: participant identity, participation role (generation or load), capacity description, and contact record.
A Registration Record is produced on successful completion. Failure to produce an Attestation Record means the registration did not complete.
A registration may not be deleted. It may be superseded by a subsequent registration that references the prior CU, establishing a chain of capacity updates.
A participant with no Registration Record may not participate in a Dispatch operation as either generation or load.
Registration Record — Field Structure ; Meridian Registration Record payload { "cu-type": "meridian/register", "participant-id": "<uuid>", "role": "generation" | "load" | "developer" | "observer", "capacity": "<freeform capacity description>", "contact": "<email>", "org": "<organization name>", "prior-cu-id": "<cu-id | nil>", ; nil for founding registration "domain": "meridianos.energy", "timestamp": "<ISO 8601>" }
Primitive 02

Dispatch — Capacity to Load

02 / DISPATCH Dispatch

Dispatch is the match operation. Generation capacity is allocated to a load node. The Dispatch Record references the Registration Records of both parties and cannot exist without them. The dispatch record is the market event — the moment at which a generation claim and a load claim are matched and committed.

Meridian does not define the matching algorithm. Participants may build price discovery, forecasting, and optimization layers on top of the protocol. The protocol defines only what must be attested when a match occurs. The match is the record.

A Dispatch operation must reference valid Registration Records for both the generation node and the load node.
A Dispatch Record must include: generation Attestation Record reference, load Attestation Record reference, capacity amount, dispatch period, and agreed terms.
A Dispatch Record is produced on successful completion. A dispatch that does not produce an Attestation Record did not occur in the Meridian sense.
A dispatch may not proceed to settlement until its Dispatch Record exists and is valid.
Dispatch Record — Field Structure ; Meridian Dispatch Record payload { "cu-type": "meridian/dispatch", "dispatch-id": "<uuid>", "gen-cu-id": "<registration CU of generation node>", "load-cu-id": "<registration CU of load node>", "capacity-mw": "<decimal>", "dispatch-start": "<ISO 8601>", "dispatch-end": "<ISO 8601>", "terms-hash": "<sha256 of agreed terms document>", "domain": "meridianos.energy", "timestamp": "<ISO 8601>" }
Primitive 03

Settle — Transaction Close

03 / SETTLE Settle

Settlement is the terminal operation on a transaction. The dispatch is confirmed, measured, and closed. The Settlement Record is the final record — it references the Dispatch Record and closes the chain for that transaction. A transaction without a Settlement Record is open. A transaction with a Settlement Record is closed and immutable.

Settlement is the record that regulators, auditors, and counterparties rely on. Because it is a Attestation Record, it is auditable by construction — its existence, its content, and its position in the chain are all verifiable without reference to any operator's representation.

A Settlement operation must reference a valid Dispatch Record.
A Settlement Record must include: dispatch Attestation Record reference, measured delivery (actual vs. dispatched), settlement timestamp, and outcome (completed / partial / failed).
A Settlement Record is the terminal record on a transaction. It cannot be amended. A disputed settlement produces a new chain branch with a dispute CU, not a modification to the original.
A transaction is not settled until its Settlement Record exists. Open transactions are visible to the federation.
Settlement Record — Field Structure ; Meridian Settlement Record payload { "cu-type": "meridian/settle", "settlement-id": "<uuid>", "dispatch-cu-id": "<dispatch CU this settlement closes>", "delivered-mw": "<decimal — actual delivery>", "dispatched-mw": "<decimal — from dispatch CU>", "outcome": "completed" | "partial" | "failed", "settlement-ts": "<ISO 8601>", "domain": "meridianos.energy", "timestamp": "<ISO 8601>" }
Section 07

Chain Integrity

Every Meridian transaction produces a chain of three CUs. The chain is the authoritative record of the transaction. The chain enforces sequence. No operation in the chain may reference a prior Attestation Record that does not exist — the append-only, hash-chained structure makes this a structural invariant, not a rule subject to operator discretion.

TRANSACTION CHAIN — COMPLETE [ Registration Record ] -- participant capacity claim of record | v [ Registration Record ] -- counterparty capacity claim of record | v [ Dispatch Record ] -- references both registration CUs | v [ Settlement Record ] -- terminal record, references dispatch CU Every CU: immutable, hash-chained, sovereign to the transaction. The chain is the authority. No operator representation required.
Dispute Handling

A disputed settlement does not amend the original Settlement Record. It opens a new chain branch beginning with a Dispute Record that references the Settlement Record in question. The original record is immutable. The dispute record is additive. Both are visible to the federation.

Section 08

Participation Types

Meridian federation membership is established by Registration Record. The role declared in the Registration Record determines what operations a participant may initiate.

Role May Initiate Description
Generation Node Register, Dispatch (generation side), Settle SMR operator, solar-plus-storage, microgrid, or other firm generation asset. Attests capacity to produce and deliver energy.
Load Node Register, Dispatch (load side), Settle AI compute cluster, manufacturing cell, industrial campus. Attests capacity to consume energy and receive dispatch allocations.
Developer Register, read-only API access Building applications, tooling, or market logic on top of the Meridian protocol. May not initiate Dispatch or Settle operations directly.
Observer Register, read-only access Policy stakeholders, regulatory observers, researchers. Registration establishes an Attestation Record record of participation without market operation authority.
Section 09

Federation Operating Rules

Membership

Membership in the Meridian federation is established by a valid Registration Record. There is no application process beyond registration. There is no operator approval. The registration produces the Attestation Record or it does not. A valid Attestation Record is the credential.

No Operator Override

No participant, including General Reasoning, Inc., may override a valid Attestation Record, remove a participant's registration from the chain, or alter a settlement record. The chain is append-only. The attestation layer structural invariants enforce this at the protocol layer, not by policy.

Protocol Changes

Changes to the Meridian protocol specification require a versioned release. Participants operating under a prior version are not automatically bound by a new version. Backward compatibility is maintained wherever possible. Breaking changes produce a new major version. The federation may operate participants on multiple compatible versions simultaneously.

Sovereign Chains

Participants may operate their own attestation instance. The protocol does not require a shared chain. A participant's sovereign chain produces CUs with the same structural requirements as the reference implementation. Interoperability is established by Attestation Record reference — a Dispatch Record references Registration Records by their content-addressable identifiers regardless of which chain produced them.

Section 10

Governance

Meridian is an open protocol. The reference implementation and specification are MIT licensed. General Reasoning, Inc. is the initial steward of the specification. As the federation grows, governance will be extended to include a participant council with defined representation for generation nodes, load nodes, and developer participants.

The governance model is designed around one invariant: no participant, including the steward, may own the protocol. The protocol is the market. A participant that owns the protocol owns the market. That is the capture point Meridian exists to eliminate.

Governance Invariant

No participant may own the Meridian protocol. No participant may claim exclusive dispatch authority over the federation. The protocol is the authority. The chain is the record. Both are open.

Section 11

API Reference

The Meridian API endpoint will be published when the v0 reference implementation reaches public beta. All endpoints require a valid registration — participation is established before API access. The API is versioned. The current version is v0 (development).

Endpoints

API Endpoints — v0 ; Registration POST /api/v0/meridian/register GET /api/v0/meridian/register/:cu-id ; Dispatch POST /api/v0/meridian/dispatch GET /api/v0/meridian/dispatch/:cu-id ; Settlement POST /api/v0/meridian/settle GET /api/v0/meridian/settle/:cu-id ; Federation GET /api/v0/meridian/federation ; registered participants GET /api/v0/meridian/chain/:cu-id ; full chain for a transaction GET /api/v0/meridian/open ; open (unsettled) dispatches

Full API documentation will be published when the v0 reference implementation reaches public beta. The specification above is normative. The implementation is the reference.

Section 12

Attestation Layer Integration

Meridian runs on the Chandra Protocol — the open, append-only, hash-chained attestation infrastructure. Every Meridian primitive writes an Attestation Record on completion. Meridian provides the market semantic layer on top of it. The attestation layer provides the integrity guarantee underneath.

The Chandra Protocol reference implementation is MIT licensed and available at chandraprotocol.com. The Meridian CU types (meridian/register, meridian/dispatch, meridian/settle) are registered attestation domain types. The Meridian query interface may be used to query Meridian CUs directly.

A Meridian deployment may use the shared chandrahub.net instance at chandraenterprise.com or operate its own sovereign attestation instance. The sovereign instance model is preferred for production federation participants — it eliminates dependency on any shared operator.

Section 13

Domain Terminology

The Meridian protocol uses generic base terms for its primitives and CU types. Domain deployments may configure a terminology layer that substitutes domain-specific language for the base terms. The terminology layer is presentational — the underlying CU structure, field names, and chain semantics are identical regardless of the terminology in use.

Base Term Meridian Energy Notes
Register Capacity Attestation The founding record of what a participant claims to have.
Dispatch Dispatch Signal / Allocation The match event. Generation to load.
Settle Settlement Close The terminal record on a completed transaction.
CU Attestation Record Domain deployments may surface any label over the base CU term.
Federation Meridian Federation Unchanged in energy domain deployment.

The domain terminology feature is a planned chandrahub.net architecture feature. Configuration format and deployment instructions will be published when the feature is available on chandrahub.net.

Ready to join the federation?

Register your capacity. Establish your founding Attestation Record. The chain starts now.

Register →