CIP-0013: Current state of integration and further advancements

[MadOrkestra]

With mobile wallets showing great progress over the past year, I'd like to bring some attention to CIP-0013 (Cardano URI Scheme), which makes quick payments by scanning a QR Code possible - a feature greatly needed to get a lot of use cases off the ground and improve the overall user experience on Cardano.

CIP-0013 was first proposed in 2020 but doesn't seem to have moved along since. There seems to be great support for CIP-0099 (Proof of Onboarding), which already is an addition to the non-active CIP-0013. Flint Wallet seems to have integrated their own deeplink solution already, so before other wallets go down this individual path, maybe lets have a discussion about what is missing and how to proceed, so we can put this CIP into action. I had great success working with BeginWallet on this for the past week, they will role out payment link integration shortly.

Current state of Integration in mobile wallets

This is from what I gathered from conversations and testing, feel free to add other wallets or correct my findings. This is not meant to put anyone on the spot, just to give a general overview of where we are in terms of integration.

Yoroi
✅ Payment Scheme
🚫 Staking Scheme
🚫 Deeplinks
✅ CIP99

BeginWallet
✅ Payment Scheme
✅ Deeplinks
🚫 Staking Scheme (not integrated yet, but no objections to the CIP)
✅ CIP99

Vespr
🚫 Payment Scheme (objections to the CIP / improvements needed before implementing)
🚫 Staking Scheme (objections to the CIP / improvements needed before implementing)
🚫 Deeplinks (objections to the CIP / improvements needed before implementing)
✅ CIP99

Lace

• to be checked

Gero
🚫 Payment Scheme
🚫 Staking Scheme
🚫 Deeplinks
🚫 CIP99

Advancements

From my conversations with multiple devs and projects, there seems to be a need for at least two improvements:

1. Asset support for payment links

Right now, there is no way to include Cardano native assets in a transaction, just ADA. Especially with stable coins being a thing now, this seems to need integrating. Or: Deciding to put this CIP live as is and have improvements in own CIPs like it was done with CIP99, also a way to go.

2. Metadata support for payment links

To match transactions on the backend of a payment system, there is the need to include some kind of metadata in payment links. This could already be achieved by adding a recognisable amount of Lovelace to the payable amount, but this is of cause more of a workaround than a solution. So it stands to reason to add functionality to include metadata in payment links

I will invite devs and wallets to join this discussion. Please spread the word, so we can hopefully work out the missing pieces and finally put this CIP into action.

🚀 2025 Update on current progress / further advancements

I'll leave these here for anyone joining the party. Currently in the works are the following advancements:

• CIP-0157? | Cardano URIs - Enhanced Payments #843
• CIP-0158? | Cardano URIs - Browse Authority #1058
• CIP-0162? | Cardano URIs - Delegate Authority #1069

[rphair]

re: future plans for wallets... cc @Crypto2099

@MadOrkestra we had a brief review of some of these topics when I last rewrote CIP-0013 to have more flexibility for future protocols to be added. Additional // schemes were suggested in this period for metadata and other chain queries (see #625 - cc @Ryun1 @klntsky).

I can't personally provide insight about what wallet developers might or should be doing, but I will definitely follow this thread to do whatever I can to make CIP-0013 implementations easier than any proprietary alternatives.

⚠️ Payment Scheme for Native Assets

I would expect that including native assets besides Ada in a payment query string would first be discussed similarly to this thread: #86, with some comments & concurrent PRs and issues suggesting:

• the use of asset names is error prone (not unique in the protocol) and therefore URIs should only contain the asset fingerprint... meaning you run out of URI space (vs. 2048 character limit) and therefore they are impractical.
  • I am willing to admit that the collision between short asset names, especially given the huge problem with fake assets, is much more of a problem here than with duplicate stake pool tickers & that resolving short asset names would place a burden on wallet software.
