IETF AGTP-COMMERCE: The Draft That Defines Agent Commerce (But Not Settlement)

In June 2026, the IETF published draft-hood-agtp-commerce-00, the agent-to-agent commerce protocol. It's a real deliverable with teeth: cryptographic proof of agent identity, merchant registries, transaction routing, and dispute metadata.

It's a cornerstone of the emerging agent economy infrastructure.

It also leaves the hardest problem completely open: when agent A owes agent B money, what proves that payment actually executed?

This gap is why we're building compute and asset settlement layers. Let's walk through what AGTP gets right, what it doesn't touch, and what the market needs to build on top of it.

What AGTP-COMMERCE Solves (Correctly)

1. Agent Identity and Cryptographic Proof

Agents need provable identities. AGTP specifies how an agent's public key becomes a verifiable identity, rooted in a merchant registry or trusted namespace.

Agent A: identity = sign(agent_id, private_key)
Agent B: verify(identity, public_key) -> trust level

This is solid. An agent can prove it is who it claims to be without a central gatekeeper. Each agent framework can run its own registry or delegate to a shared one (Anthropic, Vercel, etc.).

2. Routing and Contract Negotiation

Agents need to find each other and negotiate terms. AGTP specifies:

• Discovery (DNS, registries, direct connection)
• Contract format (what payment terms, what dispute rules)
• Signature requirements (both agents sign off on terms)

This is how agent A finds agent B, proposes a trade (e.g., "I'll pay 0.5 ETH for this training job"), and both agree before execution.

3. Transaction Metadata and Auditability

Every transaction logged with:

• Parties (signed identities)
• Terms (amount, what was traded, timeout)
• Signatures (both agents acknowledge)

If something goes wrong, the metadata is a permanent record that a jury, arbitrator, or court can reference.

All good. AGTP is doing the routing and governance layer correctly.

What AGTP-COMMERCE Does Not Solve

The Missing Layer: Settlement Proof

AGTP says: "Here's how agents find each other, what they traded, and who signed off."

AGTP does NOT say: "Here's how we know agent A actually paid agent B."

Today, every production system that settles agent payments does so against something weaker than proof:

System	Settles Against	Trust Model
Akash / io.net	Liveness (machine stays online) + reputation	Reputation slash if offline; no proof of work quality
Apex Fusion Vector	Social consensus (staked jury)	Jury is a trusted third party with good incentives
x402 (Coinbase/Cloudflare)	HTTP response (payment clears on successful response)	Says nothing about whether work was correct

Each system chose a proxy. Liveness is not proof of work. Jury votes are not cryptographic certainty. HTTP status 200 is not proof of execution.

AGTP leaves this decision to the implementation. And that's fine. But it means the market is missing the foundational primitive.

What Proof Actually Looks Like

For Asset-to-Asset Settlement

An HTLC (hash-time-lock contract) locks value and releases it when a cryptographic condition is met. The condition is a hash preimage.

Agent A's flow:

1. Chooses a secret (256-bit random number)
2. Computes hash(secret)
3. Locks ETH in a contract: "Release to B when B reveals secret"
4. Sends hash to Agent B

Agent B's flow:

1. Locks corresponding BTC in a contract: "Release to A when A reveals secret"
2. Sends lock confirmation to A

Atomic settlement:

1. Agent A reveals secret to claim BTC
2. Revelation is public; Agent B sees it and uses same secret to claim ETH
3. Both complete or both refund after timeout

The proof is the hash preimage. You can't fake it without solving the hash function backward, which is cryptographically infeasible.

No jury needed. No reputation needed. No trust in the other agent or any intermediary.

For Compute Settlement

This is newer and still in research phase. The question is: what does proof of compute execution look like?

For confidential compute on NVIDIA H100/H200 hardware, the answer exists: attestation signed by a hardware-rooted key.

Each GPU carries a Device Identity Key (DIK) fused at manufacture time and anchored to NVIDIA's root CA. When a workload runs in confidential mode, the hardware produces a signed attestation covering:

• Firmware measurements (what software is running)
• Workload hash (which code executed)
• Timestamp

Important caveat (stated every time, no exceptions): attestation proves which code ran on which silicon. It does NOT prove the output is correct, useful, or that the model was any good. And it relocates the trust root to NVIDIA's certificate authority. This is trust-minimized, not trustless.

But it's the closest thing the compute market has to a preimage. An agent could set up an HTLC that releases payment only when a valid attestation is presented.

// Pseudocode: compute HTLC with attestation condition
if verifyAttestation(workloadHash, signature, nvidiaRootCA) {
  releasePayment(agent_b);
}

For the first time, settlement could be gated on cryptographic proof that the work actually happened.

Why This Matters Right Now

The market is building three parallel layers:

1. Routing (AGTP). Agent discovery, identity, contract negotiation. Standardized. Shipping.
2. Payments (x402, AEON, IXUSD). Money moves from A to B via HTTP or chain. Fast. Custodial or wrapped.
3. Settlement (still unsolved). When payment is atomic and final with no intermediary risk.

Layers 1 and 2 are converging. Layer 3 is where the technical differentiation will happen.

Every system that wants to claim "trustless agent commerce" will need a settlement primitive. AGTP defines the routing. Someone needs to define the proof.

What We're Building (Honest Status)

We have a primitive: HTLC-based settlement on Ethereum mainnet, with code and contracts that are formally verified and live.

We have a question: what does settlement look like for compute?

We do NOT have:

• A compute settlement design
• A testnet for compute escrow
• Customers using compute settlement

We're building in public on an unsolved problem. The voice is the same as the 2026-09-04 post that priced our own forward design at 688 basis points against a 1-2 basis point fee. We're asking: if you want atomic compute settlement, what shape should it have?

Next Steps (For You)

If you're building an agent framework or an agent-to-agent marketplace:

1. Read draft-hood-agtp-commerce-00. Understand the routing layer.
2. Ask yourself: how do I settle payment atomically? If the answer is "CEX API keys" or "jury dispute," you have a scaling problem.
3. Explore HTLC settlement for asset trades. It's mainnet live and has a working MCP server.
4. For compute: think about what proof means. Attestation + HTLC is one shape. Bonds + reputation is another. Jury + collateral is a third.

The market doesn't have one answer yet. That's the opportunity.

See Also

• IETF Draft: Agent-to-Agent Commerce Protocol
• Our methodology and primitive design
• SSRN whitepaper: HTLC-Based Cross-Chain Settlement

What settlement proof matters most to you: cryptographic finality, economic finality via reputation, or something else? Comment below.