Reference Architecture for AI Agent Wallets, Identity, x402 Payments, and Settlement

An AI agent commerce stack is not complete because it has a wallet, an identity record, an x402 endpoint, and a blockchain connection. The system is complete when those layers can pass the right evidence to one another without confusing identity with authorization, payment verification with service delivery, or network confirmation with business settlement.

This reference architecture defines four layers and their interfaces:

1. Wallet: controls assets and produces a policy-approved authorization.

2. Identity: identifies the agent, operator, service, or reputation subject.

3. Payment: turns a commercial intent into a scoped x402 requirement and payment proof.

4. Settlement: records network execution, confirmation, and accounting evidence.

The layers can come from different providers. The important design work is the binding between them: which agent is authorized to use which wallet, which identity is allowed to call which service, which payment belongs to which request, and which settlement record proves that value moved to the intended recipient.

The Four-Layer Architecture and Its Trust Boundaries

The reference flow looks like this:

The diagram shows an order, but it is not a strict one-way pipeline. Identity may be checked before a wallet action or after discovery. A wallet can hold a stable identity reference. The payment requirement can carry an order or request identifier. The settlement record can be linked back to all of them.

Each layer owns a different assertion:

None of these outputs proves every downstream fact. A wallet signature is not a reputation score. An identity record is not spending permission. A verified payment is not a valid API result. A confirmed transaction is not automatically a fulfilled order.

Wallet Layer: Authorization Begins With a Controlled Signer

The wallet layer is where value can leave the agent's control domain, so its interface should be narrower than “sign whatever the model requests.”

Wallet inputs

• agent or tenant identity;

• requested tool, resource, merchant, and order;

• amount, asset, network, and scheme;

• expiration and payment identifier;

• current balance and budget;

• policy context and risk level;

• confirmation or approval requirement.

Wallet outputs

• approved payment payload or signature;

• rejected policy decision with a reason;

• transaction submission reference;

• status query result;

• audit event linked to the logical request.

The wallet should enforce transaction limits, recipient allowlists, accepted networks and assets, per-tool budgets, and retry rules. These checks belong in code or a policy engine. A prompt can explain a spending policy to an agent, but it should not be the enforcement point.

Wallet ownership also needs an operational definition. Who can rotate the key? Which process can request a signature? Can a merchant or facilitator ever move funds without the payer's signed intent? How are production keys separated from test keys? These questions belong to the wallet boundary, not to the x402 HTTP layer.

The tradeoff is between convenience and authority. A local private-key signer simplifies development but concentrates more authority in the agent process. A remote or policy-controlled signer adds integration and availability concerns but gives the operator a place to enforce limits and approval rules.

Identity Layer: Bind an Actor to a Verifiable Reference

Identity answers “which actor or service is this?” It does not answer “may this actor spend this amount?” or “did this service deliver a good result?”

An identity layer may represent:

• an agent and its controlling operator;

• a service provider and its endpoint;

• a merchant account and receiving address;

• a tool capability or execution environment;

• reputation and prior validation signals;

• attestations about ownership, behavior, or deployment.

Identity inputs

• an agent or service identifier;

• registry or namespace information;

• signed metadata or attestations;

• reputation observations;

• validation requests and responses;

• policy context for the relying application.

Identity outputs

• a stable actor reference;

• metadata and capability claims;

• reputation or validation signals with provenance;

• a verification result and timestamp;

• an identifier that can be linked to an order, wallet, and payment.

ERC-8004 is relevant to this layer because its proposal describes registries for agent identity, reputation, and validation. In an architecture, such a registry can help a buyer resolve an agent or service reference and evaluate available evidence before a transaction. It does not turn an identity record into a guarantee, and it does not replace payment authorization or service-level verification.

The key data-binding rule is to avoid using a wallet address as the entire identity model. One agent may use more than one wallet, and one service may expose multiple receiving addresses or environments. Keep the identity reference, wallet address, merchant account, and environment as related but distinct records.

Payment Layer: Turn Intent Into a Scoped x402 Requirement

The payment layer translates a commercial request into terms that a wallet can review and a resource server can verify.

Payment inputs

• service or product identity;

• order and logical request ID;

• price quote and pricing version;

• accepted scheme, network, and asset;

