# x402

*a smol brain understanding*

By [angg](https://paragraph.com/@angg) · 2025-06-11

---

I was having a hard time trying to dissect what exactly is this new standard marketed as 'payment protocol of the internet' so I decided to spend an embarrassing amount of time to understand the code and its implications.

Writing this article because I think its definitely intriguing but should be called exactly what it is: a method that standardizes off-chain delegation, also more of a primer to my other article where I mention some pointers to keep in mind before starting to build: [https://x.com/probablyangg/status/1922541517283234183](https://x.com/probablyangg/status/1922541517283234183) (the stuff that I had to figure out before I could code with it)

### What exactly is it that was launched?

a typescript library that enables you to do just want I mentioned above - easy off-chain delegation. Define who can act on behalf of a wallet, what they can do, and under what constraints.

### How

There's a service provider and a service consumer

1.  the service provider generates what it wants from the EOA (or the service consumer), sending it along with 402 status code
    
2.  an EOA (agent/human), the client: generates and signs on the payload it generates based on what it received in the 402 header
    
3.  this payload is sent over to the Facilitator for verification and settlement
    
4.  on settlement, the faciliator executes this payload on behalf of the service consumer on the blockchain
    

### Caveats

Now because there's a Facilitator and delegated blockchain execution involved, there's a limitation to the infrastructure that can be used with this standard - which is kind of stupid given by definition a standard needs to be as infra-agnostic as possible (and this was the primary reason my brain was so bummed most of the time I tried figuring this standard out)

*   Only EIP3009 compatible ERC20 tokens can be supported
    
*   Only Base chain is supported right now (afaik)
    

It is hard (but not impossible) to support DAI (or coins that support `permit`), it is straightforward to support EVM chains. Everything else - non-EVM chains, any other ERC20 tokens - is extremely hard and you'd be better off not trying to use this standard on those scenarios

### Thinking Use Cases

You could employ this standard (given you're okay with the caveats) to any situation that involves two parties: a seller with services and a consumer. The consumer needs to have an EOA. Eg., seller: API access provider, consumer: your web-app; relayer (or facilitator) simply willing to execute transactions for you (consumer) for a certain fee -- meta transaction

---

*Originally published on [angg](https://paragraph.com/@angg/x402)*