Recently, the x402 standard was proposed to allow web payments in cryptocurrencies by leveraging the HTTP error code 402. In this note, we examine the benefits of Linera as an x402 payment solution compared to traditional blockchains.

The issue with x402 on standard blockchains

We start by studying the current solutions and identify possible limitations.

How it usually works

In most blockchains, users initiate a payment by signing a transaction and posting it to the blockchain (typically a mempool or simply by calling an RPC provider). In context of x402, users may post their signed transaction as part of the payment header and let the server finish the work of confirming the transaction.

sequenceDiagram
    participant Client
    participant Server
    participant Blockchain

    Client->>Server: 1. GET /api
    Server-->>Client: 2. Error 402: Payment Required
    Client->>Client: 3. Select payment method and create payload
    Client->>Server: 4. Include header X-PAYMENT: 664 payload
    Server->>Blockchain: 5. Submit payment transaction
    Blockchain-->>Server: 6. Transaction confirmed
    Server-->>Client: 7. return response with X-PAYMENT-RESPONSE

After getting the initial 402 error (step 1 and 2), the client sends a signed transaction as payment payload in step 4. Server posts the transaction on-chain (step 5) and sends the payload only after receiving confirmation (step 6).

Problem:

• A transaction can always fail for a number of reasons, for instance if the funds are insufficient. Therefore, the server must wait for the blockchain confirmation before returning a response. In systems with asynchronous execution (e.g. Sui, Aptos, Solana APE roadmap), this takes longer than finality time because transactions in a finalized block can still fail.
• Even if the user has sufficient funds, during periods of contention, blockchain transactions may fail due to insufficient fees or be delayed, requiring the client to start from step 1.

Using a facilitator

To mitigate the blockchain confirmation delay, some platforms propose to use an intermediate called a ”facilitator”.

sequenceDiagram
    participant Client
    participant Server
    participant Facilitator
    participant Blockchain

    Client->>Server: 1. GET /api
    Server-->>Client: 2. Error 402 Payment Required
    Client->>Client: 3. Select payment method and create payload
    Client->>Server: 4. Include header: X-PAYMENT: 664 payload
    Server->>Facilitator: 5. /verify
    Facilitator-->>Server: 6. verification
    Server->>Facilitator: 7. do work to fulfill request
    Server->>Facilitator: 8. /settle
    Facilitator->>Blockchain: 9. Submit payment transaction
    Blockchain-->>Facilitator: 10. Transaction confirmed
    Facilitator-->>Server: 11. settled
    Server-->>Client: 12. return response with X-PAYMENT-RESPONSE

(source: https://docs.cdp.coinbase.com/x402/core-concepts/how-it-works)

Problem:

• Non-cooperative clients can always submit conflicting transactions directly to the blockchain and making the payment fail at step 9. In this case, the work started at step 7 is lost.
• Clients still have to wait for the full blockchain confirmation.

Using an L2 sequencer

Some recent L2s provide just-in-time execution and confirmation receipts suitable for payments.

sequenceDiagram
    participant Client
    participant Server
    participant Sequencer
    participant Blockchain

    Client->>Server: 1. GET /api
    Server-->>Client: 2. Error 402 Payment Required
    Client->>Client: 3. Select payment method and create payload
    Client->>Server: 4. Include header: X-PAYMENT: 664 payload
    Server->>Sequencer: 5. Submit payment transaction
    Sequencer-->>Server: 6. Transaction confirmed
    Server-->>Client: 7. return response with X-PAYMENT-RESPONSE
    Sequencer->>Blockchain: Settle L2 block in an L1 transaction