Validator Node
Participates in consensus, governance voting, reward distribution, and final settlement with signer access kept behind a private boundary.
Consensus
100,000 AETHEL
HSM signer
Node Operations
Operate Aethelred infrastructure with a production-grade boundary.
Aethelred node operations are structured for institutional Proof of Useful Work participation: public sentry ingress, private validator signing, attested compute, and deterministic settlement. Use this guide with the network architecture, the governance framework, and the developer portal when preparing validator admission or scaling regional capacity.
100,000 AETHEL stake
2+ sentry nodes
FIPS-level key custody
99.5% uptime target
Participation Model
Node roles across the network
The live architecture separates settlement, useful compute, ingress, and data serving so that validators can remain hardened while public services scale independently.
Worker Node
Executes AI jobs in attested enclaves, produces proof-bound outputs, and feeds verified work into the Proof of Useful Work reward loop.
TEE execution
H100 / MI300
Attestation
Sentry Node
Maintains public peer connectivity, absorbs hostile traffic, and keeps the validator signer and failover estate off the public internet.
Public ingress
No signing keys
2+ recommended
Full / Archive Node
Serves RPC, indexing, replay, and historical data workloads so explorers, analytics, and clients never need to share the validator footprint.
RPC surface
Historical state
No signer
Reference Topology
Production deployment boundary
The recommended operating model is simple: only public edge nodes face the network, the validator signer stays private, and failover capacity remains isolated until primary health is conclusively lost.
Recommended flow
1. Public sentry ingress
Deploy at least two sentry nodes with public peer connectivity and no signer material.
2. Private validator signer
Route validator traffic only through sentries across a private network boundary with HSM-backed signing.
3. Isolated failover node
Keep a cold or warm standby in a separate availability zone with signer access disabled until failover conditions are met.
4. Dedicated full-node services
Expose public RPC, indexing, explorer, and analytics workloads through full or archive replicas instead of the validator estate.
Operating principles
Public IPs belong on sentries and public data nodes, not on validators. Signer access should stay isolated inside HSM-backed infrastructure, while attested compute stays tied to approved TEE profiles and policy controls.
Private validator only
Separate failover zone
Region-aware routing
Operator note
Light clients and application-facing services can sit on top of full or archive nodes. They should not share the validator signer, HSM path, or public peer boundary.
Infrastructure Baseline
Current hardware and control requirements
The public validator baseline combines stake, compute, storage, network, attestation, and custody requirements so useful-work execution does not compromise settlement integrity.
| Component | Baseline | Recommended | Why it matters |
|---|---|---|---|
| CPU | 32-core AMD EPYC class | 64-core AMD EPYC class | Consensus, proof verification, and scheduling stability under sustained job load. |
| Memory | 128 GB ECC | 256 GB ECC | Supports large mempools, state access, and inference blob handling without swap pressure. |
| Storage | 2 TB NVMe SSD | 4 TB NVMe RAID-1 | High-IOPS state access, logs, and recovery margin for validator or archive services. |
| Network | 10 Gbps | 25 Gbps | Improves peer convergence, low-latency block propagation, and regional failover handling. |
| Key custody | FIPS 140-2 Level 3 HSM | Dedicated network or PCIe HSM | Signing keys remain non-exportable and isolated from host compromise paths. |
| TEE profile | SGX / SEV-SNP / Nitro / Azure CVM | Attestation-monitored fleet | Required for proof-bound AI execution and trusted compute enrollment. |
Validator boundary
Validator nodes should never expose a public IP, and they should peer only with approved sentry infrastructure across a private network segment.
Compliance posture
Institutional routing expects KYC/AML and OFAC-aware operational workflows before validator admission for regulated workloads.
Availability target
Public baseline remains 99.5% monthly uptime, with reward efficiency and slashing exposure tied directly to availability.
Operational Readiness
Production-safe verification checks
These commands are suitable for provisioned operator environments and reflect the current node runtime and validator inspection flow rather than demo-only placeholders.
| Command | Purpose | Healthy signal |
|---|---|---|
aethelredd status | jq '.sync_info' |
Confirm the node is tracking block height and finality progression. | Latest height advances steadily and catching_up resolves to false. |
VAL_ADDR="$(aethelredd keys show validator -a --bech val)" && aethelredd query staking validator "$VAL_ADDR" |
Inspect validator admission state, commission data, and jailed status from the active signer environment. | The validator is bonded, not jailed, and reports the expected operator address. |
aethelredd admin hsm-status |
Verify HSM connectivity and signer availability without exposing key material. | Signer is reachable and key custody remains non-exportable inside the HSM boundary. |
docker logs -f aethelred-validator |
Tail consensus, peer, and attestation events during deployment, incident response, or failover rehearsal. | No repeated timeout loops, attestation failures, or peer churn storms under steady load. |
Do not rely on demo install snippets
Operator documentation should reflect the actual aethelredd runtime, staking query path, and HSM controls. Public pages should not publish placeholder bootstrap commands that cannot be executed against the current stack.
Next Steps
Admission, tooling, and deployment planning
Node operations sit between protocol policy and application delivery. Operators should review network standards, governance controls, and developer tooling together before any mainnet admission process begins.
Prepare the validator footprint
Start with the public network architecture and governance model to confirm stake policy, regional routing expectations, and validator controls before planning production capacity.
Build against the developer stack
Use the developer portal and public testnet materials to validate application logic, Digital Seal handling, and verification flows before node onboarding expands.
Ready to pursue validator admission?
Request an operator review with your target region, sentry layout, HSM vendor, TEE profile, and expected useful-compute capacity. This gives the foundation team enough information to align your deployment with current network and compliance requirements before launch sequencing.
Include these details in your request
Target region
Sentry topology
HSM vendor
TEE profile
GPU class
Expected capacity
Use the primary contact path for validator and infrastructure review. If you are still validating application flows, keep the developer portal and testnet materials in parallel so node onboarding and software readiness stay aligned.