Hey everyone, the repo available to reviewers have been updated to reproducible builds plus the existing code, we will announce here if it changes due to any upgrades and point at the diff. The sns init file is here as well
I have forgiven you @lorimer bse of this. lets reconcile. but watch your comments
| Bucket | MENES | Share |
|---|---|---|
| Team, as neurons | 18,000,000 | 18% |
| Mercatura Forum, as a neuron | 10,000,000 | 10% |
| Decentralization swap | 10,000,000 | 10% |
| DAO treasury | 62,000,000 | 62% |
| Total | 100,000,000 | 100% |
sns may refuse them first test locally it happened to us and we had to change.
Yes we are aware of that, we agreed with our pre seed VC that they would receive their safe basically post launch through the redemption canister as they are already staked
Cool stuff. I participated, nice frontend, nice experience.
opening Internet Identity — approve in the popup ...
loading the contributor wasm module ...
connected
joined queue: joined; queue position 1
opening staging slot ...
downloading current parameters (transfer 2948360 B, deposit 168200 B) ...
sampling secret + transforming IN THIS TAB (secret never leaves) ...
uploading transformed PUBLIC parameters ...
submitting proof of knowledge (structural checks on-chain; soundness verified off-chain) ...
CONTRIBUTION ACCEPTED: contribution 9 accepted
your secret has been discarded. thank you.
I also confirmed the relevant canister is blackholed. I’ll try and get around to a quick code review and attempt a reproducible build - too many things to do and not enough hours in the day.
For future reference, this was my participation principal - fdqaq-bbqvp-dba4q-pyqxk-v6l5h-7w56p-p5mic-uqw2r-2nksq-35soa-nae
I pointed gpt-5.6-sol high against the shield ceremony repo. Here’s what it came back with in case anyone is interested. I didn’t follow up with my own review of its findings. Unfortunately I don’t have time, nor expertise in this specific area. Just sharing what I’ve got.
• Short answer: the ceremony appears technically genuine, and contribution 9 is cryptographically valid. However, you should not yet consider the resulting protocol or
parameters trusted for real value. The ceremony is unfinished, and I found several material weaknesses in its acceptance and browser-erasure claims.
What I verified
At the time of review:
The live coordinator is blackholed—no controllers—and its module hash is ce34f578….
Rebuilding commit c2b993823334 using the pinned dfx 0.32.0, Motoko 1.4.1, and mops 2.8.0 produced that exact hash.
The contributor page’s live files matched the repository manifest.
The contributor Wasm rebuilt with pinned rustc 1.95.0, wasm-pack 0.13.1, and wasm-opt 123 to the exact live hash 1467b8d6….
I reconstructed the required Phase-1 slices from the published Zcash transcript archive (https://archive.org/details/transcript_201804). The exhaustive structure
check produced the advertised SRS hash 94f26895….The coordinator’s initial transfer and deposit parameters exactly match parameters derived from that SRS.
I exported and independently replayed all nine live contributions. Every PoK and every transfer/deposit parameter consistency check passed.
The resulting challenge was exactly the live coordinator value:
273d83708a9a5f7ed60c815b92aa58048ccd8552dfcc0c1cb3b31a59ee7231ad
Thus zero-based entry 8—the UI’s “contribution 9 accepted”—is a sound transformation of entry 7. Your receipt does not include your principal, so absolute
attribution requires comparing entry 8’s recorded principal with the principal the page showed you.The inherited ceremony is real: the Zcash Foundation publishes the participant attestations (https://github.com/ZcashFoundation/powersoftau-attestations), including
the final beacon record (https://github.com/ZcashFoundation/powersoftau-attestations/tree/master/0088).Material findings
High: a bad contribution can permanently poison the blackholed ceremony.
The coordinator checks the total length and only five points: two parameter-header points and three PoK points. It does not inspect the thousands of H/L query
points before appending them; see coordinator/src/Main.mo:495 and its header-only parser at coordinator/src/Main.mo:246.The documentation says an invalid entry can be “excluded and the ceremony continued” (docs/CEREMONY.md:281). That is not true for this immutable append-only
canister: there is no rollback or exclusion method. The same weakness applies to beacon submission. A malicious participant cannot silently create trusted bad
keys if the final verifier is enforced, but they can irreversibly ruin this ceremony.The current nine entries are unaffected: I verified all of them fully. A future entry could still poison it.
High: “secret discarded” is overstated.
The contributor samples WebCrypto entropy, but merely drops the seed, ChaCha RNG state, and field scalars; it does not explicitly zeroize them (demo-frontend/
contributor-wasm/src/lib.rs:24). Wasm memory remains accessible to the JavaScript glue, and crypto.getRandomValues is a JavaScript-controlled import. Therefore,
“no export returns the secret” does not prove that JavaScript—or a compromised page or extension—could never recover or transmit it.I found no exfiltration in today’s matched source. If you used the verified page in a clean browser, your secret was probably not observed. But the strong
destruction claim is not technically established.Medium: the UI’s “honest” count is misleading.
honestCount() simply counts every non-beacon accepted entry (coordinator/src/Main.mo:281). It cannot determine whether a participant erased their secret,
colluded, or was independent. All nine entries are cryptographically valid, but “9 honest” is not something the chain can know.The ceremony is not finalized.
Live state remains finalized = false. The repository’s production gate correctly rejects the current keyset. No real-value deployment should occur until the final
beacon step and complete off-chain verification succeed.Also, a public beacon does not rescue a ceremony in which every participant retained their secrets: after publication, the beacon-derived scalar is public too.
The security argument still requires at least one genuinely unknown and erased participant secret.Provenance and build infrastructure need hardening.
The actual Phase-1 artifact is not committed, and ceremony-launch-p14/PROVENANCE-p14.json:8 contains only a placeholder attestation reference. The Docker builds
use mutable base tags/package repositories and installer URLs; see coordinator/Dockerfile:12. I nevertheless reproduced both security-critical binaries using
their exact pinned compiler/tool versions.The wider repository build is not fully green.
cargo test --workspace --locked fails to compile because workspace feature unification makes common use BLS12-381 while tree_oracle still selects BN254; see
tree_oracle/Cargo.toml:17.The ordinary demo npm run build needs generated canister declarations that are absent.
Runtime npm audit reported zero vulnerabilities; seven findings were confined to development/build dependencies.
The coordinator PocketIC battery and targeted frontend amount/keyset tests passed.
What your participation means
If entry 8 is yours, your browser received the verified code, its randomness was unpredictable, nobody observed the residual Wasm memory, and the secrets were
effectively lost, then your participation really can provide the “one honest participant” guarantee for this Phase-2 setup—after a valid finalization.That guarantee is limited: it does not validate the ledger or circuit logic, replace Phase-1 trust, or make an unfinished transcript deployable.
My practical verdict is:
- Legitimate ceremony: likely yes.
- Your accepted contribution cryptographically valid: yes.
- Safe to trust the current parameters with value: no.
- Potentially trustworthy after correct finalization, complete independent verification, and matching the deployed ledger’s verifying-key hashes: yes, subject to the
browser-erasure caveat and a broader circuit/ledger audit.
Thank you for that feedback, yes ceremony is not done until we verify the last output and place the beacon but all other steps including those are easily verifiable.
Same circuit and a variant of the shielded ledger that was developed for general confidential compute has been recently accepted in an international conference where two of our senior researchers are going to present it(IEEE and will be in scopus and google scholar etc). This will be even prior to the SNS launch on the 15-16th September this would be a great time to have it challenged especially as it went through its round of peer reviews with minimal comments.
we are going to take a closer look at the browser erasure for hardening but it assumes that one of the honest participants is compromised, in that case best we can do is include as many honest participants
Sounds great, thanks for the follow up. BTW I was planning to spend some time this weekend reproducing builds for your SNS launch and skimming your code with the help of an agent but it looks like I’m going to be super busy with social stuff I somehow forgot about. I’ll instead plan to do it over an evening or two next week.
Although it doesn’t always seem like it, I’m rooting for you guys 
Actually I almost forgot, here’s a check that’s quick and easy.
TAGGR: POST #1459710 BY @LORIMER
74.5% - That’s a lot of genesis VP for the dev neurons (more info).
Could you elaborate on that, and give the breakdown of how this is split between specific people / entities and whether/how this can be verified? From a participants perspective, understanding who these people are is super important because collectively they more that comfortably have enough VP to control the entire protocol, including where the funds go that people participate with.
Yah this is something we have been thinking about and will likely change tomorrow, the reason is that sale neurons if locked at 70 or so days would have this voting power, the fix would be to extend them to get more voting power for the participants ideally we would want to have them also locked at the same period.
This would come about to 56-60%, bear in mind there is another 10% for tier 1 launchpad-CEX listing
The breakdown roughly
Mercatura Forum; this is a corporate entity so shareholders/LPs for a VC fund (deep tech focus 10 year horizon)
The development team whether development or business side gets a total 18%
Most of them are individuals so not a corporate entity, MR research ag represented by @timo has 2.5% in addition Andy who is tied to MR is being treated as an individual as well(individual contributors beyond corporates get shares based on work).
All individuals-companies are pretty much doxxed, they can be approached on LinkedIn for example.
So two corporates and separate individuals, senior developers get around 2-2.5% as individuals with co founder titles.
oh also pre sale tokens at around 2.2% with normal people will be added to the 10% already on sale.
This still has the same effect as 74.5% regarding whether or not there is power to direct the ship or not (and the funds that were committed by other people).
Regarding verification, could you ask all relevant individuals to supply a reasonable proof and provide links to it. For example, @timo could easily verify your claim, and it should also be very easy for the other entities to post something similar (on LinkedIn for example if that’s where their recognised presence is). This burden/responsibility definitely rests with the owners of genesis principals, and not the community (it’s not right to expect anyone and everyone to DM them - it should be done in public and up front, given that it’s already clear that it’s needed).
Yes and @MForum is also here for Mercatura Forum, I’m sure both would verify this for you easily. The rest of the team will definitely do some posts explaining their Menese work over the next couple of weeks so it can be easily verified. Maybe they can share GitHubs with relevant subsystems they worked on, we will think of something to make it easily verifiable
loading the contributor wasm module ...
connected
joined queue: joined; queue position 1
opening staging slot ...
downloading current parameters (transfer 2948360 B, deposit 168200 B) ...
sampling secret + transforming IN THIS TAB (secret never leaves) ...
uploading transformed PUBLIC parameters ...
submitting proof of knowledge (structural checks on-chain; soundness verified off-chain) ...
CONTRIBUTION ACCEPTED: contribution 19 accepted
your secret has been discarded. thank you.
clipboard blocked — select the receipt text manually
Receipt
Transcript index (0-based)
18
Your principal
my principal ;)
Coordinator
osqjo-zyaaa-aaaad-agxua-cai
Transfer delta SHA-256
dc53b089a1a6f325cac4e7dca7a48998374a60b7085dbe5ac008e42d6d943f5c
Deposit delta SHA-256
1f850c1a3b388465f04cd46139ba1b29af77ac19a9a8bd96738258b4e92a92ca
I verify that the principle does belong to our company and allocation is based on pre seed investment based on our mandate. We also do not intend to offer our shares or neuron in any secondary trading for a period of 3 years post launch.
Hey @MForum, which principal are you referring to? Here’s an allocation table based on the init yaml supplied.
| Name | Principal ID | MENES Stake | % of Dev Allocation |
|---|---|---|---|
| Timo | sugn6-7mjeq-5kzk5-7dph2-w6sq7-ev56n-qt7yd-a5l66-birkn-kpdx5-gqe |
1,388,892 | 13.88892% |
| Kareem | vw2b5-vc43c-et5cx-guvr4-yt5y6-ttypw-3mef6-jmxcm-hvwby-5l3oq-yae |
1,388,888 | 13.88888% |
| Nour | tv73a-nsnvr-u3ruc-sly4k-2fygz-wft3h-gdqve-hdw5q-msmac-gvnnk-yae |
1,250,000 | 12.50000% |
| Jumana | a2gxl-ixyyn-gc6u3-uksho-svlmu-h7wm7-mnjer-e4ynk-fcw35-r4peg-iqe |
1,250,000 | 12.50000% |
| Wael | 4b2em-p3hvn-gyjjn-zvbwo-dapoy-5dzl4-jfnfy-sbx3u-lp5cq-5pldy-bae |
1,250,000 | 12.50000% |
| Abdelrahman A. | qiq6q-vhd3p-u5rkt-h4ste-ttor3-wl64m-vdpyh-2z6q6-elxpz-rhgm3-bae |
1,111,111 | 11.11111% |
| Adham | atwek-uwz7p-p72f5-32zd7-rtsqt-uhvo6-ghujz-fwm2s-gjheg-vxpku-hae |
833,333 | 8.33333% |
| Abdelrahman E. | 5b6kn-x63mz-2ezyn-q4paf-6hx7q-3mwyw-eng6g-4lfla-ydt3n-t7ddw-7ae |
833,333 | 8.33333% |
| Saher | dqd4z-olqc3-knqur-hx73y-xigsp-akta3-thyh3-uww5d-aj4vz-kso2e-mqe |
555,555 | 5.55555% |
| Andy | eoogn-23szv-p27ny-5btdd-n7mab-klzqz-wlk7f-okepn-hlj7m-collr-sqe |
138,888 | 1.38888% |
| Total | — | 10,000,000 | 100.00000% |
This will fail validation 
Could you also clarify why you’re only including these 4 canisters in the set controlled by the DAO?
https://github.com/Menese-Protocol/menese-sns/blob/main/sns_init.yaml#L186
dapp_canisters: - cxa6p-xiaaa-aaaad-aczda-cai # backend the wallet canister - cqby3-2qaaa-aaaad-aczdq-cai # frontend asset canister (PWA) - w2vjc-2yaaa-aaaab-ae6zq-cai # icp_sol_swap ICP and SOL cross chain pool - urs2a-ziaaa-aaaad-aembq-cai # sdk_gateway developer access gateway
This doesn’t encompass the protocol that you’re describing. Could you please list out all of the canisters that form part of the product but which are not owned or controlled by the DAO? e.g. the redemption canister.
As I understood from the team the company’s tokens would be available post sale. This is our audited principle 5elw2-6iogf-6v3bc-weq6n-uhiwc-7umyq-mpxo5-z35cy-6qybd-5sktc-cqe it is in the proposal as a fall back as well.
I was also offered tokens personally by the team as I contributed to parts of their libraries(the second allocation at the table), cloak integration and clmm math. Full disclosure in Mercatura fund I own 15% through my family’s office. Phil Mckenzie advisory tokens are also part of Mercatura token allocation as per a signed agreement.
That’s a good catch thank you, regarding the redemption canister we are stress testing it today and will add it there plus we will make it open source with a reproducible build.
Could you list out the other canisters that aren’t include please?