Awarded: - Bounty #30 - RLP - Motoko - $4,000

RLP - Motoko - #30

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: $4,000 USD of ICP at award date
  • Bounty Acceleration: or each 1 ICP sent to d0e3be904a939ff752979aaa53cfb66fac8d75b85ce4fa878e147d60706be6ed, will add .25 ICP to this issue and .75 ICP to fund other initiatives.
  • Project Type: Individual
  • Opened: 01/09/2023
  • Time Commitment: Days
  • 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 RLP encoding and Decoding in motoko. Some of this work has been started at GitHub - icdevs/ but it has not been tested or completed. To claim this bounty make all the tests pass and be able to encode and decode RLP. The library should be set up to work with vessel and MOPS.

Completing this bounty will give the developer the chance to tackle Bounty 32 - Merkel Patricia Trees - Motoko, and eventually, Bounty 27a - No Key Wallet Motoko

This bounty gives the opportunity to:

  • learn motoko
  • learn about evms and RLP encoding

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 d0e3be904a939ff752979aaa53cfb66fac8d75b85ce4fa878e147d60706be6ed. ICDevs will match the bounty $40:1 ICP for the first 50 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

Hi, I can complete this task.
This feature request is a prime candidate for test driven development due to the RLP algorithm being so neatly broken down into different cases/parts.
I can see that much/most of the logic has already been implemented.
As a result, this task will mainly be focused on documentation, testing, refactoring, and package manager config.
I will break up the feature into 12 parts and tackle each part the same way.
The first 6 parts will be RLP encoding of

  • single bytes,
  • byte array of 0-55 bytes,
  • byte array greater than 55 bytes,
  • list of byte arrays of 0-55 bytes,
  • list of bytes arrays greater than 55 bytes,
  • not encodable structures.

The next 6 parts will be the decoding of the mentioned structures.
At the beginning of each part I will create an exhaustive list of test cases for the “items/structures” to be encoded/decoded as well as documentation and examples. Then I will add only the existing code which makes the tests pass. Any test failures or missed edge cases will be fixed by extending or refactoring the existing code.

As I write tests, documentation, and refactor the encoding/decoding of each type of structure, I can provide progress updates by linking to commits or PR’s.

One possible extra feature that I could implement would be support for dictionaries/maps - I would implement a mapping from dictionary/map to the Ethereum doc’s suggested canonical form of: [[k1,v1],[k2,v2]...] with keys in lexicographic order, before passing the list to be encoded. The correct decoding back into a map would also be implemented. This helper functionality would live in a seperate module and the RLP base logic would have no dependencies on it.

Happy to chat further about implementation details or my qualifications.

1 Like

I submitted you for pipelineify…would you rather do this one first?

Hey, yes I’d prefer to do this one first. I can get started today.

Update 1



First update since the start of the bounty last week.
Most of my progress has been related to project setup, cleanup, and running tests.
I have cleaned up dependencies and switched the test runner library to: GitHub - internet-computer/ Testing Framework for Motoko
I have ported the original test cases into this new library and I have added missing encoding tests from: go-ethereum/encode_test.go at 99be62a9b16fd7b3d1e2e17f1e571d3bef34f122 · ethereum/go-ethereum · GitHub
The test runner is able to run 26 tests - of which 17 pass and 9 fail. The test runner traps on 8 tests.
Total of 17 failing encoding tests.
npm run test will run all non trapping tests.

In Progress

I have begun working through every input variant type ensuring failing tests pass for encoding.
Once this is done, I will repeat the same process with decoding.

Update 2



The repo is ready for review and feedback.

In Progress

I’ll start initial work and discovery on the Pipelineify bounty.

I’ll prioritize implementing any feedback on this project as it comes in.

1 Like

@skilesare - tagging you here for visibility, thanks.

1 Like