Well spotted. This has got me thinking, if the frontend were handed over to the DAO, would the DAO actually be able to verify upgrades? Does verifying hashes for frontend canisters encompass the assets being hosted by the canister?
1 Like
Thanks for the answer. I understand the desire to iterate quickly. I kind of disagree, though, with your second statement but maybe Iām just too much of a purist.
User identities are derived on the client, so whoever controls the frontend can ā whether intentionally or unintentionally ā inject malicious code into the dapp that accesses those identities and, for example, makes hidden calls. Just like decentralizing a backend improves trust, decentralizing a frontend introduces review and trust mechanisms since changes must go through proposals, i.e. improve to some extent that no malicious code is injected in the dapp by a single entity.
That said, if thereās currently nothing in the frontend that handles assets tied to identities, and as you mentioned, it will be registered as soon as such features are implemented, then I can be fine with it.
7 Likes
I think so. I donāt know the details for all SNSes or whether the DAO itself can verify upgrades, but I know from experience that we pay close attention to frontend reproducibility ā especially in projects like Internet Identity or the NNS dapp, which are handed over to the NNS. The same applies to OISY and Juno. So while Iām not sure if the verification is automated, itās at least possible to verify it manually.
That said, with modern bundlers, achieving perfect frontend reproducibility is difficult. For example, in both OISY and Juno, we aim for a setup that is as reproducible as possible within a specific environment.
Also note, I wouldnāt be too surprised if some SNS projects donāt have a reproducible frontend (or even backend). That said, I personally donāt use this as a criterion when deciding whether to approve or reject an SNS sale proposal. Itās something that can always be improved.
Did I understand your question correctly?
2 Likes
" I kind of disagree, though, with your second statement but maybe Iām just too much of a purist."
Well, it is not meant to be absolute! 
There are so many trade-offs in software, I am not saying I disagree at all with the choice of how it is done! I also think that once the frontend is mature enough, it is entirely appropriate that modifications go via DAO proposal, for all the reasons you mention. This is the target to strive for, as soon as possible!
āThat said, if thereās currently nothing in the frontend that handles assets tied to identitiesā
I want to be very careful here when I answer in the affirmative, to make sure we mean the same thing!
- Our frontend does support logging in with Internet Identity
- There is no wallet functionality on our frontend, so the the user will not have tokens that are controlled by their logged in II. I think this is what you meant, if so the answer is āYes, we have no assets controlled by your frontend IIā
- There IS the ability to add your II as a hotkey to your TACO DAO neuron and import voting power from it, that you use to cast your vote on the TACO DAO portfolio allocation!
This last point means that there is an indirect way in which your II is /associated/ with assets! This is, as you say, a reason to hand over control as soon as possible. But before these votes even impact any trading activity, during the first phase of the DAO, there should be no real room for harm.
2 Likes
Thanks for replying Snassy, Iām wrapping up work so Iāll be free to field questions about the frontend shortly
1 Like
Snassy covered most of my thoughts, but Iāll confirm, we are 100% working towards handing the frontend off to the dao, and if the community thinks it is important we can front-load it as a priority. As he said, the frontend does not handle dao state, mutation, or anything vital. I never thought of it before, but I guess anyone can whitelabel/deploy a Taco Dao frontend 
edit: the team talked about it and weāre going to focus on handing off the frontend ASAP after launch, we believe our dev speed wonāt be affected, just our deployment cadence to prod/dao, which is totally acceptable given it will be at the pace of the voters. Thank you David and Mico for the discussion, please donāt hesitate to ask more questions.
1 Like
Given that there are no wallet features at genesis and youāre handing it off asap after launch, that sounds good to me. If I would be picky, I would maybe suggest freezing the hotkey feature until then but Iām again probably just being too much of a purist. I can imagine that others would also argue, for example, that DNS isnāt decentralized anyway.
Thanks again for your feedback and consideration.
3 Likes
You did, thanks David 
I recall from prior discussions with @rbirkner that the standard asset canister doesnāt bundle assets into the wasm itself. However I gather that other frontends do, which seems like a necessary first step for verifiability (strange that the standard asset canister isnāt built this way - so Iāve been told). Are you aware of any documentation like this that instructs devs how to go about building a reproducible frontend canister?
I also wish there were better means of compensating for DNS centralisation. I get the impression that this is an issue thatās often forgotten / overlooked / swept under the rug. Iād really appreciate your input in this discussion if you have the time 
I personally think youāre being the right amount of picky. I would like to start rejecting SNS projects on these sorts of grounds, however even WaterNeuron doesnāt have a frontend thatās controlled by the DAO.
I would like this sort of thing to recieve wider discussion and broader attention. Itās an achilles heel for the IC at the moment (given what the value proposition is intended to be), in my opinion.
4 Likes
Thatās accurate (I think). The DFX assets canister does not bundle the assets into the WASM. However, when used with an SNS, deploying new assets goes through a proposal process which is a process that works in two steps:
First, a developer uploads the new assets to the canister, but they are not made live immediately. In return, the developer gets a hash that represents the staged assets. Then, the developer submits this hash through a proposal. If the proposal is executed, the new assets go live.
This approach makes our concern, reproducibility, verifiable.
Iām not sure exactly where itās documented on the IC portal, but this process should be explained somewhere in the SNS documentation.
Fun fact: thatās also how I deploy the Juno Console. Every time I deploy assets, I go through a custom, built-in proposal mechanism that Iāve ultimately adoptedā¦ for myself 
. I developed this in case Junoās SNS would have succeeded last year. Still hopes it will be useful someday.
Oh! Thatās a very important point, it validates that, at this stage, not having the frontend as part of the sale or DAO shouldnāt be a showstopper compared to existing projects. Thanks for sharing!
Still, Iām glad the team will proceed as soon as possible afterwards if the sale succeed, thatās a great commitment.
3 Likes
Love the structure and direction here; youāve clearly put in the work. The portfolio logic, Salsa Season, and cross-DAO incentives feel like a real evolution for the ecosystem. Definitely keeping an eye on this; keen to support and get involved as things move forward. Good luck with the SNS!
2 Likes
What is the point of writing code and designing systems that operate in a truly decentralised manner when we allow stuff like this
Admin functions in one Motoko file. Iāve been going through the motoko:
I would like to know who green lit this to be voted yes on, Iām obviously missing something because I would never put such code up for an SNS out of fear.
Who has reveiewed the motoko code from Taco DAO @leadership?
2 Likes
@afat was paid 40k for auditing
1 Like
Nah - @afat you seen this code? Really?
What is your concern here? That they have a way to recover balances from a 3rd party system or it is called admin? My understanding is that the admin principal is to be set to the SNS Governance canister. This allows the DAO to recover its data if something goes haywire in either their own system or in ICPSwaps.
Their dependence on 3rd party systems was discussed during the audit. It injects a number of unknown unknowns into the system and I believe this was added to resync the balance of their pools if the data was misreported or if a calculation failed somewhere along the line.
The public admin function was not in the version I audited although the private function was and was part of a retry function that was called as part of a recovery mechanism.
My audit did not cover the Treasury canister which was pending work.
2 Likes
I mean my concern, from the initial look is no way this code is ready. But donāt worry, I will be publishing my full analysis of the repo in my first podcast episode.
I actually canāt believe you stand by this repo FYI, just like scroll through a few files mate.
2 Likes
Iām not sure what all you mean by āstand by the repo.ā I did not write this code and it certainly makes some stylistic choices that I would not make. I was hired to audit the security of the code and to make sure that people on the outside could not attack the contract in some way. To an extent even the soundness of the logic of the code was outside the scope. I had to make sure that an outsider could not make the code do something other than eat the author intended. The style and correctness of that logic can make an audit easier or harder but is not something I have any control over. I have no idea if tacodao will be successful or if their approach to shared treasury management will work.
You can read my audit here: Create 20250319-RVVR-TACO-final.md by skilesare Ā· Pull Request #1 Ā· tacodaoicp/DAO_Backend Ā· GitHub . The version I audited seems to not be accessible(consult tacodao) and I canāt vouch for any changes made after the date of that commit.
This audit only covers the DAO, neuron snap, and spam portions of the code. There are specific mentions that the code could use refactoring.
My payment also covered work that I did to audit a separate earlier version of a swap canister that was ultimately not released as they changed strategies. This code was thousands and thousands of lines of code which led to the large price tag on the audit.
I stand by that you should not be able to manipulate the Dao, snapshot, or spam canisters in ways other than the author intended other than in the ways identified in the report baring some unforeseen issue with the underlying protocol or creative exploit no one has seen before. Iāll also stand by that the protocol is MUCH MUCH better that its original incarnation and that the audit was more than worth the heartache and value loss that would have resulted from exploitation had one not been done. Ultimately Tacodaoās success is on the DAO.
2 Likes
Ok Iām not trying question you, itās just I feel if you coding for a DAO you coding that if the devs disappear tomorrow the service continues. Iām sure your vital security work is sound but what about making sure code is scalable, existensible, manageable, automated.
I donāt doubt the security work but that can be enforced with good design patterns, standardising the backend is doable based on established design patterns at least working towards this should be minimal.
Personally, I am requiring my team to work towards 2 documents, to free ICFC of our dependency:
I can show this is old Iām just not finished with the patterns, the same is being prepared for the backend. Only if you truly understand what you are doing can you articulate it and explain it.
When I look at the repo Iām like this doesnāt feel like it was written with us in mind, to pick up the pieces for the community if need be?
Anyway, apologies for disturbing you.
1 Like
Hi James,
That would be me.
I added a way for an admin, such as the DAO via registered Generic Nervous System Function, to directly invoke the function that recovers balances from ICPSwap pools and returns them to the DAOās portfolio. This is so they can do so in an emergency if a large fund has become stuck on a swap canister and needs to be recovered immediately, possibly to prevent the automatic trading bot from making faulty trades. There are also methods allowing an admin to start and stop the trading bot, and pause and resume a token from trading.
This is not outside the normal for the type of control a controller of a system like this should have. I am not sure if it is the naming (āadmin_ā) that puts you off? It was meant to communicate clearly that calling it would be something a bit out of the ordinary and extra care should be taken by reviewers of a proposal calling a method with such a prefix.
I have also currently added the TACO team as master admins with permissions to call all functions that are open to any other admins. This is in order for the team to have the ability to quickly halt trading if either dramatic market shifts occur or serious errors in the trading bot are discovered.
It will be up to the DAO to decide if they would prefer to remove the master admins, or keep them (and then vote for who they should be) to have the option of quickly halting the trading bot. We have discussed options such as letting members vote for halting directly in the dapp, and maybe require less than 50% for such an emergency halt to take effect right away, but it will be up to the DAO to find the right answer. But with potentially so much money on the line, I foresee the ability to stop things quickly if they go wrong to remain important.
I hope this answers your questions! Lastly, I welcome scrutiny of the code and I am a life long open source, many-eyes proponent. I will be the first to admit my code is rarely perfect, and I make mistakes! I have also, after a few decades of online coding developed enough of a thick skin that I donāt take it personal if you yell at my code, so this is to say: please keep yelling at it - it improves the code, I am thankful for it and I donāt even hear the swear words. And, I mean, if everyone agrees you are right and that there should absolutely not be a publicly available method for admins to recover pool balances, Iāll remove it! But Iād prefer keeping it there.
1 Like
Thanks for participating in the discussion James, looking forward to your full feedback when itās ready. Could you share some specifics before your first podcast epidsode? I feel like someone is missing something here, we have a robust audit and a seasoned backend dev, neither which feel this way about the work product, or raised the red flags you have
1 Like