EIP-3009 payments

Use this guide to integrate Meridian x402 payments on EVM chains where the payment token exposes native EIP-3009 transferWithAuthorization. It is written for sellers, buyers, and AI coding agents implementing either side of the payment flow. This path applies to chains such as Base, Ink, HyperEVM, Optimism, Polygon, and Unichain when the selected payment token natively supports EIP-3009. Do not use Permit2 on these chains for the normal USDC x402 flow. Permit2 is only for chains whose payment token does not expose EIP-3009, such as MegaETH, BSC, and BOT Chain. For USDC routes supported by Across, this same EIP-3009 path can settle cross-chain. The seller exposes one paymentRequirements entry per source chain the buyer can pay from, and uses extra.destinationChainId when the recipient should be paid on a different chain.

How the flow works

seller creates payment requirements
buyer signs an EIP-3009 transferWithAuthorization
buyer sends paymentPayload to seller
seller settles through Meridian POST /v1/settle
Meridian facilitator relays transferWithAuthorization
Meridian distributes proceeds locally or via Across to the destination chain

Meridian-specific rules:

paymentRequirements.payTo is the Meridian facilitator, not the seller wallet
paymentRequirements.asset is the token that implements EIP-3009
paymentRequirements.network is the source chain the buyer pays from
authorization.to is the Meridian facilitator
The EIP-712 verifying contract is paymentRequirements.asset
The EIP-712 primary type is TransferWithAuthorization
paymentRequirements.extra.destinationChainId enables an Across-backed destination chain when it differs from the source chain
paymentRequirements.extra.creditedRecipient can carry the seller’s final recipient address when it differs from the facilitator-bound payTo
The buyer does not approve Permit2, the facilitator, or any proxy
The buyer does not sign a Permit2 witness payload
The seller keeps the Meridian API key on the backend

Prerequisites

Seller:

A Meridian organization
An organization API key from https://mrdn.finance/dev/api-keys
A backend endpoint that can receive paymentPayload from the buyer

Buyer:

A wallet on the selected chain
Balance of the selected EIP-3009 payment token

Install the common client dependency:

npm install viem

Do not install @uniswap/permit2-sdk for this flow.

Network constants

The token addresses below are Meridian’s default EIP-3009 payment tokens for common networks. If your application accepts another token on the same chain, only use this flow after confirming that token implements EIP-3009 transferWithAuthorization. Otherwise use the non-EIP-3009 Permit2 guide.

export const MERIDIAN_API_BASE = "https://api.mrdn.finance/v1";

export const EIP_3009_NETWORKS = {
  base: {
    chainId: 8453,
    token: "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
    tokenName: "USD Coin",
    tokenVersion: "2",
    decimals: 6,
    facilitator: "0x8E7769D440b3460b92159Dd9C6D17302b036e2d6",
  },
  ink: {
    chainId: 57073,
    token: "0x2D270e6886d130D724215A266106e6832161EAEd",
    tokenName: "USD Coin",
    tokenVersion: "2",
    decimals: 6,
    facilitator: "0x8E7769D440b3460b92159Dd9C6D17302b036e2d6",
  },
  hyperevm: {
    chainId: 999,
    token: "0xb88339CB7199b77E23DB6E890353E22632Ba630f",
    tokenName: "USD Coin",
    tokenVersion: "2",
    decimals: 6,
    facilitator: "0x8E7769D440b3460b92159Dd9C6D17302b036e2d6",
  },
  optimism: {
    chainId: 10,
    token: "0x0b2C639c533813f4Aa9D7837CAf62653d097Ff85",
    tokenName: "USD Coin",
    tokenVersion: "2",
    decimals: 6,
    facilitator: "0x8E7769D440b3460b92159Dd9C6D17302b036e2d6",
  },
  polygon: {
    chainId: 137,
    token: "0x3c499c542cef5e3811e1192ce70d8cc03d5c3359",
    tokenName: "USD Coin",
    tokenVersion: "2",
    decimals: 6,
    facilitator: "0x8E7769D440b3460b92159Dd9C6D17302b036e2d6",
  },
  unichain: {
    chainId: 130,
    token: "0x078d782b760474a361dda0af3839290b0ef57ad6",
    tokenName: "USD Coin",
    tokenVersion: "2",
    decimals: 6,
    facilitator: "0x8E7769D440b3460b92159Dd9C6D17302b036e2d6",
  },
  "base-sepolia": {
    chainId: 84532,
    token: "0x036CbD53842c5426634e7929541eC2318f3dCF7e",
    tokenName: "USDC",
    tokenVersion: "2",
    decimals: 6,
    facilitator: "0x8e633dBf31adCc7D41BE3e95B7c8DD3526B5235A",
  },
  "arc-testnet": {
    chainId: 5042002,
    token: "0x3600000000000000000000000000000000000000",
    tokenName: "USDC",
    tokenVersion: "1",
    decimals: 6,
    facilitator: "0x8e633dBf31adCc7D41BE3e95B7c8DD3526B5235A",
  },
} as const;

Seller setup

1. Create a Meridian API key

