Lol intimidation. Where the cherry-picked out-of-context screenshots you can provide to back that up?
Literally making a game about cute Dragons, and open source software. You’re really reaching to spin this in a negative light, Coinbase Intern.
1 Like
It’s still far from perfect — it can easily become inefficient and vulnerable to scammers. I don’t believe there’s a silver bullet here. Another issue is that someone must actually create the DAO; I doubt the foundation wants all of them to fall under the NNS alone.
It’s common knowledge at this point — there’s no need to provide anything, and they’re probably hidden anyway.
All code should be reviewed by other developers. That’s the kind of transparency we need—far better than just saying “we’re going to build this, we need 1M ICP… just trust us.”
Instead of blind trust, let’s build systems where code quality, participation, and delivery are visible to everyone. A DAO could include mechanisms to incentivize meaningful code reviews and discourage low-effort or biased ones. Reviews could be rewarded based on community voting, developer reputation, or automated metrics.
Maybe the plan all along was to let others create the DAOs and then take them over — minimizing legal risk in the process. After all, Adam did exactly that with Dragginz.
1 Like
Oisy is a pain to use in non-defi dapp because it’s focussed on defi only. So we need other wallets or oisy to open up and support delegations.
This is the reason why toolkit does not support it, imagine having to click a prompt every time you want to do a caller based action like adding a SNS to your favorites, really kills the UX
1 Like
What has the SNS projects that are taken over to do with the IC being not decentralized?
The IC is not the SNS framework and vice versa. The SNS framework just runs on the IC. The developers of the projects made the descision to decentralize the project via SNS and this is one of the risks they needed to asses.
1 Like
I don’t see any intimidation anywhere only funny boomer memes
Jordan, erm apologies sir, *NOTJordan,
Im terrified. 
1 Like
Issue is putting the cart before the horse. What unicorn startup had a large team?
1 Like
My apologies for the wall of text, mostly technical and kind of offtopic, but I thought it might be helpful to share some background behind this 
Why delegations aren’t supported
Actually there’s a technical limitation behind OISY not supporting delegations, it only gets a single Identity from Internet Identity and it can’t derive more identities since there’s no key material within OISY to derive identities from.
Overall, delegations are great to “delegate” one key pair to another without transferring any private key. Which means that OISY can sign on behalf of the identity created by Internet Identity with its own frontend session key.
How authentication differs
But authentication is different, with authentication you don’t need to sign things on behalf of another key pair like you do with e.g. token transfers in defi.
Instead with authentication, you only need a signature that proofs that the call was made by a given user, the caller principal itself doesn’t actually need to be that user.
A JWT is an example of this concept in web2, it’s signature even includes additional user data like e.g. roles and permissions. These claims make it possible to avoid the need to call the user service to see what permissions the user has. Unfortunately we don’t have these concepts on the IC yet as of now.
Alternatives to delegations
Meanwhile the most straightforward alternative for delegations would be locally created identities in the frontend, registered to act on behalf of a wallet identity through a canister call with the wallet.
A benefit of this approach over an ICRC-28 delegation is that you can differentiate the caller, either as coming from the wallet or your frontend. Which makes it possible to explicitly require wallet approval for critical methods like executing a swap on a defi platform.
Another approach is to separate authentication and wallets as concepts, for example use Internet Identity for sign in and only use wallets for the defi functionality. But this approach wouldn’t work for use cases where your users don’t expect to create accounts on the platform, e.g. a swap.
Security considerations
Overall there are various approaches to improve UX by reducing approval prompts, but having defi interaction not go through a wallet approval prompt should be considered a higher risk approach that can go wrong (and recently did go wrong).
Other wallets
On a personal note, I think OISY is great but I do welcome other wallets in the ecosystem. They help create and maintain a healthy competitive and collaborative environment. For example they have contributed various concepts, standards and tooling on the ecosystem that can be found in the WG.
4 Likes
Adam told us no other wallets. 
Well, I’m not the one defending Catalyze—Adam is.
Because he already 51% attacked it lol
They aren’t attacked because they’re part of Dom’s group. The “drain the swamp” rhetoric falls flat, they only go after those outside their circle. It’s not about scam or not.
It’s still an attack on the dao no matter who the perpetrators are.
The situation here looks somewhat different…
During a token buyout process, the price of the token would typically increase, allowing holders to sell at a good price. That could possibly justify the destruction of a project in the eyes of the community.
But in the some cases under discussion, the most of investment came during the SNS process.
If the project had failed to pass the SNS vote, the team would have received real feedback — perhaps they would have improved the product, found external investors, or handed it over to third parties… There were many options.
Instead, we’re witnessing a scenario where one SNS participant, having obtained the minimum amount of voting power required to block proposals, ditches the rest of the SNS participants, forcing the majority to comply with their will.
This precedent could negatively affect the entire idea of the SNS.
Now any small group of passionate builders will think twice before launching a project on the IC/SNS.
Or even at the fundraising stage, they might prefer to seek external investment — or abandon the project altogether.
Small investors will now also think twice before putting money into a project that rubs the big players the wrong way or competes with existing products in any way. After all, they could simply lose their investment at someone else’s whim.
The very possibility of such an outcome creates barriers for developers, limiting one of the few good opportunities to contribute something new to an ecosystem that still lacks deep liquidity.
I believe this is damaging to the SNS concept itself.
Maybe there’s another way to address the issue raised by @borovan?
Shouldn’t we try to look deeper into the specific problems of each project?
Or at the very least try to find a more balanced approach?
1 Like
And the Internet Computer as well.
I don’t see the problem here? if your project isn’t a scam and has actually made progress then there is nothing to worry about 
1 Like
It’s funny. If you saw your investment drop to a tenth of its value, you wouldn’t care about centralization or decentralization anymore—you’d be thrilled if someone bought the tokens to bring your investment back to its original value. The project was weak and failed to attract the market, so having someone buy the tokens is already a good thing. In the future, there will be strong projects, and the value of their tokens will soar, making it impossible for any whale to buy them out. That’s a fair trade-off for the ICP community. The complaints about “centralization” seem so artificial and forced.
1 Like