AI Agent Crypto Payments: Design the Boundaries Between Wallets and Settlement

An agent finds a paid data feed, receives a payment request, and signs it. The signature is valid. The transaction goes through. Yet the system can still have made the wrong purchase: the agent may have exceeded its mandate, paid an unapproved recipient, or bought a response that does not satisfy its task.

Developers can compose an agent payment stack from signer-backed wallet tooling such as GOAT Network AgentKit, a wallet provider with its own spending controls, x402 client and server infrastructure, ERC-8004 identity and reputation interfaces, and a payment service such as GOAT Flow. These components do different jobs. None of those names, alone, proves that the agent has delegated spending authority or that paid work has been accepted.

The useful architecture separates two planes. The control plane decides which purchases are permitted and which counterparties and results are acceptable. The payment plane signs, transfers, verifies, and reconciles money movement. Connect them through explicit assertions, not through a model's statement that it has permission.

Choose components by the assertions they own

A wallet gives an application a way to control assets cryptographically. A payment protocol gives a client and service a way to exchange payment requirements and evidence. An identity registry gives a discoverable handle. A settlement network records asset movement. These capabilities are complementary, not interchangeable.

For an agent buying data, the architecture should answer several different questions before a successful HTTP response is called a successful purchase:

GOAT AgentKit provides wallet actions and runtime integration; its reviewed EVM provider wraps a supplied signer. That is a path for connecting an agent framework to wallet capabilities, not evidence that the SDK provisions a managed custody account. Its identity and payment integrations can supply additional interfaces, but the application still needs to define how their outputs are trusted.

A different option is a provider-controlled wallet surface. Coinbase's documented Agentic Wallet companion interface lets users configure maximum spending per call and per session, and states that agents cannot change those limits. That is a specific control surface to evaluate, not a claim that every agent wallet or GOAT integration has those controls. Coinbase wallet interface documentation.

The choice therefore begins with ownership. If your application supplies the signer, identify who holds or operates it and who can invoke it. If a provider controls the spending boundary, identify which restrictions its actual account and API enforce. The latter can reduce application-owned control work, but it also makes provider authentication, policy semantics, availability, and recovery part of your dependency model. Neither choice removes the need to bind payments to the application's task.

Put spending authority in front of the signer

Custody, signing, and authorization are three separate design decisions. Custody concerns who controls the keys or account and how that control can be recovered or revoked. Signing concerns which cryptographic operations an interface can perform. Authorization concerns why a particular operation is permitted now.

In GOAT AgentKit's EvmWalletProvider at commit ed1987a85accd97effa367a1c8d3f5df4cee5bc8, typed-data signing delegates to the supplied signer. Transfer methods broadcast transactions and wait for receipts. The provider does not invoke PolicyEngine internally. An application that exposes direct provider calls cannot assume a runtime policy check is inseparable from every signing operation. Pinned wallet-provider implementation.

The corresponding pinned PolicyEngine checks allowed networks, action network support, write enablement, risk level, and confirmation. Although its input type includes a payload, evaluate does not inspect the amount or recipient. This implementation has no built-in per-payment amount ceiling, recipient allowlist, aggregate budget, or budget-duration enforcement. Its confirmation input is a boolean, not proof of delegated authorization. Pinned policy-engine implementation.

These are useful action gates. They should not be described as a complete spending policy. If the model can supply confirmed: true, that value cannot establish that a human approved the purchase or that an owner issued a valid mandate. A trusted component must own the approval decision and prevent the model from bypassing it through another wallet tool.

Consider a hypothetical research agent permitted to buy data within a small session budget. It launches several requests concurrently. A controller that merely reads the remaining budget before each call can approve several purchases against the same balance. The issue is not signature validity; it is concurrent allocation of authority.

An application-owned controller should reserve budget atomically against a durable purchase intent before releasing a signing operation. It should validate the actual network, asset contract, amount in base units, recipient, expiry, and operation type. The reservation should include whatever fee exposure the application intends to authorize. These are architecture recommendations, not features claimed for the reviewed AgentKit policy engine.

