← Learn hub
AsterPay as a MiCA-aligned arbiter for Circle's Refund Protocol
Published 3 May 2026 · 7 minute read · By Petteri Leinonen, Co-founder
Short answer
Circle's Refund Protocol gives stablecoin payments the missing chargeback primitive without putting any party in custody of the funds. The smart contract is finished; the arbiter slot is open. AsterPay's position is to operate as a KYA-graded, MiCA-aligned arbiter for x402 and Nanopayments flows where both the payer agent and the recipient merchant have an attestation on file. This page explains the protocol, why the arbiter role matters, and how AsterPay proposes to fill it for European agent commerce.
Position statement (3 May 2026)
AsterPay endorses Circle's Refund Protocol as the right primitive for non-custodial dispute resolution on ERC-20 stablecoin payments. We are publishing this page as our public position before integration work begins. We expect a competitive arbiter market to emerge over the next two quarters; our intent is to be the EU-native, KYA-graded option for European merchants and the agent platforms that route to them.
What Refund Protocol actually does
Circle Research released the Refund Protocol smart contract in 2026, alongside a technical write-up on the Circle blog and a community deep-dive on Arc House. The contract introduces five functions that together form a complete escrow-plus-arbitration surface for any ERC-20 token, USDC included.
| Function | Caller | Effect |
|---|
pay(to, amount, refundTo) | Payer | Locks amount in escrow, records to as recipient and refundTo as the address any refund must return to. Refund address is fixed at payment time. |
refundByRecipient(paymentID) | Recipient | Voluntary refund to the pre-specified refundTo. The merchant's "yes, refund this customer" path. |
refundByArbiter(paymentID) | Arbiter | Forced refund when the recipient refuses. Deducts from the recipient's escrowed balance; if the recipient has already withdrawn, the arbiter must cover the refund and the contract records a debt owed back to the arbiter from future payments. |
withdraw(paymentID) | Recipient | Permissionless withdrawal after the lockup period elapses, as long as no refund has been issued. Keeps the contract non-custodial: the arbiter cannot indefinitely block withdrawal. |
earlyWithdrawByArbiter(paymentID) | Arbiter (with EIP-712 sig) | Recipient signs an off-chain consent specifying a fee paid to the arbiter; the arbiter executes withdrawal before the lockup expires. Protects the recipient from arbitrary fees. |
The arbiter has exactly three powers: refund to the pre-specified address, allow early withdrawal at a recipient-consented fee, and set the lockup period for new payments. The arbiter cannot redirect funds to a third party, cannot indefinitely block a withdrawal, and cannot increase the locked amount. This is what Circle means by "non-custodial dispute resolution" — the contract structurally bounds what the arbiter is permitted to do.
Why the arbiter slot exists, and why it is open
Stablecoin payments to date have been closer to cash than to credit cards: irreversible by default, no recourse if the merchant fails to deliver. That is fine for tipping and capital movement; it is not fine for commerce. Refund Protocol fills the gap with on-chain escrow, and an arbiter is the entity the payer appeals to when the merchant refuses a legitimate refund.
Circle deliberately did not name an arbiter inside the contract. The role is configurable per deployment; any address can be set. This is the right design choice because the arbiter requirements are jurisdiction-specific: a US merchant with US customers wants a US-aligned arbiter, a German merchant with EU agent traffic wants an EU-aligned arbiter, an on-chain protocol may want a DAO. Hard-coding a single arbiter would have made the protocol unusable in most regulated markets.
That said, an arbiter cannot just be a wallet. To be useful in production it needs:
- Identity attestations on both the payer and the recipient, so disputes can be graded against verifiable evidence rather than anonymous claims.
- A regulatory posture compatible with the payer and recipient jurisdictions — especially if the dispute resolution interacts with consumer-protection law or AML reporting.
- Refund-coverage capital, because the contract allows recipients to withdraw early and an arbiter that refunds in those cases is fronting the money until the recipient pays the debt back from future receipts.
- An appeal interface — an HTTP surface, an SLA, evidence intake, a published policy — that is good enough that customers and merchants both consider it fair.
None of those are in Circle's GitHub repo. They are the operating model around the contract.
AsterPay's position on the arbiter role
AsterPay's existing trust stack already supplies three of the four requirements above. KYA (Know Your Agent) attestations cover the payer side. ERC-8004 on-chain identity covers the agent identity layer. The MiCA-aligned settlement model covers the regulatory posture for EUR flows. Refund-coverage capital is the only new dimension; it is a small balance-sheet line item compared to the trust infrastructure.
Concretely, our intent is to operate as an opt-in arbiter for x402 and Nanopayments flows where both ends have a KYA attestation. Disputes are graded against the attestation tier; merchants on higher tiers receive shorter lockup periods and lower arbiter fees. Where a merchant has already withdrawn early and the arbiter must front the refund, the debt is recorded on-chain and offset against future settlement receipts — the contract does this automatically.
What "AsterPay as arbiter" means in practice
- Opt-in per merchant. Refund Protocol escrow is not the default x402 behaviour; merchants enable it on routes where chargeback risk matters (high-ticket, novel counterparty, regulated category).
- KYA-graded lockup periods. Higher-tier merchants get shorter lockups; new or unattested merchants start at the conservative default and earn shorter lockups over time.
- Published dispute policy. Plain-English appeal SLA, evidence categories accepted, indicative timelines. Arbiter decisions are logged on-chain via the contract; reasoning is logged off-chain in the appeal record.
- EU-native posture. EUR-denominated refunds, EU consumer-protection grounding, German/French/Spanish/Italian appeal intake on the roadmap.
- Non-custodial throughout. AELIRA LTD never takes title to USDC. Refund risk capital is held in EUR on the AsterPay treasury and routed through licensed European payment partners when an actual refund must move.
- No CASP licence required for the arbiter role itself. The arbiter signs to release or refund; underlying USDC-to-EUR conversion (when triggered) flows through licensed partners on their own books.
How this fits the wider Circle stack
The picture coming together in 2026 has three layers:
- x402 — the negotiation protocol. HTTP 402, scheme-agnostic, settled into the Linux Foundation in April 2026 with backing from Google, Stripe and Visa.
- Circle Nanopayments — the gas-free settlement primitive that runs on top of x402. Live on mainnet across 11 EVM chains as of April 2026 (Circle blog). Sub-cent payments via batched EIP-3009 settlement.
- Refund Protocol — the dispute-resolution layer that wraps any ERC-20 payment, Nanopayments-settled or otherwise, in non-custodial escrow with an arbiter.
None of these are competitive with each other. An x402 request can resolve to a Nanopayments-settled payment, which can be wrapped in a Refund Protocol escrow with AsterPay as arbiter. The whole stack is composable and the trust layer (KYA, attestations, arbitration) is the part that does not commoditise as the settlement primitive does.
What we are not claiming
This is a position paper, not a product launch. Specifically:
- We have not yet deployed an arbiter contract on any mainnet. Integration design and capital sizing are the next steps.
- Circle has not endorsed AsterPay as an arbiter. The arbiter slot is open by design and we are publishing our intent to occupy it in the EU corridor, alongside whatever arbiters emerge in other jurisdictions.
- Refund Protocol does not solve every dispute scenario. It is the right primitive for "merchant did not deliver" and "wrong amount" cases. It does not solve sanctions screening, fraud detection on the payer side, or pure quality disputes that require expert review.
- The non-EVM rails AsterPay supports (Lightning, Solana) are not covered by Refund Protocol because the contract is ERC-20-only. Disputes on those rails continue to use AsterPay's existing manual settlement-reversal path.
What you can do now
If you operate a merchant or platform integrating x402 or Nanopayments, three actions are useful this quarter:
- Read the Refund Protocol repo and decide which routes need escrow. Most x402 calls do not; the high-ticket, slow-fulfilment ones do.
- Get a KYA attestation on file. It is the input the arbiter (any arbiter, not only AsterPay) will use to grade your disputes.
- If you want to be on the early-access list for AsterPay arbiter integration, email [email protected] with subject "Refund Protocol arbiter early access". We will publish concrete deployment details and contract addresses once the integration is on testnet.