# The aa-native scheme

> x402 settlement scheme designed for ERC-4337 smart contract wallets, where the payment payload carries a signed UserOperation.

`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](/whitepaper.pdf).

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:

```json
{
  "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:

| | `exact` | `aa-native` |
|---|---|---|
| Account type | EOA | ERC-4337 SCW |
| Required token feature | EIP-3009 | standard ERC-20 |
| Agent native-asset balance | required | not required (paymaster sponsors) |
| Settlement caller | facilitator EOA | bundler → SCW |

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](/docs/guides/upstream-interop)).

## Where to read more

- [HTTP 402](/docs/core-concepts/http-402) — the wire format the scheme rides on.
- [Wallet](/docs/core-concepts/wallet) — how the SCW signs the UserOp.
- [Paymaster](/docs/core-concepts/paymaster) — how gas gets sponsored.
- [Settlement contract](/docs/core-concepts/settlement-contract) — what the UserOp calls.
- [Facilitator](/docs/core-concepts/facilitator) — what verifies and submits.
- [Whitepaper §2](/whitepaper.pdf) — the normative specification.