• the use of asset names/fingerprints as keywords... rather than values in a keyword-value array... has been declared "difficult" for programmers to implement and therefore a URI scheme was suggested that would only work for single assets at a time (hence this logic was disqualified: see CIP-0013 | Extend URI scheme with single stake pool links [proposal of update] #65).

So I expect a new payment URI should support payment links like (feel free to substitute asset fingerprints for familiar token names here, and I expect the entire URI query would be case-insensitive):

web+cardano:Ae2tdPwUPEZ76BjmWDTS7poTekAvNqBjgfthF92pSLSDVpRVnLP7meaFhVd?ADA=100&WMT=500

... or, if the query URI values are ruled to be a problem for backward compatibility of already supported payment links:

web+cardano://payment?Ae2tdPwUPEZ76BjmWDTS7poTekAvNqBjgfthF92pSLSDVpRVnLP7meaFhVd&ADA=100&WMT=500"

I would be happy to work these into CIP-0013 as soon as enough discussion can validate the syntax & boundary cases here:

• address formats, as documented in other CIPs
• payment "handles", given potential problems in handle domain resolution as per @SIDANWhatever's CPS-0008? | Domain Name Resolution #605
• acceptance of the much simpler syntax of asset-names-as-keywords (or asset fingerprints, if you have the space in the URI for it) rather than other longer, more awkward, more restrictive naming conventions for the "payment array"
• outlining an efficient and secure means for wallets to interpret payment URIs using "short asset name" (e.g. WMT rather than its asset fingerprint)... because without these, users might not be incentivised to use these multi-asset payment links.

[MadOrkestra]

Maybe a general comment before we dive into details: Looking at the Path to Active for this CIP (https://cips.cardano.org/cip/CIP-13), with BeginWallet implementing payments, IMO all we really need to put this CIP live as is would be implementation of the Stake Pool URIs by one or more wallets.

With Yoroi, Begin and Vespr already having implemented CIP99 the last acceptance criteria (one or more wallets supporting additional URI protocols) seems to be already fulfilled?

So in the spirit of getting things done, this might also be a viable option to move this along and improve on it later.

Just putting this out there for any wallet dev reading this.

[rphair]

@MadOrkestra we have an Issues section on our biweekly CIP meeting agenda (normally "time permitting" after CIP pull requests are introduced, reviewed & adopted) so I've put this issue there to help ensure we get as much developer attention as possible for this: https://hackmd.io/@cip-editors/90

There's a also a Cardano wallet developer community active at the corresponding CIP Discord here: https://discord.gg/J8sGdCuKhs

[MadOrkestra]

• acceptance of the much simpler syntax of asset-names-as-keywords (or asset fingerprints, if you have the space in the URI for it) rather than other longer, more awkward, more restrictive naming conventions for the "payment array"
• outlining an efficient and secure means for wallets to interpret payment URIs using "short asset name" (e.g. WMT rather than its asset fingerprint)... because without these, users might not be incentivised to use these multi-asset payment links.

I have to read up on CIP-0026 for this, you might already know: Couldn't this be at least mitigated to some extend if wallets would validate short asset names against the Cardano token registry? Aren't ticker symbols in there individual without duplicates? Of cause this would only be half a solution as not all assets are in the registry.

[rphair]

@MadOrkestra this is why I think it would be safe enough to use the short asset names... but, not being a wallet implementor or being responsible for wallets misinterpreting payment links in certain boundary cases, I'm not qualified to say how safe (or unsafe).

I think @Crypto2099 would have hashed a lot of this out with CIP-0099 so I'm looking forward to seeing what he has to say about this & about the general subject.

[MadOrkestra]

On the second advancement idea: Adding "metadata" for payment links, I think it could really be as easy as adding a "&msg=whatever" to the URI scheme which gets put into the already available msg field in the tx metadata?

Implementation would need the usual splitting of that URL encoded string if it exceeds 64 characters, but that standard is already defined.

Only limitation would again be the URL-length limit, which is up to the creator of the URL to take care of.

For the use case of matching transactions on the backend of a payment system, this would already be sufficient. All you would do is throw your unique identifier in there. Probably best to keep this simple at this point and if payment systems arise with a more unique metadata requirement, this could/should be an own CIP?

[rphair]

could really be as easy as adding a "&msg=whatever" to the URI scheme

As I was saying above (and another reason to get lots more people brainstorming this), the devil is in the details: what if someone has a Cardano native token called MSG? It's another "boundary case" that needs to be accommodated with an exhaustively described syntax for all possibilities and associated rules for disambiguation & conflict resolution. You'd have similar collision risk with any other keyword to clarify the use of payment handles.

I'd suggested in one of our latter CIP-0013 PRs that we should have a //payment authority with a new CIP for it, but going ahead with it now might lead to the same stall we saw after I added the specification for //stake and then nobody adopted it due to lack of commercial interest: not just from wallet developers but pool analytics providers (most of whom had something to lose from easy reassignment of stake from their well-known pools).

So developing a //payment CIP would be justifiable but could still be ineffective unless potential implementors were involved in that discussion: and as collaborators rather than critics. @Crypto2099 @Ryun1 how could one best get that community to engage in this discussion: Discord? A draft CIP?

[Crypto2099]

Hey guys, great convo so far from @rphair and @MadOrkestra! I'm excited about this and having talked to both contributors so far, eager to do my part where I can to help advance the overall ecosystem adoption of web+cardano URIs and all of their myriad variations.

We have had a number of other proposals to utilize these URIs such as:

• CIP-99
• A "pointer" scheme from @Quantumplation to point to transactions or blocks
• A new "authentication" CIP I was preparing to write this week

In light of this, I'm happy to also add to my workload a new CIP to iterate above CIP-13 and implement a dedicated "payment" URI scheme where we can work through the metadata, native asset, and potentially the DNS resolution issues. I believe this is a problem that we can solve (within some certain limits).

[MadOrkestra]

As I was saying above (and another reason to get lots more people brainstorming this), the devil is in the details: what if someone has a Cardano native token called MSG? It's another "boundary case" that needs to be accommodated with an exhaustively described syntax for all possibilities and associated rules for disambiguation & conflict resolution. You'd have similar collision risk with any other keyword to clarify the use of payment handles.

True. Probably using a prefix for asset names is the way to go to make this somewhat future-proof for further parameters to be added at a later date and not conflict with asset names, but sure, we need some wallet developers in this discussion first.

So developing a //payment CIP would be justifiable but could still be ineffective unless potential implementors were involved in that discussion: and as collaborators rather than critics. @Crypto2099 @Ryun1 how could one best get that community to engage in this discussion: Discord? A draft CIP?

FWIW: I made the rounds in all Discords and talked to all the wallets listed above (plus Tokeopay, who weren't aware of this CIP at all, so they too have already created their own solution... they were open to implementing however)

Not sure what else can be done. Maybe the way forward will indeed be to push down the current Path to Active, as mentioned, BeginWallet will implement and rollout full CIP13 support. And then get ppl to use it, so it gets the publicity CIP-99 got when Hosky started using it.

[Crypto2099]

The progress has begun by first defining a "CPS" dedicated to web+cardano: URIs so that hopefully we can create a singular point-of-reference for future implementers that can contain links to the various CIPs as well as software solutions (libraries?) to help aid adoption: #841

[MadOrkestra]

Thanks @Crypto2099 for pushing onwards, I think this is the way to go and we'll hopefully be able to put CIP13 live once BeginWallet (and hopefully others, still trying to push Yoroi) rolls out full support.

Just leaving this here, so I don't forget for the new Payment Authority CIP: As we are doing this right now, from a UX point of view it'd be great to have a callback URL the wallet hits/visits after the transaction is complete or denied. This would enable further actions on the payment frontend, because other than waiting for the transaction to arrive, there is no way to know if a user actually did scan the QR code / clicked the link and took further action. This has multiple implications again, URL length just being one of them, but I have some ideas on this.

[rphair]

As additional "motivation" — for both this issue participation & related CIPs — it would be helpful to surpass Solana in this aspect: given their facility is completely centralised & ours would be generally decentralised. 🧐 [external news article from today] https://cointelegraph.com/news/new-solana-feature-allows-crypto-transactions-any-website

[MadOrkestra]

Updated the overview, beginWallet has successfully rolled out payment link support and deeplinks in the last release.
I'll update the CIP Readme later today to reflect the current state of this CIP.

Still waiting on wallets to implement the staking scheme.

[MadOrkestra]

leaving this here for good measure and to push us to finally get this CIP13/Cardano URI scheme business going again, we still have dRep delegation and properly implemented Deeplinks on the agenda too (I think, not fully caught up on what has been going on in other threads).

@francisluz has now integrated payments with CIP13 and "improvements" into beginWallet (https://x.com/BeginWallet/status/1941614893691724100) so we should probably get going before every wallet comes up with their own solution for tokens/native assets?

@francisluz can you share the implementation you're using on begin for other assets than ADA? Maybe we can take it from there? @rphair @Crypto2099