Enforcement must cover more than a transfer function. A broad token approval or arbitrary contract call can create spending exposure beyond the immediate purchase. If those actions are available, the controller must either understand their effects, constrain their scope through an appropriate account or signer mechanism, or refuse them. An amount check on one payment tool does not constrain another route to the same key.

Typed-data signing also needs a replay decision. EIP-712 defines structured signing and domain separation but does not provide replay protection by itself. The receiving application must reject repeated use or make processing idempotent. EIP-712 specification. Bind an approval to the exact intent and terms rather than treating a reusable signature or a successful confirmation prompt as open-ended permission.

This arrangement keeps the model useful: it can discover resources and propose purchases. It keeps authority accountable: only the trusted controller can turn a proposal into an allowed signing request. Revoking a session should block new commitments, while reconciliation continues for operations already authorized or broadcast.

Resolve identity without treating it as service trust

ERC-8004 is a Draft standard with separate identity, reputation, and validation registries. Its identity handle is based on ERC-721; payments are explicitly outside its scope. Registration does not guarantee a functional or non-malicious service, and feedback needs a trust model because unfiltered signals can be manipulated. ERC-8004 specification.

GOAT AgentKit's documented ERC-8004 action map covers registration, URI and metadata operations, payout-wallet reading, and feedback or reputation operations. It does not list every action in the Draft standard, including validation request/response operations or a dedicated wallet-setting action. Standard scope and SDK scope must be checked separately. AgentKit ERC-8004 action documentation.

The Draft reserves agentWallet: changing it requires wallet-control proof through setAgentWallet, not a generic metadata write. That proof establishes control of the receiving wallet, not service quality. Registration on one chain also does not confine the agent's operations to that chain.

For an integrator, discovery should produce a candidate counterparty, not an unconditional payee authorization. An ERC-8004 reference needs the registration chain, identity-registry contract, and agent ID; an agent ID alone is not a globally unique counterparty reference. Keep that reference, the service endpoint, and the proposed payment recipient as separate inputs to the trusted controller. Check their relationship using the chosen standard, service contract, and your own acceptance policy. An endpoint advertising x402 support is not proof that your client supports its current payment exchange.

Suppose the data-feed endpoint changes its receiving address after the agent has cached discovery information. Silently accepting the new address defeats a recipient restriction. Silently paying the cached address risks paying someone who no longer supplies the service. The application needs a freshness and change policy: re-resolve relevant identity information, bind the new terms to a fresh authorization decision, and stop if the relationship cannot be established.

Caching makes discovery faster and reduces infrastructure dependencies during a request. Revalidation reduces stale-payee risk but introduces extra latency and failure points. Choose a freshness boundary appropriate to purchase value and counterparty sensitivity; do not hide that decision inside an indefinite SDK cache.

Reputation belongs in service selection, with explicit rules for whose feedback matters. Work validation belongs in the acceptance path when the task requires independent checking. Neither belongs in a shortcut that converts a registry entry into unlimited spending permission. A low-value data lookup may use simple response checks; a consequential task may need a stronger evaluator and a lower automatic spending ceiling. Identity helps locate the subject of those decisions. It does not make them for you.

Choose an exact payment exchange, not just an x402 label

Generic x402 separates the client, the resource server, and an optional facilitator. In V2, PAYMENT-REQUIRED communicates payment terms, PAYMENT-SIGNATURE carries the client's payment payload, and PAYMENT-RESPONSE reports the settlement outcome. Whether funds move within the same HTTP exchange depends on the payment scheme; batch settlement can authorize first and redeem onchain later. x402 HTTP payment documentation.

The facilitator's verification operation and settlement operation have different meanings. Verification checks the payload; settlement submits and confirms the transaction. The public x402.org facilitator is documented for development and testnet use, not as universal production infrastructure. A production design must choose an appropriate facilitator or implement the supported responsibilities itself. x402 facilitator documentation.

GOAT Flow's current public payment path is a more specific product contract: DIRECT ERC-20 transfer to the merchant-configured receiving address on a selected EVM network, followed by verification. Its enabled chain and token pairs depend on merchant configuration. The transfer is the money movement; Flow's watcher or verifier observes that movement and advances product-specific payment evidence. GOAT Flow integration contract.

