Hi all,
I’m proposing an x402 specification for the Internet Computer (ICP) and would love feedback from the community.
cc @marc0olo 
8 Likes
Cool.
So ICP would be the middle layer where the requests go through?
This is not yet an agent tool that can be surfaced via x402?
If I would have known about this I would have brought it to the CB team. Just met them at an event in NYC for x402 
2 Likes
I have built a decentralized x402 payment facilitator on ICP with this scheme.
4 Likes
Is this specification ICRC2 exclusive or is it compatible with ICRC1 tokens like EXE or TAGGR as well?
Yes, ICRC2 is required
2 Likes
Would definitely be open to working on this, I created GitHub - Demali-876/consensus: Consensus deduplication proxy supporting x402 payments. but after the upgrades to address (optionally)replicated http outcalls I decided to put the project on hold. I think a much more viable option is to turn it into a decentralized proxy service but when I built it I was certain that ICP would need something like the x402 libraries to embrace this kind of protocol. I think I should design something similar for motoko devs, but the cost of HTTP outcalls are a big deterrent and the support for motoko really isn’t there for libraries like this. Definitely reignites my interest again.
1 Like
I just came across this tweet:
@w3tester are you using Anda cloud for zCloak or did you implement your own solution?
2 Likes
Thanks for pointing me to this Marco. Cool work from @zensh as always.
But we didn’t use this method for now. What we did was using the zCloak multisig wallet to generate an EIP 3009 compatible signed data and give it back to the AI agent which runs in a conventional server atm.
We did it this way for max compatibility with the existing x402 protocol.
3 Likes
x402 has released version v2, which is more user-friendly for multi-blockchain support.
I have already upgraded the Anda x402 Facilitator to v2, but I am not very familiar with the existing standards of ICP. For example, should the ICP x402 network use icp:mainnet or icp:1?
I hope the Dfinity team can get involved and help bring ICP into the x402 standard. @sea-snake @dieter.sommer
4 Likes
An IC network chain id can be referenced by it’s public key hash e.g. icp:737ba355e855bd4b61279056603e0550 for IC mainnet.
ICRC-113 defines a network registry of known networks where mainnet has chain id icp:1.
So icp:1 is an entry in the network registry that refers to icp:737ba355e855bd4b61279056603e0550.
The related standards can be found here: GitHub - dfinity/wg-token-standards: Token Standards Working Group. They’re currently still in draft PRs but the content itself is rather final e.g. icp:1 is not likely subject to change.
6 Likes
Does ICP plain to have a CAIP-2 identifier for mainnet and for local instances? I imagine due to how local instances work the latter might prove difficult.
1 Like
There’s currently icp:1337 for local and icp:1 for mainnet in the registry.
The registry does not explicitly specify how things are resolved, so for the local registry entry this could depend on how the tooling implementation handles it e.g. a configuration option to set the local instance host and port.
As mentioned above, an IC network can also be referred to in CAIP-2 by it’s public key e.g. icp:737ba355e855bd4b61279056603e0550 for mainnet. Similarly, different local instances could be referred to by their different public keys.
1 Like
Doesn’t a local IC instance pose a problem for x402 facilitators? eg: If icp:1337 is set to a local replica (e.g. 127.0.0.1:4943 via dfx), then a facilitator running remotely has no way to reach or verify that network unless they are hosted on the same machine or tunneled using a tool like ngrok? In that case icp:1337 is only meaningful to local tooling, not third-party facilitators. From an x402 perspective, it would be cleaner to have a public testnet ready and available to verify transactions rather than having to deploy your own facilitator.
1 Like
Doesn’t a local IC instance pose a problem for x402 facilitators?
That’s the same for local instances of Ethereum and other chains. Presumably a developer would usually mock this out unless they care about testing the payment facilitator.
My understanding is ICP recommends testing on the mainnet (with separate canisters for testing) because gas is super cheap (which is the main reason why you wouldn’t test on a main net). I guess you don’t test your web2 apps on a separate version of the internet either
1 Like
@zensh do I understand correctly that your payment facilitator only supports ICP tokens? I was thinking ICP would make an awesome payment facilitator for any blockchain. Presumably all the existing x402 facilitators are centralised.
Alternatively to a a local instance, you can also test token transactions with the test icp/icrc1 token instances on mainnet which can be found at https://faucet.internetcomputer.org
OISY also supports these tokens: top right dropdown → Test networks → IC (testnet tokens)
4 Likes
Yes, it only supports ICP tokens. Although it is technically possible to support other blockchains, the operating costs would be very high.
It’s only a single HTTP outcall to a RPC service, no? (Or multiple if you want consensus). Isn’t that just a fraction of a cent? That cost should be paid by the dapp that wants to verify the payment of course, but it might be very small compared to the size of the transaction.
I was thinking of building this even just for my own dapps running on the internet computer in order to be able to take payments in ETH and other currencies without having to rely on a central payment facilitator.
In the further future I envision many micro payment use cases will be further optimized with payment channels or streaming payments, which could also be supported by a payment facilitator running on ICP.
1 Like
I thought the same and prototyped it. The RPC outcall itself can be cheap, but it’s not usually “just one call”
For an EVM send flow you typically need ~4–5 RPC calls:
-
eth_getTransactionCount(nonce) -
eth_feeHistory/eth_maxPriorityFeePerGas(fees) -
eth_estimateGas(gas) -
eth_sendRawTransaction(broadcast)
And the bigger issue: signing from a canister via tECDSA is expensive/slow in practice — I saw 12+ seconds and roughly ~$0.03 per signature.
3 Likes
signing from a canister via tECDSA is expensive/slow in practice — I saw 12+ seconds and roughly ~$0.03 per signature.
Urgh, didn’t realise signing was so expensive right now 
Although Ethereum mainnet transactions take 15min to finalize anyways + an order of magnitude higher gas costs, so it might still be a good scheme for L1 transactions.
Even for L2s, there are surely still use cases where paying an extra few cents is worth not having to rely on a central party. It’s still peanuts compared to what Stripe will charge you. It might also still be cheaper for an end user to bear that cost than first having to convert to an ICP-based token.
1 Like