WHY
Purpose
Portable trust
A seal gives downstream systems one verifiable object instead of a set of informal logs, screenshots, or application-side signatures.
Portable Trust Object
Digital Seals
A Digital Seal is the on-chain attestation record minted when a supermajority of Aethelred validators agrees on an AI computation result. It is the object that turns verified execution into something another application, institution, contract, or chain can inspect without inheriting opaque trust. The current model is defined in the whitepaper, exposed through the SDK and API surfaces, and relayable over IBC on port aethelred.seal.
CURRENT DIGITAL SEAL SPEC FROM THE LIVE DOC SET
Seals are minted by consensus, not by application convention
The seal exists because consensus accepted the computation evidence, not because an application saved a convenient receipt.
Verification is transportable
SDKs, APIs, contracts, and other chains can consume a Digital Seal without replaying the full workload.
Seals unify TEE, zkML, and hybrid evidence
Different verification types can converge into one portable output object once the network agrees on the result.
50Maximum seal creations injected per block
5 MBProof budget cap per block
IBCRelay on aethelred.seal
Definition
A Digital Seal is the portable result of verified AI consensus
The seal is the network-native evidence object that sits between verified execution and downstream consumption.
WHEN
Minting Context
Consensus agreement
The network mints a seal only after the validators agree on the computation result and the seal-creation transaction passes the current rules.
WHERE
Consumption
Apps, contracts, and chains
Seals can be consumed by SDKs, exposed through APIs, checked by contracts, and relayed over IBC to other compatible chains.
Anatomy
What the current seal model binds together
The whitepaper structure is precise: seals tie identity, commitments, evidence, and chain context into a single object.
Identity and commitments
- Job IDUnique workload identity for the computation.
- Model hashThe committed model fingerprint used for execution.
- Input hashThe committed input hash that anchors the request.
- Output commitmentThe committed output hash or result commitment accepted by validators.
Verification and chain evidence
- Verification typeTEE, zkML, or hybrid path used for the computation.
- Consensus evidenceValidator attestations, agreement power, and total power context.
- Block height and chain IDChain-local binding that prevents cross-chain or cross-height replay.
- TimestampThe seal becomes an inspectable point-in-time trust record.
Seals do not replace raw evidence. They package it into a verifiable access point.
The API and SDK surface still let developers inspect associated attestations and commitments when a workflow needs deeper review.
Lifecycle
How a computation becomes a seal in the current protocol
The seal lifecycle is a consensus flow, not a post-processing attachment.
Execute the job under the selected verification mode
The workload runs under TEE, zkML, or hybrid verification based on the sensitivity and assurance requirements.
Attach computation evidence to vote extensions
Validators package job identity, commitments, and attestation evidence into the `ComputeVerification` data that consensus evaluates.
Inject seal creation during proposal preparation
If conditions pass, `PrepareProposal` injects seal creation transactions at the front of the block, subject to the documented per-block caps.
Finalize and store the seal in the chain state
Once the block commits, the seal is part of the on-chain state and can be queried, verified, or relayed.
Verification
How the current stack verifies a seal
There is more than one consumption path, but the trust object stays the same.
| Surface | Current Interface | What it gives you |
|---|---|---|
| SDKs | client.seals.verify(...) | Programmatic seal validity checks inside application code. |
| REST / gRPC | /aethelred/seal/v1 | Direct network query surface for seal retrieval and inspection. |
| Oracle / contracts | verifySeal and verifySealWithOutput | Contract-level validity and output-commitment matching. |
| Attestation retrieval | getAttestations | Deeper review of the TEE evidence bound to the sealed result. |
| Tooling | Seal verifier and CLI | Local inspection before promoting a workflow into broader operations. |
Minting conditions that must pass
- Supermajority agreementAt least `2/3 + 1` of validator power agrees on the result.
- No verifier failuresAny hard verification failure blocks seal promotion.
- Valid seal transactionThe injected creation transaction must pass validation.
- No duplicate sealThe same job ID cannot mint multiple seals.
Relay and portability
Digital Seals are designed to move. The current whitepaper specifies IBC relay over port aethelred.seal, which lets other compatible chains consume verified AI results without recreating the full execution environment.
Applications
Where seals matter most in the current site architecture
Seals are the evidence layer behind several workload categories already documented on the site.
Research reproducibility
Seals provide a transportable provenance object for experiment outputs, enabling cross-institution review without informal trust transfer.
Open research use case →Healthcare audit trails
Clinical-support and life-sciences workflows can bind model, input, and output commitments into a reviewable artifact for downstream systems.
Open healthcare use case →Supply-chain provenance
Origin, transfer, compliance, and anomaly outputs become shareable trust objects instead of opaque records inside one participant's system.
Open supply-chain use case →Agent-to-agent handoffs
One agent can pass a sealed result to another agent, giving the downstream system something verifiable to inspect before acting.
Open agent-to-agent use case →Implementation References
Move from seal concepts into contract-facing integration
If this page is where the trust model clicks, the next practical step is the contract and tooling surface that consumes seals in real workflows.
SOL
Contract Reference
Smart Contracts
The Smart Contracts page shows the current Solidity-facing seal surface, including verifySeal, verifySealWithOutput, oracle reads, callbacks, and conservative copyable patterns built from the live contracts package.
Open Smart Contracts →
OPS
Tooling Surface
Seal Verifier and developer docs
Use the Seal Verifier, API surface, and documentation hub when the next step is operational inspection rather than contract consumption. That path is better for teams validating evidence flows before writing on-chain policy.
Open Seal Verifier →Move from Digital Seal concepts into implementation
Use the seal model as the bridge between protocol trust and application logic.
Move from this page into the API surface, the seal verifier, and the workload-specific use-case pages when you need to turn the concept into a real integration pattern.