Thanks for the detailed completion report, @mrmtech. We verified the contract on Blockscout: source code verified (exact match), Ownable2Step and all audit fixes are in place, and the on-chain setManifestCid transaction checks out. The CoinFabrik audit and remediation work look solid.
A few items that need to be addressed before moving forward to the M3 proposal:
Fuzz and invariant test evidence is missing. The report references test files at contracts/test/foundry/ and a foundry.toml config, but neither exists on the dev branch. The fuzz testing report (docs/identity/DidManifestRegistry-Fuzz-Invariant-Testing-Report.md) is also not in the repo. The post mentions these will be uploaded āalongside the milestone deliverables,ā but since this is the completion report, weād expect them to be available now for verification.
Monitoring setup not verifiable. The Tenderly dashboard requires authentication, so we canāt verify the alerting configuration independently. Could you share a screenshot of the alert rules and history, or make the Tenderly project publicly viewable?
Broken evidence link. One of the audit report links points to drive.google.com/file/d/YOUR_LINK_HERE/view instead of the actual PDF.
The core work looks strong. Please make sure the complete deliverables are available in the repo before submitting the M3 proposal on-chain.
Fuzz and invariant test evidence checks out on the dev branch, and the audit report link is fixed. Both items are resolved.
On the monitoring side, the screenshot shows alert activity on the contract, but we were hoping to see the alert rule definitions themselves: which events are monitored, notification channels, and any thresholds configured. Could you share one more screenshot of the Tenderly alert configuration page (not the event log) so we can confirm the setup is comprehensive?
Hi @tane
Sure! Here the alerts that we have configured now, CID set, CID delete, and ownership transfer.
Keep in mind this is our testnet environment, thatās why channels is simply an email. Next milestone is to set up the mainnet, and will configure more appropriate channels.
Thanks @mrmtech, all three items are resolved. Weāre satisfied with the M2 deliverables and will support the M3 proposal moving forward.
One note for M3: your fuzz report recommends increasing invariant depth to 500 runs x 100 calls before mainnet. Weād expect to see that reflected in the M3 deliverables.
@mrmtech, we noticed two M3 proposals submitted on-chain: one at $5,000 and a revised one at $4,000. Could you clarify which is the intended proposal and cancel the other? Weād like to vote but want to make sure weāre supporting the correct one.
Hi @mrmtech! We see that two identical proposals were posted on the same day, two and a half hours apart (the first one and the second one). Could you tell us why this happened and which one is the valid one so we can vote?
P.S. @Tane: We see that both proposals propose the execution of USDRIF 4,000 transaction.
You are right, and we somehow got that $5,000 from somewhere else. Apologies. Our and your request stands, though. We need a clarifications on both identical proposals.
Hi team! We made a the proposal, waited for like 4 hours and was not visible, so we assume something happened, and created the second one. Nothing happened for many hours, we asked one of our contacts. Suddenly these morning, both were visible We also asked for a way to withdraw one of them, but were told its not possible.
Thank you so much, @mrmtech for this very through report of the Milestone 2 deliverables. With the completion of M2, it marks a significant step forward for decentralized identity on Rootstock. Following a review of the deliverables and the recent technical discussions with @Tane (thank you for the in-depth review!) exchange on the forum, we have voted in favor of this proposal to support the funding for Milestone 3.
Our reasoning for this support is based on the following:
Rigorous Security Standards: The team went well beyond a standard manual audit by incorporating Mythril symbolic execution and Foundry fuzzing. Executing ~59,000 property checks with zero failures demonstrates a level of technical maturity and āabove and beyondā due diligence that is critical for an identity registry.
Operational Readiness: The implementation of real-time monitoring via Tenderly, specifically for āhigh-riskā events like ownership transfers and CID deletions, proves the infrastructure is prepared for production. The transparency in sharing these alert configurations builds strong confidence in the projectās long-term management.
Technical Accountability: The dual-write pattern (MySQL and Rootstock) and the outbox retry mechanism show that the architecture is built for real-world reliability, ensuring that blockchain latency does not hinder the end-user experience.
We also fully support the recommendation by @Tane to increase the invariant testing depth to 500 runs and 100 calls for the Mainnet migration. This extra layer of stress testing is a logical requirement given the security stakes of SSI. We look forward to the Mainnet deployment and the upcoming pilot programs!
Thank you for delivering such a good report for M2 @mrmtech
Really impressed with the external audit came back with zero critical, high, or medium findings, all recommendations were addressed and verified in a re-audit, your team also went beyond the minimum by adding fuzz testing and live monitoring.
I will vote yes for M3, taking whatās been proven on testnet to mainnet, with production infrastructure and real end-to-end flows. Budget is 4K for 2 months of work which is reasonable given whatās being delivered.
We voted in favor of this proposal to fund Milestone 3, as the proposer has fully complied with the deliverables committed to in Milestone 2 and has adequately addressed the comments made in this thread. We are very pleased to see that, although the first external audit identified only one minor issue and two potential enhancements, you have resolved everything, and this has been verified in the re-audit. We eagerly await the Mainnet launch as a key component of Milestone 3!
@mrmtech We are pleased with the delivery of Milestone 2. The team not only fulfilled the stated requirements but also went beyond them by conducting additional testing beyond a standard audit, including fuzz testing, Mythril, and high-volume test scenarios. This gives us greater confidence in the robustness of the system.
Therefore, we are in favor of supporting Milestone 3, as the technical risk has been reduced and we have strong confidence in the teamās execution.
@mrmtech Thank you for successfully completing Milestone 2 deliverables. I have voted FOR your Milestone 3 proposal!
I want to tag @SwaptoX who is a fellow grantee and as part of their next deliverables milestone, will start to plan for an audit. I thought it would be helpful for them to connect with you and exchange learnings. Please donāt hesitate to loop me in as a delegate point of contact if you have questions or need the collectiveās assistance!
Iām also a Rootstock grantee currently working on the SwaptoX aggregator. As part of my upcoming milestone, Iāll be starting the audit planning soon, so Iād really appreciate learning from your experience.
If youāre open to sharing, Iād be particularly interested in:
how you approached defining the audit scope (core contracts vs. additional components)
what the audit process looked like in practice (iterations, timeline, etc.)
whether you had to go through multiple revisions or significant refactoring
how you handled findings raised during the audit
and any lessons learned or things you would do differently in hindsight
If you have time, Iād really appreciate any insights you can share. Thanks in advance!
What a fantastic recomendation, @Axia , since in our opinion, @mrmtech audit was exceptional and weāre sure there were lessons learned/best practices that could help other builders.
Idealy, if there was a fluid way for builders to connect to share best practices, that didnāt require the delegates as intro middle-men, that would be the perfect scenario. How we foster that type of culture would be something to consider.
Hey @DAOstar_gov, one idea that comes to mind is creating a FAQ / Best Practices guide for builders. The responses to be collected on this forum post can be a good starting point. As delegates and contributors, we should take the mindset of running small experiments.
@Axia , that is a fabulous idea regarding creating a FAQ/Best Practices guide! We also very supportive of your post you reference here to collect feedback directly from builders. We believe that this approach opens up a more collaborative builder ecosystem, when the Collective and the builders are working together to extend the functionality and utilities of RT.
We also asked for a way to withdraw one of them, but were told its not possible.