CIP proposal: mobile deep-link signing for native dapps (CIP-30 extension)

Developers CIPs
1

Hi, posting a draft of CIP-30-DeepLink before I open the PR. it’s a wire-protocol extension on top of CIP-30 that lets a native mobile dapp ask an installed Cardano wallet to signTx / signData over the OS’s deep-link mechanism. no relay server, no embedded webview, no QR, no websocket.

context: CPS-0010 lists mobile-native dapps as a connector shape CIP-30 can’t reach today. CIP-30 is a JS injection contract over window.cardano, so a native iOS/Android dapp running outside a wallet-controlled browser has no standardised signing path. the existing workarounds aren’t great. embed a webview and lose the mobile-native UX, run a custodial signing relay, or ship a private deep-link bilaterally with one wallet. none of those scale across the ecosystem.

the draft profiles the existing CIP-30 method surface (signTx, signData, getUsedAddresses, getRewardAddresses, getNetworkId, optional submitTx, reserved signGovernance for CIP-95) over Universal Links on iOS / App Links on Android, with a per-wallet cip30dl-<wallet-id>: custom-scheme fallback. envelope is X25519 + XSalsa20-Poly1305 (Phantom/Petra shape) plus a separate ed25519 session-signature over a canonical form of every response URL. the Cardano-ethos divergence from Phantom is encrypt and sign, so the dapp can prove which wallet produced the response. BLAKE2b-256 commit over transaction_body binds the signed tx, and source-app identity binds to the redirect host’s AASA / assetlinks.json so the bundle ID rendered on the wallet’s signing screen is the one the OS attests at the network layer (not a self-claim).

two reference impls are in flight at Flux Point Studios. Aegis (parametric insurance dapp, V12.2 live on preprod) on the dapp side, and Yuti (Flutter wallet) on the wallet side. neither has shipped yet, both target the typical CF review window. publishing the draft ahead of the impls on purpose so editors and other wallet teams can shape the design before code calcifies around it.

draft lives here: CIPs/CIP-deeplink-signing/README.md at feat/cip-deeplink-signing-draft · Flux-Point-Studios/CIPs · GitHub

happy to hear thoughts before I open the PR, will hold off opening for at least a week. anything from the editors on submitTx MUST vs MAY, CIP-95 governance in v1 vs v1.1, or the registry-vs-attestation-manifest split would be especially useful.

cc @ryun1 @KtorZ

2 Likes
2

thanks @realdecimalist — as far as I’m concerned, the draft in your branch above is already suitable for submission into the CIP repository itself & would be tagged for Triage straightaway: i.e. introduction, at the next CIP biweekly call, to confirm that it’s ready for the peer review process (which I believe it is).

I especially appreciate your drawing these long-time CIP-0013 considerations into your assessments of both performance & compatibility. As more of the CIP-0013 / CPS-0016 //authority fields get implemented (see tracker issue) I think this is a great time to share these findings with the wallet dev population.

Note you will get @ryun1’s attention immediately (as well as a more compelling platform to tag wallet devs) once the CIP repo PR is submitted (BTW @KtorZ hasn’t been involved as a CIP editor in a while). Links for the biweekly cycle of CIP meetings & how to attend them (open to the public; no reservation required) is on the front page here: CIPs Wiki

2 Likes
3

thanks @rphair, really appreciate the fast read.

opening the PR now then. happy to introduce it at the next biweekly, will check the wiki for the schedule.

glad the CIP-0013 / CPS-0016 //authority cross-refs landed. will keep watching that tracker as the //authority field set grows and surface any wallet-dev friction back into this PR or a v1.1 revision as it comes up.

2 Likes