Infrastructure for AI Agents: Four Contracts for Wallets, Identity, Payments, and Settlement

A developer can add a wallet SDK, register an agent identity, protect an API with x402, and query a transaction receipt. That still does not produce a coherent agent-commerce stack.

The wallet may sign for an address that is not bound to the registered agent. The payment requirement may name a merchant destination that identity policy never evaluated. The transaction may confirm while the service remains undelivered. A bridge status may be described as settlement even though the application needs a different confirmation boundary.

Production infrastructure for AI agents connects wallets, identity, payment, and settlement without pretending they are one capability. Each needs an explicit contract: state it owns, inputs it accepts, evidence it emits, and failures it must report. The stack becomes safe enough to automate only when all four preserve shared invariants across one transaction.

Four Components Do Not Automatically Form One Stack

Wallet, identity, payment, and settlement systems answer different questions.

• Wallet: What authority can sign or submit this action?

• Identity: Which agent or service is acting, and which endpoints and trust signals belong to it?

• Payment: What value is required, what did the payer authorize, and did the payload satisfy the terms?

• Settlement: What happened to the value movement, at which confidence boundary, and can that state be reconciled?

Problems begin when one component is expected to answer another component's question. A wallet address is not a complete agent identity. An identity registration is not spending authority. A verified payment is not delivered service. A fast network confirmation is not automatically Bitcoin finality.

The architecture should keep those responsibilities separate while making their handoffs explicit.

Wallet Contract: Bound Authority In, Signing Evidence Out

The wallet contract owns keys or signing access, accounts, balances, nonces, network context, and authorization boundaries. Its job is to turn an approved typed action into signing or submission evidence.

Accepted Inputs

• agent and task identifier;

• typed payment or onchain action;

• destination, asset, amount, and network;

• policy approval reference;

• expiry, nonce, or replay boundary;

• idempotency key where supported.

Required Outputs

• signer or account used;

• exact payload authorized;

• signature, transaction identifier, or structured denial;

• submission timestamp and network;

• current execution state;

• reason when policy or signing fails.

The wallet must not infer commercial intent from a natural-language instruction alone. The runtime should resolve the instruction into a typed action and run policy before signing.

Wallet architecture also determines isolation. Separate agents may share a funding source while retaining different budgets and permissions. A wallet implementation should support the intended boundary by agent, merchant, network, asset, action type, amount, or time window. If it cannot, the application must not pretend that one unrestricted signer is equivalent to many controlled agent wallets.

Recovery belongs in the contract. Key rotation, signer suspension, lost credentials, pending transaction lookup, duplicate submission, and account migration are production states, not operational afterthoughts.

Identity Contract: Stable Subject In, Current Bindings Out

The identity contract owns the durable subject reference and the relationships that make the subject usable: controller, authorized operators, service endpoints, wallet references, metadata, reputation, and validation pointers.

ERC-8004 provides Identity, Reputation, and Validation registries for agents. Its identity model can associate an agent identifier with machine-readable registration metadata and service endpoints. Reputation and validation can add contextual trust signals.

The identity contract should emit:

• registry and agent identifier;

• current controller or operator;

• active status;

• service endpoint and capability metadata;

• wallet or payment-destination references when declared;

• reputation and validation references;

• metadata version, update time, and revocation state;

• evidence that endpoint or domain binding was checked when available.

Identity does not own wallet funds or payment settlement. A registry can say which wallet an agent advertises, but the wallet system still proves signing authority. A registered identity can publish capabilities, but it does not prove that the endpoint currently performs them safely.

The handoff to payment policy is a resolved identity snapshot. It should be fresh enough for the risk and tied to the endpoint and merchant destination used in the current request.

Payment Contract: Terms In, Verifiable Payment State Out

The payment contract connects a priced resource to a payer authorization.

For an HTTP-native flow, x402 lets a resource server return 402 Payment Required with supported payment requirements. The client or agent selects an acceptable option, prepares a signed payment payload, retries the request, and receives structured payment and resource status after verification and settlement processing.

The payment contract owns:

• resource and merchant order identity;

• price or maximum authorization;

• asset, network, scheme, destination, and expiry;

• payer authorization payload;

• verification result;

• settlement request and response reference;

• payment receipt or error;

• relationship between payment and protected delivery.

It should accept a policy-approved payer and merchant identity snapshot, then reject material differences. If amount, destination, resource, network, or scheme changes after approval, the transaction should be re-evaluated.

x402 does not provide the agent's identity policy, wallet custody model, service-quality guarantee, or refund rules. A facilitator can verify a payment payload and submit settlement for supported schemes. The merchant application still decides what successful payment unlocks and how paid-but-failed delivery is remedied.

