Side note about frontend build reproducibility: according to our experience, though tooling has maybe involved lately it’s not something I check every week, frontend reproducibility across OS can be tricky. You know, NodeJS and related eco-system is what it is. On the same OS though, it should be reproducible - that’s why e.g. in projects like Juno, OISY, and NNS dapp, we’ve set up GitHub Actions that run several builds in a row to assert they always output the same hash for the same context.
Yeah, I think embedding assets in the WASM is a much simpler and familiar verification process. It’s just like verifying any other canister.
Your second point is essentially what the standard static asset canister does. The build hash doesn’t change when assets are modified. They’re uploaded after the canister is built and deployed. Verifying requires the assets to be staged first, but I’ve never seen this done in practice. Embedded assets makes much more sense to me if decentralisation / verifiability is desired. I’m not saying it can’t be done with the standard asset canister. I’ve just never seen it used that way (even though its covered in the docs).
I just mean there are some extra hoops to jump through (described above), and SNSs I’m familiar with, such as WaterNeuron, have been lazy and decided to subvert the verification process entirely for the frontend. Massive security flaw in my opinion. I don’t actively participate in that DAO anymore.
I think we need to be pushing for higher standards for all future SNSs. I think ONICAI’s on track for being one of the most complete and compliant launches I’ve seen on the IC.
I just meant it’s not the goal of those examples or crates. Yes they hold assets for demo purpose but their main goal is not this topic I think. Anyway, nvm.
Worth noting that this is limiting when the WASM must be installed in a single call - i.e. 2MB. With chunked installation this limit has been lifted, but I don’t know if that’s the case everywhere, I didn’t check (NNS, SNS?).
Hi @icpp I had a go at building the IConfucius canister (dpljb-diaaa-aaaaa-qafsq-cai). I see the build hash currently deployed to the network is 56f8f3d4310914cfb79f4baabf6e76fdb22c98b7b61631f00d7270c931a6e7c0.
When I build (simply via dfx build) I get a IConfucius/src/IConfucius/.dfx/local/canisters/iconfucius_ctrlb_canister/iconfucius_ctrlb_canister.wasm file. When I compute the hash (shasum -a 256 iconfucius_ctrlb_canister.wasm) I get 276acbd8c80f6033507d47d503e572ab4edd92b54a5c55fe6b3c8f5fb6ab2425.
Is it possible that you’ve performed any further processing before deploying? I tried shrinking the WASM (ic-wasm iconfucius_ctrlb_canister.wasm -o iconfucius_ctrlb_canister.wasm shrink) and then recomputing the hash. This resulted in the following hash 64053035114b4838fdc7a9b10f0670a85a294c0fde8ac020e8b87ca9b56f78f6
These don’t match what’s currently deployed to mainnet. Maybe due to build environment differences? I’m on Ubuntu 22.04.5 LTS.
In fact I just checked again and the build hash on mainnet is c7fab5fb7ab878ba0e69f5936e1f928cecc1a8ee2d6c1358b5471284a88222d5. This seems to have changed shortly after I checked, so I guess it’s not stable at the mo due to recent changes not at the head of the master branch (which I pulled).
Thanks @icpp. BTW I just got a notification that the ONICAI mAIner marketplace launched earlier today. Nice job!
I’ve already purchased 3 mAIners, and I’ve now topped them up with cycles. Looking forward to watching them progress while earning me FUNNAI (soon to be ONICAI).
I encourage anyone reading this to scoop up some mAIners while they’re cheap. The sub-100 ICP prices won’t last for long I’m sure.
This is also a good opportunity for the network to demonstrate some serious burn for Mission 70! Let’s all do our bit!
During today’s upgrade of the funnAI protocol canisters, the Archive canister did not upgrade.
The issue is that it still used the classic persistence model, and one of the data structures has become to large to be serialized during the pre-upgrade step. We researched it, and this canister is truly in a non-upgradeable state.
We decided to deploy a fresh Archive canister, using the Enhanced Orthogonal Persistence (EOP), which will never run into this problem, because it keeps the heap wasm as is during an upgrade and does not require to deserialize the data structure that is causing the issue.
We have configured the protocol to start archiving data to that new canister.
The original Archive canister will be kept up & running as is but will no longer receive new data. We will attempt to extract the data and then add it back to the new Archive canister.
The new Archive canister will be decentralized during the SNS, and the original one will not.
That resulted in one more change to the onicai_init_sns.yaml file. Everything else stays the same.
Good news though is that ALL the other canisters upgraded without issues and are now using the EOP persistence model.
Nobody needs DFINITY’s permission to propose an SNS, and the SNS framework is all open source and upgradeable by anyone in the community who wishes to propose a sensible proposal that the community would adopt.
This is a World Computer. Show it some respect please.
I would add that the ONICAI team are one of the most impressive teams I’ve seen on the IC. We could do with a killer SNS like this
Hi everyone, we’re excited to share this milestone with you:
After a thorough security review and an upgrade to the latest dfx version of all code, the complete funnAI codebase along with all other onicai code is now open source!
And you can find all onicai SNS canisters (i.e. all assets to be decentralized and handed to the SNS) in this spreadsheet: onicai SNS - canisters - Google Sheets
We had to make one last modification to work around a limit of the decentralization sale. It is allowed to include only up to 25 canisters during the initial process, while we have 60 canisters in total.
We out commented a number of canisters in the onicai_sns_init.yaml that will be added later if the SNS decentralization sale is successful.
The initial set of canisters to decentralize include:
funnAI canisters, with 3 out of 30 LLMs. The remaining 27 LLMs will continue to run as part of the protocol, but just not under SNS governance yet.
IConfucius canisters
DeVinci canisters
ICGPT canisters with 1 out of 4 LLMs. The remaining 3 LLMs will continue to run as part of the ICGPT application, but just not under SNS governance yet.
Grand Season 2 Proposal: 139985 - Creation of the Onicai SNS | Review by Dexter for TacoDao
Vote: ADOPT
YAML Review:
The token distribution and voting power allocations demonstrate a strong balance, ensuring fair governance and incentives across stakeholders. For details, see the Onicai SNS initialization YAML file.
Reasoning:
The Onicai team has long been a powerhouse of engineering on the Internet Computer (IC). Lead developers @icpp and @patnorris have significantly advanced the ecosystem, particularly in on-chain AI capabilities. Their work exhibits a level of quality and professionalism that is rare not just within the SNS framework, but across the broader IC landscape. In my opinion, only 2-3 other projects match this standard.
The team’s approach to preparation, iteration, and incorporating community feedback from the forum has been exemplary a solid 10/10, as I highlighted in my post on reviving the SNS framework. Unlike most SNS launches, which often seek funding before building substantial products, Onicai has reversed this: they’ve already developed robust products and are now elevating it through decentralization.
What stands out most is their commitment to participant rights and milestone-based funding, as outlined in the forum discussion. Here’s a key excerpt on participant expectations:
Q5: What rights and privileges does a participant get for contributing to an SNS launch, and what should this participant expect to gain?
(I personally view SNS launches as early seed investments into startups/companies. If there’s a “conflict of interest”—an exchange of value between Party A and Party B—there should be an expected outcome from that exchange.)
Participants gain the right to monitor, influence, and ensure their investment/contribution is used as intended per the SNS launch conditions and problem statement. They can hold the team accountable to prevent misuse.
They also gain the privilege of directly interfering in the project’s crystallization by affirming or denying proposed changes via voting. This utilizes their participation privilege, making them actively involved in the mission statement and solution completion.
— @bitel911
At the end of each quarter: Public review call with the community and the development team of the goals and development progress, plus review of the proposed goals for next quarter.
If the goals for the last quarter have been reached, the development team puts in a proposal for 50% of the development budget for last quarter (that’s the 50% after delivery).
If the goals for next quarter have been agreed upon, the development team formalizes them and puts in a proposal for 50% of the development budget to do the work (that’s the 50% before delivery), and then starts working on them.
At the midway point of the quarter, e.g. 6 weeks into the quarter, there’s a public update call with the community and the development team to give an update on this quarter’s development work.
We envision this process to happen every quarter to give actual development transparency to the community. The development will thus work a bit like DFINITY developer grants, with regular updates and reviews.
— @patnorris
In my view, this should serve as the default template for SNS funding. The team has nailed it by learning from past launches and their pitfalls. This is precisely how a DAO especially one funded like a seed round should operate: with clear communication, consistent delivery, and ongoing advancement.
(this little section in the Whitepaper which I would just name the buisnessplan which most projects are missing, actual Treasury inflows
This Cookie jar has its own oven, and thats why its a bakery, it will thrive and become self sufficient.
Personal Opinion (Outside of Known Neuron or Taco DAO Views):
The hard work is nearly complete; now it’s about executing a successful SNS sale. I encourage anyone with ICP to spare to contribute and help the Onicai team reach their maximum funding goal of 80,000 ICP (this is not financial advice). If any team deserves a flawless 10/10 launch, it’s them.
I’m confident this proposal will pass it’s the right time, the right team, the right product, and a clear path forward.
My message to the team: When you reach the top of one mountain, it’s just the base of the next. Keep climbing; we’re here to help, support, and ensure we all succeed.
