This page replaces the older long-form documentation mock with a March 12, 2026 reference that stays aligned to the current SDK metadata, live developer pages, published testnet planning, and the active protocol trust model. Use it to install the official SDKs, submit a first verified job, understand the current API and endpoint surfaces, and then continue into Digital Seals, Stablecoin Infrastructure, zk proofs, TEE attestation, Enterprise Corridors, and Infinite Sandbox.
SOURCE-BACKED AGAINST CURRENT SDKS, TESTNET PAGE, WHITEPAPER, AND TOKENOMICS
What changed
This is no longer a generic docs mock with stale legacy protocol language or hosted-product assumptions.
What this page does
It gives one technical route from installation through verification and rollout without forcing readers to stitch the site together themselves.
What stays separate
Deep protocol concepts still live on dedicated pages for Digital Seals, stablecoin infrastructure, zk proof systems, TEE attestation, wallets, and comparison.
4 SDKsPython, TypeScript, Rust, Go
10 servicesDocumented local devnet
2/3 + 1Seal minting threshold
Overview
Start with the route that matches the work
Aethelred is a sovereign Layer 1 for verifiable AI inference. The useful workflow is: install an SDK, submit a job, verify the result path, rehearse on the local stack, and only then promote toward public testnet or production operations.
This page deliberately keeps the reference practical. It covers package names, import names, first-job execution, the current REST and WebSocket surfaces, the published public-testnet endpoint plan, and the protocol objects that matter most in implementation: Digital Seals, stablecoin infrastructure, zk proof systems, TEE attestation, enterprise corridor architecture, and wallet-controlled signing boundaries.
Install the official SDKs with the package names that actually exist
The current SDK metadata is at version 1.0.0 for Python, TypeScript, and Rust. Package names and import names are not identical in every language, so this page keeps them explicit.
Python SDK
Aethelred Python client
Packageaethelred-sdk
Importfrom aethelred import AethelredClient
Version1.0.0
LicenseApache-2.0
pip install aethelred-sdk
TypeScript SDK
TypeScript and JavaScript client
Package@aethelred/sdk
Importimport { AethelredClient } from '@aethelred/sdk'
Version1.0.0
LicenseApache-2.0
npm install @aethelred/sdk
Rust SDK
Rust crate for async clients
Crateaethelred-sdk
Importuse aethelred_sdk::AethelredClient;
Version1.0.0
LicenseApache-2.0
cargo add aethelred-sdk
Go SDK
Go module for source-first integration
Modulegithub.com/aethelred/sdk-go
Go version1.21+
Import pathgithub.com/aethelred/sdk-go
LicenseApache-2.0
go get github.com/aethelred/sdk-go
Implementation note:
The Python packaging name is aethelred-sdk, but the runtime import remains aethelred. This is the kind of mismatch the older documentation page hid; this page keeps it explicit.
First Verified Job
Submit once, wait for completion, and verify the result path
The current flow is consistent across languages: submit a PoUW job, wait for the network result, then inspect or verify the resulting seal. The two examples below are grounded in the current developer page and SDK method surface.
curl
# Submit a compute job against the current REST example
curl -X POST https://api.testnet.aethelred.org/aethelred/pouw/v1/jobs \
-H "Content-Type: application/json" \
-H "X-API-Key: ${AETHELRED_API_KEY}" \
-d '{
"model_hash": "09f7e2b3c5d6a1f9f7e2b3c5d6a1f9f7e2b3c5d6a1f9f7e2b3c5d6a1f9f7e2b3",
"input_hash": "f4d3a381d89f9f7a35bfa48d9b5f9d7c6c18d2a8b431c1d6a2d2d413c3e7ed09",
"proof_type": "PROOF_TYPE_HYBRID",
"priority": 5,
"max_gas": "1000000",
"timeout_blocks": 120,
"metadata": {"source": "documentation-first-job"}
}'
python
# Package install: pip install aethelred-sdk
import hashlib
from aethelred import AethelredClient, ProofType
client = AethelredClient("https://rpc.testnet.aethelred.org")
payload = b'{"prompt":"Hello AI"}'
model_hash = "09f7e2b3c5d6a1f9f7e2b3c5d6a1f9f7e2b3c5d6a1f9f7e2b3c5d6a1f9f7e2b3"
submit = client.jobs.submit(
model_hash=bytes.fromhex(model_hash),
input_hash=hashlib.sha256(payload).digest(),
proof_type=ProofType.HYBRID,
priority=5,
max_gas=1_000_000,
timeout_blocks=120,
metadata={"source": "documentation-first-job"},
)
print(f"job id: {submit.job_id}")
job = client.jobs.wait_for_completion(submit.job_id, poll_interval=2.0, timeout=120.0)
print(f"job status: {job.status.value}")
seals = client.seals.list(model_hash=model_hash)
seal = next((item for item in seals if item.job_id == job.id), None)
if seal is None:
raise RuntimeError(f"no seal found for job {job.id}")
verification = client.seals.verify(seal.id)
print(f"seal valid: {verification.valid}")
STEP 01
Submit the workload
Provide a model hash, input hash, proof type, and execution budget. The job becomes the tracked unit of work.
STEP 02
Wait for completion
Poll or subscribe until the job reaches a completed state. The SDKs expose helpers so applications do not need to hand-roll this loop.
STEP 03
Verify the seal path
The output becomes operationally useful only when the seal and its verification context can be consumed by the rest of your system.
Access Model
Use the currently published access rules, not the assumptions from the old docs page
The older page treated Aethelred like a finished hosted API product. The current documentation surface is more precise: some flows are already coded in the SDKs, some REST examples use API keys, and the public testnet endpoints are still in launch-preparation status.
REST Examples
Header-based access appears in current examples
The published curl reference sends X-API-Key: ${AETHELRED_API_KEY} when posting jobs to the testnet REST surface.
SDK Access
Clients can use network presets or custom URLs
The official SDKs expose network configuration and custom endpoint overrides, which is the safer integration path while endpoint naming is still converging toward launch.
Launch Status
Public launch policy is not fully frozen
No contractual public rate-limit policy is published on this site as of March 12, 2026. Treat the testnet dashboard as the launch-facing source for public endpoint activation.
Why this matters:
This page intentionally does not repeat the draft request-per-minute tiers that still appear on the broader developer page, because they are not presented elsewhere as final launch policy.
API Surfaces
Current endpoints published on the developer surface
These are the operational API paths currently documented on the live developer page. They cover job submission, job status, seal retrieval, model registration, validator discovery, and WebSocket subscriptions.
Method
Endpoint
Purpose
POST
/aethelred/pouw/v1/jobs
Submit a new Proof-of-Useful-Work job.
GET
/aethelred/pouw/v1/jobs/{job_id}
Query the state of a submitted job.
GET
/aethelred/seal/v1/seals/{seal_id}
Retrieve the Digital Seal associated with a verified result.
POST
/aethelred/pouw/v1/models
Register or publish model metadata for later job execution.
GET
/aethelred/pouw/v1/validators
List validators and inspect the current validator surface.
WS
/websocket
Subscribe to state changes without polling every status transition manually.
REST
Use REST for deterministic flows
Job submission, seal retrieval, validator discovery, and model registration fit cleanly into REST-driven service backends.
WS
Use WebSocket for event-driven status changes
Applications that need live job status or asynchronous job orchestration should keep WebSocket subscriptions in the architecture.
Network Surfaces
Separate current SDK defaults from public testnet launch hosts
The current source tree exposes one set of network defaults in the SDK packages and a more launch-oriented set of public hosts on the Testnet page. This page keeps both visible so implementation teams can plan correctly.
Current SDK Defaults
Package-level testnet configuration
REST
https://api.testnet.aethelred.org
RPC
https://rpc.testnet.aethelred.org
WebSocket
wss://ws.testnet.aethelred.org
gRPC
grpc.testnet.aethelred.org:9090
Public Testnet Plan
Launch-facing hosts from the Testnet page
HTTP RPC
https://testnet-rpc.aethelred.io
WebSocket
wss://testnet-ws.aethelred.io
GraphQL
https://testnet-gql.aethelred.io
gRPC
testnet-grpc.aethelred.io:443
Explorer
https://testnet.explorer.aethelred.io
Planning note:
The package defaults and public launch hosts are not fully normalized yet. For launch-facing connectivity, prefer the Testnet page at activation time and keep your SDK configuration overrideable rather than hard-coded.
Verification
Anchor implementation work to the current trust model
Aethelred is not just an inference API. The protocol value comes from Proof-of-Useful-Work consensus, Digital Seals as the portable result object, and the ability to mix TEE and zk proof systems depending on workload requirements.
Consensus
Proof-of-Useful-Work
Validator work is tied to useful AI execution rather than synthetic hashing. That is the base assumption for job submission, scheduling, and validator economics throughout the site.
PoUWUseful Inference
Portable Result
Digital Seals
A Digital Seal is minted when at least 2/3 + 1 of validator power agrees on the result. It becomes the object other applications, contracts, or chains can verify later.
Digital Sealaethelred.seal
Execution Evidence
TEE and zk proof systems
The current documentation surface supports TEE, zkML, and hybrid verification. The published zk proof set includes EZKL, RISC Zero, Plonky2, Halo2, and Groth16, while the TEE page documents Intel SGX, AWS Nitro, AMD SEV-SNP, and NVIDIA H100 Confidential Computing.
Move from local rehearsal to public exposure in controlled stages
The current site already describes a sensible promotion path. Teams should not jump directly from code snippets to public launch assumptions.
STAGE 01
Local devnet
Start against the documented 10-service local stack with a 3-validator topology so job execution, seal inspection, and observability are repeatable.
Devnet3 Validators
STAGE 02
Infinite Sandbox
Use the sandbox to rehearse compliance checks, sanctions-aware flows, Digital Seal validation, and workflow promotion without changing the operating model.
ComplianceSeal Replay
STAGE 03
Public testnet
Move into the public launch surface when faucet, explorer, GraphQL, gRPC, bridge, and RPC activate together. Keep config values overrideable until activation.
tAETHELExplorer
STAGE 04
Production boundary
Keep wallet signing, HSM boundaries, node operations, and verification consumption separate. Use the wallet, nodes, and foundation research pages for the operational layer.
WalletsNode Ops
Related Docs
Open the page that matches the next decision
Documentation is only useful when it gets the reader to the exact next reference page without ambiguity.
