AP2 解决了支付，但没解决结算：智能体商业为何仍需两者兼备

AP2 Solved Payments, Not Settlement. Here's Why Agent Commerce Still Needs Both

Last week, Google and Mastercard handed AP2 to the FIDO Alliance. The news bounced through agent economy channels as a validation moment: "AI agent payments just got standardized."

It's true. And it's incomplete.

AP2 (Agent Payments Protocol) is excellent at one thing: moving money when an agent is authenticated and authorized to spend it. x402 (HTTP-native payments under the Linux Foundation) is excellent at moving money at the HTTP layer, per-request.

Both are payment rails. Neither is a settlement layer.

For agents trading digital assets with each other across blockchains, or procuring compute from untrusted providers, those are two different problems. And if agent commerce standardizes on one without the other, we'll have solved how agents authorize transfers but not what condition releases them.

What AP2 Does (And What It Doesn't)

AP2's job:

• Authenticate the agent (is this agent who it claims to be?)
• Authorize the spend (does this agent have permission to transfer X tokens?)
• Route the payment (move the money)

What it doesn't do:

• Define what the money is moving against
• Specify what condition must be met for release
• Establish finality (who decides whether the transaction is final?)

Example: An AI agent buys GPU time from a provider it has never met, on a chain neither trusts more than the other.

AP2 handles: "Agent is authenticated, authorized to spend 1 ETH, and the payment is routed."

It does NOT handle: "The 1 ETH releases only when the GPU provider proves the job ran correctly."

That second part is settlement. And AP2 punts it to the application layer.

The Three Layers (And Why They're Confused)

Most agent commerce discussions collapse three distinct layers:

Layer 1: Authentication & Authorization (AP2 Handles This)

"Is this agent who it claims to be, and does it have permission to spend?"

This is solved. AP2, ERC-8183 (agent identity), and OAuth all work here. FIDO donating AP2 to the standards body means: this layer is standardizing.

Layer 2: Payment Routing (x402 Handles This)

"How does the money physically move from payer to payee?"

x402 answered this: embed payment credentials in the HTTP request itself. Hyperbolic is using it in production for GPU inference. Coinbase and Stripe are in the ecosystem.

This layer is also largely solved.

Layer 3: Settlement (Still Open)

"What condition must be satisfied before the money actually changes hands?"

This is where the gap lives.

For agent-to-merchant (agent → AWS, agent → Stripe): settlement can be custodial. AWS holds the money until the invoice is validated. Stripe intermediates. Both are trusted third parties.

For agent-to-agent (agent → agent) or agent-to-untrusted-provider (agent → random-datacenter-in-Singapore): custodial settlement doesn't work.

You need a condition that is:

1. Cryptographic (provable without trusting a third party)
2. Cross-chain (workable when payer and payee are on different blockchains)
3. Atomic (both sides complete or both sides refund)

How Different Systems Answer "Settlement"

Apex Fusion Vector

Settlement condition: Staked reputation + bonded escrow + jury-based dispute resolution + signed receipts.

Finality model: Economic. A jury of staked participants votes on whether work was valid. If they agree, the settlement is final because attacking the quorum is financially expensive.

Advantages: Works inside one ecosystem. Proven at scale (20,000+ work packages as of Sept 2026).

Limitations: Jury is a trusted third party with incentives, not a cryptographic guarantee. Requires shared reputation infrastructure.

Hashlock (HTLC-Based)

Settlement condition: Cryptographic preimage (for assets) or hardware attestation (for compute).

Finality model: Cryptographic. An HTLC releases funds when a hash preimage is revealed or an attestation is validated. No jury. No intermediary.

Advantages: Trust-minimized. Works cross-chain natively. No dependencies on ecosystem reputation.

Limitations: Capital lockup. Timeout risk. Attestation still requires a hardware CA as trust root (not fully trustless).

Akash Network

Settlement condition: Liveness (provider stays online).

Finality model: Behavioral + reputation. Escrow drains per block. Goes offline, loses income. Layered with on-chain reputation scoring.

Advantages: Simple. Incentive-aligned for uptime.

Limitations: Liveness ≠ correctness. Provider can be online and still deliver wrong output. See our Sep 30 post for details.

Why This Matters for Agent Standards

If AP2 + x402 become the standard for agent payments without a settlement layer standard, here's what happens:

Scenario 1: Agent → Merchant (works fine)

• Stripe or OKX or Coinbase intermediates settlement.
• AP2 routes the payment to a trusted processor.
• Settlement is custodial but accepted.

Scenario 2: Agent → Agent Across Chains (breaks)

• AP2 routes the payment.
• But what happens next?
  • Do both agents agree on a third party to hold the money? (Centralized, high trust)
  • Do they use economic finality with a jury? (Requires shared reputation substrate)
  • Do they use cryptographic finality with an HTLC? (Requires a different protocol entirely)

Right now, AP2 + x402 say nothing about this.

What the Standard Should Include

A complete agent commerce standard needs:

1. Authentication & authorization (AP2 covers this) ✓
2. Payment routing (x402 covers this) ✓
3. Settlement condition (OPEN — no standard yet)
4. Finality model (OPEN — reputation vs cryptographic)
5. Cross-chain atomicity (OPEN — needs HTLC or equivalent)

You can standardize 1 and 2 and ship it. Merchants are happy. Agent-to-merchant payments work.

But agent-to-agent commerce, or compute procurement on untrusted infrastructure, still needs a settlement answer.

The Real Debate

Here's the question the agent standards community should be asking (and mostly isn't):

Should settlement be standardized as part of agent commerce, or left to applications to implement?

Case for bundling: If every agent framework implements settlement differently (some use Vector, some use Hashlock, some use custodial escrow), agents can't interoperate across framework boundaries without conversion risk.

Case for leaving it open: Settlement is use-case specific. Agents paying for compute need attestation-based settlement. Agents swapping assets need HTLC settlement. Agents paying humans need custodial settlement. One standard fits none.

Hashlock's position: We built atomic settlement for the open case (agent ↔ agent, cross-chain, untrusted). AP2 + x402 are good complements — they handle the payment rail. Settlement underneath is still the unsolved layer.

We're not positioned as the standard. We're positioned as one answer to the settlement question, and we're building in public on it.

What to Watch

• Oct 2026: AP2 gets transferred to FIDO. Watch for settlement governance questions in early implementations.
• Q4 2026: Vector (Apex Fusion) continues scaling agent work settlement. If jury-based settlement wins mindshare, cryptographic approaches stay niche.
• 2027: If agent-to-agent commerce grows without a settlement standard, you'll see fragmentation (each framework standardizes internally) or a new standard (IETF AGTP Commerce mentions settlement but it's still draft).

The Open Question

Do you think agent commerce standards should include settlement from day one, or can the industry function with settlement as an application-layer problem?

Agree: Settlement standardization is critical for interoperability.

Disagree: Payment + auth are enough; settlement is app-specific and can't be standardized.

Let me know your take.

Explore more:

• AP2 → FIDO Alliance donation
• Apex Fusion Vector — agent work settlement in production
• Hashlock SSRN whitepaper — cryptographic settlement
• x402 Foundation — HTTP-native payments
• IETF AGTP Commerce (draft) — standardization in progress

UTM: hashlock.markets/?utm_source=devto&utm_medium=blog&utm_campaign=2026-10-01-ap2-settlement