Deterministic evaluation
The runtime produces the same decision for the same input every time. No side effects during evaluation.
Architecture
Modular runtime for
policy-bound execution.
Sovereign is built as a set of composable packages, each responsible for a specific layer of the constitutional execution model.
System diagram
Layers from intent to persistence.
Each layer is independently testable and depends on the layers below it.
Base payment lane
Base-first execution path.
Every x402 payment flows through the constitutional runtime before any funds move. The agent never controls the wallet.
Akasha / Agent
↓ EconomicIntent (typed, no signing surface)
Sovereign Constitutional Runtime
↓ Wallet profile · Budget · Merchant · Risk
Procurement Wallet + Constitution
↓ DecisionPacket issued
x402 Execution Adapter
↓ Pays merchant via x402
Base Sepolia / Base
↓ USDC Settlement
DataArtifact created
↓
Provenance + Audit + Accounting
Local x402 simulation
Default mode. Full constitutional evaluation runs. No testnet payment is made. Identical constitution to Base Sepolia path.
Base Sepolia x402
Real x402 payment using test USDC on eip155:84532. Same constitutional path. Real settlement receipt attached to artifact.
Base mainnet — not enabled
Defined but intentionally disabled in the current MVP.
Packages
One package per domain boundary.
Each package owns its types, logic, and tests. No package reaches across into another layer's internals.
packages/domain
Core entities and strongly typed primitives. The shared vocabulary for the entire system.
packages/constitution
Default wallet constitutions, compiler, analyzer, and runtime bundles.
packages/runtime
Deterministic evaluation and intent execution flow. The core policy engine.
packages/budget-engine
Reservations, commits, releases, and reversals. Budget state machine.
packages/merchant-trust
Merchant registry, route fingerprints, quarantine logic, and payee verification.
packages/decision-packets
Scoped authorization packets with signature, expiry, and nonce checks.
packages/ledger
Audit events, economic action records, journals, artifacts, and provenance links.
packages/trading
Risk engine, paper broker, trade plans, and paper execution records.
packages/sdk
Proposal-only developer client. No raw signing surface. The agent interface.
packages/persistence
Snapshot and Postgres repository layer. Swappable storage backends.
Domain model
Key entities.
These are the primary types that flow through the system from intent to settlement.
| Entity | Package | Description |
|---|---|---|
| WalletInstance | domain | A wallet with type, profile, and linked constitution |
| ConstitutionVersion | constitution | Versioned policy document for a wallet |
| CompiledBundle | constitution | Executable policy derived from a ConstitutionVersion |
| EconomicIntent | domain | Typed agent request for an economic action |
| BudgetReservation | budget-engine | Hold on budget funds pending execution |
| MerchantRoute | merchant-trust | Route fingerprint and payee binding for a merchant |
| DecisionPacket | decision-packets | Scoped, signed, expiring authorization from the runtime |
| EconomicActionRecord | ledger | Settlement record for a completed economic action |
| DataArtifact | ledger | Paid data artifact with provenance metadata |
| TradePlan | trading | Agent-generated trade plan from paid data |
| RiskCheck | trading | Deterministic risk evaluation result for a trade plan |
| PaperOrder | trading | Paper execution record with status and settlement |
| PositionSnapshot | trading | Point-in-time portfolio state from paper trading |
Design principles
How the system is built.
Typed boundaries
Every layer communicates through strongly typed domain types. No untyped maps or generic objects crossing package lines.
Adapter isolation
Execution adapters are swappable. The runtime never knows which adapter will execute — it only issues packets.
No agent signing
The SDK has no signing surface. Agents submit intents. The runtime decides. Adapters act.
Snapshot and Postgres
Local demos run against a snapshot file. Production-grade validation uses Postgres with schema migrations.
Append-only audit
Audit events are append-only. No event is ever updated or deleted. The hash chain makes tampering detectable.
Explore the implementation.
The SDK docs and demo runbook show the system in action.