Flow also documents an MPP integration profile, with its own challenge, verification, and signed-receipt exchange. The repository does not establish generic MPP interoperability through a published conformance result or checked-in official-SDK interoperability tests. Do not treat the profile as a drop-in replacement for every MPP or generic x402 client. GOAT Flow repository.

AgentKit is different again: it supplies agent-facing adapters and actions. Its payment documentation distinguishes merchant-gateway and payer-wallet interfaces and describes adapter-specific steps. That sequence does not establish that every public Flow DIRECT order requires the same typed-data signature submission. AgentKit payment interfaces.

Before connecting a client, choose the exact version, scheme or profile, asset, network, and authentication contract. Then decide which side signs, which side broadcasts, and which side verifies. A method named verify is especially easy to misread: observing an already broadcast DIRECT transfer is not the same operation as verifying a generic authorization payload before settlement.

This choice also determines secret placement. An agent's payer interface should not inherit merchant administrative credentials simply because both interfaces live in one SDK. Keep privileged merchant operations on the appropriate backend and give the agent only the capabilities its role requires. Protocol automation reduces interaction friction; it should not merge payer and merchant authority.

Generic x402 offers a modular client/server vocabulary. A product profile can give an integrator a more concrete operational contract. The tradeoff is that specificity reduces ambiguity only if both sides implement the same contract. Protocol naming alone proves neither compatibility nor availability. Obtain a real challenge from the target environment and compare it with the chosen client before treating the combination as deployable.

Preserve the payment intent across uncertain outcomes

The most expensive architecture mistake can occur after the application loses certainty. A timeout means that the caller stopped receiving evidence. It does not mean that the transaction failed, that no funds moved, or that a second purchase is safe.

Return to the hypothetical data-feed purchase. The controller has approved and reserved one intent. The client broadcasts the transfer, but its connection fails before it receives the final response. The agent still needs the data and proposes trying again. At this point the system should resume the existing intent, not interpret the proposal as a fresh authority request.

Persist a record before the side effect, then attach broadcast and receipt evidence as it becomes available. The record should correlate the authorized terms, application task, payment order or request identifier, chain reference, and delivery attempt. If the signer broadcasts outside the application's process, the signer interface must provide a way to recover the transaction reference or disposition; otherwise the application has an unresolved reconciliation dependency.

GOAT AgentKit documents memory or Redis idempotency support and a default restriction against retrying non-read actions. That is relevant protection at the runtime layer. It does not establish end-to-end exactly-once payment and fulfillment across independent services. AgentKit runtime documentation.

In generic x402, settlement_pending is nonterminal; recovery should reconcile the existing broadcast transaction rather than blindly initiate another payment. In Flow's DIRECT integration, retain the original verification context after broadcast. These are profile-specific ways to continue an uncertain operation, not interchangeable status vocabularies.

An application can model its own intent as proposed, authorized, payment unresolved, payment confirmed, delivery received, and work accepted. Those are suggested application states, not promised API enums. Their purpose is to prevent one piece of evidence from advancing several unrelated decisions at once.

A transaction hash is a lookup reference. A valid payload proves only what its verification contract checks. A relevant chain receipt establishes a chain outcome under the selected confirmation policy. A trusted backend status or authenticated product receipt can establish the payment disposition specified by that product. None automatically demonstrates that a returned data feed is correct, fresh, complete, or suitable for the task.

If the verifier is unavailable after a transfer, retain an unresolved payment state and its budget reservation while reconciliation continues. Releasing the reservation immediately could authorize another spend before the first is understood. Holding it forever can strand usable capacity. The controller therefore needs a bounded escalation policy for uncertainty, with a human or operational owner able to investigate without manufacturing a failure result.

If money moved but data never arrived, classify the outcome as a delivery problem rather than rewriting payment history. Retry retrieval only under the service's actual contract. A refund requires an explicit mechanism or agreement; x402 support, an identity record, or a payment receipt does not create a universal refund right or reverse a finalized transfer. If replacement service is needed, authorize that as a separate purchase with its own cost and evidence.

This ledger is also where payment and reputation can meet responsibly. Record feedback about the observed service outcome, not simply about a successful transfer. Otherwise a reliable payment rail can make an unreliable service look successful in the agent's own history.

