Completed: Bounty #27b - NoKeyWallet - Rust - up to $10k

Rust NoKey Wallet - #27b

Current Status: Discussion

  • Discussion (10/21/2022)

  • Ratification

  • Open for application

  • Assigned

  • In Review

  • Closed

Official Link

Bounty Details

  • Bounty Amount: $5,000 USD of ICP at award date - $5000 USD of ICP Match Available

  • DFINITY Foundation Grant Match Available: $2000 USD of ICP at award time - (For every ICP sent to 8e6a56cf83240d1f07afe5002d8ce3574e2bde9ede8c4a8964cd6b53c40d0c22, will add $40 USD of ICP at award date to the bounty, up to the first 125 ICP donated, After 125 ICP, donations to the above address will add .25 ICP to this issue and .75 ICP to fund other initiatives)

  • Project Type: Team

  • Opened: 09/05/2022

  • Time Commitment: Weeks

  • Project Type: Library

  • Experience Type: Intermediate - Rust;


This Rust class is allows for canisters to hold assets on other EVM based chains.

This bounty gives the opportunity to

  • learn Rust

  • learn about signing transactions

  • learn about evm transactions

  • learn about t-ecdsa

  • learn about managing nonces

The NoKey wallet is a stable class that any Rust canister can add that will allow it to act as a wallet for Evm-based chains. It should implement the following features:

  • Derive a t-ecdsa key according to a consistent derivation scheme.

  • Save that derivation for the user in a (Nat,Text) pair.

  • Sign Evm-based transactions with a t-ecdsa key selected by the wallet owner. The transaction will be passed in as part of the sign function sign(rawtrx, {#derivation([Nat], #named(id)}, nonce, other Info?, saveHistory)

  • Keep a history of signed transactions.

  • Enable clearing the history

  • Provide an upgrade strategy, preferably using stable vars.

  • Suggest and follow a safe nonce generation/management scheme that protects the user.

To apply for this bounty you should:

  • Include links to previous work writing tutorials and any other open-source contributions(ie. your github).

  • Include a brief overview of how you will complete the task. This can include things like which dependencies you will use, how you will make it self-contained, the sacrifices you would have to make to achieve that, or how you will make it simple. Anything that can convince us you are taking a thoughtful and expert approach to this design.

  • Give an estimated timeline on completing the task.

  • Post your application text to the Bounty Thread

Selection Process

The developer’s advisors will propose a vote to award the bounty and the Developer Advisors will vote.

Bounty Completion

Please keep your ongoing code in a public repository(fork or branch is ok). Please provide regular (at least weekly) updates. Code commits count as updates if you link to your branch/fork from the bounty thread. We just need to be able to see that you are making progress.

The balance of the bounty will be paid out at completion.

Once you have finished, please alert the dev forum thread that you have completed work and where we can find that work. We will review and award the bounty reward if the terms have been met. If there is any coordination work(like a pull request) or additional documentation needed we will inform you of what is needed before we can award the reward.

Bounty Abandonment and Re-awarding

If you cease work on the bounty for a prolonged(at the Developer Advisory Board’s discretion) or if the quality of work degrades to the point that we think someone else should be working on the bounty we may re-award it. We will be transparent about this and try to work with you to push through and complete the project, but sometimes, it may be necessary to move on or to augment your contribution with another resource which would result in a split bounty.


The bounty was generously funded by the DFINITY Foundation. If you would like to turbocharge this bounty you can seed additional donations of ICP to 8e6a56cf83240d1f07afe5002d8ce3574e2bde9ede8c4a8964cd6b53c40d0c22. ICDevs will match the bounty $40:1 ICP for the first 125 ICP out of the DFINITY grant and then 0.25:1 after that. All donations will be tax deductible for US Citizens and Corporations. If you send a donation and need a donation receipt, please email the hash of your donation transaction, physical address, and name to More information about how you can contribute can be found at our donations page.

FYI: General Bounty Process


The draft bounty is posted to the DFINITY developer’s forum for discussion


The developer advisor’s board will propose a bounty be ratified and a vote will take place to ratify the bounty. Until a bounty is ratified by the Dev it hasn’t been officially adopted. Please take this into consideration if you are considering starting early.

Open for application

Developers can submit applications to the Dev Forum post. The council will consider these as they come in and propose a vote to award the bounty to one of the applicants. If you would like to apply anonymously you can send an email to austin at icdevs dot org or sending a PM on the dev forum.


A developer is currently working on this bounty, you are free to contribute, but any splitting of the award will need to be discussed with the currently assigned developer.

In Review

The Dev Council is reviewing the submission


The award has been given and the bounty is closed.


DFINITY Foundation Grant: - $5000 USD of ICP at award date

Other Bounties


I’m interested along with @nikolas-con for this bounty.

Design Overview

The project will have 2 parts, a rust library with unit tests and an example project with an ICP canister and a simple frontend. We will also make a Readme on how to use the library and how to import the Rust library in other projects.

  1. Rust library
  • Functions: create_public_key, get_caller_public_key, sign_raw_transaction, get_caller_transactions, clear_caller_history, stable_save and stable_restore
  • Dependencies: At the moment we are editing the signed transaction hex manually and we don’t use external libraries other than ic_cdk, ic_cdk_macros, candid. In the final version we probably use a few libraries to sign the transaction instead of doing it manually.
  • Consideration: The library should support different types of EVM transactions (eg. eip-2718, eip-1559, history)
  1. Example project (Rust canister + React frontend)
  • Functionality: Connect wallet (Plug wallet), Create Ethereum wallet, Transfer ETH

  • Dependencies: ethers, hardhat, ethereumjs-tx, react

The example project will show how to use the library. It will be a simple No Key wallet with ICP.

Estimated timeline

  1. Create a POC that signs an EVM transaction on ICP - Done
  2. Setup a proper project to accommodate the library (including tests, example project etc) - 1w
  3. Add functions to the Rust library to create user public key and manage transactions history and nonces - 2w
  4. Handle different transaction types - 2w
  5. Implement stable save and restore - 1w
  6. Add unit tests for the Rust library - 2w
  7. Implement example project to showcase a no key Ethereum wallet 1w

Open-source contributions

  1. IDLE Finance bounty #18
  1. IDLE Finance bounty #11
  1. Open Source project (I maintain)

I’d also love to see a way to just submit a raw transaction…no reason this wallet couldn’t sign the creation of it’s own contracts on evm chains.

I’ve asked the board to approve and I don’t for see any issues. Let’s focus on the Rust version for you all…I’d love another group to do the motoko version and coordinate with you all on it. It could/should probably use the same interface and setup.

For the main library we are looking to fully support raw transactions, whether they are transfers, contract calls or smart contract creation transaction.

At the moment our POC works with Ethereum (and a local Hardhat instance). Later will have to look into other EVM chains and see if there are any changes necessary.

Sure thing, we are happy to help.

Hey @skilesare ,

We have made significant progress with the library.

Here’s the repository:

So far we’ve built the main functionality to create (and store) EVM addresses and sign (and store) transactions on behalf of the canister. We also added support for Legacy, EIP1559 and EIP2930 transaction types and different chain ids (eg. Ethereum testnets, Avalanche, BSC etc).

Up next:

  1. Handle nonce differently for each EVM chain

  2. Add more unit tests

  3. Add two more e2e tests (for creating a smart contracts / ERC20 transfers)

  4. Work on the “no key wallet” example canister to make more visually pleasing

Might also be a good time to have a look on the repo just to check we are on the same page. Also, what should we call the rust crate for this library?


Guys…this looks amazing so far. I don’t have a great answer on the Rust question as I don’t know my way around that ecosystem much. Can a rust dev make a comment?

I don’t know much about the EVM but I took a quick look and had some initial thoughts on the randomness and private keys in the wallet:

  1. I imagine it’s better to use the randomness from the IC instead of the getrandom crate
  2. People seem to agree that a private key stored in a canister would be very difficult to exfiltrate but not impossible.
1 Like

Maybe supporting standard derived path would be much better. We will open-source something soon, we can discuss later

1 Like

This can be useful: GitHub - rocklabs-io/ic-web3: Ethereum RPC client for canisters on the IC, ic-web3 can help access Ethereum RPC endpoints and sign/send Ethereum transactions from within canisters.


This particular package is using t-ecdsa I believe.

I don’t think so:

1 Like

Ah…ok. @LiveDuo we should be using t-ecdsa to sign these in a secure way. It may be ok to have a switch and just use a random key if a dev wants that kind of security, but it is likely not something that would be used in production. (Might be great for testing though).

@skilesare @paulyoung
We are using the sign_with_ecdsa system call to sign transactions. The getrandom library is only used for getting a random private key in unit / integration tests.

We enabled the js cargo flag because cargo build tries to include the getrandom library and has issues with wasm32-unknown-unknown target.

If there’s a better way to get randomness in unit / integrations tests we are happy to look into it. We will try changing the getrandom dependency to dev-dependencies and see if that works. Also, happy to change the js cargo flag if there’s a better way.

1 Like

People seem to agree that a private key stored in a canister would be very difficult to exfiltrate but not impossible.

Are there actionable things around this? Should we include a warning in the Readme file?

1 Like

That makes sense. Moving to dev dependencies makes that clearer.

A consumer of this crate might still see that and do the same thing, but my main concern was that the library itself was using it.

As an author I would over-communicate the risks involved so that people don’t overlook them or feel misled.

I tried to do that here: GitHub - codebase-labs/ic-auth-tokens: Generate authentication tokens based on the randomness provided by the Internet Computer

As a consumer I would really appreciate it being called out up front.

Given that it’s just used for creating a private key for testing we can possibly get by without it. An option is to hardcode an example private key for our tests.

As an author I would over-communicate the risks involved so that people don’t overlook them or feel misled.

I tried to do that here: GitHub - codebase-labs/ic-auth-tokens: Generate authentication tokens based on the randomness provided by the Internet Computer

As a consumer I would really appreciate it being called out up front.

There were a few forum discussion about the issue. Might be a good idea to include links to those too.

I came across a discussion about increasing the subnet size for the ecdsa signing canisters a few weeks ago. I was under the impression that the subnet will increase in size to (partially?) mitigate the issue.

Looking forward seeing how far how you guys gone.

We thought about supporting the standard derivation path and we probably end up doing it. We are thinking about providing two signing functions - one with only the required parameters for those that don’t know Ethereum as much and one with more parameters that gives developers more flexibility.

Do you have any use cases in mind?

I’m trying to understand the motivation for storing the private key. It seems unnecessary.

If that’s the case and you’re relying on tECDSA then I would encourage consumers of the crate to do the same (perhaps by doing that in the wallet?)