The output is not merely paid=true. It is a queryable payment state with enough data to link payer, merchant, resource, authorization, settlement, and response.

Settlement Contract: Confidence Rules In, Reconciled Value State Out

Settlement is where ambiguous language creates architectural errors.

The settlement contract owns the observed value-movement state and the rules that determine when the application treats that state as sufficient. It should expose:

• payment or transaction reference;

• amount, asset, payer, and destination;

• submission and confirmation state;

• network, scheme, or rail context;

• confirmation or finality evidence where applicable;

• duplicate-settlement protection;

• refund, reversal, cancellation, or expiry state;

• status-query path after a lost callback;

• timestamps and reconciliation evidence.

The application supplies the acceptance rule. A low-value API may deliver after successful verification under its chosen scheme. A scarce asset or high-impact action may require stronger confirmation. A long-running service may queue after authorization and begin costly execution only after accepted settlement.

Settlement still does not own service delivery. The application needs a separate delivery state and must reconcile it with payment.

Settlement Has Three Different Clocks

Developers should name the settlement clock they mean.

Application Acceptance

The merchant decides that payment evidence is sufficient to release a resource, reserve capacity, or begin work. This is a product and risk rule.

Execution-Network Confirmation

The selected blockchain or payment rail reports transaction inclusion, confirmation, capture, or another value-movement state. The meaning and reversibility vary by network and scheme.

Bitcoin-Secured Bridge And Protocol Settlement

GOAT Network uses BitVM2 in its BTC bridge and Bitcoin-secured settlement foundation. That architecture concerns BTC deposits, withdrawals, bridge verification, challenges, and the security relationship between GOAT Network and Bitcoin.

It should not be rewritten as “every x402 payment settles directly on Bitcoin L1.” An x402 payment can use supported schemes, assets, and networks, and the resource server applies its own acceptance rule. GOAT's own security documentation also distinguishes fast GOAT Network confirmation from Bitcoin finality.

The three clocks can relate, but they are not interchangeable. Monitoring should report which boundary has been reached rather than compressing all of them into settled.

Six Invariants Must Survive Every Handoff

These invariants are more useful than forcing all components into one database. Each system can retain its native state as long as the application has durable correlation and clear authority.

The invariant check should run at transitions, not only after incidents. Before signing, confirm subject, authority, and intent. Before delivery, confirm payment state and uniqueness. During reconciliation, compare settlement and delivery without overwriting either history.

A Reference Transaction Across The Four Contracts

Consider a buyer agent purchasing a risk-scoring response from a seller agent.

1. Identity resolution: The buyer resolves the seller's agent identifier, endpoint, current controller, service metadata, and payment-destination binding.

2. Resource request: The buyer calls the endpoint and receives an x402 payment requirement for the protected response.

3. Policy evaluation: The runtime checks seller identity, reputation or validation signals, amount, destination, asset, network, task budget, and cumulative exposure.

4. Wallet authorization: The approved typed payload reaches the wallet. The wallet checks its own authority boundary and signs or denies.

5. Payment verification: The resource server or facilitator verifies that the payload satisfies the payment requirements.

6. Settlement processing: The selected scheme and network produce payment execution and confirmation state.

7. Delivery: The seller returns the risk score and a delivery identifier under the agreed contract.

8. Reconciliation: The application links identity snapshot, policy decision, signature, payment, settlement, delivery, and any later refund or feedback.

No step should reconstruct identity from a display name or infer delivery from a transaction hash. The transaction should carry stable references through the flow.

Failure Ownership Must Be Assigned Before Launch

Shared ownership is sometimes unavoidable, but one component must coordinate the resolution. Otherwise, wallet, facilitator, merchant, and network providers can each be locally correct while the customer remains unpaid or undelivered.

Integration Tests Should Cross Capability Boundaries

Component unit tests are necessary. The failures that matter occur between them.

Test these cases end to end:

1. The seller's payment destination differs from its evaluated identity metadata.

2. The quote expires between policy approval and wallet signing.

3. Two agents share one wallet but have different spending limits.

4. The client times out after signing and retries the same purchase.

5. Payment verification succeeds but settlement submission fails.

6. Settlement succeeds but the merchant response is lost.

7. Delivery fails after payment confirmation.

8. The identity controller changes while a long-running order is open.

9. A refund settles after the agent task has closed.

10. GOAT Network confirmation is available while a Bitcoin bridge operation remains in an earlier security state.

For every test, require a stable transaction ID, authoritative status source, retry rule, customer-visible state, and terminal or compensating action.

The test passes only when the system can explain both value movement and service outcome.

GOAT Shows One Way To Compose The Contracts