Seller-side setup starts in Meridian:

Connect the seller wallet at https://mrdn.finance
Open https://mrdn.finance/dev/api-keys
Create an organization-scoped API key
Store the public pk_... key on the server

Use the key in the Authorization header when calling Meridian:

const meridianHeaders = {
  Authorization: `Bearer ${process.env.MERIDIAN_API_KEY}`,
  "Content-Type": "application/json",
};

The API key can also be created programmatically with a valid SIWE session cookie:

curl -X POST https://api.mrdn.finance/v1/api_keys \
  -H "Content-Type: application/json" \
  -H "Cookie: siwe-session=your_session" \
  -d '{
    "name": "My Application Key",
    "test_net": true
  }'

2. Choose the network and amount

Amounts must use the selected source token’s base units. USDC-style EIP-3009 tokens usually have 6 decimals, but still bind the amount to the configured source token.

const network = "base";
const config = EIP_3009_NETWORKS[network];
const amountInTokenBaseUnits = 1_000_000n;

3. Build `paymentRequirements`

Use the EIP-3009 token address as asset. Keep payTo pointed at the Meridian facilitator.

const paymentRequirements = {
  scheme: "exact",
  network,
  asset: config.token,
  payTo: config.facilitator,
  maxAmountRequired: amountInTokenBaseUnits.toString(),
  resource: "https://seller.example/api/tool",
  description: "Paid access to agent action",
  mimeType: "application/json",
  maxTimeoutSeconds: 300,
  extra: {
    name: config.tokenName,
    version: config.tokenVersion,
  },
};

If you expose a standard HTTP 402 challenge, return:

return Response.json(
  {
    x402Version: 1,
    accepts: [paymentRequirements],
  },
  { status: 402 },
);

4. Expose multiple source-chain routes

If the seller wants to accept payments from several chains, return one paymentRequirements object per accepted source chain in accepts. The buyer or SDK selects the entry matching the buyer’s connected wallet chain. For a seller that wants to receive on Base but accept payment from Base, Ink, and Optimism:

const destinationNetwork = "base";
const destinationChainId = EIP_3009_NETWORKS[destinationNetwork].chainId;
const sellerBaseRecipient = "0x1111111111111111111111111111111111111111";

const sourceNetworks = ["base", "ink", "optimism"] as const;

const accepts = sourceNetworks.map((sourceNetwork) => {
  const source = EIP_3009_NETWORKS[sourceNetwork];

  return {
    scheme: "exact",
    network: sourceNetwork,
    asset: source.token,
    payTo: source.facilitator,
    maxAmountRequired: amountInTokenBaseUnits.toString(),
    resource: "https://seller.example/api/tool",
    description: "Paid access to agent action",
    mimeType: "application/json",
    maxTimeoutSeconds: 300,
    extra: {
      name: source.tokenName,
      version: source.tokenVersion,
      creditedRecipient: sellerBaseRecipient,
      destinationChainId,
    },
  };
});

return Response.json({ x402Version: 1, accepts }, { status: 402 });

In this model, an Ink-funded buyer pays the network: "ink" requirement. The buyer signs on Ink against Ink USDC, Meridian pulls funds into the Ink facilitator, and Across routes the output to Base before final settlement to creditedRecipient. Do not return only a Base requirement if you expect buyers to pay from Ink, Optimism, or another chain. A paymentRequirements object is source-chain specific because the EIP-712 signature domain includes the source chain and source token contract. Across currently uses exact-input routing in this flow. If the seller must receive an exact destination-chain amount, quote the route and set each source-chain maxAmountRequired high enough to cover Across fees.

5. Receive `paymentPayload`

The buyer sends raw JSON, not a transaction they submit on-chain. Build or retrieve the matching paymentRequirements server-side; do not trust buyer-supplied requirements for pricing, recipient, network, or token selection.

{
  "x402Version": 1,
  "scheme": "exact",
  "network": "base",
  "payload": {
    "signature": "0x...",
    "authorization": {
      "from": "0x2222222222222222222222222222222222222222",
      "to": "0x8E7769D440b3460b92159Dd9C6D17302b036e2d6",
      "value": "1000000",
      "validAfter": "0",
      "validBefore": "1741885200",
      "nonce": "0x..."
    }
  }
}

6. Settle with Meridian

Call POST /v1/settle from the seller backend. Do not expose the Meridian API key to an untrusted client.

const response = await fetch(`${MERIDIAN_API_BASE}/settle`, {
  method: "POST",
  headers: meridianHeaders,
  body: JSON.stringify({
    paymentPayload,
    paymentRequirements,
  }),
});

const result = await response.json();

if (!response.ok || !result.success) {
  throw new Error(result.errorReason ?? "Meridian settlement failed");
}

Buyer setup

1. Select a payment requirement

Use the seller-provided requirement for the network and token the buyer will pay with. If the seller returned several accepts entries, choose the route whose network matches the buyer’s connected source chain.

const buyerNetwork = "ink";
const paymentRequirements =
  accepts.find((entry) => entry.network === buyerNetwork) ?? accepts[0];
