# Let's discuss reproducible builds and code verification once again

**URL:** <https://forum.dfinity.org/t/lets-discuss-reproducible-builds-and-code-verification-once-again/41918>\
**Category:** Developers\
**Created:** [March 5, 2025, 1:00pm UTC](https://forum.dfinity.org/t/lets-discuss-reproducible-builds-and-code-verification-once-again/41918 "2025-03-05T13:00:51Z")\
**Posts on this page:** 1\
**Showing post:** 41

<div class="post-metadata">

**Author:** ![skilesare](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/skilesare/32/5609_2.png) [@skilesare](https://forum.dfinity.org/u/skilesare)\
**Post date:** [March 19, 2025, 2:33am UTC](https://forum.dfinity.org/t/lets-discuss-reproducible-builds-and-code-verification-once-again/41918/41 "2025-03-19T02:33:41Z")

</div>

I’ve put together a set of ICRCs that together form a wasm registry capable of deploy and upgrading canisters via governance(a sort of formalization of what the SNS does plus some other helpful things). One of the items specifically discusses a framework for having third parties verify builds. The actual process, incentives, and security of doing so were purposely left out so that various things could be tried with the same interface.

> [@ICRC-105 and it's seven cousins](https://forum.dfinity.org/t/icrc-105-and-its-seven-cousins/42596):
>
> Hello everyone, [ICDevs.org](http://ICDevs.org) is excited to present the following work that lays the foundation for a project we’re calling AstroFlora. AstroFlora seeks to build on top of the work we’ve done at [https://daos.icdevs.org](https://daos.icdevs.org) by building out the lego blocks that one would need to implement the patterns and forms identified in that project. The IC currently offers a couple different options for launching new tokens with the most successful and popular being the SNS. Features are added to the SNS c…

Specifically ICRC-26 lays out the interface and associated icrc-3 blocks.

As part of this I reserved some space for ICRCs for the actual build process:

Motoko Build Verification - [ICRC-128](https://github.com/dfinity/ICRC/issues/128)  
Rust Build Verification - [ICRC-129](https://github.com/dfinity/ICRC/issues/129)  
Azel Build Verification - [ICRC-130](https://github.com/dfinity/ICRC/issues/130)  
Kybra Build Verification - [ICRC-131](https://github.com/dfinity/ICRC/issues/131)  
C++ Build Verification - [ICRC-132](https://github.com/dfinity/ICRC/issues/132)

I’d love viewpoints (and maybe contributions?) from @icpp for c++, @timo for motoko, @lastmjs for Azel and Kybra, and I’ll let you rust guys hash it out. :). I don’t know if there is a huge hurry for this but I thought I’d reserve the space as I assume we’ll eventually want to put something down on digital paper. I’ll probably take a swing at formalizing what Timo’s done on the motoko side if Timo doesn’t do it first, closer to when we actually release something as many of the initial modules we’ll put into the system will be motoko.

---

_[View the full topic](https://forum.dfinity.org/t/lets-discuss-reproducible-builds-and-code-verification-once-again/41918)._
