Verifiable Witness

Blockchain

AI compute clusters and battery storage are becoming autonomous economic actors.

Wattness is building the verification layer that lets an agentic decision at the edge be checked by someone who was not present when it was made — provable execution, incentive-compatible access and machine-to-machine settlement, without putting a chain anywhere near grid latency.

A physics core decides, an agent runtime distributes the decision, and this layer is what a counterparty checks.

Execution integrityEnclave attestation · selective zero-knowledge for scalar claims
Throughput architectureThe chain sees commitments, not decisions
Grid impactNo added latency on the critical path

Distribution

Where the decision is actually made

Distribution is the second layer of the stack. It carries the physics core into runtimes that belong to other people, which is what puts a decision beyond inspection.

One physics core. Every AI agent.

Interface

Transport: Model Context Protocol
Tools: generate_sced_offer_curve · evaluate_thermal_margin · compute_degradation_cost · submit_attestation
Status: Interface specified. Server not yet public.

AccessRequest Shadow Access

Speaks the same interface as

Claude Code
OpenClaw
Hermes Agent
OpenCode
Cursor
Windsurf
Any standard MCP client
…

The physics core does not run in a place we control. It runs as a tool inside whatever agent runtime an operator already uses — called by their workflow, on their schedule, against their asset. That is the point, and it is also the problem this page exists to solve.

A general-purpose agent runtime can plan, route and orchestrate. It cannot solve power flow, and it cannot solve electrochemistry. An unconstrained agent asked to reduce an energy bill will cycle a battery through its warranty to capture a price spike it does not understand the cost of capturing.

So the runtime does not decide. It calls something that can: a deterministic model that reads state of charge, thermal margin and accumulated wear from the machine, and returns an offer curve bounded by what the asset can physically sustain. Same machine in the same state, same answer, every time. The distribution layer is never the product. The physics-grounded core is.

Which creates the condition that makes verification necessary rather than decorative. The decision was made by software running in someone else's process, invoked by someone else's operator, against an asset neither we nor the market can inspect. Nobody in the chain can check it by looking at it.

An agent has no legal personality. It cannot be sued, cannot hold a licence, and cannot be called before a regulator. What it can hold is a key. So the tool call carries an identity, the inputs it read are committed, and the answer it returned is attested — and a counterparty who was not present when the decision was made can reconstruct it afterwards.

That is the whole argument for putting anything on a chain at all.

The shape of a tool call

Wattness Physics CoreTransport: Model Context Protocol

Tool: generate_sced_offer_curve
Called by: — · agent runtime, operator-selected
Asset reference: —
Inputs committed: state of charge · thermal margin · state of health · deferrable fraction where applicable
Returns: bounded offer curve · flexibility schedule · capability descriptor
Attestation: enclave measurement · signed inputs · signed result

Values withheld. The desk publishes its method continuously.The fields are the interface. The values are withheld: no asset is connected, no runtime is integrated and nothing here has been called in production. What is on display is the shape of the call.

We are agnostic across the current field of agent runtimes and expect that field to keep changing. The core speaks a tool interface, not a vendor.

Tool surfaceModel Context Protocol

evaluate_thermal_margin
Headroom remaining before the asset must throttle itself, from its own thermal state rather than from a nameplate.
compute_degradation_cost
What a proposed cycle costs the asset's remaining life, priced into the decision rather than applied as a correction after it.
generate_sced_offer_curve
An offer curve bounded by what the machine can physically sustain, in the shape the market already accepts.
submit_attestation
The signed record of what was read and what was returned, travelling alongside the offer rather than between it and the market.

Agent skills & runtimes

Claude Code
The four tools, served to Claude Code over MCP. An engineer gets a bounded offer curve and a degradation cost inside the terminal workflow they already run.
OpenClaw
The same four tools, packaged as an OpenClaw skill. An operator's self-hosted agent calls the physics core without the core leaving their runtime.
Hermes Agent
The same four tools, exposed to Hermes as a standard tool provider. The runtime may learn between calls; the core does not. Same state, same answer.
OpenCode / Cursor
The same four tools inside an editor, so a team writing dispatch or bidding software can call the physics core at design time rather than assume what an asset can sustain.

Dual-path architecture

Architectural isolation: physical dispatch vs. cryptographic settlement

Wholesale power markets cannot tolerate public blockchain latency or block reorganisation risk in the critical dispatch path. So the design separates the physical control loop from the verification layer: one path carries dispatch instructions to ISOs over conventional QSE interfaces, the other anchors execution proofs and delivery scores asynchronously. Both are specified below.

Path A · Physical dispatch

