What really needs a shared record, and who remains responsible?

Research status: Open question · Novelty unestablished · No field trial completed

The question

In a concrete arrangement between a resource operator, a participant, and a customer, what must be recorded or verified—and can ordinary controllers, databases, signed records, and contracts do the job?

Why it matters

Permission, physical delivery, payment, and responsibility are different things. Adding a ledger can make some records easier to inspect without making a measurement true or a machine obey.

What is currently known

There are established mechanisms for delegated authority, auditable statements, and financial settlement. Cryptographic verification can check a statement against a specified model; it cannot establish that the model completely describes the physical world. No need for a new token or blockchain has been demonstrated in this research.

What remains unknown

Whether a particular use case needs a trust property that a simpler arrangement cannot provide at acceptable cost—and what responsibility remains with operators when evidence conflicts or delivery fails.

Contributions that would help

A worked example of the parties, their disagreement, and the evidence needed to resolve it.
A conventional solution that meets the same requirements.
A precise explanation of what independent verification would add.
An objection from someone affected by the allocation, including people who are not market participants.

A useful first contribution: “Who would I have to trust here, and what could I do if they were wrong?”

What would change our minds

If ordinary infrastructure supplies the required property, use it. A reproducible counterexample to those alternatives could justify evaluating additional cryptographic machinery. That still would not establish a need for a new chain or token.

Start with these sources

Macaroons — delegated authority with restrictions. Reading status: author source read. Not independently reproduced. A copyable credential is not by itself a conserved spending record.
IETF SCITT architecture — a draft transparency architecture. Reading status: current draft inspected. Not a finalized standard. Not independently reproduced. Transparency receipts describe a recorded statement; they do not make an issuer honest or a measurement true.
PJM’s FTR fact sheet — an example of a financial instrument distinct from physical delivery. Reading status: official description of the financial role inspected. Not independently reproduced. An FTR is not a physical right to inject or withdraw electricity.

Prompt above the response box

What needs to be trusted or checked, and what is the simplest arrangement that works?

INTAKE · NOT OPEN

Contributions are not open yet

no response box · nothing is saved · no receipt · no review queue

OFF

Question record

SOE-Q003 · version 1.0

Question: In a concrete arrangement between a resource operator, a participant, and a customer, what must be recorded or verified—and can ordinary controllers, databases, signed records, and contracts do the job?
Version / date: 1.0 · 27 September 2026. First public version of this record.
Scope: Included: what must be recorded or verified among an operator, a participant, and a customer, and whether ordinary controllers, databases, signed records, and contracts suffice. Excluded: treating a ledger, price, meter, or token as a substitute for physical control, measurement, or legal responsibility.
Owner: Editorial owner when a record changes: Chris Taylor, or a reviewer he designates. That names a person, not a panel. Intake is not open, so no contribution is in review.
Disposition: Open as a question about a concrete arrangement. A new token, DAO, blockchain, or settlement layer as a necessary enabler is unsupported. Novelty unestablished. No field trial completed.
Claims: Fact about the research to date: no need for a new token or blockchain has been demonstrated. Fact about cryptography within a specified model: verification can check a statement against that model and cannot establish that the model completely describes the physical world. Unknown whether a particular use case needs a trust property simpler infrastructure cannot provide at acceptable cost. Unsupported Meridian as a new sovereign architecture, on the evidence checked.
Assumptions: Permission, physical delivery, payment, and responsibility stay separate layers. Mutual distrust is not by itself a proof that a blockchain is necessary or adequate. First architecture to test, when there is one accountable operator and durable reservations: an ordinary transactional database and local controllers.
Baseline: Ordinary controllers, databases, signed records, and contracts. Macaroons for delegated authority with restrictions. A draft transparency architecture such as SCITT when the need is a checkable statement, not physical truth. Financial instruments such as FTRs stay distinct from physical delivery.
Contributions: None. Contributions are not open yet.
Objections: Unresolved: ordinary infrastructure may already supply the required property, in which case it should be used. A counterexample to those alternatives would still not establish a new chain or token. No contributor objection is on file.
Tests: Proposed, not started. No cryptographic machinery is being built from this page.
Results: No field trial. No demonstrated unmet trust property.
Revision: Version 1.0 published 27 September 2026. This record does not inherit a claim that a new settlement layer is required.

Also read Q1 · Q2 · Evidence · Research · Discuss. Intake is not open.

Honest frame. SOE-Q003 is open. No new token or blockchain has been demonstrated. Contributions are not open yet.