Assigned: BNT-13 - Motoko Certified Assets Canister


Status: Assigned
Project Type: Cooperative - Multiple workers can submit work, and the bounty is shared
Time Commitment: Weeks
Experience Level: Intermediate
Size: USD 5’000 in ICP (at time of distribution)


For some time, dfx has included an assets canister. This canister facilitates the storage and retrieval of static assets. It is automatically provisioned when the canister type in dfx.json is designated as assets.

Assets can be delivered via either or the more secure, with the latter being the recommended best practice. Assets served through are expected to be certified, with the boundary nodes verifying that the replica replying to the http_request hasn’t altered the output. This behaviour is specified in the HTTP Gateway Protocol.

Currently, only a Rust version of a certified assets canister exists. Although DFINITY’s asset canister was originally crafted in Motoko and there are additional Motoko versions available, these lack asset certification. Consequently, they can only be accessed via the less secure A primary reason for this limitation was the absence of adequate developer tools for the smooth implementation of certified assets in Motoko. However, with the introduction of ic-certification, the situation has evolved, equipping developers with the essential components to construct a certified assets canister using Motoko.

Leveraging the ic-certification, we’ve introduced the certified-cache library, simplifying the caching of certified API responses. Another noteworthy library, assets, equips canisters with the essential logic to manage assets in line with the asset canister interface utilised by both dfx and @dfinity/assets. Integrating these functionalities, the server library offers a straightforward HTTP server for Motoko. Within its repository, the http-greet example nearly achieves a full-fledged assets canister implementation in Motoko. However, it misses several key features:

  • Chunked uploads
  • Streaming
  • V2 certification
  • Testing
  • Access control

The objective of this bounty is to incorporate the above-mentioned features into assets
subsequently transforming the http-greet example into a comprehensive certified assets canister.

Acceptance Criteria

  • The implementation shall fully mirror the existing Rust certified assets canister functionality and interface (including v2 certification)
  • The code shall be of production quality, have good documentation and reasonable test coverage.
  • The code shall be open sourced with an MIT license.

How to apply?

Include links to previous relevant work.
Include a brief overview of how you will complete the task.
Post your application to this forum thread.



Hey @domwoe, We have almost all of this (except maybe V2 certification which we haven’t looked at) baked into the ORIGYN_NFT and it should be generalizable. @ferMartz could take a look and see how far we are.

Chunked Upload(Fernando has done this work in conjunction with @infu and @nomeata 's libraries but we haven’t merged it yet:

Access Control: This is obviously focused on NFT based scenarios at the moment, but only collection owners can upload assets, so it likely just needs to be modified.

Testing: We have some basic testing in the project…all motoko tests. Likely some additional streaming tests would be good to have.

V2 Certification: Where can we look up more info on how this changed?

As far as serving the files, they currently get served out of an NFT based schema so that each NFT is basically its own asset canister, but this can be generalized for a single set of files pretty easily.

Hey @skilesare,

sorry for the late response. I was on vacation last week.

It’d be great to have you and @ferMartz work on this.

I see that you already started a thread about this: Certification v2 Questions - #3 by skilesare

Anything else you need?

I think we need to pick up the thread with @NathanosDev to get V2 working. Likely we can get a v1 version pretty easily as we have all the pieces. Some clarity around the details for things like how to handle streaming(one big file using a streaming strategy or certify the chunks…what about byte-based requests…etc) would be helpful.

Bounty is assigned to @ferMartz! Keep us posted!

Hi @skilesare @domwoe!

Looking forward to this! We are also planning to look into this the coming week.
I will post updates here if there are any.


Unfortunately, @ferMartz has withdrawn. The bounty is open again!

1 Like

@tomijaga decided to tackle the bounty. Looking forward to the progress


By the way, I’m happy to hand over the package "assets" to this project in mops once the work is complete! Or to take over distributing it, however the devs would like to handle it