Platform

Overview

How It Works

Beneficiary Identity

Policy Corridors

Deterministic Finality

Architecture

Security Model

Governance

Integration

Solutions

Corridors Overview

Institutional Overview

Pricing

All Scenarios

Humanitarian Impact Fund

Assurance

Technical Assurance

Verify Receipt

Receipt Example

Developers

Documentation

APIs & Bridges

Architecture Docs

Glossary

BID API

Company

About

Team

Partners

Roadmap

Investors

Contact

Blog

All Documentation

Schedule Consultation
← Back to Documentation
AATM Operational Spec All Documentation →

Autonomous AI Token Managers Operational Specification

Binding operational decisions for regulatory classification, liability allocation, AUM limits, herding prevention, agent isolation, and recertification policy.

Operational SpecificationJIL SovereignMarch 2026

1. Executive Summary

This document resolves six open operational questions that must be answered before AATM can proceed to mainnet deployment. Each decision was debated across legal, engineering, and compliance teams and is now binding for the AATM subsystem.

The six questions addressed are: (1) How is AATM classified under securities regulation? (2) Who bears liability when something goes wrong? (3) How much AUM can a single agent manage? (4) How do we prevent herding behavior across agents? (5) Can agents communicate with each other? (6) How often must agents be recertified?

Binding Status: All decisions in this document are final and enforceable at the smart contract level. Parameter changes require validator governance approval (7-of-20 vote). This spec supersedes any prior informal guidance on these topics.

These decisions are designed to be conservative by default. As the system matures and real-world data accumulates, parameters can be relaxed through the standard governance process - but they cannot be weakened unilaterally by any single party.

2. Regulatory Classification

Decision: Strategy execution engine - NOT an investment advisor.

The user sets ALL parameters: strategy type, risk tolerance, rebalance thresholds, and stop-loss levels. The agent executes within user-defined constraints only. It has no discretionary authority. It cannot override, expand, or reinterpret the user's instructions.

Multi-Jurisdiction Analysis

JurisdictionFrameworkClassificationRationale
EUMiFID IIExecution-only serviceNo suitability assessment required. User defines all parameters. Agent has zero discretion.
United StatesInvestment Advisers ActNo advisory registrationUser maintains full control. Agent cannot exceed user-defined parameters. No personalized recommendations.
SingaporeMAS GuidelinesTechnology service providerPlatform provides execution infrastructure. Strategy logic is user-configured, not platform-originated.
UAEDFSA/ADGMTechnology serviceNon-advisory automated execution within user-specified boundaries.
SwitzerlandFINMATechnical infrastructureNo asset management license required for execution-only tooling.
Required Disclaimer (all AATM interfaces): "AATM agents execute strategies defined by the user. JIL Sovereign does not provide investment advice. Users are solely responsible for strategy selection and parameter configuration."

Structural Safeguards

  • No default strategies - Users must explicitly configure every parameter. No "just click start" onboarding that hides advisory decisions.
  • No recommendations - The UI may display historical performance data but cannot suggest specific strategies, risk levels, or token allocations.
  • Audit trail - Every parameter change is logged on-chain with the user's signature, proving the user - not the platform - made each decision.

3. Liability Allocation Framework

A three-layer liability model ensures clear accountability at every level of the stack. No gaps, no ambiguity.

LayerPartyCoversCap
ProtocolJIL SovereignSmart contract bugs, oracle failures, infrastructure downtime$250K+ protection coverage per vault
Agent DeveloperStrategy authorStrategy drift beyond parameters, model degradation, unexpected behavior$500K E&O insurance required for certified agents
UserVault ownerParameter selection, strategy choice, market riskUser accepts market risk per terms

Dispute Resolution

The dispute-resolution service (port 8105) handles all claims. Users submit disputes with evidence (transaction hashes, parameter snapshots, expected vs actual behavior). The service categorizes the dispute into the correct liability layer and routes accordingly.

  • Under $10K - Automated resolution within 48 hours based on on-chain evidence.
  • $10K - $100K - Human review panel (3 compliance officers) within 7 business days.
  • Over $100K - Escalation to validator governance. Requires 7-of-20 validator vote to authorize payout from protocol coverage pool.

Insurance Requirements

All certified agent developers must maintain $500K errors-and-omissions (E&O) insurance covering strategy drift and model degradation. Proof of coverage is verified during agent certification and checked at every 90-day recertification. Lapsed insurance triggers immediate agent suspension.

4. Maximum AUM Caps

Graduated caps based on agent maturity prevent new, unproven agents from managing disproportionate capital. Caps increase as the agent accumulates a live track record.

Agent AgePer-Vault CapPer-Agent-Class Soft Cap
New (< 90 days)$5M$25M
Established (90-365 days)$25M$250M
Mature (365+ days)$50M$500M

Enforcement

  • Hard limits are enforced by the AutonomousAgentVault.sol maxDeposit() check. Deposits that would exceed the per-vault cap are reverted at the contract level. There is no override mechanism for hard limits.
  • Soft caps trigger alerts via performance-monitor (port 8545) when total AUM across all vaults using the same agent class approaches the threshold. Deposits are not blocked but require explicit user acknowledgment.
  • Override - Exceeding a soft cap by more than 10% requires a 7-of-20 validator vote. The governance proposal must include a risk assessment explaining why the cap should be exceeded for this specific agent class.

Age Calculation

Agent age is measured from the date of first mainnet certification - not from code creation, testnet deployment, or registration. Only live mainnet operation counts. Time spent suspended does not count toward maturity.