Recipient: ISO / RTO control rooms
Protocol: Conventional QSE interfaces · 5-minute SCED
Payload: Nodal offer curves & telemetry
Purpose: Real-time dispatch

Path B · Cryptographic witness

Recipient: Solana · Base · EVM
Protocol: Enclave attestation · signed Merkle root
Payload: Attestation hash & delivery score
Purpose: Attributable reputation and settlement

Core protocol primitives

Three primitives, and what each one is for

01
Agent identity & attestation
Mechanism
Each edge agent holds a keypair inside a trusted execution environment that signs its state evaluations. The enclave attests which binary ran against which committed inputs. Zero-knowledge proofs are used selectively, for scalar claims where they are cheaper than disclosure.
Why it matters
Attests that an agent's bid adhered to physical thermal and degradation boundaries without revealing proprietary data centre workload schedules.
Status
In development
02
Delivery scoring
Mechanism
A strictly proper scoring rule that tracks declared capacity against delivered performance over rolling windows. Computed continuously off-chain; the score set is committed periodically as an anchored root.
Why it matters
Addresses the incentive-compatibility flaw of open connect-and-manage grids. Overstating capacity lowers the score, so the penalty is in the rule rather than in a rate case.
Status
Proposed · for submission to an open standards process
03
Autonomous machine-to-machine settlement
Mechanism
Programmable settlement for peer-to-peer flexibility, and for granular energy attribute certificates where a registry recognises them. The certificate remains the registry's instrument; nothing here replaces it.
Why it matters
Lets an autonomous data centre agent buy short-duration capacity from a nearby storage agent to hold its own thermal margin, programmatically.
Status
Proposed

Execution surface

Three jobs, and where each one runs

None of them sits in the dispatch path, and none of them is load-bearing for a decision.

01
Anchoring
Solana
Role
Attestation roots, written at the cadence decisions are made. High frequency, small payloads, latency-tolerant — a hash does not care when it lands.
Why here
Anchoring at this frequency is cheapest on Solana, and state compression makes writing many small commitments practical rather than theoretical.
Language
Rust · Anchor. Held apart from the rest of the system by design.
02
Identity and settlement
Base · EVM
Role
Agent identity and portable reputation, and the payment surface for agent-to-agent settlement where a counterparty wants one.
Why here
An autonomous agent has no legal personality. The standards that give it an identity and a checkable history are specified in this ecosystem, not invented by us.
Language
Solidity. One artefact, portable unchanged to any EVM network.
03
Artefact storage
BNB Greenfield
Role
Optional. Where a full solve trace needs to persist rather than be summarised, the object is stored and the pointer is committed.
Why here
Storage addressed by on-chain pointer, in one place, rather than a second system bolted to a chain that does not store.
Status
Proposed

The contracts are Solidity, and one artefact covers any EVM network — Ethereum and its layer twos, BNB Smart Chain and others. Base is the first deployment target, because the agent identity and payment standards this architecture depends on are specified there.

The Solana programs are specified separately, in Rust. There is one reason for them: anchoring at this frequency is cheapest there. Nothing in the design assumes a particular chain, because nothing in the design puts a chain in the dispatch path.

Verifiable witness explorer

What a receipt looks like

A receipt is what a counterparty actually reads. It names which binary ran, against which committed inputs, and what came back.

Wattness Witness ExplorerNetwork: Solana

Physical parameter evaluation

State of charge: —
Thermal margin: — · degradation penalty evaluated
Declared capacity: — · flexibility band

Attestation receipt

Proof type: — · enclave attestation; selective ZK for scalar claims
Verification: —
Rolling delivery score: — · strictly proper multiplier applied

Values withheld. The desk publishes its method continuously.The fields a receipt carries, with the values withheld. Nothing here is a reading: no asset has been dispatched, no proof has been anchored and the desk has submitted nothing to any market. What is on display is the shape of the record.

Institutional auditability

What this asks a control room to accept: nothing new

The proof travels alongside the offer. It sits beside the dispatch path rather than inside it, and nothing in the dispatch path depends on it.

Ordinary artefacts out
Offer curves, telemetry and settlement files in the formats a control room already accepts. No tariff rewritten, nothing anyone has to be taught to read.
Reconstructible after the fact
A decision can be rebuilt by someone who was not present when it was made — the same machine in the same state returns the same decision, and the record says why.
A proposal, not a rule in force
The delivery-weighted allocation rule is a design contribution prepared for an open standards process, offered for others to attack. It is not deployed market machinery, and saying otherwise would be the error this page exists to argue against.

Deployment and relationships