The aa-native scheme

aa-native is the settlement scheme that lets ERC-4337 smart contract wallets participate in x402 payments. It is the scheme NERO 402 was built to ship; its formal definition is in the whitepaper.

This page summarizes what changes from the upstream exact scheme and points at the more detailed concept pages for each piece.

The shape change

In exact:

• The agent (an EOA) signs an EIP-3009 transferWithAuthorization typed authorization.
• The facilitator submits the authorization directly to the token contract.
• The token contract recovers the signer via ecrecover and moves the funds.

In aa-native:

• The agent (an ERC-4337 SCW) signs a UserOperation whose callData invokes a settlement contract.
• The facilitator submits the UserOp through a bundler.
• The settlement contract is the msg.sender of the token transfer, which means any standard ERC-20 works.

The wire envelope is unchanged. Only the inner payload differs:

{
  "x402Version": 2,
  "accepted": {
    "scheme": "aa-native",
    "network": "eip155:1689",
    "amount": "1000",
    "asset": "0x...",
    "payTo": "0x...",
    "maxTimeoutSeconds": 60
  },
  "payload": {
    "userOp": { "sender": "0x...", "callData": "0x...", ... },
    "settlementCallSpec": {
      "merchant":   "0x...",
      "token":      "0x...",
      "amount":     "1000",
      "requestHash":"0x..."
    }
  },
  "extensions": null
}

The facilitator decodes userOp.callData and asserts it resolves to a SettlementContract.settle(merchant, token, amount, requestHash) invocation matching settlementCallSpec. This prevents an agent from signing a UserOp that does something different from what it claims.

Why a separate scheme

Both schemes occupy distinct positions in the design space. The full comparison is in the whitepaper §3; the short version:

Most widely deployed ERC-20 contracts, including USDT on most chains, do not implement EIP-3009. aa-native works against any standard ERC-20 because the settlement contract calls transferFrom from the SCW's already-authorized state.

Coexistence with exact

The two schemes coexist on the same facilitator. A merchant accepting both signals support in paymentRequirements[] and lets the client pick. The reference NERO 402 facilitator implements both for interoperability with unmodified upstream @x402/fetch clients (see the upstream interop guide).

Where to read more

• HTTP 402 — the wire format the scheme rides on.
• Wallet — how the SCW signs the UserOp.
• Paymaster — how gas gets sponsored.
• Settlement contract — what the UserOp calls.
• Facilitator — what verifies and submits.
• Whitepaper §2 — the normative specification.