const network = paymentRequirements.network as keyof typeof EIP_3009_NETWORKS;
const config = EIP_3009_NETWORKS[network];

For cross-chain routes, do not change the signing domain to the destination chain. The buyer always signs on the source chain selected by paymentRequirements.network.

2. Sign `TransferWithAuthorization`

The buyer signs typed data against the token contract. There is no ERC-20 approval, no Permit2 allowance, and no witness object.

import { bytesToHex } from "viem";

const transferWithAuthorizationTypes = {
  TransferWithAuthorization: [
    { name: "from", type: "address" },
    { name: "to", type: "address" },
    { name: "value", type: "uint256" },
    { name: "validAfter", type: "uint256" },
    { name: "validBefore", type: "uint256" },
    { name: "nonce", type: "bytes32" },
  ],
} as const;

const randomNonce32 = () =>
  bytesToHex(crypto.getRandomValues(new Uint8Array(32)));

const now = BigInt(Math.floor(Date.now() / 1000));
const authorization = {
  from: account.address,
  to: paymentRequirements.payTo as `0x${string}`,
  value: BigInt(paymentRequirements.maxAmountRequired),
  validAfter: 0n,
  validBefore: now + BigInt(paymentRequirements.maxTimeoutSeconds),
  nonce: randomNonce32(),
};

const signature = await walletClient.signTypedData({
  account,
  domain: {
    name: paymentRequirements.extra?.name ?? config.tokenName,
    version: paymentRequirements.extra?.version ?? config.tokenVersion,
    chainId: config.chainId,
    verifyingContract: paymentRequirements.asset as `0x${string}`,
  },
  types: transferWithAuthorizationTypes,
  primaryType: "TransferWithAuthorization",
  message: authorization,
});

3. Send `paymentPayload` to the seller

Serialize bigint values as decimal strings. Keep the nonce as the original 32-byte hex string.

const paymentPayload = {
  x402Version: 1,
  scheme: "exact",
  network: paymentRequirements.network,
  payload: {
    signature,
    authorization: {
      from: authorization.from,
      to: authorization.to,
      value: authorization.value.toString(),
      validAfter: authorization.validAfter.toString(),
      validBefore: authorization.validBefore.toString(),
      nonce: authorization.nonce,
    },
  },
};

await fetch("https://seller.example/api/tool", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({ paymentPayload }),
});

Checklist for AI agents

Read the seller’s existing route structure before adding payment handling
Keep settlement on the backend
Use this guide for Base, Ink, HyperEVM, and other EIP-3009 token chains
Use asset = EIP-3009 token address
Use payTo = Meridian facilitator
For multi-chain sellers, return one accepts entry per source chain
For Across routes, keep network, asset, and payTo source-chain based
For Across routes, set extra.destinationChainId to the settlement chain id
Put the final seller recipient in organization settings or extra.creditedRecipient
Use authorization.to = Meridian facilitator
Use domain.verifyingContract = paymentRequirements.asset
Use primaryType = TransferWithAuthorization
Generate a fresh 32-byte nonce per payment
Convert every bigint in paymentPayload to a string before JSON encoding
Do not add Permit2 approval, Permit2 SDK code, or Permit2 witness fields

Common mistakes

Using Permit2 on Base, Ink, HyperEVM, or another native EIP-3009 token chain
Setting payTo to the seller wallet
Setting authorization.to to the seller wallet
Returning only a Base requirement when buyers need to pay from Ink or another source chain
Signing with the destination chain id for a cross-chain payment
Signing with the facilitator as the EIP-712 verifying contract
Using the wrong token name or version in the EIP-712 domain
Reusing an EIP-3009 nonce
Sending raw bigint values through JSON
Putting the Meridian API key in browser code

Start Here

Integration Guides

Programmatic Access

AI Skills

Reference

How the flow works

Prerequisites

Network constants

Seller setup

1. Create a Meridian API key

2. Choose the network and amount

3. Build `paymentRequirements`

4. Expose multiple source-chain routes

5. Receive `paymentPayload`

6. Settle with Meridian

Buyer setup

1. Select a payment requirement

2. Sign `TransferWithAuthorization`

3. Send `paymentPayload` to the seller

Checklist for AI agents

Common mistakes

References

​How the flow works

​Prerequisites

​Network constants

​Seller setup

​1. Create a Meridian API key

​2. Choose the network and amount

​3. Build paymentRequirements

​4. Expose multiple source-chain routes

​5. Receive paymentPayload

​6. Settle with Meridian

​Buyer setup

​1. Select a payment requirement

​2. Sign TransferWithAuthorization

​3. Send paymentPayload to the seller

​Checklist for AI agents

​Common mistakes

​References

How the flow works

Prerequisites

Network constants

Seller setup

1. Create a Meridian API key

2. Choose the network and amount

3. Build `paymentRequirements`

4. Expose multiple source-chain routes

5. Receive `paymentPayload`

6. Settle with Meridian

Buyer setup

1. Select a payment requirement

2. Sign `TransferWithAuthorization`

3. Send `paymentPayload` to the seller

Checklist for AI agents

Common mistakes

References