Awarded: - Bounty #32 - EVM Transactions - Motoko - $8,000

EVM Transactions - Motoko - #32

Current Status: Discussion

  • Discussion (01/09/2023)
  • Ratification: (01/09/2023)
  • Open for application: (01/09/2023)
  • Assigned
  • In Review
  • Closed

Official Link

Bounty Details

  • Bounty Amount: $8,000 USD of ICP at award date
  • Bounty Acceleration: For each 1 ICP sent to 4dc0678d04c632921a7e5b913a4e3f185a3b48e2da6cba71f4be1e86272a789b, will add .25 ICP to this issue and .75 ICP to fund other initiatives.
  • Project Type: Team
  • Opened: 01/09/2023
  • Time Commitment: Weeks
  • Project Type: Library
  • Experience Type: Intermediate - Motoko; Intermediate - EVM;


As we make progress to further integrating EVM based blockchains with motoko, we need more EVM based tools. While Bounty #29 seeks a short term solution, this bounty seeks to implement the fundamental libraries needed to build and verify transactions and data on motoko canisters without having make an async call to a utility canister.

To execute this bounty you need to implement the creation, encoding, and decoding of EVM based transactions in Motoko. This work has been replicated in RUST at GitHub - nikolas-con/ic-evm-sign: A library to sign EVM transactions on the Internet Computer. and you should generally follow the candid structures used in this project and replicate the functionality in motoko. The library should be set up to work with vessel and MOPS.

The library should support multiple network ids and transaction types like Legacy, EIP1559, EIP2930.

You should also implement the various helper functions in the Ethereum js library: ethereumjs-monorepo/packages/util at master · ethereumjs/ethereumjs-monorepo · GitHub with proper tests.

Completing this bounty will give the developer the chance to tackle Bounty 27a - No Key Wallet Motoko which will finalize the functionality and use t-ecdsa to sign and manage these transactions.

This bounty gives the opportunity to:

  • learn motoko
  • learn about evms and transaction types

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 4dc0678d04c632921a7e5b913a4e3f185a3b48e2da6cba71f4be1e86272a789b. ICDevs will match the bounty $40:1 ICP for the first 75 ICP out of the DFINITY grant and then 0.25:1. 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

Ratification: (01/09/2023)

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.

Other Bounties

1 Like

Hi, @skilesare, I would like to work on this bounty.

Now with the RLP and keccak256 motoko libraries it’s possible to tackle this challenge.

My github: av1ctor (v1ctor) · GitHub

Thanks in advance!

Hi @skilesare, is this up for grabs? If yes and @v1ctor is not available to tackle this, then I would like to take this up.

Hey , has this been implemented , because i am working on this …

@v1ctor are you working on this at the moment?

here’s my github , dipanshuhappy (Dipanshu Singh) · GitHub

Hi, @skilesare, yes I’m working on it, but I never got any answer since I posted that message applying for this bounty.

There’s a doubt though: the bounty description tells it should replicate the ic-evm-sign, but signing the tx is not part of the scope, right? That would need libsecp256k1 to be ported to motoko, and I didn’t find a library yet that could do that (implementing one in motoko would not be a simple task).

I apologize for the delay…you’re approved to work on it.

…and yes…I assume that the signature is part of this… Maybe this is far enough along: GitHub - mix-labs/libsecp256k1: Pure Motoko Implementation of secp256k1.

If it is just impossible we can talk about it. Give that library and look and see how short it falls.

Looks like V1ctor is already working on it. Is there something else that would be cool for you to work on? We just release a bunch of new bounties here: Bounties - Internet Computer Developer Forum

Well @v1ctor , waiting on it :+1: , i guess i will use the rust sdk for now , but yeah i do plan on working on bounties , i will look into them.

Any idea on when the ICP <> Eth integration will be done?

You should be the output of Until viscor finishes if you need motoko. It will be async, but should get your eth transactions signed.

As far as eth integration goes, this is a bit of what we are doing here! I think the community is working on se.more robust canistesnfor querying state and roots from services, but there is no reason you can’t do those yourself if you are willing to rely on just, say, infura and trust it.

No prob, thanks!

Nice, I was not aware of that secp256k1 port to Motoko. It shows it’s 70% done, that’s a great start. If there’s something missing I will try to port myself from C or Rust and open a PR at the repository.

Well i can use that for now … because i just need to get a proof of concept ready , not the final stuff…


Isn’t signing the evm-transaction part of Assigned: Bounty #27a - NoKeyWallet - Motoko - up to $10k?

I’ve already implemented it in my Motoko library - at 474808c71ee7d275771a99c2df0d022d16430a8b · darkdrag00nv2/ · GitHub. It is very close to completion and only e2e testing is remaining.

That being said, it makes inter-canister calls to the evm-utility library for encoding/decoding/hashing as per your suggestion here. If we’re trying to avoid inter-canister calls, then it might make sense to implement it here in pure Motoko.
Otherwise @v1ctor can just use my library to sign the evm-transactions which will make async inter-canister call. May be I am missing something here :thinking:

Ok, after reading & thinking a bit more. I’ve realized that I might have overdone it in the no-key-wallet lib from #27a.

I think the no-key-wallet lib is just supposed to sign the raw transaction and return the signature in the method response. This part does not require any inter-canister calls. I actually went ahead and also used the evm-utility library to encode the transaction along with the signature data. Hence, the inter-canister call. I can remove that part and just return the signature eliminating the async call.

Encoding/Decoding the transaction along with the signature information can be implemented in pure Motoko by @v1ctor as part of this bounty.

Sorry for the confusion :slight_smile: Do let me know in case I am wrong.

Yeah, the idea is not depend on inter-canister calls and do everything in pure Motoko.

The problem is: the current state of the only (known?) port of the libsec256k1 to Motoko (GitHub - mix-labs/libsecp256k1: Pure Motoko Implementation of secp256k1.) is completely broken and has no tests. I forked it and am trying to get it done (at GitHub - av1ctor/mo-libsecp256k1: Pure Motoko Implementation of secp256k1.) but the challenge is way harder than just getting evm-utility library (that could use stable and tested Rust libraries) ported to Motoko - what was the objective of this bounty.

Have you checked motoko-bitcoin/src/ecdsa at main · tgalal/motoko-bitcoin · GitHub ?

It doesn’t use the “v” component when verifying the signature and I’m not a cryptographer, so I have no ideia how to implement the missing methods :slight_smile:

Thanks anyway! I will still trying to debug the libsecp256k1 Motoko port.

FWIW, I ended up implementing (sort of) the derivation of v from the signature (r and s) in my NoKeyWallet library (bounty #27a) - code. I did use the evm_utility canister for calculation of recovery_key though but you should be able to see its code on how it implements recover_public_key and try to replicate that in Motoko. My library is untested as well, so might have bugs but the high level logic should be correct.

Of course, it might be very hard to do, so definitely up to you :slight_smile: