§21 On-Chain Wallets and Micropayments for Agents

In 2024 Coinbase released AgentKit; in 2025 x402 bound HTTP requests to on-chain micropayments—autonomous programs in the fiat system still must open accounts, sign, and pass KYC. An on-chain wallet encodes “who may spend” as programmable signing authority, balance caps, and spending policies; payment shifts from “click to confirm” to the automatic execution of micropayments, streaming charges, and contractual splits.

Section 1 The Agent as Economic Subject

Traditional accounting and law assume that a “subject” is a natural or legal person. An Agent’s running instance is neither an independent legal person nor, in fact, merely idle: it initiates requests, consumes resources, and generates payables. Treating it as a pure tool means every act is immediately attributed to the deployer—simple but crude: one mistaken call may trigger tens of thousands of downstream API charges, and ex post attribution cannot restore the causal chain of each call. Treating it as a quasi-subject means giving the Agent a constrained on-chain identity: an independent address, an independent balance cap, an independent audit log. The deployer still bears ultimate responsibility, but internally one can distinguish “which Agent, which task, which outlay.”

In silicon-based settings the carrier of monetary discipline must shift in part from institutional reputation to verifiable rules. “Verifiability” stands alongside Menger’s “saleability” as a second dimension of monetary emergence—monetary emergence ≈ saleability ranking × verifiability threshold; silicon coordination pushes the latter threshold to the millisecond. Against frontier designs by three carriers—reputation, stake, and parameters: x402 and agentic commerce sit at the reputation layer; DePIN slash at the stake layer; ERC-4337 whitelists and PCIM collateral ratios at the parameter layer. The verifiability gradient of the three may be summarized as:

At the payment layer, whether an Agent enters the default settlement set depends, at the margin, more on whether spending policy, collateral state, and transaction history can be re-checked by a program than on whether a custodian’s brand is loud. The Agent wallet is the payment interface of this shift: reputational constraint rests on “trust that Stripe will not debit wrongly”; verifiable constraint rests on “any auditor can, at block height H, re-read transfer events and spending-policy bytecode.” The higher the frequency of silicon coordination, the greater the marginal value of the latter.

An on-chain address supplies a lightweight subject identifier. On Ethereum and compatible chains, an externally owned account (EOA) is controlled by a private key; a contract account is controlled by code. Agent practice commonly uses three modes: a custody service holds the EOA key and the Agent requests signatures via API; a smart-contract wallet (e.g. Safe multisig, ERC-4337 account abstraction) expresses spending rules in code—the Agent submits only an “intent,” and the contract decides whether to execute; a session key signs for the main wallet within a limited time and amount and is revoked when the task ends. The three modes trade security against autonomy differently; there is no universally optimal solution, only a match to the business setting.

Another element of economic subjectivity is metering. The API economy already bills by call count, token count, and gigabyte-month of storage. Native on-chain metering can bind “consumption” to “payment”: when calling a data interface, the client simultaneously sends a stipulated quantity of VRC-20 quota tokens or a tiny amount of stable settlement asset to the server address (VRC-10 Bitcurrency for Openverse; protocol-neutral counterparts USDC/DAI); the server contract returns data after verifying receipt. The unit of account moves from a platform’s internal ledger to a verifiable on-chain event, laying the foundation for machine-to-machine (M2M) settlement.

Section 2 Machine-to-Machine Settlement (M2M)

M2M settlement means value transfer completed by programs under preset rules, without step-by-step human approval. “Automatic debit after goods receipt” in supply-chain finance is already an embryonic form of M2M, except that the subjects remain corporate legal persons. In the Agent era, M2M granularity can refine to a single inference, a single log retrieval, a single geocode—amounts that may fall below the minimum fee unit of traditional payment systems, producing the inversion “payment amount smaller than transaction cost.”

Since 2024, x402 (HTTP 402 micropayments), Coinbase AgentKit (on-chain tooling for Agents), and Visa/Mastercard agentic commerce pilots have approached the same problem from the Web-protocol layer, the custodial-wallet layer, and the card-network layer respectively: letting silicon subjects complete small settlements without stepwise human authorization. Anthropic’s Model Context Protocol (MCP, Nov 2024 specification) and Google’s Agent2Agent (A2A, 2025) standardize tool calls and task delegation at the orchestration layer—payment semantics still must be closed separately by AP2/x402 and the like¹. The core six-line comparison (x402, AgentKit, agentic commerce, DePIN three networks, M2M/ISO) is taken up below by M2M stack position with engineering detail.

x402 was open-sourced by Coinbase in May 2025; in September of the same year Coinbase and Cloudflare co-founded the x402 Foundation. The server returns HTTP 402 with a PAYMENT-REQUIRED header; the client Agent signs and retries with a PAYMENT-SIGNATURE header; a facilitator completes on-chain settlement in USDC or similar stables—payment and the HTTP call share a frame, but constraint still hangs on facilitator reputation and compliance review, not on independently re-checkable on-chain rules such as collateral ratios¹. AgentKit (CDP, Nov 2024) offers framework-agnostic on-chain action providers; integrated with x402, Agents can pay autonomously, but wallet custody reintroduces reputational constraint. The differentiating margin among the three is verifiability—whether each call can be independently replayed by a third party, and whether spending policy is on-chain readable. Against Openverse: VTP messages + VRC-20 per-call quotas + contract whitelists aim to embed x402’s “pay per request” in an auditable multi-layer asset standard; that combination is an engineering proposal, pending mainnet and compliance-interface measurement.

The table below summarizes mainstream schemes by M2M stack position, stressing differences in constraint carrier; the same logic holds for ERC-20/USDC; Openverse is listed as a design-instance contrast.

On-chain micropayments try to break the amount inversion. Layer-2 rollups, state channels, and payment channels batch many small transfers to the main chain, spreading Gas cost; Openverse documentation layers a Layer 0 value-exchange layer and Layer 1 application chains—high-frequency business on Layer 1, final settlement and cross-domain routing anchored at Layer 0, to lower per-settlement friction—that layering must not be conflated with x402’s already-running HTTP micropayment pilots; together with x402 embedding payment at the HTTP layer and AgentKit wrapping signatures at the application layer, they occupy different stack positions of the same problem. Honesty requires acknowledging: micropayments may still be uneconomic when public chains congest; permissioned consortia or enterprise private chains are often more pragmatic in closed settings—private-domain VRC-11 settlement logic applies especially here. What M2M micropayments seek is to compress value exchange to the same frequency as silicon calls.

The credit model of M2M settlement differs from credit-card pre-authorization. On-chain settlement is usually “pay then service” or “atomic swap”: either payment and delivery complete in the same transaction (coupled by smart contract), or an escrow contract releases funds when conditions are met. The latter structure matters especially for Agents orchestrating complex service chains—user funds lock in the contract; sub-Agents claim shares by milestone, avoiding the chain risk of “upstream paid, downstream absconds.” Escrow and multisig are the default governance means for multi-Agent collaboration.

If the marginal advantage of on-chain M2M over x402/AgentKit is verifiability, then under the same API vendor and similar call volumes, firms using on-chain per-call settlement should show a lower per-call cost-attribution error rate $\epsilon_{\mathrm{attrib}}$ (the share of month-end reconciliation that cannot be matched to a concrete Agent task) than firms relying only on centralized bills—measurable in 12–24 month pilots by “task ID ↔ on-chain tx hash mapping completeness.” Observable metrics include $\epsilon_{\mathrm{attrib}}$, Gas as a share of call fees $\gamma_{\mathrm{gas}}$, and custodial Agent mispay rate $r_{\mathrm{mispay}}$ (AgentKit-class controls). If $\epsilon_{\mathrm{attrib}}$ shows no significant difference, the comparative advantage of on-chain M2M should be narrowed to compliance-audit settings, and claims of general efficiency gains should be withdrawn.

Testable proposition (frequency threshold): If constraint carriers migrate toward parameter/stake layers as M2M coordination frequency $f$ rises, then after enterprise Agent call frequency exceeds a threshold $f^*$ (e.g. daily mean >10⁴ calls per API product line), the marginal adoption rate $\Delta_{\mathrm{adopt}}$ of parameter-layer schemes (4337 policy contracts, PCIM collateral queries) relative to reputation-layer schemes (AgentKit custody, x402 facilitators) should rise—measurable in 12-month A/B pilots by stack-switch share. If $\Delta_{\mathrm{adopt}}$ does not rise with $f$, the claim that “frequency drives constraint-carrier migration” should be narrowed, and one should instead test whether compliance cost $\kappa_{\mathrm{audit}}$ is the true driver.

Section 3 Custody, Multisig, and Spending Policy

When enterprises configure on-chain wallets for deployed Agents, they ordinarily should not hand the main Treasury private key directly to the program. A common architecture is layered: the main Treasury holds large reserves under human multisig; an operational hot wallet holds day-to-day liquidity with limited quota; each Agent instance or Agent class holds a sub-account or sub-contract funded from the hot wallet by policy. Sub-account rules may encode: daily spend caps, per-transfer caps, transfers only to whitelisted contracts, no transfers to personal addresses, no calls to unaudited approve functions, and so on.