Name the settlement chain and the bridge assumptions separately

For every purchase, write down the chain on which the asset transfer happens. A DIRECT ERC-20 transfer executes on its selected EVM network. If that network is GOAT, it is GOAT-side execution; if another enabled network is selected, the transfer happens there. The presence of GOAT Flow or an agent identity does not turn that transaction into a native Bitcoin L1 payment.

GOAT Network's Bitcoin-secured architecture is a separate layer of analysis. Its bridge documentation describes BTC locked on Bitcoin and PegBTC minted on GOAT, with withdrawals advanced by an operator and a subsequent reimbursement path. It lists role-specific assumptions: an honest Committee member, an honest Watchtower, a rational Challenger, and an honest Designated Verifier. These are official design claims, not independent assurance about a particular deployed bridge. GOAT bridge architecture.

That model should not be compressed into an unconditional claim that any one honest participant makes every operation safe. The roles protect different assertions. A challengeable reimbursement path also has timing and participation dependencies; it is not the same event as the agent receiving an API response or an EVM transfer obtaining a receipt.

For a builder, the practical consequence is to keep asset availability, transaction confirmation, service execution, and any bridge exposure separately observable. A system funding an EVM wallet through a bridge may depend on bridge availability before it can make purchases. A wallet already funded on the chosen network can have a different immediate payment path. Neither case proves a universal settlement time or removes the need to define the application's confirmation policy.

Ask what happens when a necessary operator, verifier, RPC endpoint, or relayer is unavailable, and who owns recovery. Ask which deployed contracts and versions your application actually depends on and how changes are accepted. Documentation can describe a security design without proving current participant availability, collateral adequacy, or deployed version equivalence. Those checks belong to deployment evaluation, not to a brand-level settlement promise.

Keep two records where needed: the payment's asset-chain outcome and the underlying funding or bridge exposure. This makes accounting and incident investigation intelligible without pretending the layers share one finality clock. It also prevents an agent from assuming that a pending funding operation authorizes spending assets that are not yet available.

Make the integration contract the deliverable

For a known paid API, developers may need a constrained signer, an exact payment client, and a durable outcome ledger before they need an open discovery registry. For purchases across unfamiliar agent services, identity resolution and an explicit service-evaluation policy become more important. Adding ERC-8004 does not repair missing budget enforcement; adding a facilitator does not repair missing delivery acceptance.

Use GOAT AgentKit when its documented action and adapter interfaces match the agent framework and the application can supply the remaining authority controls. Evaluate a provider-controlled wallet when its enforced restrictions fit the mandate better than an application-owned signer service. Choose generic x402 infrastructure when both sides agree on its version and scheme. Choose a Flow integration when the target deployment exposes the specific product contract the client implements. These are conditional architecture choices, not a tested ranking or a compatibility certification.

Before connecting those components, agree on an interface contract among the agent-runtime, wallet, payment, and service teams. It should identify the principal delegating authority and how that delegation expires or is revoked. It should name the actual recipient and asset-network binding, the component reserving budget, the component allowed to sign or broadcast, and the evidence that changes payment status. It should also identify who accepts the service output and who investigates an unresolved or paid-but-undelivered intent.

The hypothetical data agent is ready for a bounded integration exercise when a concurrent request cannot allocate the same budget twice, a changed recipient cannot slip through cached discovery, and a timed-out broadcast has a recovery path that does not demand another payment. Those are acceptance conditions to verify in your own environment, not tests claimed here.

No live wallet, authenticated merchant configuration, deployed registry equivalence, or cross-profile interoperability is established by the documentation reviewed here. Network availability, supported assets, limits, and completion evidence must be checked in the chosen environment. The architecture can still be specified now: keep proposed purchases separate from authority, payment evidence separate from useful work, and transfer-chain outcomes separate from bridge assurances.

The result is an agent that can request payment tools without becoming the authority over them. Each component has a narrow assertion to prove, and each uncertain outcome has an owner. That is the foundation on which wallet, identity, x402, and settlement infrastructure become a coherent application rather than four features connected by optimistic assumptions.