Paper deep dive

AESP: A Human-Sovereign Economic Protocol for AI Agents with Privacy-Preserving Settlement

Jian Sheng Wang

Year: 2026Venue: arXiv preprintArea: cs.CRType: PreprintEmbeddings: 83

Intelligence

Status: succeeded | Model: Gemma-4-26B-A4B | Prompt: intel-v1 | Confidence: 90%

Last extracted: 7/20/2026, 6:20:11 AM

Summary

The paper introduces the Agent Economic Sovereignty Protocol (AESP), a layered protocol designed to balance AI agent autonomy with human economic control. AESP enforces that agents are economically capable but never sovereign through five mechanisms: a deterministic eight-check policy engine, human-in-the-loop review, EIP-712 dual-signed commitments, HKDF-based context-isolated privacy, and an ACE-GF cryptographic substrate. The protocol is implemented as an open-source TypeScript SDK with interoperability via MCP and A2A.

Entities (8)

AESP · protocol · 98%ACE-GF · cryptographic-module · 92%EIP-712 · standard · 90%HKDF · algorithm · 88%DSE · concept · 87%A2A · protocol · 85%MCP · protocol · 85%ML-DSA-44 · algorithm · 82%

Relation Signals (7)

AESP → enforces → Human Sovereignty

confidence 96% · AESP enforces the invariant that agents are economically capable but never economically sovereign.

AESP → uses → ACE-GF

confidence 95% · AESP enforces the invariant... through... an ACE-GF-based cryptographic substrate.

AESP → implements → EIP-712

confidence 93% · AESP uses EIP-712 for its dual-signed payment commitments.

AESP → uses → HKDF

confidence 90% · AESP’s privacy mechanism... uses HKDF domain separation and per-transaction context labels.

AESP → interoperateswith → MCP

confidence 88% · AESP exposes its economic operations as MCP tools... enabling any compatible framework to discover AESP-mediated services.

AESP → interoperateswith → A2A

confidence 88% · AESP exposes its economic operations as... A2A agent cards, enabling any compatible framework to discover AESP-mediated services.

ACE-GF → supports → ML-DSA-44

confidence 85% · The ACE-GF module includes ML-DSA-44 as an optional signature scheme.

Cypher Suggestions (0)

No Cypher suggestions yet.

Abstract

Abstract:As AI agents increasingly perform economic tasks on behalf of humans, a fundamental tension arises between agent autonomy and human control over financial assets. We present the Agent Economic Sovereignty Protocol (AESP), a layered protocol in which agents transact autonomously at machine speed on crypto-native infrastructure while remaining cryptographically bound to human-defined governance boundaries. AESP enforces the invariant that agents are economically capable but never economically sovereign through five mechanisms: (1) a deterministic eight-check policy engine with tiered escalation; (2) human-in-the-loop review with automatic, explicit, and biometric tiers; (3) EIP-712 dual-signed commitments with escrow; (4) HKDF-based context-isolated privacy with batched consolidation; and (5) an ACE-GF-based cryptographic substrate. We formalize two testable hypotheses on security coverage and latency overhead, and specify a complete evaluation methodology with baselines and ablation design. The protocol is implemented as an open-source TypeScript SDK (208 tests, ten modules) with interoperability via MCP and A2A.

PDF

Open source PDF →Open local PDF →

Trouble viewing inline? Open PDF directly →

Full Text

81,386 characters extracted from source content.

Expand or collapse full text