• recipient address or payment destination;

• expiration and replay rules;

• wallet policy decision;

• optional identity or authorization context.

Payment outputs

• x402 Payment-Required response or equivalent requirement;

• signed payment payload;

• payment identifier for retries and correlation;

• facilitator verification response;

• payment or settlement response;

• resource-server admission decision.

The x402 client/server flow makes the boundary concrete: the client requests a resource, the server returns payment requirements, the client constructs and resubmits a payment payload, and the server verifies it locally or through a facilitator. The resource server then decides whether to provide the resource.

The payment requirement should bind the amount, token, network, recipient, resource, order, and expiration. If any of those change, the client should treat the requirement as a new quote rather than silently reusing the old authorization.

The Payment-Identifier extension provides a useful correlation mechanism for retries. Generate the payment ID at the logical request level and persist it across client restarts, load-balanced servers, payment processing, service execution, and result retrieval. Do not generate a new identifier for every retry.

Payment verification answers whether the payload satisfies the declared terms. It does not answer whether the agent is reputable, whether the service output is correct, or whether the merchant has reconciled its accounting record.

Settlement Layer: Produce Network and Accounting Evidence

Settlement is where the payment scheme interacts with a network and asset. A facilitator may submit the transaction and monitor confirmation, or the resource server may perform more of that work directly. The architecture should expose the result as a durable record either way.

Settlement inputs

• verified payment payload;

• scheme and network;

• token or asset;

• recipient and amount;

• payment ID and order ID;

• confirmation policy;

• facilitator or node response.

Settlement outputs

• transaction reference;

• network and asset;

• recipient and amount confirmed;

• confirmation or finality state;

• facilitator response, if applicable;

• merchant settlement record;

• reconciliation event.

The facilitator boundary matters. Official x402 documentation describes a facilitator as a service that verifies payloads and settles payments, then returns results so the resource server can decide fulfillment. The facilitator is not automatically the merchant ledger, delivery system, or refund authority.

The settlement layer should also handle duplicate submission and uncertain state. Some scheme/network combinations require duplicate-settlement protection. If a transaction is submitted twice while the first submission is still pending, the system must prevent duplicate access or double accounting according to the selected mechanism.

Settlement evidence is necessary but not sufficient. The final business record should connect transaction reference, payment ID, order, identity reference, wallet, service execution, and delivery receipt. That is what lets an operator answer what was paid, by whom, to whom, for which service, and with what result.

How Data Moves Through the Stack

Consider an agent buying a market-data API call from a service with a registered identity.

1. Discover: The agent resolves the service identity, endpoint, capability, and available validation or reputation evidence.

2. Authorize intent: The agent creates a logical request and asks the wallet policy engine whether this service, amount range, network, and tool are allowed.

3. Create quote: The payment layer creates a server-authoritative order and x402 requirement containing amount, asset, network, recipient, expiration, resource, and payment ID.

4. Sign: The wallet checks the requirement against policy and returns a signed payload.

5. Verify: The resource server or facilitator verifies the payload against the declared requirement.

6. Admit: The service records the payment and request state, then decides whether the request can enter execution.

7. Settle: The selected settlement path submits or confirms the payment and returns transaction evidence.

8. Execute: The API runs the requested operation and validates the output.

9. Deliver: The agent receives the result and a receipt linked to the order, payment ID, and execution record.

10. Reconcile: The merchant compares payment, settlement, delivery, and accounting state and resolves any mismatch.

The order of settle and execute may vary by payment mode and service design. What should not vary is the explicit distinction between payment verification, settlement, service execution, and delivery.

Components Do Not Need One Provider

The four layers can be sourced from different providers. A custom stack might look like this:

Using one provider can reduce integration effort and make data correlation easier. It can also create concentration risk, migration cost, or a larger failure domain. Composing providers can improve specialization and portability, but it requires explicit identifiers, consistent status models, and careful trust-boundary testing.

The components do not have to share a brand. They do have to agree on the fields that matter: agent identity, wallet identity, order ID, payment ID, resource, quote version, network, token, recipient, settlement reference, and delivery status.

Mapping a Full-Stack Implementation to the Four Layers

GOAT Network maps to multiple parts of this architecture through documented AgentKit and GOAT Flow surfaces.

