Key terms in wallet infrastructure, blockchain APIs, and AI agent tooling.
Programmable Wallet Infrastructure
Programmable wallet infrastructure is a B2B platform layer that lets developers compose wallet operations — reading balances, preparing transactions, signing through hosted or self-hosted paths, applying policy controls, and producing audit evidence — through SDK, REST API, or MCP, instead of stitching together signing libraries, custody vendors, and policy engines.
Programmable wallet infrastructure combines five primitives into one platform: wallet data (assets, balances, prices, history, transaction status), transaction workflows (fee calculation, simulation, preparation, swaps, broadcast), signing and key infrastructure (hosted MPC, self-hosted vaults, external signers), governance and controls (per-tenant policies, role-separated approvals, automation safety), and verifiable evidence (policy receipts, signer paths, hash-chained audit records). Teams use only the primitives they need or compose them into full governed workflows for stablecoin payouts, payment platforms, RWA settlement, family-office mandates, and AI agent operations.
How WalletSuite implements this
WalletSuite is programmable wallet infrastructure for AI agents and B2B teams — one platform across SDK, REST API, and MCP Server with hosted MPC, self-hosted OWS, and external signer paths under one policy and evidence layer.
Explore the platform →Wallet Infrastructure
Wallet infrastructure is the backend layer of APIs, SDKs, and services that lets companies embed blockchain wallet functionality (key management, signing, balance queries, and transfers) into their own products without building it from scratch.
Traditional wallet development requires teams to run full nodes, manage private keys, handle nonce tracking, and normalize data across chains. Wallet infrastructure providers abstract this into a unified API surface, reducing integration time from months to days. The infrastructure typically includes transaction construction, fee estimation, multi-chain routing, and webhook-driven event notifications.
How WalletSuite implements this
WalletSuite provides wallet infrastructure as an SDK, REST API, and MCP Server covering 80+ blockchains with normalized data formats across all of them.
MCP Server (Model Context Protocol)
An MCP server is a lightweight process that exposes domain-specific tools to AI models via the Model Context Protocol, an open standard created by Anthropic for connecting LLMs to external data and actions. Tools can include querying balances, preparing transfers, and looking up token prices.
MCP follows a client-server architecture where AI hosts (Claude Desktop, IDEs, custom agents) connect to MCP servers over stdio or HTTP. Each server declares a set of typed tools that the model can invoke during a conversation. No SDK integration is required on the client side.
How WalletSuite implements this
WalletSuite's MCP Server exposes on-chain wallet operations across every supported blockchain, letting AI agents query balances, resolve tokens, prepare transfers, sign, and broadcast through natural-language prompts.
Start Building →AI Wallet Agent
An AI wallet agent is an autonomous or semi-autonomous software agent powered by a large language model that can interact with blockchain wallets on behalf of a user or another system. It checks balances, prepares transactions, and manages on-chain assets using natural-language instructions.
Unlike traditional wallet UIs, AI wallet agents accept natural-language instructions and translate them into wallet operations. They typically connect to wallet infrastructure via MCP or direct API calls. Key design constraints include transaction safety (agents prepare but do not sign by default), policy gates that restrict which operations an agent can perform, and multi-chain resolution so the agent handles chain selection automatically.
How WalletSuite implements this
WalletSuite's MCP Server turns any Claude, GPT, or custom LLM agent into a wallet agent with band-filtered permissions and policy-gated signing.
Build an AI wallet agent →Multi-Chain Wallet
A multi-chain wallet is a wallet that manages keys, balances, and transactions across multiple blockchains from a single interface or API, rather than requiring separate wallet software for each network.
Multi-chain wallets solve the fragmentation problem: without one, a business handling Ethereum, Solana, and Bitcoin needs three separate integrations with different data formats, signing schemes, and fee models. A unified multi-chain wallet normalizes these differences behind a consistent data model with standardized balance queries, transaction construction, and token resolution.
Wallet as a Service (WaaS)
Wallet as a Service is a cloud-hosted model where a provider manages the full wallet stack (key generation, custody, signing, and transaction submission) so that businesses can offer wallet functionality to their users without operating their own key infrastructure.
WaaS serves fintech apps, exchanges, and neobanks that want to add crypto features without the operational burden of key management and HSM provisioning. The service boundary typically sits between the application layer (UI, business logic) and the cryptographic layer (key derivation, signing). WaaS providers offer APIs for account creation, policy-based access controls, and audit-ready logging.
Transaction Construction
Transaction construction is the process of building an unsigned blockchain transaction before it is signed and broadcast to the network. It involves selecting inputs, encoding calldata, estimating gas or fees, and setting chain-specific parameters.
Each blockchain has its own transaction format: Ethereum uses RLP-encoded transactions with gas estimation, Bitcoin uses UTXO selection, and Solana uses instruction-based messages. A wallet infrastructure provider normalizes this complexity behind a single prepare_transfer or build_transaction call. The output is an unsigned payload that the caller signs with their own key, maintaining custody separation. Proper construction also includes nonce management, fee priority estimation, and token contract resolution.
Token Resolution
Token resolution is the process of mapping a human-readable token identifier (such as a symbol like USDC or a name like 'USD Coin') to the exact contract address and chain where that token is deployed, handling ambiguity when the same symbol exists on multiple chains.
Token symbols are not unique: USDC exists on Ethereum, Solana, Polygon, Arbitrum, and dozens of other chains, each at a different contract address. Token resolution verifies the asset against a curated registry, returns the canonical contract address for the target chain, and flags ambiguous matches so the caller can choose. This prevents misrouted transfers, one of the most common and costly errors in both programmatic and AI-driven wallet operations.
Policy Gate
A policy gate is a rule that restricts what an AI agent or API consumer can do with a wallet. Policies define allowed chains, spending caps, expiry windows, and required confirmations before a signing or broadcast operation proceeds.
Policy gates sit between the request and the signature. When an agent calls sign_transaction or send_transaction, the system checks the request against the policy bound to that wallet and agent token. If the request violates a rule (wrong chain, expired token, over budget), the operation is denied before any signature is produced.
How WalletSuite implements this
WalletSuite evaluates policies in both signing modes. In MPC mode, the co-signing service refuses to release its share when policy is violated. In OWS opt-out mode, policies live as JSON documents in the encrypted vault alongside the wallet they protect.
Band Filtering
Band filtering is a permission model that groups wallet operations into escalating tiers (read, prepare, sign, broadcast) and exposes only the tiers you enable. An agent configured with read and prepare bands cannot sign or broadcast, regardless of what it requests.
The four bands form a progression: read lets an agent query balances, prices, and transaction history. Prepare adds the ability to build unsigned transaction payloads. Sign unlocks local key decryption and signature generation. Broadcast allows submitting signed transactions to the network.
How WalletSuite implements this
WalletSuite's MCP Server resolves active bands at startup by intersecting the configured bands with the agent token's allowed bands, so neither side can escalate beyond what the other permits.
Non-Custodial Wallet
A non-custodial wallet is a wallet where no single party can move funds unilaterally. The user (or a quorum that includes the user) holds the cryptographic material required to sign, and the wallet software facilitates transactions without ever taking sole possession of the keys.
Non-custodial wallets shift security responsibility to the user: if all key material is lost, the funds are unrecoverable. This tradeoff is accepted because it eliminates counterparty risk. Modern non-custodial architectures include 2-of-2 MPC (where the wallet provider and the user each hold a share, and both signatures are required) and self-hosted local signing (where the user holds the entire key).
How WalletSuite implements this
WalletSuite is non-custodial by architecture: the customer always owns their funds. Default at paid tiers is 2-of-2 MPC — the signing share is split so a compromise on either side can't move money. Self-hosted Open Wallet Standard (OWS) is available as an opt-out for HFT and regulated environments.
Wallet SDK
A wallet SDK is a client library that provides typed functions for wallet operations (key derivation, signing, balance queries, transaction building) so developers can integrate wallet functionality without making raw API calls or handling low-level cryptography.
A good wallet SDK abstracts chain differences behind a consistent interface: the same method signatures work whether the underlying chain uses ECDSA or Ed25519 signing, UTXO or account-based transactions.
How WalletSuite implements this
WalletSuite's SDK is a TypeScript package with full type coverage. It shares types with the MCP Server, so tool schemas and SDK method signatures stay in sync.
Gas Abstraction
Gas abstraction hides the complexity of blockchain transaction fees from the end user or calling application. Instead of requiring the caller to hold the native token, estimate gas limits, and set priority fees, the infrastructure handles fee calculation and payment behind the scenes.
Without gas abstraction, every transaction requires the sender to hold the chain's native token (ETH on Ethereum, SOL on Solana) in sufficient quantity to cover the fee. This creates onboarding friction and multi-token management overhead. Gas abstraction can take several forms: the infrastructure estimates and includes fees automatically, a paymaster contract sponsors the gas, or the fee is deducted from the transferred token via a meta-transaction.
How WalletSuite implements this
WalletSuite's API handles fee estimation and gas optimization as part of transaction construction.
Key Derivation
Key derivation is the process of generating multiple private keys from a single seed or mnemonic phrase using a deterministic algorithm. Each key maps to a unique blockchain address, and all keys can be recreated from the original seed.
The dominant standard is BIP-44, which defines a hierarchical path format: m/purpose'/coin_type'/account'/change/index. For example, m/44'/60'/0'/0/0 produces the first Ethereum address, while m/44'/195'/0'/0/0 produces the first Tron address from the same seed. This lets a single 12- or 24-word mnemonic back up wallets across many chains.
How WalletSuite implements this
WalletSuite's OWS vault uses BIP-39 mnemonics with BIP-44 derivation paths, generating chain-specific keys from one seed per wallet.
HD Wallet (Hierarchical Deterministic)
An HD wallet generates a tree of key pairs from a single root seed, following the BIP-32 standard. Any branch of the tree can derive child keys without exposing the parent key, and the entire tree can be restored from the original mnemonic.
The hierarchy enables organizational structure: one branch per blockchain, one sub-branch per account, one leaf per address. This is more practical than storing independent keys for every address, because a single backup (the mnemonic) covers all current and future addresses. HD wallets are the foundation of most modern wallet software.
How WalletSuite implements this
WalletSuite's OWS vault creates HD wallets with 12-word BIP-39 mnemonics and derives chain-specific keys using standard BIP-44 paths.
Open Wallet Standard (OWS)
The Open Wallet Standard is an open-source framework that gives AI agents a secure, universal way to create wallets, sign transactions, and interact with blockchains without ever exposing private keys to the agent process. It standardizes local key generation, encrypted storage, and policy-gated signing across multiple chain families.
OWS was launched in March 2026 by MoonPay with backing from PayPal, Circle, the Ethereum Foundation, the Solana Foundation, and 20 other organizations. It generates a single BIP-39 mnemonic and derives accounts across 10 chain families (EVM, Solana, Bitcoin, Cosmos, Tron, TON, Sui, Spark, Filecoin, XRP Ledger) via BIP-44 paths. Keys are encrypted at rest using AES-256-GCM in the Keystore v3 format (MetaMask-compatible), stored locally at ~/.ows/. The policy engine evaluates every signing request before any key is decrypted, enforcing chain restrictions, spending limits, time-bound authorizations, and contract allowlists. All policies use AND semantics — the first denial short-circuits the request.
How WalletSuite implements this
WalletSuite's MCP Server integrates OWS as an optional signing layer. When enabled (OWS_ENABLED=true), four tools are added across two bands: create_wallet, get_wallet_address, and sign_transaction in the sign band, plus send_transaction in the broadcast band.
Learn about OWS →Custody Model
A custody model defines who can produce a signature for a wallet. The main models are self-custody (user holds keys), custodial (a third party holds keys), and hybrid (keys are split between parties via MPC or multisig so no single party can sign alone).
The choice of custody model affects security, compliance, and user experience. Self-custody eliminates counterparty risk but puts full responsibility on the user. Custodial solutions simplify the user experience but introduce trust requirements and regulatory obligations. Hybrid approaches like 2-of-2 MPC (multi-party computation) split the key so neither the provider nor the user can sign alone — both signatures are required.
How WalletSuite implements this
WalletSuite supports two non-custodial paths. Default at paid tiers: 2-of-2 MPC (WalletSuite holds one share, customer holds the other). Opt-out for HFT and regulated environments: self-hosted OWS (keys fully on customer infrastructure).
Multi-Party Computation (MPC)
Multi-party computation is a cryptographic technique that lets two or more parties jointly produce a digital signature without ever assembling the full private key in one place. Each party holds a key share; the signature is computed across shares.
MPC removes the single-point-of-compromise problem of traditional key custody. In a 2-of-2 setup, both parties must participate in every signature — neither party alone can produce a valid signature. DKLS23 is a modern threshold ECDSA scheme that produces signatures indistinguishable from single-key ECDSA, with sub-second compute and small bandwidth (under 1KB per round).
How WalletSuite implements this
WalletSuite uses 2-of-2 DKLS23 MPC as the default signing architecture at all paid tiers. WalletSuite's co-signing service holds one share; the customer holds the other — a compromise on either side can't move funds. OWS is the opt-out path for HFT trading agents that need sub-millisecond local signing.
Agent Token
An agent token is a scoped credential issued to an autonomous agent process, binding the agent to a specific wallet, a band cap (read, prepare, sign, broadcast), and a policy set (chain allowlist, spend limits, expiry). The agent never sees private keys; it presents the token, and the wallet infrastructure enforces what the token is allowed to do.
Agent tokens decouple authority from identity. A team can run dozens of agents — strategy bots, treasury managers, operator consoles — each with its own token bound to a different wallet, band cap, and policy. Tokens are revocable independently of the underlying wallet, so rotating an agent's authority means deleting a token, not redeploying. Tokens carry their policy at issuance: if a token has chains [Ethereum, Polygon] and a $1k daily cap, those constraints follow the token wherever it goes.
How WalletSuite implements this
WalletSuite issues agent tokens via the API or owner-mode MCP session. Each token is bound to a specific wallet, a band cap, and a policy at issuance time. The MCP Server intersects the token's bands with its session bands at startup, so neither side can escalate beyond what the other permits. Token rotation is a new token, not a redeploy.
Hash-Chained Audit Trail
A hash-chained audit trail is a log where each event includes a cryptographic hash of the previous event, forming a verifiable chain. Editing any past event breaks the chain and is detectable on inspection — which is why this property is called tamper-evident, not tamper-proof.
Hash chaining gives log integrity without distributed consensus or hardware-enforced storage. Each entry — a signing decision, a policy evaluation, a broadcast — is recorded with the SHA-256 hash of the prior entry. Reviewers can replay the chain to verify nothing was altered after the fact. The format is JSONL (one JSON object per line): append-only by writing convention, human-readable, and exportable to SIEM tools (Splunk, Datadog) without transformation.
How WalletSuite implements this
WalletSuite writes hash-chained JSONL events for every sign, broadcast, policy pass, and policy denial. SHA-256-chained, append-only, single-writer. Self-hosted (OWS) deployments write to ~/.walletsuite/audit-trail.jsonl; hosted deployments expose the same events via the audit API.
Per-Mandate Execution
Per-mandate execution is the pattern where each autonomous agent receives a separate, narrowly-scoped credential — one token per strategy, sub-treasury, or trading book. The agent's authority is bounded at issuance to a specific asset universe, chain set, spend ceiling, and time window.
Treasury teams, market makers, and DAO labs use mandates to define what an automated process is allowed to do. Without mandate-bound credentials, every automated process shares the same wallet authority — a single compromise affects everything. Per-mandate execution scopes each process to its mandate via an independent agent token, so a compromise on one agent can't reach assets outside that mandate. Common mandate dimensions: asset allowlist, counterparty allowlist, per-tx and daily spend caps, and the expiry window after which the token must be re-issued.
How WalletSuite implements this
WalletSuite supports per-mandate execution via scoped agent tokens. Each token is bound at issuance to a specific wallet, band cap, asset allowlist, chain allowlist, spend ceilings, and expiry. Tokens are independently revocable; rotating an agent's mandate is issuing a new token, not redeploying.
Family office digital asset operations →Hosted MPC
Hosted MPC is a deployment model for multi-party computation signing where the wallet provider operates the co-signing service alongside the customer. The customer holds their own MPC share; the provider holds the other. Both signatures are required for every transaction, and the customer never operates signing infrastructure themselves.
Hosted MPC contrasts with self-hosted MPC (customer runs both shares) and traditional custody (provider holds the entire key). It gives mainstream developers the security property of MPC — no single party can sign alone — without the operational burden of running a co-signing service.
How WalletSuite implements this
WalletSuite's hosted MPC uses 2-of-2 DKLS23. The co-signing service runs on WalletSuite infrastructure with HSM-backed share storage and KMS envelope encryption. The customer's share is held by the customer's authentication context. Both shares are required to produce a signature.
Spend Governance
Spend governance is the layer that decides whether a specific signing operation should proceed — combining band filtering (which tools the agent can call), policy gates (chain allowlist, spend limits, expiry), and agent tokens (the credential carrying the policy set) into a single evaluation before any signature is produced.
Without spend governance, autonomous agents either get full wallet authority (high risk) or no signing authority (low utility). Spend governance sits between the agent's request and the signing service. An agent calls sign_transaction; the governance layer intersects the agent's token with the active policy and the requested operation. If any rule rejects, signing never happens — the request fails with a structured error and lands in the audit trail as a denied event.
How WalletSuite implements this
WalletSuite evaluates spend governance in both signing modes. In hosted MPC, the co-signing service refuses to release its share when policy is violated. In self-hosted OWS, the policy gate evaluates before the vault decrypts. Either way, no signature is produced for an out-of-policy request.
Flexible Signing
Flexible signing is a wallet architecture where policy, approval, audit, and automation logic are decoupled from the signing backend, so teams can change which signer handles a transaction (hosted MPC, self-hosted vault, external signer, customer HSM/KMS) without rebuilding governance.
Most wallet platforms tie governance to a single signing model: change the signer and you lose your policies, approvers, and audit evidence. Flexible signing inverts the model — governance is the stable layer, and signing is a pluggable backend. The same policy engine, approval workflow, and evidence pipeline runs whether the transaction is signed by hosted MPC, by self-hosted OWS, by an external signer through a signed-payload workflow, or by a customer-controlled HSM. Teams can mix signers per workflow, migrate over time, or run several in parallel for different products.
How WalletSuite implements this
WalletSuite is built around flexible signing as a core platform property. WalletSuite MPC and self-hosted OWS are first-class signing options; signed-payload workflows let teams plug in external signers, custodians, or customer-controlled HSM/KMS infrastructure under the same policy and evidence model.
Why WalletSuite →Signed-Payload Workflow
A signed-payload workflow is an integration pattern where the wallet platform prepares an unsigned transaction payload and emits it to an external signer (custodian, HSM, KMS, hardware wallet), which produces the signature out-of-band. The platform never holds the signing key but still applies policy, approvals, and evidence to the transaction.
Many enterprise teams already have a signing path they trust — Fireblocks, Turnkey, AWS KMS, an on-premise HSM, Ledger, or a Safe multisig. Signed-payload workflows let those teams keep their signer and add a governance and evidence layer on top. The platform builds the unsigned payload, evaluates policy, routes approvals, and emits the payload to the external signer; the signature returns and the platform broadcasts and records the result. The signer never sees policy logic; the platform never sees the key.
How WalletSuite implements this
WalletSuite supports signed-payload workflows for any external signer. The platform prepares unsigned payloads, evaluates policy, routes approvals, and accepts signatures back from the external signer. The same policy engine and Evidence API record the operation regardless of which signer produced the signature.
Tenant Governance
Tenant governance is the pattern where a multi-customer wallet platform isolates wallets, policies, approvers, limits, agent tokens, audit logs, and evidence exports per customer (tenant), so that one merchant, fund, business unit, or workspace cannot see or affect another.
Payment platforms, stablecoin platforms, RWA platforms, and treasury products often serve hundreds of customers from one backend. Without tenant governance, every operational change — a new policy, a new approver, a higher daily cap — risks crossing customer boundaries. Tenant governance defines a hard isolation surface: each tenant has its own wallets, policy set, approver roster, agent tokens, audit trail, and evidence exports. Operational APIs and admin UIs operate within a tenant scope; cross-tenant queries require explicit operator-level authority.
How WalletSuite implements this
WalletSuite is tenant-scoped at every layer: wallet, policy, approval, agent token, audit log, and evidence export. Customers use this to embed governed wallet operations into their own products under their own brand without building a control plane from scratch.
Payment platforms →Evidence API
The Evidence API turns wallet operations into structured, exportable receipts. Each receipt captures the facts of a transaction together with the policy version that approved it, the rules that matched, the approval trail, the signer path, and the hash-chain link to prior events.
Audit reviewers, compliance teams, and customer-facing reporting surfaces need more than a transaction hash. The Evidence API attaches decision context to every operation: tenant ID, wallet ID, policy version, policy hash, matched rules, decision reason, approval trail, signer path, KYT pre-check result, broadcast status, and the prior-event hash. Receipts are queryable by tenant, wallet, time range, or policy outcome, and exportable as JSONL for SIEM ingestion or evidence packets for regulators.
How WalletSuite implements this
WalletSuite emits an Evidence API record for every policy evaluation, signing decision, and broadcast outcome. Records are hash-chained, tenant-scoped, and exportable through the same endpoint customers use to surface activity to their own end users.
Policy Receipt
A policy receipt is the structured record produced when a policy gate evaluates a wallet operation. It captures the policy version and hash, the matched rules, the decision (approve, deny, requires-review), the decision reason, the approval trail, and the signer path that was authorized or refused.
A signature alone proves a transaction happened. A policy receipt proves why it was allowed to happen. Receipts attach to every operation — approved and denied — so audit reviewers can replay how a decision was made under the policy version that was active at the time. Combined with a hash-chained audit trail, receipts give tamper-evident proof of governance, not just execution.
How WalletSuite implements this
WalletSuite emits a policy receipt for every policy evaluation through the Evidence API. Each receipt links to its hash-chained audit entry so the receipt and the underlying event verify together.
Shadow Control
Shadow Control is an adoption mode where WalletSuite policy evaluation runs alongside an existing backend rule set without enforcing decisions. Each transaction is evaluated by both systems; outcomes are compared and recorded as evidence, but the existing rules remain authoritative until the team chooses to switch enforcement on.
Migrating wallet governance from in-house scripts to a productized layer is risky — a misconfigured policy can deny legitimate transactions or pass dangerous ones. Shadow Control de-risks the migration by letting the new policy engine evaluate every transaction in parallel, emitting approve, deny, or requires-review verdicts that are stored as evidence but not acted on. Teams compare verdicts side by side, fix divergences, and only switch enforcement on once the policy behavior is trusted.
How WalletSuite implements this
WalletSuite ships Shadow Control for enterprise design partners. The policy engine runs against every transaction the existing system processes; verdicts and divergences land in the Evidence API for review, while the existing rules continue to gate signing and broadcast.
ERC-4337 (Account Abstraction)
ERC-4337 is the Ethereum standard for account abstraction — letting smart contracts act as wallets without changing the protocol layer. It enables features like social recovery, batch transactions, paymasters (gas sponsorship), and session keys.
Account abstraction separates the signing key from the wallet account. ERC-4337 introduces UserOperation objects that bundle intent, signature, and gas payment, validated by an EntryPoint contract. For AI agents, ERC-4337 lets a single smart-account wallet have multiple session keys with different policies — one for the agent, one for the human — with gas paid by a paymaster instead of the agent holding ETH. The EntryPoint contract is deployed at the same address on every EVM chain that supports the standard, simplifying multi-chain agent wallets.
EIP-712 (Typed Structured Data)
EIP-712 is the Ethereum standard for signing typed structured data — letting wallets show users a human-readable description of what they're signing, instead of an opaque hex blob.
EIP-712 defines a deterministic encoding of structured JSON data for signing. Wallets can display the actual fields (recipient, amount, expiry) rather than just a hash. Critical for agent wallets: when a policy gate or audit log records what was signed, EIP-712 makes the payload diffable and human-reviewable. Used heavily by Permit2, Safe transactions, and any modern dApp that asks users to sign off-chain messages with on-chain effects.
CAIP-2 (Chain ID Standard)
CAIP-2 is a Chain Agnostic Improvement Proposal that defines a standard string format for identifying blockchain networks — for example, eip155:1 for Ethereum mainnet, eip155:42161 for Arbitrum One, solana:mainnet for Solana mainnet.
Without a chain identifier standard, every wallet API has its own naming (eth-mainnet vs ethereum vs 1), and policy rules become brittle. CAIP-2 lets a policy say allowed_chains: ['eip155:1', 'eip155:8453'] unambiguously across vendors. The format is namespace:reference where the namespace identifies the chain family (eip155 for EVM chains, solana, bitcoin, etc.) and the reference identifies the specific network within that family.
Chain Allowlist
A chain allowlist is a policy primitive that restricts an agent or wallet to a pre-approved set of blockchain networks, denying transactions on any chain not on the list before a signature is produced.
Implemented at the policy gate layer (server-side, before signing). Common pattern: a treasury wallet's agent token only allows Ethereum mainnet and Arbitrum One; a request to send funds on an unauthorized chain hits the policy gate, gets denied, and is logged to the hash-chained audit trail. Combined with band filtering, this means an agent that's compromised — by prompt injection, supply-chain attack, or runaway loop — cannot redirect funds to attacker-controlled chains because the chain identifier doesn't match the policy.
Prompt Injection Defense
Prompt injection defense is the set of techniques that prevent attacker-controlled input — embedded in user prompts, document content, tool outputs, or web pages — from making an AI agent take actions the operator didn't authorize.
For agent wallets, the canonical defense is band filtering at MCP server startup: if the signing tool isn't registered in the agent's tool registry, no prompt can call it, no matter how cleverly crafted the injection. Layered defenses include policy gates evaluated server-side (chain allowlist, spend caps, expiry), structured outputs that don't pass through the LLM, and hash-chained audit logs that record every action the agent attempted (denials are evidence too). The architectural principle: don't try to make the LLM resist injection; make the systems below the LLM unable to honor a malicious instruction even if the LLM is fooled.
x402 (Agent Payment Protocol)
x402 is an HTTP-based payment protocol that lets services charge AI agents per-call using stablecoins, by responding with HTTP 402 Payment Required and a payment quote that the agent signs and broadcasts on-chain before retrying.
x402 turns the underused HTTP 402 status code into a payment handshake. The agent makes a request; the server responds 402 with a quote (asset, amount, recipient, expiry); the agent signs and broadcasts the payment on a fast chain (typically USDC on Base or another L2); the agent retries the request with a payment proof header. Designed for agent-to-API and agent-to-agent commerce where account creation and API key issuance don't make sense, and where the marginal cost per call is small enough to settle on-chain.
A2A (Agent-to-Agent Protocol)
A2A is an open protocol for autonomous AI agents to discover, authenticate, and exchange tasks with each other across different vendors, frameworks, and runtimes — the agent-to-agent counterpart to MCP's agent-to-tool.
Where MCP standardizes how an agent talks to tools and data, A2A standardizes how one agent delegates a task to another. It defines capability advertisement, task lifecycle, and structured outputs, so a CrewAI agent can commission a LangChain agent without bespoke integration. For wallet operations, A2A becomes relevant when one agent (a research agent that knows what should happen) needs to commission another agent (an execution agent that owns a wallet and can sign). Each agent runs with its own bands and policy; the boundary between them is the A2A task contract.
