spec: authCapture (replaces commerce) (#42)

## Summary

- Adds the **`authCapture`** scheme spec — cross-VM abstract
(`scheme_authCapture.md`) + EVM implementation
(`scheme_authCapture_evm.md`).
- Retires the obsolete `commerce` scheme spec (`scheme_commerce.md` +
`scheme_commerce_evm.md`).
- Spec-only PR — no code changes. The companion @x402r/evm
implementation lands separately in #40.

## Why this is a separate PR

The original PR #40 bundled spec + implementation; this PR carves the
spec out so reviewers can read the protocol surface without wading
through the @x402r/evm code diff. PR #40 is now strictly the
implementation.

## What's in the EVM spec

- `extra` field schema (`captureAuthorizer`, `captureDeadline`,
`refundDeadline`, `feeRecipient`, `min/maxFeeBps`, `autoCapture`,
`assetTransferMethod`)
- Wire format for ERC-3009 and Permit2 payloads
- Spec → on-chain `PaymentInfo` field mapping (preserves canonical
Solidity names so the EIP-712 typehash matches the contract
byte-for-byte)
- Verification + settlement logic
- **Canonical Addresses appendix**: deterministic CREATE2 addresses for
`AuthCaptureEscrow`, `ERC3009PaymentCollector`,
`Permit2PaymentCollector` — same address on every supported EVM chain,
with salt labels so anyone can reproduce
- 14-chain deployed-chain table with per-chain `assetTransferMethod`
constraint (BSC + Tempo are Permit2-only because their canonical stables
lack ERC-3009)

## Test plan
- [ ] Reviewer reads `scheme_authCapture.md` for the abstract scheme
- [ ] Reviewer reads `scheme_authCapture_evm.md` for the EVM
implementation contract
- [ ] Cross-checks the Canonical Addresses table against the upstream
`base/[email protected]` source repo's deploy script

🤖 Generated with [Claude Code](https://claude.com/claude-code)

---------

Co-authored-by: Claude Opus 4.7 (1M context) <[email protected]>

Author: A1igator

specs/schemes/authCapture/scheme_authCapture.md

@@ -0,0 +1,85 @@
+# Scheme: `authCapture`
+
+## Summary
+
+`authCapture` is a payment scheme where funds can be held and settled later. The client authorizes a maximum amount, and the facilitator submits it — either locking funds in escrow for later settlement (two-phase) or sending them directly to the receiver with refund capability (single-shot).
+
+The **captureAuthorizer** is the entity authorized to authorize, capture, void, refund, or charge a payment. In a facilitator-submits flow, that's either the facilitator itself or any smart contract that ends up calling the underlying escrow.
+
+Unlike `exact`, which has no built-in mechanism for returning funds, `authCapture` supports returning funds to the client through void, refund, and reclaim.
+
+## Example Use Cases
+
+- Refundable payments with buyer protection
+- Delayed delivery where the client needs recourse if the service is unsatisfactory
+- Subscription or session billing with periodic captures against a single authorization
+
+## Settlement Paths
+
+The scheme supports two settlement paths, selected via `extra.autoCapture`:
+
+| `autoCapture`     | Behavior                                                                                                                     |
+| :---------------- | :--------------------------------------------------------------------------------------------------------------------------- |
+| `false` (default) | Two-phase. Funds held in escrow. CaptureAuthorizer can capture, void, refund. Client can reclaim if capture deadline passes. |
+| `true`            | Single-shot. Funds sent directly to receiver. CaptureAuthorizer can refund post-settlement.                                  |
+
+### Two-phase (`autoCapture: false`, default)
+
+```
+AUTHORIZE → RESOURCE DELIVERED → CAPTURE / VOID → (REFUND)
+```
+
+1. **Authorize**: Client authorization is submitted — funds locked in escrow.
+2. **Resource delivered**: Server returns the resource (HTTP 200).
+3. **Capture or void**: The captureAuthorizer can capture (finalize funds to the receiver) or void (release escrowed funds back to client).
+4. **Reclaim**: If the capture deadline passes without action, the client can reclaim directly.
+5. **Refund**: After capture, the captureAuthorizer can refund within the refund window.
+
+### Single-shot (`autoCapture: true`)
+
+```
+CHARGE → RESOURCE DELIVERED → (REFUND)
+```
+
+1. **Charge**: Client authorization is submitted — funds sent directly to receiver.
+2. **Resource delivered**: Server returns the resource (HTTP 200).
+3. **Refund**: The captureAuthorizer can refund within the refund window.
+
+No capture, void, or reclaim — funds are never held in escrow.
+
+## Core Properties
+
+### Fund Safety
+
+- Cannot overcharge — settlement amount is capped by the client-signed maximum.
+- Two-phase path: client can reclaim escrowed funds after the capture deadline if no action is taken.
+- Fee bounds are client-signed and enforced at settlement.
+
+### Replay Prevention
+
+- Each payment has a unique nonce derived from the payment parameters and a fresh client-generated salt.
+- Nonce is consumed on-chain at settlement, preventing double-spend.
+
+### Expiry Enforcement
+
+Two absolute-timestamp deadlines govern the payment lifecycle (network-specific implementations may add a derived pre-approval expiry from `maxTimeoutSeconds`):
+
+- **Capture deadline** (`captureDeadline`): Last moment to capture escrowed funds (two-phase); after this, the client can reclaim.
+- **Refund deadline** (`refundDeadline`): Last moment to issue a refund on captured or charged payments.
+
+## Relationship to `exact`
+
+| Aspect     | `exact`            | `authCapture`                                                         |
+| :--------- | :----------------- | :-------------------------------------------------------------------- |
+| Settlement | Immediate transfer | Via escrow (two-phase) or direct with refund capability (single-shot) |
+| Refundable | No                 | Yes (both paths)                                                      |
+| Fee system | None               | Configurable (min/max bounds, client-signed)                          |
+
+## Appendix
+
+Network-specific implementation details (contracts, signature formats, verification logic) are in per-network documents: `scheme_authCapture_evm.md` (EVM).
+
+### References
+
+- [Escrow Scheme Proposal — Agentokratia (Issue #834)](https://github.com/coinbase/x402/issues/834)
+- [Escrow Scheme Proposal — x402r (Issue #1011)](https://github.com/coinbase/x402/issues/1011)