Wallet and authorization: AgentKit provides wallet and action integration patterns, while its runtime documents policy checks for allowed networks, write permissions, and risk levels. This is the layer that can decide whether a proposed payment action is permitted before signing or submission.

Identity: GOAT documents ERC-8004 integration for AgentKit. That is relevant to registering or working with agent identity, reputation, and validation workflows. The application still decides which identity evidence is sufficient for a particular transaction.

Payment and commerce operations: The AgentKit payer-side x402 plugin documents actions for payment creation, authorization submission, token transfer, status, and cancellation. The merchant-side plugin documents a broader portal surface including authentication, orders, balances, webhooks, API keys, and related operations.

Runtime and settlement evidence: AgentKit Runtime documents idempotency, bounded retries and timeouts, output validation, metrics, and hooks. GOAT Flow documentation also exposes payment statuses and merchant-facing payment operations that can feed order tracking and reconciliation.

These capabilities make GOAT relevant when developers want a composable agent-commerce stack rather than only a raw x402 middleware package. They do not mean every layer must come from GOAT, nor that every deployment has the same networks, assets, custody model, APIs, or settlement conditions. Verify the target environment before implementation.

Go-Live Checklist for Agent Commerce

Interface checks

• Wallet output includes the exact authorization scope, not only a signature.

• Identity output includes provenance, timestamp, and actor/service reference.

• Payment output includes order ID, payment ID, quote, resource, recipient, amount, asset, network, and expiry.

• Settlement output includes transaction reference, confirmation state, and accounting linkage.

• Delivery output identifies the result, execution state, and retrieval path.

Security checks

• Wallet policies enforce limits, allowlists, and confirmation rules.

• Identity evidence is not treated as authorization by itself.

• Payment IDs and order IDs survive retries and restarts.

• Expired, altered, or cross-resource payment requirements fail closed.

• Duplicate settlement and duplicate fulfillment paths are tested.

• API keys and signing secrets stay within their intended control plane.

Operational checks

• A missing webhook can be recovered through status polling or reconciliation.

• Payment, settlement, identity, wallet, and delivery records are queryable together.

• Refund and dispute decisions reference the original payment and order.

• Metrics show unknown payment states, idempotency hits, failed execution, and paid-but-undelivered requests.

• Every component can be replaced without losing the correlation identifiers.

FAQ

What are the four layers in an AI agent commerce stack?

The four layers are wallet, identity, payment, and settlement. The wallet controls authorization and assets; identity represents agents and services; payment defines and verifies the commercial charge; settlement records value movement on a selected network and asset.

Which layer is responsible for authorization?

The wallet and its policy engine should make the final signing or transaction authorization decision. Identity can provide context, and payment can define the scope, but neither should silently override wallet spending policy.

Which layer verifies an x402 payment?

The resource server can verify locally or use a facilitator. A facilitator may verify and settle, but the resource server still decides whether to fulfill the service.

Do all four layers need to come from the same provider?

No. Different providers can supply wallet, identity, x402, merchant operations, and settlement components. The stack needs compatible identifiers, status models, trust assumptions, and recovery behavior across provider boundaries.

Is settlement proof the same as proof of service delivery?

No. Settlement proof shows that the payment path recorded value movement and confirmation according to its rules. Delivery proof shows that the requested service executed and produced an acceptable result. The merchant should store both.

Can one provider supply all four layers?

GOAT Network's documented AgentKit and GOAT Flow surfaces map across wallet/action runtime, ERC-8004 identity integration, payer and merchant payment operations, order/status handling, webhooks, idempotency, output validation, and runtime observability. Developers can compose those capabilities with other providers and must verify the actual deployment configuration.

Make Proof Transitions Explicit

The value of a four-layer architecture is not the number of boxes. It is the clarity of the transitions between them.

Identity should produce a reference that a policy can evaluate. The wallet should produce an authorization scoped to a request. The payment layer should produce a verifiable requirement and payment proof. The settlement layer should produce network and accounting evidence. The service should separately produce delivery evidence.

When those outputs are linked by stable request, order, and payment identifiers, developers can change providers without losing control of the transaction lifecycle. That is what turns four infrastructure categories into a reference stack for AI agent commerce.