No one is touching ERC-20

Consumer payments need chargebacks, cash doesn’t

Circle does not want to make USDC payments reversible. They’re kind of already are, they can mint, burn, freeze, blacklist, etc. So what is Circle talking about? Here are some of the things Circle is working on:

1. Refund Protocol (smart-contract based, opt-in): on-chain escrow + dispute workflows; refunds are mediated by contracts/agents. This is on top of ERC-20.

2. Encrypted memos/receipts for ERC-20 transfers via helper contracts (this solves the super annoying “no memo field” without changing ERC-20). Again, these are helper contracts and opt-in.

3. Privacy: the Confidential ERC-20 Framework is a wrapper/flow that can mask amounts. Again, an add-on, not an ERC-20 token overhaul.

Circle isn’t proposing to make vanilla ERC-20 transfers reversible. Their “reversibility” lives in opt-in rails on top (escrow/refunds, metadata, privacy).

Is this good? Yes. We have fully unbundled payments (great!). Now time to make some bundles available optionally. Escrow/refund is absolutely necessary for consumer protection (e.g. for ecommerce) but you can keep cash-like final transfers simple.

Here is a mini-explainer why it matters for many payment flows. Currently, blockchain payments are “push” only. The sender broadcasts a transaction. But they could be designed as “pull” payments, where an authorized party requests funds. Pull models would open new use cases for stablecoins, since they mimic how credit cards and other mainstream systems work. There’s no technical reason blockchains couldn’t support this; it’s just a matter of design choices.

The design choice has been that push payments can be trustless. This is because the auth comes from the holder of the funds, so it’s a one step action. Kind of like with cash, where if I give you cash the act of handing it over is the authorisation itself. With a pull payment there is a requestor who makes a payment request that is pre-authorised. The key concept is that that it’s pre-authorised. It’s not a mere request for a push payment (e.g. like Peanut request links) but a payment that automatically deducts from your balance without you having to authorise it, just like a subscription.

Because pull payments inherently involve pre-auth, there needs to be a mechanism for the holder to trust that they won’t get drained. This is where some kind of adjudication and dispute resolution has to come in to protect against bad charges. If a fraudulent or unauthorised charge occurs, you need an entity to decide whether to reverse it. Introducing reversibility into stablecoins would create similar challenges, including the need for a trusted arbiter. Kleros’ Escrow is a brilliant proof of concept of decentralised arbitration but has largely failed as a product or business.

Is this bad? Potentially. Unless the standards are open, this can lower interop and create a moat and lock-in effects. Example: CCTP is on-chain and “permissionless,” but it relies on Circle’s off-chain attestation service. This is an operational dependency and potential moat (especially with Fast Transfer), making switching to USDT much harder for an app or middleware. That’s where neutrality and portability matter. Lock-in effects are bad because when (not if) Circle starts being evil, it’s going to be impossible to switch.