Multisig transforms “signing” from a biometric ritual into on-chain cryptographic consensus. Finance and operations each hold a key; abnormal Agent transfers cannot take effect unilaterally. This is akin to traditional dual-control bank–enterprise links, yet unbound by business hours, and the rules are publicly inspectable—internal audit and external supervisors can verify whether multisig policy has been tampered with, rather than trusting only a bank-issued PDF statement.

A smart-contract wallet’s “spending policy” may also include timelocks and pausable switches: when Agent behavior looks anomalous, a guardian can pause the sub-account in one click without waiting for bank support hours. By contrast, freezing a fiat account often requires judicial or regulatory process, with response times measured in days; on-chain pause is a self-rescue mechanism the deployer voluntarily embeds. Legal-effect boundaries still await case law, but engineering-wise it is already a standard requirement of enterprise secure operations.

Section 4 Micropayments and Streaming Payments

Micropayment means a single settlement of a tiny amount—typical scenes include per-call APIs, per-page content, per-second compute. Streaming payment releases continuously over time: e.g. transferring 0.001 dollars’ worth of tokens each second to a content provider; when the user stops consuming, payment stops, without prepaying a full monthly subscription. Combined, the two express a “pay for what you use” economic relation, close to the elastic usage essence of silicon systems.

Three main technical paths exist. State channels: parties exchange signed tickets off-chain and touch the chain only when opening or closing the channel—suited to high-frequency interaction with fixed counterparties. Sidechains or Layer 2: batch micro-transfers on a rollup and periodically anchor main-chain security. Direct on-chain micro-transfers: on networks with low enough fees, a simple transfer can stand—suited to permissioned or intra-enterprise chains.

In Agent orchestration, streaming payment can bind to “session lifetime”: the user opens a dialogue with an Agent and simultaneously opens a payment stream to the service provider; when the dialogue ends or times out, the stream closes automatically. This is fairer than “prepaid monthly membership” and more transparent than “ex post aggregated bills.” Implementation depends on wallet and front-end support for “streaming payment protocols”—Superfluid, Sablier, and similar Ethereum-ecosystem tools already supply precedents; Openverse documentation has envisioned folding similar semantics into VRC standards to reduce integration fragmentation; at the protocol-neutral layer one may also call existing Ethereum streaming contracts directly. Streaming payment splits “purchase” into continuous fragments synchronized with consumption, closer to elastic usage than monthly prepay.

Regulatory touchpoints of micropayments must not be ignored: large volumes of tiny cross-border transfers may be flagged by AML systems as structuring. Enterprises must set minimum retention records, counterparty whitelists, and suspicious-pattern alerts within a compliance frame—on-chain auditability here is an aid, not an exemption.

Section 5 Automatic Split via Smart Contract

When multiple Agents or multi-party services jointly complete one delivery, how is revenue shared? The traditional approach relies on ex post contracts and manual splits—high friction, many disputes. A smart contract can, at the instant of receipt, split funds to multiple addresses by preset shares: platform cut 10%, data provider 30%, compute provider 40%, orchestrating Agent operator 20%—ratios written in code; the caller need not trust the platform’s honest ex post bookkeeping.

Automatic splits fit naturally with fungible tokens such as VRC-20: the receiving contract takes a stable settlement asset (VRC-10 Bitcurrency or VRC-11 Privcurrency as Openverse reference instances; protocol-neutral counterparts USDC/DAI or enterprise private-domain stables) and maps it by shares to beneficiaries; if a party must receive a specific utility token (e.g. API quota coin), the split logic can become multi-asset output. NFTs (VRC-721) may also participate: only addresses holding a specific capability credential may claim a share—used for “exclusive data sources” or “exclusive device time slots” and other non-fungible scenes.

For Agent platforms, automatic splits lower the trust cost of ecological cold-start: third-party skill developers are willing to integrate because on-chain rules guarantee a verifiable revenue share after each call, without fear that the platform will rewrite backend split ratios. The logic matches app stores and ad networks, but the execution layer sinks from the platform database to contract bytecode—the platform may still upgrade the contract, yet the upgrade itself must be public on-chain, and holders have a chance to exit.

Section 6 On-Chain Auditability and Centralized API Bills

Stripe, AWS, Azure, and other centralized platforms provide detailed usage bills and invoices—friendly to enterprise finance and meeting paper requirements for tax deduction. Their limit is that the bill is a unilaterally generated, theoretically mutable record; audit must trust the platform’s internal controls; cross-platform aggregation requires manual reconciliation; cost attribution fine-grained to “a single Agent call” often requires buying extra log-analytics products.

