This EIP proposes a URI scheme for chain-specific payment requests, enabling users to specify transactions in the form “send me X tokens of type Y on chain Z”. The URI format includes essential components such as the recipient’s blockchain account, the amount of tokens, the token contract address, and optional success and error callback URLs. This standard aims to eliminate ambiguity in multi-chain payment requests, ensuring clarity and accuracy in peer-to-peer transactions and vendor or dApp requests across different blockchain networks.
Cool proposal, good job!
I can see success-callback-url and error-callback-url params in the ERC you’ve proposed.
Can you please clarify a little bit: how these callbacks should work in detail?
Like:
- I scan some QR–invoice, my device will identify “cspr://” url scheme
- It opens my default wallet with deep-link support for this scheme
- I see UI to send X tokens of Y type to Z address. I confirm the tx
- [Here callback should be called, I guess. How? By my wallet, exposing my IP address? By some third-party? Which one? I’ll be redirected automatically or I can decline redirection request?]
I see a lot of pitfalls and potential problems directly related to callbacks - both from the security side and from the implementation point of view.
It would be great if you could describe in much more detail how exactly they are supposed to be arranged.
Your concern is totally understandable. I was intending to leave the standard open to allowing a vendor to customize their checkout experience by supplying the wallet with a destination URL for a success or error page. However, this may be unnecessary as it opens up a handful of potential issues like you mentioned. I’d be open to removing that and allowing the host dApp to be in control of post-transaction handling.
Maybe it makes sense to define a response that the wallet should return to the requester to indicate success / failure?
how will it support privacy? The IRS, wife and gas toll collector would be keen on knowing X, Y, Z
I’d argue that privacy concerns are out of scope for what this ERC seeks to accomplish. The main goal here is to define a URI scheme so any wallet implementation can receive a request of this manner and understand exactly what the desired outcome is. The formulation & execution of the transaction(s) required to achieve that outcome is up to the wallet and I’d think that’s where privacy considerations come into play