5. Herding Prevention

When multiple AI agents converge on the same strategy, their collective activity can destabilize markets. Four independent mechanisms prevent herding behavior.

5.1 HHI Diversity Check

The Herfindahl-Hirschman Index (HHI) is calculated across all active agents in real time. If more than 40% of agents execute the same direction on the same trading pair within a 5-minute window, new orders from agents on that pair are throttled with a 30-second delay. The throttle lifts automatically once diversity recovers.

5.2 Staggered Execution

All agent orders include a 0-30 second random jitter before submission to the DEX. This prevents simultaneous execution even when multiple agents reach the same trade decision at the same time. Jitter is cryptographically random (derived from block hash + agent ID) and cannot be predicted or gamed.

5.3 Overlap Limit

A maximum of 3 agents with greater than 80% strategy parameter overlap can be active simultaneously. "Overlap" is calculated by comparing normalized parameter vectors (risk score, allowed tokens, rebalance thresholds, drawdown limits). New agent registrations are blocked if adding the agent would exceed the overlap threshold.

5.4 Circuit Breaker

If any single trading pair loses more than 5% of pool liquidity within 1 hour due to agent activity, all agent orders on that pair are paused for 15 minutes. Human traders are unaffected. The circuit breaker resets automatically after the pause window.

Monitoring

The behavioral-drift-detector service (port 8735) tracks correlation metrics across all active agents continuously. Alerts fire at 0.7 correlation coefficient. Automatic blocking engages at 0.9 correlation. All correlation events are logged and included in the agent's recertification review.

6. Agent Communication Boundaries

Decision: No direct inter-agent communication.

Agents operate in isolated runtime sandboxes. Each agent process runs in a dedicated container with network policies that restrict all outbound connections except approved API endpoints.

Read-Only Data Access

Data SourceAccess LevelRationale
Market data (price feeds, order books)Read-onlyRequired for strategy execution
Aggregate metrics (total TVL, pool utilization, volume)Read-onlyNeeded for position sizing and liquidity assessment
Own vault state (positions, balances, history)Read-onlyRequired for portfolio management
DEX execution endpointWrite (trade submission only)Core execution capability

Prohibited Access

  • Other agents' positions - No agent can see what any other agent holds or has traded.
  • Other agents' parameters - Strategy configurations are private to each vault.
  • Other agents' trade history - Historical execution data is isolated per agent.
  • User PII - Agents have zero access to personally identifiable information.
  • Arbitrary network - No internet access, no DNS resolution, no outbound connections beyond the approved API list.
Design Rationale: Communication only happens through the market. Agents see the same public order book that every other participant sees. This prevents coordination attacks, front-running between agents, and information leakage. If two agents reach the same conclusion, it is because the market data led them there independently - not because they colluded.

7. Recertification Policy

Certification is not a one-time gate. Agents must pass both scheduled and event-triggered recertification throughout their operational lifetime.

Trigger Matrix

TriggerFrequencySLAAction on Failure
ScheduledEvery 90 days4 hours48h grace period, then suspend
Code UpdateOn every commit1 hourBlock deployment until pass
Drawdown >15%Immediate1 hourSuspend trading, notify users
3+ User ComplaintsImmediate4 hoursRestrict to close-only mode
Parameter ChangeBefore activation1 hourBlock parameter change

Certification Suite

The agent-certification service (port 8540) runs 9 independent test suites. All 9 must pass for certification to be granted.

SuiteTestsPass Criteria
Backtest10-year historical replay across 4 market regimesPositive risk-adjusted returns at declared risk level
StressFlash crash, liquidity crisis, oracle failure, exchange outageNo total loss in any scenario
AdversarialRed-team prompt injection, parameter manipulation attemptsZero constraint violations under adversarial conditions
RiskPosition sizing, drawdown behavior, leverage complianceAll trades within declared Strategy struct
ComplianceSanctions screening, market manipulation detectionCorrectly refuses all prohibited actions
PerformanceLatency, throughput, resource consumptionUnder 500ms decision latency at p99
DriftBehavioral stability over 30-day simulationStrategy drift below 5% threshold
FairnessNo bias toward specific tokens, users, or time windowsUniform treatment across all valid inputs
GasTransaction cost efficiency and batching optimizationWithin 120% of optimal gas benchmark

8. Cross-Reference Matrix

This matrix maps each operational decision to the services, contracts, and governance mechanisms that enforce it.

DecisionEnforced ByPort / ContractOverride Mechanism
Execution-only classificationUI constraints, on-chain audit trailAutonomousAgentVault.solLegal review only
3-layer liabilitydispute-resolution service:8105Validator governance (7-of-20)
Per-vault AUM hard capmaxDeposit() revertAutonomousAgentVault.solNo override
Per-class AUM soft capperformance-monitor alerts:8545Validator governance (7-of-20)
HHI diversity checkbehavioral-drift-detector:8735Emergency governance only
Staggered execution jitterAgent runtime sandboxExecution router :8562No override
Overlap limit (3 agents)agent-certification registry:8540Validator governance (7-of-20)
Liquidity circuit breakermarket-state service:8561Emergency governance only
Agent sandbox isolationContainer network policyDocker / runtimeNo override
90-day recertificationagent-certification scheduler:854048h grace, then hard suspend
Governance Principle: Hard limits (per-vault cap, sandbox isolation, execution jitter) have no override mechanism by design. Soft limits (per-class cap, overlap threshold) can be adjusted through validator governance. This ensures safety cannot be compromised by any single party while allowing the system to evolve as it matures.