The core advantage of on-chain settlement is independent verifiability—“execution–state–history” here becomes “any auditor can replay transfer events at block height H.” x402 and AgentKit push “ability to pay” to engineering usability; whether a third party can independently re-check payment rules and state is the key discriminant of verifiable constraint at the M2M layer—AgentKit packages wallets, on-chain tools, and policy templates, yet constraint still hangs on custodian reputation; ERC-4337 session keys + whitelist contracts write constraint into queryable state, closer to “verifiable rules.” The UNS addressing + contract whitelists envisioned in the Openverse whitepaper point the same way in engineering instances—whether they beat AgentKit must await mispay-rate and audit-cost comparison at comparable scale, not design-document assertion. In an Agent economy, if each tool call accompanies an on-chain micropayment, task-level cost equals the sum of related transactions, without trusting the orchestration platform’s internal allocation algorithm; replayable on-chain transaction logs give silicon value circulation machine-readable physical evidence.

Centralized billing’s advantages should not be slighted either: customer support, refund disputes, credit-card chargebacks, VAT invoice issuance—these “soft services” that on-chain systems cannot natively cover remain a platform’s competitive edge. The realistic path is hybrid: on-chain records hard settlement facts; off-chain platforms issue fiat invoices from on-chain snapshots; or enterprises settle in private-domain chains with VRC-11 and make a one-shot fiat FX declaration at month-end. Dual-layer accounting—“silicon sub-ledger on-chain, legal-person general ledger off-chain”—is the natural extension of the CFO frame to this setting.

Auditability also changes abuse detection. Centralized platforms can ban malicious users internally, opaquely; in on-chain mode, anomalous spending patterns can be monitored by anyone (within privacy permissions), and communities and insurers can develop risk-scoring products. The cost is privacy: fully transparent micropayments expose commercial strategy and user behavior; zero-knowledge proofs and permissioned chains become compromises—cryptographic detail is not pursued here; the tension between auditability and privacy will shape Agent-wallet product form.

Section 7 Risk One: Private Keys and Custody

The greatest technical risk of Agent wallets is private-key leakage. Humans can spot phishing mail; an Agent may read a private key from environment variables via a malicious page, a poisoned tool return, or a supply-chain-compromised dependency. Once leaked, on-chain assets are usually swept by automated scripts within minutes—unlike a credit card, one cannot call the bank to revoke.

Mitigations include: master keys never online, hot wallets with low balances, hardware security modules (HSM) or cloud KMS, contract wallets that restrict callable methods, and periodic rotation of session keys. Enterprises must bring Agent wallets under key-management procedures at the same tier as server certificates—many incidents stem from carrying “testnet key” habits into production.

Custodians offer compliance and insurance but reintroduce counterparty risk: users must trust the custodian not to misappropriate or be hacked. This resembles bank deposits, except that the regulatory frame is still immature. Self-custody retains cryptographic ownership but leaves operational risk entirely with the deployer. In Agent settings, pure self-custody is unrealistic for ordinary users; more feasible is “programmable custody”: the custody contract signs only when on-chain policy is met; the custody operator cannot see plaintext keys or move funds unilaterally.

Section 8 Risk Two: Prompt Injection and Rogue Tools

A distinctive risk of LLM Agents is prompt injection: attackers embed hidden instructions in web pages, mail, or database fields, inducing the Agent, while pursuing the user’s legitimate goal, to transfer funds, approve unlimited allowances, or sign malicious contract calls. Analogous to SQL injection, yet wired directly to the value layer—defense must cover input filtering, least-privilege tool permissions, and a hard rule that “value-transfer operations require human second confirmation.”

Rogue tools are forged APIs the Agent is induced to call: they return plausible data while routing funds to the attacker. Whitelisted tool registries, on-chain contract-address checks, and showing the user a “summary of the about-to-execute on-chain operation” are necessary engineering defenses. Fully autonomous Agent payment without human confirmation should exist only inside sandbox quotas with a clearly bounded loss upper limit.

“Autonomous Agent steals coins” is often painted in media as science-fiction catastrophe; the more common reality is misconfiguration and social engineering: developers hard-code keys into repositories, users grant Agents excessive permissions, phishing sites mimic wallet connect. Regulatory response may require that “autonomous payment” bind to a real-name subject and traceable logs, rather than a blanket ban—parallel to “substance over form” in token-fundraising regulation.

Section 9 Session Keys, Account Abstraction, and UNS Addressing

