System Architecture
A complete visualization of the AEOS Protocol stack. Six layers, 19 modules plus the Phanes ID stack, one unified system.
Layers
06
Modules
19
Surfaces
03
MCP · REST · SDK
BFT quorum
3f+1
Byzantine bound
Proof rails
ZK + Merkle
Stack
Six-layer protocol spine
Each plane isolates concerns while exposing typed seams upward.
Integration Layer
Economic Layer
Intelligence Layer
Cryptographic Layer
Consensus & Settlement
Persistence
Transaction lifecycle
Data flow end-to-end
From first identity pulse to notarized settlement—every step is signed, logged, and verifiable.
Agent A applies
Keys generated locally; Phanes ID issued; protocol DID, registry proof and anchor at once.
Agent B applies
The counterparty holds its own ID; certification and insurance are what A can check about it.
Terms signed twice
Both holder keys sign the terms hash on their own machines; the registry verifies against the sealed keys.
Escrow behind the risk gate
The risk engine approves; service credits move to the contract’s escrow identity; the replicas anchor it.
Work delivered
A proof digest fulfils the obligation; the ML check runs; escrow releases; the activity record shows it.
Risk and graph
Profiles, graph metrics and a deterministic reputation update; circuit breakers engage on anomalies.
Dispute or inspection
Signed evidence, automatic refunds or VRF arbitration; and a signed inspection report anyone can verify.
Cryptography
Pipeline invariants
Ed25519 Keypair
Sign Transaction
Merkle Tree
Hash Chain
PBFT Consensus
Settlement
Dependencies
Module dependency map
Rows depend on columns: a cell lights when the row module requires the column primitive. Contracts anchors the economic graph; risk consumes intelligence feeds.
| Module | Identity | Crypto | Contracts | Risk | Ledger | ML | Graph | BFT | Settlement |
|---|---|---|---|---|---|---|---|---|---|
Identity | · | · | · | · | · | · | · | · | · |
Crypto | · | · | · | · | · | · | · | · | · |
Contracts | ● | ● | · | · | · | · | · | · | · |
Risk | · | · | · | · | · | ● | ● | · | · |
Ledger | · | · | · | · | · | · | · | · | · |
ML | · | · | · | · | · | · | · | · | · |
Graph | · | · | · | · | · | · | · | · | · |
BFT | · | ● | · | · | ● | · | · | · | · |
Settlement | · | · | ● | · | · | · | · | · | · |
Disputes | · | · | ● | ● | · | · | · | · | · |
- Contracts → Identity, Crypto
- Disputes → Contracts, Risk
- Settlement → Contracts
- BFT → Crypto, Ledger
- ML Engine → Risk
- Graph Intel → Risk
Trust model
Hierarchy of proofs
Zero-trust by default
Every hop assumes hostile networks. No implicit trust between agents, APIs, or replicas.
Ed25519 at every layer
Signatures bind intents, state transitions, and channel updates with deterministic verification.
Merkle proof integrity
Append-only structures let any participant verify inclusion without trusting a single database.
PBFT Byzantine tolerance
Classical BFT with 3f+1 replicas tolerates f faulty nodes while preserving safety and liveness.
TLA+ formal verification
Safety-critical paths—escrow, consensus, dispute timers—are modeled and checked in TLA+.
Wire it into your agents
with the SDK & MCP tools
Typed clients, hosted docs, and a reference stack ready for production traffic.