Coinbase recently announced a new payment protocol: x402. Since x402 was initiated by Coinbase, it naturally supports Base Sepolia and is available by default. Furthermore, it already supports the Solana chain, proving that x402 is not tied to any specific chain.

https://github.com/coinbase/x402

To understand the process, I created a new repository (https://github.com/gin-lsl/x402-solana-demo) containing all the Server, Client, and Facilitator components. Here, Koa was chosen as the base framework to enable the client to obtain access to a specific interface provided by the server by paying with Devnet's USDC (a custom token).

Some explanations

First, I created the corresponding token using the spl-token tool, which can be seen here: https://solscan.io/token/9gKBTRXgVTszU31A12oJKKSy6aje8LyoVvNfSimembHo?cluster=devnet

Solana was chosen here because this chain is very developer-friendly, providing an almost unlimited amount of test tokens for everyone to develop and test. It does not set any barriers, does not require login, does not require linking any social media accounts, and does not require a wallet with a balance on the mainnet.

If you need to run the project, you need to create a .env file, fill in the required environment variables, and then start the server and run the client code in the terminal:

Code Explanation

Since this is only for demonstration purposes, they are simply placed in one location. Below are some key document descriptions:

solana.ts

It provides an interface called "/solana/get-balance", which we assume is a valuable interface that requires a small fee to call. As the Server, it corresponds to parts (5) to (8) in the sequence diagram, and more specifically, part (7).

Typically, servers only handle business logic and don't need to deal with on-chain transactions. Therefore, even if a system's developers are unfamiliar with Web3, they can still integrate Web3 payment methods with minimal changes to their business logic.

facilitator.ts

It implements the capabilities of Facilitator, mainly providing the /supported, /verify, and /settle interfaces, which are used to query currently supported chains, verify transaction data, and provide on-chain settlement capabilities, respectively. This is where it interacts with the chain, requiring a private key to pay on-chain transaction fees. Architecturally, it is independent of the Server (i.e., solana.ts), corresponding to (9) and (10) in the sequence diagram;

Even if you decide to provide your own Facilitator service, this part of the code is actually standardized, and you can basically use the official pattern directly without having to implement it yourself. However, currently the official support is only full for base. If you want to use other chains, some adaptation work is required. This mainly involves sending simulated transactions to the chain to verify the transactions (if it's a chain that "x402" already supports, you can directly call the verify function), and officially submitting the transactions to the chain and waiting for final confirmation (if it's a chain that "x402" already supports, you can directly call the settle function).

For the Solana chain, after the request reaches POST /settle, the settle function in "x402/facilitator" is called. After some verification, sendTransaction on RPC is called to send the transaction, and then waitForRecentTransactionConfirmation is used to wait for and confirm the transaction result. The relevant code is provided by @solana/kit. The EVM part follows similar logic.

x402-middleware.ts

Used to connect the Server and Facilitator, it acts as a Koa middleware, guarding APIs that require payment to access. The code references the official "x402-express". Its function is to automatically return a 402 status and forward /verify and /settle requests.

My code in this section essentially just assembles various parameters and forwards them to the facilitator or returns them to the client. For ease of testing and to avoid delving into too much detail, I've written most parameters as fixed values. These include:

• Setting maxAmountRequired to a very large value will actually be validated on the client side. If the amount the user needs to pay is higher than this value, an exception will be thrown directly.
• The asset was set to our own created token: 9gKBTRXgVTszU31A12oJKKSy6aje8LyoVvNfSimembHo, instead of the token address built into x402. On the mainnet, this should be the official USDC address.

Interestingly, x402-express implements a Koa-like onion model by rewriting functions on the Response. Therefore, in their middleware for Express, the actual flow is verify -> business logic -> settle. Submitting to the blockchain occurs after executing the business logic, which indeed matches the sequence diagram above. Implementing this logic is very simple in Koa, but requires some additional code in Express, which may be why they prioritized providing Express middleware.

payment-client-fetch.ts

Acting as a client, it initiates requests to the server, corresponding to steps 1 through 4 in the flowchart. This utilizes helper functions provided by "x402-fetch" to automatically handle 402 statuses, generate signatures using the client wallet's private key, and resend the data.

It will attempt to directly request the interface. Upon encountering a 402 error, it will read the returned content (which should contain the x402 version supported by the server, currently fixed at 1, and the required parameters for the server), sign the transaction using your private key, and then serialize the transaction information and resend it to the original URL via the X-PAYMENT Header.

After understanding the basic structure of the project, we can run the Server and Client using the following commands:

Client execution results and logs:

think

In my opinion, if the previous efforts of Web3 developers were aimed at lowering the barrier to entry for ordinary users to use Web3, making it easier for end users to utilize the Web3 ecosystem (payments, investments, etc.), then the current x402 was created to lower the barrier to entry for Web2 developers to access Web3 payment channels.

While the helper functions provided in the x402/client section are useful, they only do what they're supposed to do. Users can already easily pay with USDC and other currencies via their wallets. Therefore, relatively speaking, x402 is probably more significant for developers and service providers.

However, the widespread adoption of x402 will still encounter many problems. Large companies have their own internal settlement systems, and they will have their own attitudes and pace regarding how to integrate new standards. Integrating a new payment method into their existing systems will inevitably be a long and arduous process. Furthermore, large companies will have to consider regulatory implications when integrating payment methods, which may force them to abandon more convenient payment methods and continue using traditional, complex solutions.

Perhaps Node RPC providers would prefer it. In addition to providing basic interfaces, RPC providers also offer many Advance APIs, transaction acceleration interfaces, etc. If these can be provided through x402, perhaps more people can experience their services.

Finally, please note that x420 itself is just a basic payment protocol. Its significance lies in proposing a set of standardized technical specifications. With a recognized standard, it becomes easier for developers and companies of all sizes to collaborate on improving the entire ecosystem. We should view the proposal of new standards rationally and avoid falling into the narrative traps set by hype-mongers.

This article was written by ZAN Team (X account @zan_team ).