GOAT Network's public agent stack provides a concrete composition example. GOAT Network AgentKit exposes wallet and onchain actions, runtime policies, hooks, observability, guardrails, x402 commerce, and ERC-8004 identity capabilities. GOAT's broader network architecture includes programmable execution and a BitVM2-based Bitcoin-secured bridge foundation.

Those surfaces map naturally to the four contracts:

• wallet and action providers handle signing and execution surfaces;

• ERC-8004 supplies agent identity and trust references;

• x402 supplies HTTP-native payment requirements and payment workflows;

• network, order, transaction, and bridge states provide different settlement evidence.

The mapping does not remove application responsibilities. Developers still define wallet policy, identity freshness, merchant trust, accepted confirmation, delivery semantics, reconciliation, and remedies. x402 is not exclusive to GOAT, and the Bitcoin-secured bridge architecture should not be used to overstate the settlement path of every agent payment.

GOAT is relevant because the capabilities can be developed in one ecosystem context, not because their boundaries disappear.

AgentKit Is A Product Name, Not A Shared Specification

The fanout research surfaces both Coinbase AgentKit and GOAT Network AgentKit. They are distinct products.

Coinbase AgentKit documents wallet-provider interfaces and onchain actions under Coinbase package namespaces. GOAT Network AgentKit is published under @goatnetwork/agentkit and documents GOAT-oriented wallet actions, x402 commerce, ERC-8004 identity, runtime policies, and plugins.

Shared naming is not interoperability. Do not infer that a feature documented for one AgentKit exists in the other. Evaluate package provenance, interfaces, networks, wallet providers, policies, and release documentation separately.

This is exactly why capability contracts matter: an implementation can be replaced only when it satisfies the required contract, not because it shares a product category or name.

Keep One Operational Record Without Hiding Native State

The application needs a canonical record that correlates the four contracts:

transaction_id
buyer_agent_id
seller_agent_id
identity_snapshot_id
policy_decision_id
wallet_authorization_id
payment_requirement_id
payment_id
settlement_reference
delivery_id
payment_state
delivery_state
refund_or_reversal_reference
created_at
updated_at

transaction_id
buyer_agent_id
seller_agent_id
identity_snapshot_id
policy_decision_id
wallet_authorization_id
payment_requirement_id
payment_id
settlement_reference
delivery_id
payment_state
delivery_state
refund_or_reversal_reference
created_at
updated_at

transaction_id
buyer_agent_id
seller_agent_id
identity_snapshot_id
policy_decision_id
wallet_authorization_id
payment_requirement_id
payment_id
settlement_reference
delivery_id
payment_state
delivery_state
refund_or_reversal_reference
created_at
updated_at

This record should reference native evidence rather than replacing it. The wallet remains authoritative for what it signed. The identity registry remains authoritative for its own state. The payment service remains authoritative for verification. The network or facilitator remains authoritative for its settlement response. The merchant remains authoritative for delivery.

Observability should show disagreements. A dashboard that flattens signed, verified, confirmed, and delivered into one green status makes support easier only until the first exception.

FAQ

What infrastructure do AI agents need for wallets, identity, payments, and settlement?

They need bounded signing authority, a durable identity and trust model, machine-readable payment requirements and verification, settlement adapters with explicit confidence rules, and an application record that connects payment to delivery.

Is an agent wallet the same as an agent identity?

No. A wallet proves control of signing authority for an account. An agent identity can reference controllers, endpoints, capabilities, wallets, reputation, and validation. The relationship must be explicitly bound.

Does ERC-8004 handle agent payments?

No. ERC-8004 defines identity, reputation, and validation registries. Payments are orthogonal, although payment and delivery evidence can enrich trust signals.

Does x402 provide settlement?

x402 defines payment verification and settlement workflows for supported schemes and networks. The application still chooses its accepted confirmation state, handles delivery, and records refunds or failures.

Do all GOAT agent payments settle directly on Bitcoin?

No. GOAT's BitVM2 architecture concerns its Bitcoin-secured bridge and settlement foundation. Individual agent-payment execution depends on the x402 scheme, asset, network, and application acceptance rule.

Are Coinbase AgentKit and GOAT Network AgentKit the same?

No. They are separate toolkits from different projects. Developers should use the correct package namespace and verify each product's wallet, action, network, payment, and policy capabilities independently.

Make The Contracts Explicit Before Choosing The Products

The infrastructure stack succeeds when four capabilities remain distinct and interoperable.

Wallets control signing authority. Identity makes agents and services resolvable. Payments bind value requirements to authorization. Settlement records value movement at a named confidence boundary. The application preserves subject, authority, intent, uniqueness, provenance, and delivery across all four.

Define those contracts before selecting SDKs or protocols. Then test the handoffs under retries, delays, identity changes, failed delivery, and refunds. That produces an agent stack that can be operated and explained, not merely demonstrated.