ERC-4337 account abstraction further decouples “signing authority” from “asset custody”: users or enterprises deploy smart-contract accounts; an EntryPoint contract validates UserOperations; Bundlers batch them on-chain. For Agents, spending rules become upgradeable policy modules—e.g. “auto-execute only when the call comes from a registered Agent-service IP range and the amount is below a threshold”—without waking human multisig each time.

Session keys are a lightweight variant of account abstraction: the main wallet authorizes a temporary key to sign within a limited time window, limited contract methods, and limited cumulative quota. After an Agent finishes one “research task,” the session key expires automatically; even if leaked, the main Treasury is not at risk. The logic resembles a credit card’s “single-use virtual number,” yet is enforced by an on-chain state machine without issuer human intervention.

UNS (Universal Name Service) addresses readable naming in Agent orchestration. Silicon subjects programming payments prefer transferring to addresses resolved from human-readable names rather than memorizing forty-two-character hex strings. Openverse documentation maps readable names to on-chain identifiers via UNS and links them to VTP routing messages—when configuring tool whitelists, an Agent may declare “pay Privcurrency only to addresses under permitted domains,” lowering mis-transfer risk. The protocol-neutral counterpart is ENS and similar on-chain name services; supply-chain private networks already name Privcurrency with enterprise brand prefixes (e.g. StarUSD); UNS extends the same naming logic to the cross-domain routing layer.

In deployment practice, enterprises should build a “policy template library” per Agent class: customer-service Agents allow only micro VRC-20 quota consumption; procurement Agents may pay VRC-11 to whitelisted supplier addresses (permissioned domain); R&D Agents may call external model APIs but require multisig approval for Bitcurrency outlays above a threshold (public-domain stable settlement). Templates map one-to-one to on-chain contracts; at audit one can compare “policy document” with “on-chain bytecode” directly—verifiability that traditional online-banking USB-key permission tables rarely provide.

Section 10 Fiat On-Ramps, Off-Ramps, and Dual-Track Accounting

Agent on-chain wallets and fiat accounts will coexist for a long time: wages, rent, and taxes still require fiat; on-chain micropayments suit machine-to-machine, intra-ecosystem, and programmable scenes. On/off-ramps, stablecoin mint/redeem, and banks’ cooperation with judicial freezes of on-chain flows form the transition layer between the two systems.

At deployment, enterprises should write on-chain wallet uses into dual-track compliance and engineering files: allow API settlement, forbid speculative trading; allow Privcurrency in-circle payment, forbid large transfers to non-KYC addresses—and execute against smart-contract whitelists, shrinking the crack between compliance and engineering.

On/off-ramps remain the bottleneck of silicon wallets. Compliant exchanges converting fiat to on-chain Bitcurrency or enterprise Privcurrency must complete KYC and source-of-funds review; the Agent itself cannot perform that ritual—a carbon-based guardian must complete it before deployment and set periodic fiat top-up rules for the hot wallet. At month-end reconciliation, on-chain micropayment flows can export as CSV mapped to ERP accounts—“silicon sub-ledger on-chain, legal-person general ledger off-chain” dual accounting requires CFO and engineering jointly to maintain the chart-of-accounts map, rather than treating the on-chain wallet as a simple substitute for a fiat account.

Dispute handling and chargeback have no native on-chain equivalent. Credit-card chargebacks protect consumers when the merchant fails to perform; on-chain transfers, once confirmed, are usually irreversible. Agent commerce therefore relies more on ex ante escrow, reputation deposits, and pausable contracts than on ex post bank mediation. If a platform offers users “Agent payment protection,” it must build off-chain reserves and arbitration rules and make clear in the UI the difference from on-chain irreversibility—lest users assume holding Bitcurrency enjoys the same protection as bank deposits.

Section 11 Engineering Deployment and Asset Selection

Enterprises deploying Agent on-chain wallets should start from a minimum viable configuration rather than stacking every module at once: a separate sub-account or session key per Agent class; spending policy written into auditable contracts; VRC asset whitelists and UNS resolution; fiat top-up cadence and month-end reconciliation—tool calls involving value transfer must require human second confirmation or a loss-capped sandbox; if any link is missing, the pilot may still start, but known risk should be logged. The wallet answers “who may spend, and how”; the machine-readable value layer must also clarify asset types—VRC-20 carries fungible utility, VRC-10/11 public- and private-domain stable settlement, VRC-721 permissions and slots, VRC-13 time commitments, chosen by counterparty domain, delivery tense, and scarcity. Agents’ default settlement path does not go through VRC-12 (Bitsecurity)—security tokens represent equity flow and require a securities-compliance frame; they are unfit as machine micropayment or everyday unit of account. Openverse instance parameters follow public documentation.