AESP: A Human-Sovereign Economic Protocol for AI Agents with Privacy-Preserving Settlement Jian Sheng Wang Abstract As AI agents increasingly perform economic tasks on behalf of humans, a fundamental tension arises between agent autonomy and human control over financial assets. We present the Agent Economic Sovereignty Protocol (AESP), a layered protocol in which agents transact autonomously at machine speed on crypto-native infrastructure while remaining cryptographically bound to human-defined governance boundaries. AESP enforces the invariant that agents are economically capable but never economically sovereign through five mechanisms: (1) a deterministic eight-check policy engine with tiered escalation; (2) human-in-the-loop review with automatic, explicit, and biometric tiers; (3) EIP-712 dual-signed commitments with escrow; (4) HKDF-based context-isolated privacy with batched consolidation; and (5) an ACE-GF-based cryptographic substrate. We formalize two testable hypotheses on security coverage and latency overhead, and specify a complete evaluation methodology with baselines and ablation design. The protocol is implemented as an open-source TypeScript SDK (208 tests, ten modules) with interoperability via MCP and A2A.111https://github.com/ya-xyz/aesp I Introduction I-A Motivation The rapid deployment of large language model (LLM)-based agents has created a new category of software that can reason, plan, and execute multi-step tasks with minimal human guidance [6]. When these tasks involve financial transactions—purchasing goods, subscribing to services, settling escrow—two requirements come into conflict. On one hand, agents must be autonomous enough to act without constant human micro-management; a human approving every API call defeats the purpose of delegation. On the other hand, humans must retain sovereignty over when and how their money moves; an agent that can unilaterally drain a wallet is an unacceptable liability. Existing wallet and DeFi interfaces are designed for direct human interaction. Agent-facing protocols that enforce human-defined economic boundaries are largely absent from the current ecosystem. Recent surveys of autonomous agents on blockchains [2] identify trust boundaries as a high-value attack surface, and the emerging “agent economy” literature [3] proposes architectures for agent-to-agent commerce but often assumes full agent autonomy rather than human-sovereign control. The tension between autonomy and accountability has been identified as a fundamental challenge in decentralized AI systems [4, 8]. The emerging consensus identifies two paradigms for AI economic participation: fully autonomous agents holding their own wallets on permissionless rails, versus human-delegated agents operating strictly as legally accountable extensions of a specific human principal. We argue for—and implement—a third path: sovereign agent economics, where agents transact autonomously at machine speed on crypto-native infrastructure while remaining cryptographically bound to human-defined governance boundaries. This reframes the autonomy–accountability tension from a binary choice into an engineering design space with tunable parameters. Most recently, Tomašev et al. [28] from Google DeepMind contributed a comprehensive conceptual framework for “Intelligent AI Delegation,” identifying nine dimensions of safe delegation—including permission handling, verifiable task completion, trust and reputation, and monitoring. Their work provides a valuable taxonomy and design vocabulary for the field; the authors note that concrete implementations realizing these principles remain an open challenge. Gap Existing frameworks [28, 7, 8] identify the requirements for safe economic delegation but provide no implementation or empirical validation. No prior work quantifies the trade-off between sovereignty enforcement and transaction efficiency in agent economic systems. Specifically, no existing system answers: What is the cost—in latency, false positives, and usability—of enforcing human sovereignty over every agent economic action? Hypotheses AESP addresses this gap. We formalize our claims as two testable hypotheses: • H1 (Security): AESP’s eight-check policy gate can automatically block the vast majority of unauthorized transactions while keeping the false positive rate on legitimate requests in the single-digit percentage range. Escalation is evaluated separately as operational burden (review load), not as algorithmic security success. • H2 (Efficiency): The end-to-end latency overhead introduced by AESP—comprising policy evaluation, cryptographic signing (via the Rust module), and HKDF key derivation—remains on the order of a few hundred milliseconds per transaction and does not materially degrade transaction completion rates compared to an unconstrained baseline. AESP provides a concrete, implemented protocol layer between the human’s Digital Sovereign Entity (DSE)—the human and their devices—and the settlement layer (vaults, escrow, allowances). Every agent action is either permitted by policy or escalated to the human for approval. The protocol draws on established access control models [9, 10, 11], cryptographic commitment schemes [18, 19], and blockchain privacy techniques [14, 15, 17] to provide a formally specified and implementable framework for human-sovereign agent economics. We specify a complete evaluation methodology with baselines and ablation design (Section XIII). I-B Design Principle The central invariant of AESP is: Agents should be economically capable but never economically sovereign. This invariant is enforced through five mechanisms: 1. Policy-gated execution. Every agent action is evaluated against a deterministic sequence of eight policy checks (per-transaction limit, time window, address allowlist, chain allowlist, method allowlist, first-payment review, minimum balance, and budget limits) before execution is permitted (Section VI). 2. Human-in-the-loop review. Actions that fail any policy check are routed to the human’s device for explicit approval. Critical policy changes—such as increasing spending limits or broadening agent scope—require biometric confirmation, following the progressive validation model advocated by recent AI safety frameworks [7] (Section IX). 3. Cryptographic commitment. Agent-to-agent agreements are structured as EIP-712 [18] typed data, signed by both buyer and seller agents, and optionally backed by on-chain escrow. The dual-signing requirement ensures that neither party can unilaterally modify the terms after commitment (Section VIII). 4. Context-isolated privacy. Each transaction uses an HKDF-derived [19] ephemeral address whose derivation context includes the agent ID, direction, sequence number, and transaction ID. Different contexts produce cryptographically independent addresses, preventing on-chain observers from correlating transactions across agent contexts (Section X). 5. Cryptographic execution substrate. The ACE-GF module [29] provides multi-chain signing, Argon2id/HKDF-based derivation, context-isolated address generation, and optional ML-DSA-44 support across WASM and native FFI targets. Under deployment assumption DA1, key material remains within the cryptographic module boundary (Section V). I-C Contributions This paper makes the following contributions: • A protocol specification with formal definitions of the agent identity model, policy evaluation algorithm, negotiation finite state machine, commitment lifecycle, review escalation flow, and privacy derivation scheme (Sections IV–X). • A cryptographic foundation via the ACE-GF substrate [29]—a Rust implementation with WASM and native FFI bindings—providing multi-curve signing (Ed25519, secp256k1, ML-DSA-44), authenticated encryption, Argon2id-to-HKDF key derivation, and context-isolated multi-chain address generation via the REV32 wallet format (Section V). • An open-source SDK implementation in TypeScript with 208 tests across ten modules,222https://github.com/ya-xyz/aesp covering identity derivation, policy enforcement, negotiation, commitments, review, MCP tools, A2A cards, cryptographic primitives, and context-isolated privacy (Section XI). • An evaluation framework comprising four baselines of increasing restrictiveness, a per-check ablation design, an unlinkability security game, and two falsifiable hypotheses on security coverage and latency overhead (Section XIII). • A privacy design with HKDF-derived ephemeral addresses, batched consolidation with timing jitter and Fisher-Yates shuffle, targeting transaction unlinkability against practical on-chain analysis while preserving auditability (Section X). • Interoperability with existing AI frameworks via the Model Context Protocol [21] (eight tool definitions) and Google’s Agent-to-Agent protocol [22] (agent card generation) (Section XII). I-D Relationship to Existing Frameworks A key positioning of this work is relative to the “Intelligent AI Delegation” framework by Tomašev et al. [28]. Table I provides a detailed mapping between the conceptual requirements identified in that framework and the corresponding mechanisms implemented in AESP. Their taxonomy of delegation dimensions—permission handling, monitoring, verifiable task completion, trust and reputation—provides the conceptual vocabulary that AESP’s design draws upon. AESP contributes a concrete instantiation: a policy engine with 8 deterministic checks, a human-in-the-loop review queue, EIP-712 dual-signed commitments, and cryptographic identity certificates. We view this as a complementary contribution: conceptual framework and implemented protocol together advance the field further than either alone. TABLE I: Mapping between Google DeepMind’s Intelligent AI Delegation Framework [28] and AESP Implementation Delegation Dimension Conceptual Requirement [28] AESP Realization Permission Handling (§4.7) Tiered permission models with progressive trust PolicyEngine: 8-check evaluation, 3 approval tiers (auto/review/biometric), 8 critical change types Monitoring (§4.5) Continuous monitoring and logging ReviewManager: async review queue with priority, expiration deadlines, 6 event types, emergency freeze Verifiable Completion (§4.8) Verifiable task completion mechanisms CommitmentBuilder: EIP-712 dual-signed commitments, 7-state lifecycle, SHA-256 commitment hashes Trust & Reputation (§4.6) Trust establishment and reputation models Identity certificates with owner Ed25519 signatures, hierarchical delegation (depth ≤5≤ 5), DID-based identity Security (§4.9) Cryptographic security and key management ACE-GF substrate (Section V; WASM/C FFI/Dart FFI): Ed25519, secp256k1, X25519, ML-DSA-44, AES-256-GCM; keys never leave crypto boundary Agent Communication Standardized agent communication protocols 8 MCP tools + A2A agent cards (implemented, tested) Privacy Not explicitly addressed HKDF context-isolated ephemeral addresses, Fisher-Yates shuffle, ±30% timing jitter, batched consolidation Post-Quantum Readiness Not addressed ML-DSA-44 (FIPS 204) lattice-based signatures via cryptographic module I-E Outline Section I surveys related work. Section I defines the system model, architecture, and threat model. Sections IV–X present the protocol components: identity, cryptographic foundation, policy, negotiation, commitment, review, and privacy. Section XI describes the implementation. Section XII discusses interoperability. Section XIII presents the evaluation methodology and experimental design for validating H1 and H2. Section XIV illustrates protocol expressiveness through case studies. Section XV addresses limitations. Section XVI concludes. I Related Work I-A Agent Economic Frameworks The idea of autonomous economic agents predates LLMs. Minarsch et al. [1] introduced the Fetch.ai Autonomous Economic Agent (AEA) framework, where software agents pursue economic goals using a decentralized Open Economic Framework with blockchain settlement. More recently, Xu [3] proposed a five-layer architecture for “The Agent Economy” spanning decentralized physical infrastructure (DePIN), decentralized identifiers (DIDs), cognitive tooling, ERC-4337 settlement, and Agentic DAOs. Their design assumes full agent autonomy—agents possess independent economic agency. AESP addresses the same problem space but takes the opposite stance: agents operate under human sovereignty, not independently of it. Alqithami [2] provides a comprehensive survey of 317 works on autonomous agents on blockchains, proposing a five-part taxonomy of integration patterns and identifying trust boundaries as a primary attack surface. Hu et al. [4] analyze the paradox of deploying LLM-based agents on trustless substrates (blockchain, TEEs), where immutability gains tamper-resistance but loses oversight mechanisms—precisely the tension that AESP’s policy-gated escalation model resolves. I-B Intelligent AI Delegation Tomašev et al. [28] present the most comprehensive conceptual treatment of AI delegation to date. Their framework identifies eleven task characteristics, defines delegation as a principal-agent relationship, and proposes nine dimensions of safe delegation: task specification, resource provisioning, tool access, monitoring, trust and reputation, permission handling, verifiable task completion, security, and rollback. This taxonomy provides a rigorous design vocabulary for reasoning about agent delegation; the authors identify concrete implementation as an important open direction. AESP builds on their conceptual foundations: Table I maps each framework dimension to the corresponding AESP mechanism, illustrating how conceptual requirements can be realized as protocol components. I-C Human-in-the-Loop AI Control The paradigm of learning from human feedback was established by Christiano et al. [5], who showed that complex RL tasks can be solved using non-expert human preference feedback on fewer than 1% of agent interactions. Ouyang et al. [6] extended this to language models with InstructGPT, demonstrating that RLHF produces outputs aligned with human preferences. At the systems level, Cheng et al. [7] propose a three-pillar model (transparency, accountability, trustworthiness) with progressive validation analogous to staged autonomous driving. AESP’s tiered escalation—where routine transactions are auto-approved, unusual transactions require explicit review, and critical policy changes require biometric confirmation—implements a concrete realization of this progressive approach for economic transactions. Hu and Rong [8] identify the accountability gap that arises when cryptographic self-custody scaffolds agentic sovereignty; AESP’s design directly addresses this by keeping the human principal as the ultimate economic authority. I-D Policy and Authorization Models AESP’s policy engine draws on three traditions in access control. Role-Based Access Control (RBAC) [9] assigns permissions to roles rather than individuals; AESP adapts this by assigning spending authority to agent scopes. Attribute-Based Access Control (ABAC) [10] evaluates policies over subject, object, operation, and environment attributes; AESP’s context-aware policy checks follow this pattern. Capability-based security [11] grants unforgeable tokens for specific rights; AESP’s per-policy, time-limited spending authorizations serve an analogous function. Recent work has begun adapting these models for AI agents. Abaev et al. [12] present AgentGuardian, which monitors agent execution traces to learn legitimate behaviors and derive adaptive access-control policies. Ganie [13] proposes integrating RBAC into LLM-based agents for industrial applications. AESP’s contribution is a hybrid approach: static policies defined by the human principal, with tiered escalation for out-of-policy actions and a classification system for detecting critical policy changes. I-E Blockchain Privacy Transaction privacy on public blockchains is well-studied. Stealth addresses (ERC-5564) [14] allow recipients to receive assets without publicly linking transactions. Mixing protocols such as Tornado Cash [15] use zero-knowledge proofs, while CoinJoin [16] combines multiple inputs and outputs. Wicht et al. [17] formalize blockchain privacy notions—untraceability and unlinkability—using a Transaction DAG model. AESP’s privacy mechanism differs in that it does not require mixing or zero-knowledge proofs. Instead, it uses REV32 context-isolated derivation, where chain-specific key material is derived from an identity root via HKDF domain separation and per-transaction context labels [19]. The resulting addresses are cryptographically independent, providing address-level unlinkability without on-chain mixing; residual side-channel leakage from consolidation patterns is discussed in Section X. I-F Cryptographic Commitments and Escrow EIP-712 [18] defines a standard for hashing and signing typed structured data with domain separators that prevent cross-application signature replay. AESP uses EIP-712 for its dual-signed payment commitments. Asgaonkar and Krishnamachari [20] propose dual-deposit escrow smart contracts for provably cheat-proof delivery; AESP’s commitment model is compatible with such designs, though the protocol is settlement-layer agnostic. I-G Agent Interoperability The Model Context Protocol (MCP) [21] provides a standardized interface for connecting AI assistants to external tools via JSON-RPC. Google’s Agent-to-Agent (A2A) protocol [22] enables cross-framework agent discovery through Agent Cards. AESP exposes its economic operations as MCP tools and generates A2A agent cards, enabling any compatible framework to discover AESP-mediated services. I-H Digital Sovereignty and Self-Sovereign Identity The concept of self-sovereign identity (SSI), articulated by Allen [25] and standardized through W3C DIDs [23] and Verifiable Credentials [24], holds that individuals should control their own digital identities. Krul et al. [26] systematize trust models across SSI components. Srivastava and Bullock [27] examine digital sovereignty in the AI context. AESP extends SSI from identity to economics: just as individuals should control their identifiers, they should control how their agents spend their money. I-I Post-Quantum Cryptography NIST’s selection of ML-DSA (formerly CRYSTALS-Dilithium) as the primary post-quantum digital signature standard under FIPS 204 [30] has motivated research into post-quantum readiness for blockchain systems. Fernandez-Carames and Fraga-Lamas [31] survey post-quantum approaches for blockchain. AESP’s cryptographic module includes ML-DSA-44 as an optional signature scheme, enabling forward-compatible agent identity and transaction signing. I System Model and Architecture I-A Layered Architecture AESP is organized as a four-layer stack (Figure 1): DSE (Digital Sovereign Entity)Human principal • Mobile • Browser extensionAESP ProtocolIdentity | Policy | Negotiation | Commitment | Review | Privacy | CryptoInteroperability BridgeMCP tools (8) | A2A agent cardsSettlement LayerVaults | Escrow | Allowances | AuthorityL4L3L2L1policy, freezesigned authexecutereviewstatusevents Figure 1: AESP four-layer architecture. Blue arrows (downward) represent the sovereignty and authorization flow; red arrows (upward) represent escalation and event reporting. Layer 4 (DSE) represents the human principal and their devices (mobile phone, browser extension). The DSE holds the master ACE-GF mnemonic (REV32-encoded sealed entropy), defines policies, and approves or rejects escalated actions. All economic sovereignty resides at this layer. Layer 3 (AESP) implements the protocol logic: agent identity derivation and certification, policy evaluation, negotiation state management, commitment construction, review queue management, cryptographic operations (via an ACE-GF-based cryptographic substrate), and privacy-preserving address derivation. AESP does not hold funds or execute on-chain transactions; it produces signed authorizations and commitments. Layer 2 (Bridge) exposes AESP operations to external AI frameworks. MCP tool definitions allow any MCP-compatible agent to check balances, create allowances, or file disputes. A2A agent cards advertise agent capabilities for cross-framework discovery. Layer 1 (Settlement) performs on-chain execution: funding escrow, releasing payments, managing vaults and allowances. AESP is settlement-layer agnostic; any conforming implementation can serve as Layer 1. I-B Participants We define three categories of participants: • Human principal H: The owner of the master ACE-GF mnemonic and the ultimate economic authority. H defines policies, approves escalated actions, and can freeze any agent at any time. • Agent AiA_i: A software entity derived from H’s master key at index i, identified by id(Ai)=SHA-256(pk(Ai))id(A_i)=SHA -256(pk(A_i)), operating within the policy boundaries set by H. • Counterparty agent AjA_j: An agent controlled by a different human principal H′H , with whom AiA_i may negotiate and form commitments. I-C Threat Model We formalize the threat model in terms of adversary capabilities, defense guarantees, and explicit failure modes. I-C1 Adversary Capabilities 1A_1: Compromised agent. The adversary gains control of agent AiA_i’s runtime (e.g., through prompt injection, supply-chain compromise, or software vulnerability). Formally, 1A_1 can invoke any SDK function available to AiA_i and can craft arbitrary action requests r with any parameters (amount, recipient, chain, method). Deployment assumption (DA1: Mandatory policy mediation). We assume that the deployment architecture enforces that all agent signing requests are routed through the AESP SDK’s PolicyEngine before reaching the cryptographic module. Concretely, the signing functions are not directly exposed to the agent runtime; they are accessible only through the SDK’s policy-gated API. This is an architectural invariant that must be enforced by the host environment. The reference deployment pattern for browser environments loads the ACE-GF WASM module in a dedicated Web Worker; the Worker exposes only high-level operations (sign, derive_address, encrypt) via postMessage, and raw credential material (mnemonic, passphrase) is passed once at initialization and never returned to the caller. The agent runtime on the main thread has no direct access to WASM linear memory or signing exports. In Node.js, the equivalent isolation is achieved via worker_threads or a subprocess with IPC; in native FFI deployments, a sandboxed execution context provides the same boundary. If 1A_1 can bypass the SDK and invoke signing functions directly, the policy enforcement guarantee is void. Under DA1, 1A_1 cannot modify the cryptographic binary, access the master ACE-GF mnemonic material, or bypass the PolicyEngine evaluation path. 2A_2: Malicious counterparty. Agent AjA_j (or its principal H′H ) may manipulate negotiation outcomes, repudiate commitments, or exploit timing in the escrow flow. AESP mitigates this through the dual-signing commitment protocol (Section VIII): both parties must sign the same EIP-712 structure before escrow is funded. 3A_3: On-chain observer. A passive adversary O monitors all on-chain transactions and attempts to link them to a single identity or vault. AESP’s context-isolated privacy (Section X) ensures that transactions using different context strings produce cryptographically independent addresses. O cannot determine whether two ephemeral addresses belong to the same principal without breaking HKDF or compromising the master key. I-C2 Defense Boundaries We state the following defense guarantees and their boundaries explicitly: • Policy enforcement guarantee: Under deployment assumption DA1 (mandatory policy mediation), no action violating the active policy can reach the signing layer without first being routed to the ReviewManager. This guarantee is architectural: it depends on the host environment enforcing that the cryptographic signing API is not directly accessible to the agent runtime. In deployments where DA1 is not enforced (e.g., the agent process has direct access to signing exports), a compromised agent can bypass the policy gate entirely. • Key isolation guarantee: Private keys never leave the Rust module’s memory space. In WASM deployments, signing is performed within WASM linear memory; in native FFI deployments, keys remain in the Rust process’s address space. Zeroization on drop is enforced in both paths. This guarantee fails if the adversary can modify the compiled binary or exploit a runtime vulnerability in the host environment. • Sovereignty guarantee: The human principal H can freeze any agent at any time, immediately halting all economic activity. This guarantee holds as long as the DSE device is not compromised. I-C3 Failure Cases We identify three failure modes that AESP does not fully mitigate, and we discuss them honestly: Collusion attack. If both the buyer agent AiA_i and seller agent AjA_j are compromised (or their principals collude), they can construct mutually beneficial but policy-violating commitments. AESP’s policy gate operates per-agent; cross-agent collusion detection requires a reputation or anomaly-detection layer that is out of AESP’s current scope. Approval fatigue. If an adversary triggers a high volume of review requests (e.g., 50 requests in 30 minutes), the human principal may begin approving requests without careful inspection. AESP’s review system supports urgency levels and expiration deadlines but does not currently implement rate-limiting or fatigue detection. We quantify this risk in Section XIII-D. Time-window boundary exploitation. An adversary aware of the policy’s time window boundaries can queue transactions to execute at the exact moment the window opens, potentially overwhelming the budget tracker before the human can react. AESP’s rolling budget limits (daily/weekly/monthly) provide a secondary defense, but a burst of transactions within a single evaluation cycle could exceed intended limits if the per-transaction limit alone is generous. I-C4 Out of Scope We do not defend against: (1) a compromised settlement layer (requires on-chain security guarantees orthogonal to AESP); (2) a compromised DSE device (if the adversary controls the human’s phone, all AESP guarantees are void); (3) side-channel attacks on the cryptographic module (requires constant-time implementations at the hardware level); or (4) social engineering of the human principal into approving malicious requests (requires user education, not protocol design). IV Identity IV-A Agent Derivation AESP derives agent identities deterministically from the human principal’s ACE-GF mnemonic. In REV32 mode, the mnemonic decodes to a 32-byte REV payload rHr_H, and key material is derived through the ACE-GF pipeline: rootH=HKDF(Argon2id(pH,salt(rH)),"acegf:identity:root")root_H=HKDF\! (Argon2id(p_H,salt(r_H)),\; "acegf:identity:root" ) (1) where pHp_H is the owner’s passphrase domain and salt(rH)salt(r_H) extracts the salt component from the REV32 payload (the partitioning of the 32-byte payload into salt and entropy fields is defined by the ACE-GF specification [29]). The HKDF notation follows RFC 5869 [19]; the full Extract-and-Expand decomposition is given in Equation 5 (Section V-C). Agent-specific keys are then derived deterministically from rootHroot_H under agent-scoped derivation context, yielding (ski,pki)(sk_i,pk_i) for each agent index i. id(Ai)=SHA-256(pki)id(A_i)=SHA -256(pk_i) (2) The agent is assigned a Decentralized Identifier (DID) [23] of the form did:aesp:id(Ai) did:aesp:id(A_i). This derivation is deterministic: the same ACE-GF mnemonic, passphrase domain, and agent index produce the same agent identity, enabling deterministic recovery. IV-B Identity Certificates To establish verifiable authorization, the human principal H issues an identity certificate for each agent: cert(Ai)=⟨ver,id(Ai),pki,xidH,C,h(π),αmax,chains,tcreated,texpires,σH⟩ splitcert(A_i)= ,id(A_i),pk_i,xid_H,C,h(π),\\ _ ,chains,t_created,t_expires, _H split (3) where verver is the certificate version (currently “1.0”), xidHxid_H is the human’s xidentity public key, C is the set of granted capabilities (e.g., payment, negotiation), h(π)h(π) is the SHA-256 hash of the associated policy object, αmax _ is the maximum autonomous transaction amount, and σH _H is the human’s Ed25519 signature over the certificate fields. Verification requires the trusted owner xidentity xidHxid_H. A verifier checks that σH _H is a valid Ed25519 signature by xidHxid_H over the canonical serialization, that the certificate has not expired, and that the claimed capabilities are within the scope of the associated policy. IV-C Agent Hierarchy AESP supports hierarchical delegation up to a configurable maximum depth dmax=5d_ =5. The hierarchy forms a rooted tree with the human principal at the root: H→A0→A0,1→A0,1,2→⋯H→ A_0→ A_0,1→ A_0,1,2→·s (4) Each agent can only delegate capabilities that are a subset of its own. The AgentHierarchyManager enforces the depth constraint and provides an escalation chain function that, given agent AiA_i, returns the ordered sequence [Ai,parent(Ai),…,H][A_i,parent(A_i),…,H] used for review routing. If an agent cannot resolve a policy violation, the review request is escalated up the chain toward the human principal. V Cryptographic Foundation AESP uses ACE-GF as its cryptographic execution substrate [29]. This layer provides deterministic identity reconstruction, context-isolated derivation, and multi-curve signing capabilities required by AESP. The same core implementation is exposed across WebAssembly and native FFI targets, enabling consistent cryptographic behavior across browser, server, and mobile deployments. V-A Architecture The ACE-GF substrate is organized as a layered implementation: • Core derivation layer: REV32 reconstruction, HKDF domain separation, and context-isolated per-chain key streams. • Cryptographic operations layer: Signing, encryption, and key agreement APIs with curve-specific dispatch. • Signer layer: Chain-specific transaction signing for EVM, Solana, Bitcoin, and other supported ecosystems. • Platform bindings: WASM and native FFI interfaces that keep a single cryptographic core while adapting to host runtimes. • Security utilities: Argon2id-based credential hardening, REV32 artifact handling, and memory zeroization. V-B Supported Cryptographic Primitives Table I summarizes the cryptographic primitives available in the cryptographic module (all primitives are available across all platform targets unless noted). TABLE I: Cryptographic Primitives in the ACE-GF Substrate Category Primitive Usage in AESP Signatures Ed25519 Agent identity, Solana tx ECDSA/secp256k1 EVM tx, EIP-712 signing Schnorr/secp256k1 Bitcoin Taproot tx Post-Quantum ML-DSA-44 (FIPS 204) Future-proof agent certs Key Agreement X25519 ECDH E2E negotiation msgs Encryption AES-256-GCM Negotiation msg encryption AES-256-GCM-SIV Passphrase sealing ChaCha20-Poly1305 Alternative encryption KDF Argon2id Passphrase + REV32 → Kmaster HKDF-SHA256 Context-isolated derivation Hash SHA-256 Identity, commitments V-C REV32 Wallet Format and Context-Isolated Derivation The core innovation in the cryptographic layer is the REV32 wallet format, which uses identity-root-based context-isolated key generation (rather than HD path extension). The derivation pipeline operates as follows: 1. REV32 recovery. Decode the ACE-GF mnemonic into the 32-byte REV32 payload (sealed entropy + metadata). 2. Identity-root derivation. Derive an identity root from the sealed REV32 secret and passphrase domain, then derive chain-specific key material from that root. 3. Context extension. Given a context string ctxctx, compute a derived key using HKDF: prk=HKDF-Extract(salt,identity_root)dk=HKDF-Expand(prk,info,L) splitprk&=HKDF -Extract(salt,identity\_root)\\ dk&=HKDF -Expand(prk,info,L) split (5) where info="ACEGF-REV32-V1-"‖curve‖":"∥ctxinfo= "ACEGF-REV32-V1-"\|curve\| ":"\|ctx and L is the key length for the target curve. 4. Address generation. The derived key dkdk is used to compute the chain-specific address (Ed25519 pubkey for Solana, Keccak-256 of ECDSA pubkey for EVM, etc.). This pipeline supports seven address namespaces: Solana, Ethereum/EVM, and Bitcoin (including Taproot) have full signer implementations; Cosmos and Polkadot have address derivation support; ML-DSA-44 provides a post-quantum namespace; and xidentity serves as AESP’s native identity namespace. The critical property is context isolation: given two distinct context strings ctx1≠ctx2ctx_1 _2, the derived keys dk1dk_1 and dk2dk_2 are computationally independent. This property, which follows from the pseudorandomness of HKDF [19], is the foundation of AESP’s privacy mechanism (Section X). The cryptographic module exposes context-isolated derivation through a unified API: view_wallet_unified_with_context(credential,ctx)→ view\_wallet\_unified\_with\_context(credential,ctx) (6) where W contains addresses for all supported chains, derived under the given context. The TypeScript SDK calls this function to generate privacy-preserving ephemeral addresses. V-D Key Protection and Memory Safety The cryptographic module implements several key protection measures: • Memory isolation. All cryptographic operations execute within the Rust module’s own memory space—WASM linear memory in browser/Node.js deployments, or the native process heap in C FFI and Dart FFI deployments. In either case, the host runtime only sees public keys, addresses, and signed outputs; private keys never cross the binding boundary. • Zeroization. All sensitive data structures implement Rust’s Zeroize and ZeroizeOnDrop traits, ensuring that key material is overwritten when it leaves scope. • Argon2id sealing. When wallet secret material must be persisted (e.g., in browser storage or application keychain), it is protected with AES-256-GCM-SIV under a key derived from the user’s passphrase via Argon2id. The default parameters (memory cost = 4 MB, time cost = 3, parallelism = 1) are tuned for constrained WASM environments; native FFI deployments can increase these to match OWASP recommendations. • No key export. Neither the WASM nor the C FFI binding exposes raw private key bytes. The sign_* and derive_* functions accept wallet credentials and context, perform operations internally, and return only the result. V-E Post-Quantum Readiness The cryptographic module includes ML-DSA-44 (Module-Lattice Digital Signature Algorithm, FIPS 204 [30]), the NIST-selected post-quantum signature standard. ML-DSA-44 signatures are available as an optional signing scheme for agent identity certificates and transaction authorization. This provides a migration path for AESP deployments that require resistance to quantum computing attacks, without impacting current classical-security deployments that use Ed25519 or secp256k1. V-F EIP-712 Typed Data Signing with Context The cryptographic module provides native EIP-712 [18] typed data signing with context support: evm_sign_typed_data_with_context(credential,ctx,typed_data_hash)→σ evm\_sign\_typed\_data\_with\_context(credential,ctx,typed\_data\_hash)→σ (7) This function derives a secp256k1 keypair under the given context (using the REV32 pipeline), then signs the EIP-712 hash of the typed data. This enables AESP’s commitment protocol (Section VIII) to use context-isolated keys for signing commitments, providing an additional layer of privacy: the signing key for a commitment is derived from a context string specific to that transaction, preventing signature-based correlation. VI Policy Engine VI-A Policy Structure A policy π is a tuple: π=⟨id,agentId,xidH,s,κ,tcreated,texpires⟩π= ,agentId,xid_H,s,κ,t_created,t_expires (8) where s∈auto_payment,negotiation,commitment,fulls∈\ auto\_payment, negotiation, commitment, full\ is the policy scope and κ is a conditions record containing the fields shown in Table I. TABLE I: Policy Condition Fields Condition Type Semantics maxAmountPerTx number Max per-transaction spend maxAmountPerDay number Rolling 24-hour limit maxAmountPerWeek number Rolling 7-day limit maxAmountPerMonth number Calendar-month limit allowListAddresses string[] Permitted recipients allowListChains string[] Permitted chains allowListMethods string[] Permitted methods timeWindow start, end Operating hours (H:M) minBalanceAfter number Min post-tx balance requireReviewFirstPay boolean First pay needs review Scopes are ranked to enable escalation detection: rank(auto_payment)=1rank( auto\_payment)=1, rank(negotiation)=2rank( negotiation)=2, rank(commitment)=3rank( commitment)=3, rank(full)=10rank( full)=10. VI-B Policy Evaluation Algorithm When agent AiA_i requests an action r, the policy engine evaluates all active policies for AiA_i in sequence. For each policy π, the engine performs eight checks in fixed order: 1. Per-transaction amount. If r.amount>κ.maxAmountPerTxr.amount>κ.maxAmountPerTx, reject. 2. Time window. If κ.timeWindowκ.timeWindow is defined and the current time t falls outside [start,end][start,end] (handling midnight wrap-around), reject. 3. Address allowlist. If κ.allowListAddressesκ.allowListAddresses is non-empty and r.to∉κ.allowListAddressesr.to∉κ.allowListAddresses, reject. 4. Chain allowlist. If κ.allowListChainsκ.allowListChains is non-empty and r.chain∉κ.allowListChainsr.chain∉κ.allowListChains, reject. 5. Method allowlist. If κ.allowListMethodsκ.allowListMethods is non-empty and r.method∉κ.allowListMethodsr.method∉κ.allowListMethods, reject. 6. First-payment review. If κ.requireReviewFirstPay=trueκ.requireReviewFirstPay=true and AiA_i has no prior successful payment under π, reject. 7. Minimum balance. If κ.minBalanceAfter>0κ.minBalanceAfter>0 and the projected post-transaction balance <κ.minBalanceAfter<κ.minBalanceAfter, reject. 8. Budget limits. Query the budget tracker for AiA_i’s rolling daily, weekly, and monthly totals. If adding r.amountr.amount would exceed any limit, reject. If all eight checks pass for any policy, the action is auto-approved and the matching policy ID is returned. If no policy permits the action, it is routed to the review subsystem (Section IX). Disjunctive (OR) semantics. When an agent has multiple active policies, evaluation follows disjunctive (OR) semantics: the action is approved if any matching policy permits it (Algorithm 1: the loop returns on the first passing policy). This is a deliberate capability-based design [11]—each policy grants a specific capability (e.g., “pay up to 100 USDC to vendor X”), and an agent with multiple policies receives the union of their permissions. Use cases include per-vendor spending limits, coexisting daily-ops and emergency policies with different thresholds, and time-scoped temporary policies that overlap with a permanent base policy. A consequence of OR semantics is that the most permissive matching policy determines the outcome; the human principal is responsible for not issuing overly broad policies. This responsibility is enforced by the critical policy change classification (Table IV), which requires human authorization—up to biometric confirmation—for any change that broadens agent permissions. Algorithm 1 Policy Evaluation 0: Action request r, agent AiA_i, active policies ΠAi _A_i 0: Decision ∈approved(π),review_required∈\ approved(π), review\_required\ 1: for each π∈ΠAiπ∈ _A_i do 2: κ←π.conditionsκ←π.conditions 3: if r.amount>κ.maxAmountPerTxr.amount>κ.maxAmountPerTx then 4: continue 5: end if 6: if ¬inTimeWindow(t,κ.timeWindow) (t,κ.timeWindow) then 7: continue 8: end if 9: if κ.allowListAddresses≠∅∧r.to∉κ.allowListAddressesκ.allowListAddresses≠ r.to∉κ.allowListAddresses then 10: continue 11: end if 12: if κ.allowListChains≠∅∧r.chain∉κ.allowListChainsκ.allowListChains≠ r.chain∉κ.allowListChains then 13: continue 14: end if 15: if κ.allowListMethods≠∅∧r.method∉κ.allowListMethodsκ.allowListMethods≠ r.method∉κ.allowListMethods then 16: continue 17: end if 18: if κ.requireReviewFirstPay∧¬hasPriorPayment(Ai,π)κ.requireReviewFirstPay (A_i,π) then 19: continue 20: end if 21: if projectedBalance(r)<κ.minBalanceAfterprojectedBalance(r)<κ.minBalanceAfter then 22: continue 23: end if 24: if ¬withinBudget(Ai,r.amount) (A_i,r.amount) then 25: continue 26: end if 27: return approved(π) approved(π) 28: end for 29: return review_required VI-C Critical Policy Change Classification When a policy is modified, AESP classifies the change to determine the required approval level. Eight change types are recognized, as shown in Table IV. TABLE IV: Critical Policy Change Classification Change Type Condition Approval budget_increase Any max* increased biometric scope_escalation rank(new) >> rank(old) biometric addr_remove_all Allowlist cleared biometric addr_add New address added review time_window_remove Time restriction removed review min_balance_lower Min balance decreased review first_pay_disable First-pay review off review expiration_extend Expiration extended review Changes in the biometric set require the human principal to confirm via biometric authentication (e.g., Face ID, fingerprint) on their mobile device. Changes in the review set require explicit confirmation through the review interface. VII Negotiation VII-A State Machine Agent-to-agent negotiation in AESP is modeled as a finite state machine (FSM) with eight states and thirteen transitions. States: S=s0,s1,…,s7S=\s_0,s_1,…,s_7\ as defined in Table V. TABLE V: Negotiation FSM States State Name Description s0s_0 initial Session created, no messages s1s_1 offer_sent Initiator sent an offer s2s_2 offer_received Responder received an offer s3s_3 countering Active counter-offer exchange s4s_4 accepted Both parties agree s5s_5 rejected Negotiation terminated s6s_6 committed EIP-712 commitment attached s7s_7 disputed Dispute filed post-commitment Transitions: The valid transition function δ:S×M→Sδ:S× M→ S is defined by thirteen tuples: δ=(s0,offer)→s1,(s0,offer_recv)→s2,(s1,counter)→s3,(s1,accept)→s4,(s1,reject)→s5,(s2,counter)→s3,(s2,accept)→s4,(s2,reject)→s5,(s3,counter)→s3,(s3,accept)→s4,(s3,reject)→s5,(s4,commit)→s6,(s6,dispute)→s7 splitδ=\&(s_0, offer)→ s_1,\;(s_0, offer\_recv)→ s_2,\\ &(s_1, counter)→ s_3,\;(s_1, accept)→ s_4,\\ &(s_1, reject)→ s_5,\;(s_2, counter)→ s_3,\\ &(s_2, accept)→ s_4,\;(s_2, reject)→ s_5,\\ &(s_3, counter)→ s_3,\;(s_3, accept)→ s_4,\\ &(s_3, reject)→ s_5,\;(s_4, commit)→ s_6,\\ &(s_6, dispute)→ s_7\ split (9) Note that s3→s3s_3→ s_3 (counter → counter) is a self-loop, allowing multiple rounds of negotiation. Sessions are bounded by a maximum round count (default: 10) and a time-to-live (default: 24 hours). The current FSM enforces only this session-level TTL; per-state timeouts (e.g., an accepted-state commitment deadline shorter than 24 hours) are delegated to the application layer. This design keeps the core FSM simple while allowing deployment-specific timeout policies to be layered on top. VII-B Message Format and Encryption Negotiation messages are typed as one of four message types: negotiation_offer, negotiation_counter, negotiation_accept, and negotiation_reject. When transmitted between agents, messages are end-to-end encrypted using X25519 ECDH key agreement (performed by the cryptographic module) to derive a shared secret, followed by AES-256-GCM symmetric encryption. The encrypted envelope includes a version identifier, algorithm descriptor, base64-encoded ciphertext, a unique message ID for replay protection, and a timestamp. The protocol is transport-agnostic: encrypted messages can be carried over MCP tool calls, HTTP, WebSockets, or any other channel. The NegotiationProtocol class accepts a pluggable MessageSender interface for transport abstraction. VII-C Agreement Hash When both parties accept, an agreement hash is computed: hagree=SHA-256(JSON(lastRound.payload))h_agree=SHA -256(JSON(lastRound.payload)) (10) where lastRound.payload is the most recently exchanged offer or counter-offer. This hash is included in the acceptance message and can be bound into the EIP-712 commitment (Section VIII) to cryptographically link the negotiation outcome to the payment commitment. VIII Commitment VIII-A EIP-712 Structure AESP uses EIP-712 [18] typed structured data for agent-to-agent payment commitments. The domain separator is: D=⟨name:“YalletAgentCommitment”,version:“1”,chainId:c⟩D= name:``YalletAgentCommitment′,\\ version:``1′,\; chainId:c (11) The commitment type contains nine fields: buyerAgent (address), sellerAgent (address), item (string), price (uint256), currency (address), deliveryDeadline (uint256), arbitrator (address), escrowRequired (bool), and nonce (uint256, from crypto.getRandomValues). VIII-B Dual-Signing Flow A commitment passes through the following lifecycle: draft→proposed→buyer_signed→fully_signed→escrowed→delivered→completed split draft→ proposed→ buyer\_signed→ fully\_signed\\ → escrowed→ delivered→ completed split (12) with alternative transitions to disputed (from escrowed or delivered) and cancelled (from any pre-escrowed state). The commitment hash is: hc=SHA-256(JSON(⟨D,V⟩))h_c=SHA -256(JSON( D,V )) (13) where V is the commitment value record and JSON(⋅)JSON(·) denotes deterministic JSON serialization with lexicographically sorted keys (matching the SDK’s JSON.stringify with sorted-key canonicalization). Both buyer and seller compute hch_c independently over the same canonical form and sign it; the fully_signed state is reached only when both signatures are present. When context-isolated signing is enabled, each party uses the cryptographic module’s evm_sign_typed_data_with_context function with a commitment-specific context string, ensuring that the signing key is unique to this transaction. VIII-C Settlement Integration AESP does not implement escrow or fund transfers. It produces a fully-signed commitment record containing the EIP-712 structure, both signatures, and metadata (escrow transaction hash, delivery confirmation hash, release transaction hash). The settlement layer consumes this record to fund escrow, verify delivery, and release payment. This separation ensures that AESP remains settlement-layer agnostic. IX Review (Human-in-the-Loop) IX-A Review Queue When the policy engine rejects an action (Section VI), AESP creates a review request and places it in a priority queue. Each request includes the original action, the agent ID, the policy violation reason, an urgency level (low, normal, high, critical), and an expiration deadline (default: 30 minutes). The review subsystem returns a promise that resolves when the human submits a response (approve, reject, or modify) or rejects when the deadline expires. This design allows the calling agent to await the review outcome without polling. IX-B Escalation Tiers AESP defines three escalation tiers (Table VI). TABLE VI: Escalation Tiers Tier Trigger Required Action Automatic All policy checks pass No human involvement Review Policy check fails Human confirms via UI Biometric Critical policy change Human biometric auth This tiered model implements progressive validation [7]: routine operations proceed without friction, unusual operations require a human check, and high-risk changes require physical presence at the device. IX-C Emergency Freeze The human principal can freeze any agent at any time by issuing a freeze command through the DSE. When an agent is frozen: (1) all pending review requests for that agent are immediately rejected; (2) any new action is blocked with an AGENT_FROZEN error; (3) the freeze status is persisted and survives restarts. Freezing is the mechanism of last resort ensuring the human can always halt an agent’s economic activity. IX-D Event System The review system emits six event types: request_created, request_approved, request_rejected, request_modified, request_expired, and request_cancelled. External systems (e.g., mobile notification services, audit loggers) can subscribe to these events to provide real-time visibility into the review pipeline. X Privacy X-A Problem Statement On public blockchains, all transactions are visible to any observer O. If an agent uses the same address for multiple transactions, O can trivially link them. Even with different addresses, timing patterns, amounts, and counterparties may allow statistical correlation. AESP’s privacy subsystem addresses the transaction unlinkability problem: given two transactions tx1tx_1 and tx2tx_2 produced by AESP, an observer O who does not possess the master key should be unable to determine whether they originate from the same vault or principal. X-B Context-Isolated Address Derivation AESP derives ephemeral addresses using HKDF [19] with a context string that encodes the transaction’s identity context. The context string is constructed by sorting key-value segments alphabetically and joining with colons: ctx=sort(agent:a,dir:d,seq:n,tx:t)∥’:’ctx=sort(\ agent:a,\; dir:d,\; seq:n,\; tx:t\)\| ':' (14) where a is the agent ID, d∈inbound,outboundd∈\ inbound, outbound\, n is a sequence counter, and t is a unique transaction UUID. The sorting ensures deterministic context string generation. The context string is passed to the cryptographic module’s REV32 derivation pipeline (Section V-C), which applies HKDF with: info="ACEGF-REV32-V1-"‖curve‖":"∥ctxinfo= "ACEGF-REV32-V1-"\|curve\| ":"\|ctx (15) Since different context strings produce cryptographically independent HKDF outputs, addresses derived from different contexts are unlinkable without knowledge of the master key. X-C Privacy Levels AESP supports three privacy levels: • Transparent (ℓ0 _0): The agent uses its main vault address directly. No privacy protection. • Basic (ℓ1 _1): One shared address per agent-chain-direction triple. Context: agent:a,dir:d,mode:basic\ agent:a, dir:d, mode:basic\. • Isolated (ℓ2 _2): A unique address per transaction. Context includes a unique transaction ID, ensuring one-time use. X-D Address Pool To avoid derivation latency at transaction time, AESP pre-derives a pool of ephemeral addresses for each agent-chain-direction triple. The default pool size is 5. When an address is claimed, the pool asynchronously replenishes. Pool addresses use the context segment pool:pre and an incrementing sequence counter; when claimed, they are mapped to the specific transaction context. X-E Consolidation Ephemeral addresses accumulate funds that must eventually be consolidated back into the vault. Naive consolidation—sweeping all addresses in a single transaction—would re-link them. AESP’s ConsolidationScheduler mitigates this with three techniques: Timing jitter. The base consolidation interval (default: 4 hours) is perturbed by a configurable jitter ratio (default: ±30%±30\%): tactual=tbase⋅(1−ρ+2ρ⋅r),r∼Uniform(0,1)t_actual=t_base·(1-ρ+2ρ· r), r (0,1) (16) where ρ is the jitter ratio. Address shuffle. Before consolidation, the set of ephemeral addresses is permuted using the Fisher-Yates algorithm: for i=n−1 downto 1:j←random[0,i];swap(ai,aj)for i=n-1 downto 1:\;j [0,i];\;swap(a_i,a_j) (17) ensuring that consolidation order reveals no information about derivation order. Batched execution. Addresses are consolidated in batches of configurable size (default: 5), with random inter-batch delays drawn uniformly from [10,60][10,60] minutes. X-F Audit Tags Despite unlinkability guarantees, the asset owner must reconstruct transaction history for auditing. AESP’s ContextTagManager creates an encrypted context tag for each ephemeral transaction, recording agent ID, policy ID, commitment ID, ephemeral address, and metadata. Tags are stored locally and optionally archived to permanent storage (e.g., Arweave) in encrypted form. Archiving supports three batching strategies: immediate (each tag archived individually), time window (batched after a configurable window, default: 5 minutes), and count threshold (batched when count reaches a threshold, default: 50). X-G Privacy Design Rationale The privacy design rests on the following argument. At the address derivation layer, HKDF [19] with distinct info strings produces outputs that are computationally indistinguishable from independent random values, assuming the input keying material has sufficient min-entropy (in REV32 mode, 224 bits of entropy are carried in the REV payload). This means that addresses derived from different context strings are cryptographically unrelated—an observer who sees only on-chain addresses cannot determine whether they share a common master key without breaking HKDF’s pseudorandomness. However, address-level unlinkability does not imply full transaction unlinkability in practice. Side channels—consolidation timing, transaction amounts, counterparty patterns—can leak correlation information even when addresses are independent. AESP’s consolidation countermeasures (timing jitter, Fisher-Yates shuffle, batched execution) are designed to reduce these side channels, but we do not claim formal unlinkability against all adversaries. Section XIII-C describes the planned empirical evaluation of residual linkability under a heuristic clustering adversary. A formal privacy analysis in a simulation-based framework (e.g., the Transaction DAG model of Wicht et al. [17]) is left to future work. XI Implementation XI-A SDK Architecture AESP is implemented as a TypeScript library (@yallet/aesp) targeting ES2022 with ECMAScript module (ESM) output. The implementation is organized into ten modules, each available as a separate entry point for tree-shaking (Table VII). TABLE VII: AESP SDK Modules Module Primary Exports types All shared type definitions crypto Signing, encryption, hashing identity deriveAgentIdentity, certificates policy PolicyEngine, BudgetTracker negotiation NegotiationStateMachine, protocol commitment CommitmentBuilder review ReviewManager mcp MCPServer, tool definitions a2a AgentCardBuilder privacy AddressPoolManager, consolidation XI-B Cryptographic Backend All cryptographic operations are performed by the Rust module described in Section V. The TypeScript SDK interacts with the module through a thin adapter layer that handles serialization/deserialization—via wasm-bindgen in browser/Node.js deployments or via C FFI bindings in server-side and mobile deployments. For SHA-256 hashing only, a Web Crypto API fallback is provided when the cryptographic module is unavailable. XI-C Storage Abstraction All stateful modules accept a pluggable StorageAdapter interface: interface StorageAdapter getItem(key: string): Promise<string | null>; setItem(key: string, value: string): Promise<void>; This enables deployment across environments (in-memory for testing, localStorage for browser, databases for server). XI-D Testing The implementation includes 208 tests across nine test suites (covering all ten modules), executed with Vitest. Test coverage spans identity derivation, policy evaluation (including all eight check types and all eight critical change classifications), negotiation FSM transitions, commitment lifecycle, review queue and freeze mechanics, MCP tool validation, A2A card generation, cryptographic operations, and privacy features (address derivation, consolidation jitter, Fisher-Yates shuffle, audit batching). XII Interoperability XII-A Model Context Protocol (MCP) AESP defines eight MCP [21] tools that expose economic operations to any MCP-compatible AI framework (Table VIII).333The yault_ prefix reflects the reference settlement layer integration (Yault). Deployments targeting other settlement layers may rename these tools while preserving the same JSON Schema interfaces. TABLE VIII: MCP Tool Definitions Tool Description yault_check_balance Query agent account balance yault_deposit Deposit to ERC-4626 vault yault_redeem Redeem vault shares yault_create_allowance Create payment allowance yault_cancel_allowance Cancel an allowance yault_file_dispute File dispute with evidence hash yault_check_budget Query remaining budget yault_list_agents List sub-agents with status Each tool includes a JSON Schema definition for argument validation. The MCPServer class provides a transport layer supporting both stdio and server-sent events (SSE). XII-B Agent-to-Agent (A2A) Protocol AESP generates A2A agent cards [22] from agent configuration. Each card advertises the agent’s capabilities (payment, negotiation, data query, commitment, delegation, arbitration), supported input/output modes, authentication scheme (Ed25519), and endpoint URL. This enables cross-framework agent discovery: an agent running on a different platform can discover an AESP-managed agent’s economic capabilities and initiate interaction. XIII Evaluation Methodology This section specifies the evaluation methodology for validating the two hypotheses stated in Section I. All experiments execute at the SDK layer using the AESP TypeScript library and the cryptographic module (WASM binding for the primary benchmark environment); no on-chain transactions are required. The experiment framework, runner scripts, and reproduction instructions are maintained alongside the source code.444https://github.com/ya-xyz/aesp This version focuses on methodology and experimental design; empirical result tables are deferred to a dedicated evaluation report. XIII-A Evaluation Design XIII-A1 Request Corpus We define a synthetic request corpus of 1,500 action requests: • Attack set (n=1,000n=1,000): Requests representing unauthorized agent activity, divided into two categories. Single-condition violations (n≈950n≈ 950) each violate at least one individual policy condition, stratified across: over-limit amounts, out-of-window timing, disallowed addresses, disallowed chains, disallowed methods, first-payment violations, minimum-balance violations, and budget-exceeding requests. Aggregate violations (n≈50n≈ 50) are individually policy-compliant—each passes all eight checks in isolation—but represent unauthorized behavior detectable only through cross-request context (e.g., rapid sequences of compliant transactions that collectively exhaust budget between tracker evaluation windows). • Legitimate set (n=500n=500): Requests that comply with all policy conditions, covering normal transaction patterns across varied amounts (0.01–100 units), permitted addresses, permitted chains, and within-window timing. Amounts are drawn from a log-normal distribution to simulate realistic spending patterns. Each request is a structured PolicyCheckRequest object with fields for amount, recipient address, chain ID, method, timestamp, and balance context. The reference policy uses representative conditions: maxAmountPerTx = 100, maxAmountPerDay = 500, maxAmountPerWeek = 2,000, maxAmountPerMonth = 5,000, timeWindow = 09:00–21:00, minBalanceAfter = 10, requireReviewFirstPay = true, with 10 addresses in the allowlist, 3 chains, and 4 methods. XIII-A2 Baselines We compare AESP against four baselines of increasing restrictiveness. Because there is no standardized public benchmark suite or directly comparable deployed protocol that exposes the same eight-check gate with tiered human escalation, these baselines are designed as mechanism-isolation controls: each step adds one layer of governance complexity, allowing us to attribute security and latency changes to specific protocol components rather than to implementation differences across unrelated systems. • B0 (Unconstrained): No policy checks. All requests are auto-approved. This represents a raw wallet with no agent restrictions. • B1 (Amount-only): Only the per-transaction amount check (maxAmountPerTx). Simulates a simple spending cap. • B2 (Two-check): Amount check + time window check. Simulates a spending cap with operating hours. • B3 (Full gate, no escalation): All eight policy checks are applied, but rejected actions are silently dropped (no human review, no escalation). Simulates a strict automated filter without human-in-the-loop. • AESP (Full): All eight policy checks + three-tier escalation. Rejected actions are routed to the ReviewManager; auto-approval, explicit review, and biometric tiers are active. XIII-A3 Metrics For H1 (Security), we report auto-block performance as the primary security outcome and treat escalation as operational load: • Auto-blocked rate: Fraction of attack requests deterministically rejected by the policy gate without human involvement. This is the guaranteed defense: auto-blocked requests cannot proceed regardless of human behavior. • Escalation load rate: Fraction of attack requests routed to the human principal via the ReviewManager. This is an operational burden metric, not counted as deterministic security success. • False positive rate (FPR): Fraction of legitimate requests auto-blocked or escalated. • Per-check attribution: Which of the eight checks triggered auto-blocking, used in the ablation study. For H2 (Efficiency), we measure: • Policy evaluation latency: Time for the 8-check sequence (evaluatePolicy()). • Signing latency: Ed25519 and secp256k1 signing time (via the cryptographic module). • Key derivation latency: HKDF context-isolated derivation time. • End-to-end overhead: Total latency from action request to signed authorization (policy check + signing + derivation). All latency measurements will use performance.now() with 100 warm-up iterations discarded and ≥ 1,000 measured iterations. Results will be reported as median with interquartile range (IQR) across ≥ 5 independent trials. The primary benchmark environment is a modern Node.js runtime (e.g., v25) with the WASM binding loaded via wasm-bindgen; comparative measurements using the native C FFI binding will be reported where applicable. XIII-A4 Ablation Design To isolate the contribution of each policy check, we remove one check at a time from the full eight-check gate (B3 configuration, without escalation) and re-evaluate the auto-blocked rate. The expected output is a delta table showing the marginal contribution of each check to overall security coverage. XIII-B Planned Analyses XIII-B1 Security Coverage (H1) The baseline comparison will report the auto-blocked rate, escalation load rate, and FPR for each of the five configurations (B0–B3 and AESP Full). We expect the eight-check gate to auto-block the vast majority of single-condition violations, while escalation load will be concentrated in aggregate violations that pass individual checks but exhibit suspicious cross-request patterns. The ablation will quantify the marginal contribution of each check. Interpreting escalation. Escalation is not treated as automatic interception. If the human approves all escalated requests without inspection, effective protection equals the auto-blocked rate alone. We therefore report escalation only as review load and analyze its usability implications separately (Section XIII-D). XIII-B2 Latency Overhead (H2) We will measure per-operation latency for: 8-check policy evaluation, budget tracker query, Ed25519 signing, secp256k1 signing, EIP-712 typed data signing, HKDF context derivation, SHA-256 hashing (cryptographic module vs. Web Crypto fallback), and composite end-to-end paths. All cryptographic operations are benchmarked via the WASM binding as the primary target; native C FFI measurements will be reported as a secondary comparison. The hypothesis threshold is 200 ms median end-to-end overhead; we expect actual overhead to be substantially lower given that individual cryptographic operations typically complete in single-digit to low-double-digit milliseconds. XIII-C Transaction Unlinkability To assess the privacy subsystem, we will generate N=1,000N=1,000 transactions across multiple agents, each using context-isolated addresses (privacy level ℓ2 _2), and apply a simulated address-clustering heuristic (common-input-ownership and temporal proximity) to the resulting on-chain footprint. The experiment will compare three configurations: (1) no consolidation countermeasures (baseline), (2) timing jitter (± 30%) alone, and (3) jitter + Fisher-Yates shuffle + batched consolidation (batch size 5, inter-batch delay 10–60 min). We expect progressive reduction in linkability across these configurations, with residual linkability arising primarily from amount-based correlation in consolidation outputs. XIII-D Anticipated Threats to Validity Construct validity. The attack corpus is synthetic; real-world attack distributions may differ. We mitigate this by stratifying across all eight check types and including compound attacks that violate multiple conditions simultaneously. External validity. Latency measurements will be platform-specific. WASM performance varies across runtimes (browsers, Deno, server-side Node.js), and native FFI performance will differ from WASM results. Browser-based deployments may show 1.5–2× higher overhead due to JIT warmup, while native C FFI deployments are expected to be faster. Approval fatigue. The evaluation assumes the human principal responds optimally to review requests. In practice, high review volumes may degrade human decision quality. Addressing approval fatigue through rate-limiting and intelligent batching is future work (see Section XV). XIV Case Studies To demonstrate the expressiveness and practical applicability of AESP, we present three case studies that exercise different combinations of protocol features. Each case study is implemented as an end-to-end scenario using the AESP SDK. XIV-A Three-Party Grocery Delivery This scenario models a consumer agent, a grocery store agent, and a delivery agent coordinating a grocery delivery transaction. The consumer agent negotiates prices with the grocery store agent through the negotiation FSM (Section VII), forms an EIP-712 commitment (Section VIII), and coordinates delivery payment. Key protocol features exercised: • Multi-agent identity derivation (three agents from separate principals) • Cross-agent negotiation with offer/counter/accept flow • Dual-signed commitment with escrow • Policy enforcement (spending limits, chain restrictions) • Human review for the initial high-value grocery order XIV-B Autonomous Cloud Resource Optimizer This scenario models an AI agent that autonomously manages cloud infrastructure spending. The agent monitors resource utilization and negotiates spot instance prices, subject to human-defined budget policies. Key protocol features exercised: • Policy engine with budget tracking (daily/weekly/monthly limits) • Critical policy change classification (budget increase requires biometric) • Emergency freeze/unfreeze cycle • Rolling budget window management XIV-C Privacy-Preserving NFT Hunter This scenario models an agent that scouts and acquires NFTs across multiple marketplaces while preserving the buyer’s identity privacy. Key protocol features exercised: • All three privacy levels (transparent, basic, isolated) • Address pool replenishment and claiming • Batched consolidation with Fisher-Yates shuffle and timing jitter • Context-isolated address derivation via the cryptographic module • Encrypted audit tag archiving These case studies demonstrate that AESP’s modular design allows different applications to compose protocol features as needed: the grocery scenario emphasizes multi-party coordination, the cloud optimizer emphasizes policy enforcement and human oversight, and the NFT hunter emphasizes privacy. XV Discussion and Limitations Evaluation status. Section XIII specifies the complete evaluation methodology—request corpus, baselines, metrics, and ablation design—for validating both hypotheses. The framework separates deterministic protection (auto-block rate) from operational burden (escalation load) and measures end-to-end latency overhead of policy evaluation, cryptographic signing, and key derivation. Settlement layer dependency. AESP defines the protocol and produces signed authorizations, but does not implement on-chain execution. End-to-end operation requires a conforming settlement layer. The current implementation is designed for integration with Yault but is architecturally settlement-agnostic. Privacy limitations and residual leakage. Context-isolated privacy depends on a wallet that supports HKDF-based context derivation in REV32 mode. As described in Section XIII-C, consolidation countermeasures (timing jitter, Fisher-Yates shuffle, batched consolidation) are designed to reduce address linkability, but residual leakage from amount-based correlation in consolidation outputs is expected. Specifically, if an adversary can observe consolidation transaction amounts and match them against known ephemeral address balances, partial re-linking becomes possible. Techniques such as amount splitting or mixing during consolidation could reduce this residual, but are not currently implemented. Approval fatigue. The requireReviewFirstPay check and budget-boundary proximity are expected to produce a non-trivial false positive rate. Under sustained high-throughput operation, this could generate review fatigue. AESP currently supports urgency levels and expiration deadlines but does not implement rate-limiting, intelligent batching of review requests, or adaptive thresholds that learn from human approval patterns. Addressing this is a priority for future work. Binding performance variance. Cryptographic latency varies by binding target. WASM execution in browsers may show 1.5–2× higher overhead than Node.js due to JIT compilation warmup and stricter memory constraints. Server-side and mobile deployments using the native C FFI or Dart FFI bindings bypass the WASM layer entirely and are expected to match native Rust performance. Post-quantum migration. While ML-DSA-44 is available in the cryptographic module (across all binding targets), a complete post-quantum migration requires post-quantum key agreement (replacing X25519) and post-quantum encryption (replacing AES-256-GCM with a post-quantum KEM + symmetric scheme). The current post-quantum support covers signatures only. Scalability. The review queue introduces latency for out-of-policy actions. In a high-throughput agent economy, the 30-minute default review deadline may be too slow. Adaptive deadline policies and batch review interfaces are areas for improvement. Formal verification. While the negotiation FSM and policy evaluation sequence are specified precisely, the implementation has not been formally verified. Applying model checking to the state machine and policy evaluation logic is a natural next step. Regulatory compliance. AESP’s policy engine and audit trail support compliance requirements (spending limits, allowlists, audit records), but jurisdiction-specific regulations (e.g., money transmitter classification, MiCA) require analysis at the settlement and platform layers. XVI Conclusion We have presented AESP, a protocol for enabling AI agents to participate in economic transactions while ensuring that economic sovereignty remains with the human principal. The protocol enforces the invariant that agents are economically capable but never economically sovereign through a combination of deterministic policy evaluation, tiered human-in-the-loop review, dual-signed EIP-712 commitments, HKDF-based context-isolated privacy, and a full-stack cryptographic foundation built on the ACE-GF substrate with multi-platform bindings. We specify a complete evaluation methodology with four baselines of increasing restrictiveness, a per-check ablation design, and a transaction unlinkability experiment, targeting two falsifiable hypotheses: (H1) the eight-check gate auto-blocks ≥ 90% of unauthorized transactions with ≤ 5% false positive rate, while escalation load is reported separately; and (H2) end-to-end latency overhead remains below 200 ms. AESP builds on the conceptual foundations established by recent work—notably Google DeepMind’s Intelligent AI Delegation framework [28]—and provides a concrete, implemented realization of the requirements they identify. The accompanying open-source TypeScript SDK (208 tests, ten modules)555https://github.com/ya-xyz/aesp provides interoperability with MCP and A2A. As AI agents become increasingly capable of autonomous economic action, protocols that quantifiably enforce human sovereignty will be essential infrastructure. AESP provides a formally specified and implementable foundation for this emerging requirement. References [1] D. Minarsch, S. A. Hosseini, M. Favorito, and J. Ward, “Autonomous Economic Agents as a Second Layer Technology for Blockchains: Framework Introduction and Use-Case Demonstration,” in Proc. 2nd Crypto Valley Conference on Blockchain Technology (CVCBT), 2020, p. 27–35. [2] S. Alqithami, “Autonomous Agents on Blockchains: Standards, Execution Models, and Trust Boundaries,” arXiv:2601.04583, Jan. 2026. [3] M. Xu, “The Agent Economy: A Blockchain-Based Foundation for Autonomous AI Agents,” arXiv:2602.14219, Feb. 2026. [4] B. A. Hu, Y. Liu, and H. Rong, “Trustless Autonomy: Understanding Motivations, Benefits, and Governance Dilemmas in Self-Sovereign Decentralized AI Agents,” arXiv:2505.09757, May 2025. [5] P. F. Christiano, J. Leike, T. B. Brown, M. Martic, S. Legg, and D. Amodei, “Deep Reinforcement Learning from Human Preferences,” in NeurIPS, vol. 30, 2017. [6] L. Ouyang et al., “Training Language Models to Follow Instructions with Human Feedback,” in NeurIPS, vol. 35, 2022. [7] E. C. Cheng et al., “Toward Safe and Responsible AI Agents: A Three-Pillar Model for Transparency, Accountability, and Trustworthiness,” arXiv:2601.06223, Jan. 2026. [8] B. A. Hu and H. Rong, “Sovereign Agents: Towards Infrastructural Sovereignty and Diffused Accountability in Decentralized AI,” arXiv:2602.14951, Feb. 2026. [9] R. S. Sandhu, E. J. Coyne, H. L. Feinstein, and C. E. Youman, “Role-Based Access Control Models,” IEEE Computer, vol. 29, no. 2, p. 38–47, 1996. [10] V. C. Hu et al., “Guide to Attribute Based Access Control (ABAC) Definition and Considerations,” NIST SP 800-162, 2014. [11] J. B. Dennis and E. C. Van Horn, “Programming Semantics for Multiprogrammed Computations,” Commun. ACM, vol. 9, no. 3, p. 143–155, 1966. [12] N. Abaev, D. Klimov, G. Levinov, D. Mimran, Y. Elovici, and A. Shabtai, “AgentGuardian: Learning Access Control Policies to Govern AI Agent Behavior,” arXiv:2601.10440, Jan. 2026. [13] A. G. Ganie, “Securing AI Agents: Implementing Role-Based Access Control for Industrial Applications,” arXiv:2509.11431, Sep. 2025. [14] T. Wahrstatter, M. Solomon, B. DiFrancesco, and V. Buterin, “ERC-5564: Stealth Addresses,” Ethereum Improvement Proposals, 2022. [15] M. Nadler and F. Schar, “Tornado Cash and Blockchain Privacy: A Primer for Economists and Policymakers,” Federal Reserve Bank of St. Louis Review, vol. 105, no. 2, p. 122–136, 2023. [16] G. Maxwell, “CoinJoin: Bitcoin Privacy for the Real World,” BitcoinTalk Forum, Aug. 2013. [17] F.-X. Wicht, Z. Wang, D. V. Le, and C. Cachin, “A Transaction-Level Model for Blockchain Privacy,” in Proc. Financial Cryptography and Data Security (FC), 2024. [18] R. Bloemen, L. Logvinov, and J. Evans, “EIP-712: Typed Structured Data Hashing and Signing,” Ethereum Improvement Proposals, 2017. [19] H. Krawczyk and P. Eronen, “HMAC-based Extract-and-Expand Key Derivation Function (HKDF),” IETF RFC 5869, 2010. [20] A. Asgaonkar and B. Krishnamachari, “Solving the Buyer and Seller’s Dilemma: A Dual-Deposit Escrow Smart Contract for Provably Cheat-Proof Delivery and Payment for a Digital Good without a Trusted Mediator,” in Proc. IEEE ICBC, 2019. [21] Anthropic, “Model Context Protocol (MCP) Specification,” Version 2025-11-25, 2025. [22] Google, “Agent2Agent Protocol (A2A),” Version 0.3, 2025. [23] M. Sporny, A. Guy, M. Sabadello, and D. Reed (Eds.), “Decentralized Identifiers (DIDs) v1.0,” W3C Recommendation, 2022. [24] M. Sporny, D. Longley, and D. Chadwick (Eds.), “Verifiable Credentials Data Model v1.1,” W3C Recommendation, 2022. [25] C. Allen, “The Path to Self-Sovereign Identity,” Apr. 2016. [26] E. Krul, H.-Y. Paik, S. Ruj, and S. S. Kanhere, “SoK: Trusting Self-Sovereign Identity,” in Proc. Privacy Enhancing Technologies Symposium (PETS), 2024. [27] S. Srivastava and J. B. Bullock, “AI, Global Governance, and Digital Sovereignty,” arXiv:2410.17481, Oct. 2024. [28] N. Tomašev et al., “Intelligent AI Delegation,” Google DeepMind, arXiv:2602.11865, Feb. 2026. [29] J. S. Wang, “ACE-GF: An Atomic, Seed-Storage-Free Identity Primitive for Autonomous Digital Entities,” arXiv:2511.20505, Nov. 2025. [30] National Institute of Standards and Technology, “Module-Lattice-Based Digital Signature Standard (ML-DSA),” FIPS 204, Aug. 2024. [31] T. M. Fernández-Caramés and P. Fraga-Lamas, “Towards Post-Quantum Blockchain: A Review on Blockchain Cryptography Resistant to Quantum Computing Attacks,” IEEE Access, vol. 8, p. 21091–21116, 2020. Appendix A Protocol Constants Table IX summarizes the protocol constants used throughout AESP. TABLE IX: Protocol Constants Constant Value Section REV32 context namespace ACEGF-REV32-V1-* + context labels IV Max hierarchy depth 5 IV Policy scope ranks 1, 2, 3, 10 VI Max negotiation rounds 10 VII Negotiation TTL 24 hours VII Review deadline 30 minutes IX Address pool size 5 X Consolidation interval 4 hours X Consolidation jitter ±30% X Consolidation batch 5 X Inter-batch delay 10–60 min X Audit batch threshold 50 X Audit time window 5 min X EIP-712 domain name “YalletAgentCommitment” VIII EIP-712 version “1” VIII Argon2id memory 4 MB V Argon2id iterations 3 V HKDF info prefix ACEGF-REV32-V1- V Supported chains 7 (see §V-C) V Appendix B Cryptographic Module API Summary Table X lists the primary exports used by the AESP TypeScript SDK. Function names shown are from the WASM binding (wasm.rs); the _wasm suffix is a binding-layer convention and does not indicate WASM-specific behavior—equivalent functions are exposed through the C FFI (ffi.rs) and Dart FFI bindings with their respective platform naming conventions (e.g., _ffi suffix for C FFI). TABLE X: Primary Cryptographic Module Exports (WASM binding names) Export Function view_wallet_unified_with_context_wasm Derive multi-chain wallet under context evm_sign_typed_data_with_context EIP-712 signing with context isolation solana_sign_transaction_with_context Solana transaction signing acegf_encrypt_for_xidentity Encrypt data for a recipient identity acegf_compute_dh_key_wasm X25519 ECDH key agreement acegf_seal_passphrase_wasm Argon2id passphrase sealing acegf_unseal_passphrase_wasm Passphrase unsealing pqc_sign_message_wasm ML-DSA-44 post-quantum signing pqc_verify_signature_wasm ML-DSA-44 verification

Instant research discovery