Consensus
A proposed Proof of Useful Work design assigns AI jobs to validators and aggregates execution evidence through the network’s consensus path.
Make machine outputs provable, governable, and portable.
Aethelred is designing a sovereign Layer-1 network for regulated AI and verifiable compute. Its purpose is to bind an output to evidence of what ran, where it ran, which policy applied, and how the result was verified.
The proposed unit of trust is a Digital Seal: a portable record created only after confidential execution, dual-evidence verification, and deterministic settlement. The architecture is public, but the project itself describes it as design-stage and governance-dependent.
Commit through Digital Seal
Consensus, execution, verification, settlement
TEE attestation plus zero-knowledge proof
No settlement when either signal fails
A model can return a plausible answer while leaving no durable record of its inputs, execution environment, policy context, or verification path.
That gap is manageable in low-consequence experimentation and unacceptable in finance, healthcare, sovereign systems, industrial control, and autonomous operation. Compliance teams need to reconstruct not only what happened, but why a specific result was permitted to settle.
Aethelred treats provenance and policy as part of execution. The aim is to make machine-generated outputs independently inspectable without exposing all underlying data or trusting a single intermediary.

A proposed Proof of Useful Work design assigns AI jobs to validators and aggregates execution evidence through the network’s consensus path.
Inference is intended to run inside attested enclaves across supported confidential-computing environments, keeping sensitive workloads isolated while producing hardware evidence.
TEE attestation is combined with zero-knowledge-backed verification. The public design names Groth16, PLONK, EZKL, Halo2, and STARK pathways rather than assuming one proof system fits every workload.
CometBFT finality is intended to bind proof references, Digital Seals, policy metadata, transfers, block height, and validator set into a final record.
Submit the workload definition, policy requirements, input commitments, and verification conditions before execution.
Assign an eligible validator and supported confidential environment under the network’s scheduling rules.
Run the workload inside an enclave and return evidence about code identity, environment, and execution state.
Produce the second verification signal using a zero-knowledge or zkML-compatible proof path appropriate to the workload.
Accept the result only when both evidence paths and policy checks pass; otherwise fail closed.
Issue a portable record binding the machine output to verification signals, policy metadata, and deterministic settlement.

Transaction attestation, machine-generated risk decisions, regulatory reporting, and cross-border settlement evidence.
Clinical inference trails, experiment provenance, data-handling policy, and reproducibility without exposing every sensitive input.
Execution evidence, classified workflows, machine credentials, and locally governed validator infrastructure.
Decision proofs, component passports, vehicle-to-everything trust, and accountable agent-to-agent exchange.
Product passports, transfer integrity, customs records, and evidence for rules attached to physical goods.
Authentication, decision-chain proofs, machine permissions, usage rights, and settlement between autonomous services.
The official roadmap labels an internal network release completed.
The public page describes validator onboarding, developer tooling, and SDK work in progress.
Audit, remediation, and hardening are described as a forthcoming phase, not a completed assurance.
Economic, legal, operational, and governance readiness remain prerequisites.
A future objective contingent on prior evidence, review, and governance decisions.