Assigned: RFP-7: Wallet Standard Reference Implementation

Developers Bounties
1

Overview

The IC ecosystem already contains a number of different wallet applications and approaches. However, there is no standard around wallet integration yet. This RFP looks to kickstart the work on a possible wallet standard implementation that works for all dapps and wallets. Applicants are expected to apply for a 25k grant.

We are looking for an open-source implementation of a wallet, a dapp that integrates with that wallet, and a dummy target canister that implements the ICRC-21 (draft) consent message interface. This implementation should then serve as a guiding example for other wallets and dapps on the IC.

Requirements

  • The dapp must be able to request signatures on arbitrary canister calls to arbitrary target canisters.
  • The wallet must be able to sign arbitrary canister calls alongside the corresponding read_state request.
  • The wallet must display a consent message to the user as specified by ICRC-21 (draft) and allow them to sign or reject the request. If the target canister does not implement the ICRC-21 (draft) interface, the wallet should display a warning to the user.
  • The wallet must implement interfaces for both hot and cold wallet use-cases.
    • Note: cold wallet interactions can be simulated by restricting the wallet to just using the JSON-RPC messages with the dapp. I.e. in the cold-wallet case, the wallet must not communicate (directly) with any other party than the dapp itself and must only use the JSON-RPC message channel.
  • Any suitable channel for communication between the dapp and the wallet can be used. However, the wallet should be able to be used with any dapp that implements the wallet integration. A non-exhaustive list of suitable channels:
  • The interactions between the dapp and the wallet should use JSON-RPC messages and be adaptable to other channels (see above).
  • The code must be open-source.
  • The code must have production quality.

Considerations

Given that the implementation will be used to derive future ICRC standards related to wallets, extra emphasis is placed on the following points:

  • The code should be well documented and easy to understand.
  • The code should implement security best practices.
    • In particular, the validation of consent messages must be done in a secure way.
  • There should be a live demo of the wallet and dapp deployed to the IC so that it can be easily tested by the community. If the wallet or dapp is a browser extension or mobile app, it must be published on the respective extension / app store.
  • Due to the scope and complexity of the project, it is expected that the applicant has prior experience with the IC and development of wallet applications.
  • The wallet standards are discussed in the Identity and Wallet Working Group. As an implementer, you are expected to join the biweekly working group meetings to present your progress.

Milestones

This grant has three milestones:

  1. Architecture and design of the wallet, dapp, and example target canister as well as the specification for the JSON-RPC messages.
  2. End-to-end hot wallet canister call signing use-case:
    (a) Dapp requests a signature on a canister call from the wallet.
    (b) The wallet fetches the consent message from the target canister (if available).
    (c) User approves / rejects the request.
    (d) If approved, the wallet signs the canister call and the read_state request and sends it back to the dapp.
  3. End-to-end cold wallet canister call signing use-case:
    (a) The dapp fetches the consent message from the target canister (if available).
    (b) Dapp requests signature on the canister call from the wallet and provides the matching consent message.
    (c) The wallet validates the request and consent message.
    (d) User approves / rejects the request.
    (e) If approved, the wallet signs the canister call and the read_state request and sends it back to the dapp.

Milestones 2 and 3 require a live demo of the wallet, dapp, and dummy target canister deployed to the IC as well as passing a security audit (the applicant does not bear the cost of the security audit).

How to apply?

Please submit your application at Internet Computer Loading mentioning RFP-7 and selecting the 25k tier. There youā€™ll also find more details about the DFINITY Developer Grants program. Please provide details about your timeline for finishing this project.
If you have questions, please post to the following thread on the Developer Forum or the grants channel in the Developer Discord.

References

7 Likes
2

This is super cool. Iā€™m guessing this has a significant overlap with what Retired: ICDevs.org Bounty #15 - Motoko Wallet - $5,000+ was supposed to be. I need to dig into this and see what all is involved.

Will this work with canister wallets? If using a canister wallet, do you need an signature?

3

Hi @skilesare

I think in the case of canister wallets we have to distinguish two cases:

  1. canisters that use their raw canister id as the ā€œwallet principalā€
  2. canisters that provide canister signatures and thus the ā€œwallet principalā€ is derived from a public key (see spec)

The first variant is a bit of a special case, because they are the only type of wallet AFAIK, that is unable to provide a signed canister call envelope back to the relying party, but instead needs to submit the call itself. For this variant, we might want to add a special case in the standard later on. But initially, wallets of this type will not be able to implement the standard. IMHO, I would advise against using the canister id directly exactly for that reason.

Also, as an added benefit of using the second design (apart of having the same interaction model as any other wallet), is that you get the ability to derive as many principals as you need / like from a single canister, thus simplifying management of identities a lot if you want to use multiple (e.g. for different purposes).

For canister wallets of the second type, these standards will apply directly, yes.

1 Like
4

Another reason to do Derived Canister IDs!

I almost wish weā€™d never done the other ā€˜standardā€™ plugin-style wallet at all on the IC and only had canister-based wallets. All our ORIGYN NFTs will have canister-based wallets in them and there are other features we expect to add that lean into the canister wallet paradigm.

2 Likes
5

Glad reading this. We will see what we can do. Thanks @domwoe and @frederikrothenberger to take it to standard level

1 Like
6

Hi @domwoe and DFINITY Team,

Iā€™m thrilled to respond to this RFP.
As a solo developer, Iā€™ve been actively working on two distinct projects on the Internet Computer: B3Pay and B3Wallet. Both projects are fully decentralized.

B3Pay is a versatile payment solution designed to accept payments fully on-chain from both Bitcoin and EVM-based chains.

B3Wallet, on the other hand, is not only focused on meeting the standards outlined in this RFP but also aims to redefine them. Itā€™s a unique wallet canister per user, fully owned by the user. Itā€™s capable of signing transactions upon request and confirming the style, thereby ensuring a secure and user-friendly interface. I am currently enhancing its capabilities to ensure full integration with a variety of wallets and canisters. B3Wallet also includes a multi-owner feature and confirmation request mechanism, offering capabilities that traditional wallets do not.

Communication is a critical component of my design strategy. My approach includes implementing various suitable channels such as Browser window.postMessage, Browser extension message passing, WalletConnect, QR codes, and more.

I strive for high production quality, stringent security practices, and comprehensive documentation as top priorities. B3Wallet project will be my entry for the upcoming Bitcoin Hackathon, and I believe winning a prize there would further validate my efforts and support these projectsā€™ development.

Upon completion, I intend to open-source both B3Pay and B3Wallet, and I plan to transition them under the control of a Service Nervous System (SNS) to ensure continued decentralization and community ownership.

At the moment, Iā€™m not ready to provide detailed specifics, but rest assured, in the near future, I will share more information, including a demo, with the community through this forum. This will not only serve as a showcase of my work but will also enable me to gather valuable feedback and refine the projects according to user needs.

Iā€™m excited to contribute to the flourishing IC ecosystem and I welcome any suggestions or additional requirements you might have.

Best,

Behrad Deylami

1 Like
7

I really hope something come out of this. It would be a great step forward!

8

Thank you for your interest. I sent you a PM on the forum.

9

Quick update: Weā€™ll be considering applications until the end of this week (June 2nd).

10

Papers, the team behind AirGap and Beacon got selected.

1 Like