Are you a developer that’s spent 2 years on the IC with little $$ to show for it? There’s a 100k+ opportunity just sitting out there, auditing.
According to this, Sonic was quoted 193k for their pre-SNS audit.
I’ve personally reviewed the code of 10-20 applications in the ecosystem, all of which have varying code quality, monitoring, and security standards. There’s a large gap, and with the SNS on the horizon having auditing solutions available will help investors feel more comfortable initiating DAOs, which will in turn allow more projects to reach the SNS.
Others in the community have offered solutions (@infu and @aiv), but there’s a giant financial opportunity for individuals or firms that want to specialize in auditing, especially for DeFi applications.
We don’t need 3rd party web2 auditing firms to quote absurdly high rates because they need to learn about the IC and Motoko on top of performing the audit. It’s not glamorous work, but auditing could pull in easily more than 100k per auditor per year depending on the quality, thoroughness, and reputation of the audit.
Want to build an auditing firm? You’d probably be able to find an investor in a second. Many investors are sitting on apps that won’t see a return on investment until they SNS.
Needless to say, the opportunity is there and the space is wide open. We may have 20 NFT marketplaces, 5 DEXs, 2 Reddits, 2 search engines, and 2 Twitters, but literally no one within the IC ecosystem has built an auditing pipeline or conducted official audits.
I absolutely agree. An auditor who hasn’t been actively contributing to the IC and posting on this forum (so we can see how much they know) shouldn’t be allowed to audit. Outside companies are going to put a stamp on something, but that won’t mean it’s any good.
The security of the IC has to grow with experts from the inside.
I am certainly not the best you can find for the job, but the idea here is to build up expertise and learn.
Besides, what is this audit going to mean when you often upgrade your contracts? Are we going to pay outsiders for stamps every month? And are they really going to provide the security they are supposed to? Nobody around here will really know. And the IC’s product basically revolves around high security.
There is also another question that needs to be answered.
How deep an app audit has to go? Does it have to check the guarantees provided by the CDK or even deeper, check the IC Protocol? I doubt 200k will be enough for these. So I am guessing, an app has to audit its own logic and trust the audits of the CDK and the ICP.
I think the app logic / async-related hacks, could be easily done with end-to-end test/hack scripts (like what icblast does). One benefit of this approach is that after you upgrade, you can run the same scripts and they will run checks again for free.
It should probably be a community effort where many devs join the audit with their unique expertise.
With such high audit fees quoted why not build a series of canisters to perform the audit process that are part of the NNS. Then the fee for audits could be cycles consumption + a community approved fee. Fee could then be used to build cycles for the canisters and pay those that developed the audit cannisters a per audit payment that we as the governance community set. This may help avoid future overpriced audits on the IC.
That’s an interesting idea, but it will be pretty hard and expensive to put test scripts inside a canister. A canister can’t make calls from multiple principals asynchronously which is something you will need for an audit. There are probably going to be a lot more of these obstacles
Another thing that is an issue, how could one enforce any audit done to the project, since it should normally be done before launch, how can you ensure that the audited and not modified code will be deployed ? or would that require a 2 phase action in which you first check for bugs and errors and after check again? as you said where to draw the line as far as how deep it goes ?
Projects are currently required to provide easily replicable builds. Anyone can build them and get hashes of the wasms. When someone proposes an upgrade it includes these hashes so the public can compare them with the hashes they got.
Along with these hashes, test scripts made by auditors can be run by anyone, that check the locally deployed apps if things are okay.
One attack vector I don’t think anyone has talked about is this (Applicable to all, not just Sonic from where this screenshot is)
We have explored the option in which outsiders obtain all tokens for sale and we are making our DAOs secure against that. You can see the attacker can’t obtain more than 43%.
The project-attackers will need to buy in this case ~8% of the tokens = from 285k$ to 500k$
After that, the project-attackers will gain full control. They can take out all the treasury, which will be 2-4mil$ and they can also update all canisters and take all DEX liquidity (let’s say that’s 1mil$)
All this can happen for 3 sec and all the cash will be somewhere in BTC or ETH.
It actually is going to be easier than that, because not everyone who bought tokens will participate in governance and also some may vote wrong by mistake.
Not sure what the answer is, perhaps, the community fund share should be a lot higher (These are neurons interested in the ecosystem’s longevity. ) and projects share 1/4 of what it is.
I agree 100%. I’ve recently worked on a nodejs code that can look and fill as real live replica (checkout lightic package on npm). The IC is so much different than other chains, so I think regular audit companies would need to start from scratch to create IC specific verification pipeline.
In addition to standard security code checks, we need to consider inter-canister message deliveries, idempotency of messages, cycles management, canister upgrades, cycles draining be external canisters/users, message scanning and rejecting, http, outbound calls and ecdsa optimizations, cache optimization, multi-canister upgrade strategies, stable memory backups and many others.
This is frightening, and is a serious risk that is nearly impossible to mitigate without having a legal framework or some accountability in place.
Additionally, no one’s discussed the case where post-SNS, the dev team tanks the project in order to tank the value of the associated token, purchases it up cheap to gain a majority, and then extracts the remaining ICP from the treasury.
@bjoernek or @lara are there any thoughts on how the SNS can mitigate this type of an attack?
One of the solutions, would bo to time-lock tokens issued to other parties than sale. It would increase initial threshold required to make 51% attack. In such option you also protect the project against aggressive sell of by the parties that received tokens by other means than public sale.
As a side-note: If you have bought tokens from the decentralization sale, you should in no circumstance follow a neuron that’s part of the investor/developer camp.
Another problem is this split (for Dexes in general)
Trading rewards and LP rewards - basically going to initially go to the investors, which were the ones providing liquidity.
Basically, too many problems.
One reason that the fees are so high is liability. When you do one of these they make you sign something that says they are not responsible for changes in tech, so on and so forth…but the reality is, if you lose $100m because the auditing company missed a decimal place the audit company is going to get sued. I imagine they have a significant liability insurance bill.
I’ve thought about offering services, but doing so officially is likely a significant undertaking and I’m not sure that it’s going to save anyone any money after they talk to their lawyer. I’d hate for someone to end up wrecked because they were trying to do something good.
I agree that the concept of a time-lock plays a pivotal role in this scenario.
The current SNS framework allows for the specification of a vesting period for neurons allocated to developers and seed investors. This vesting period serves as a lock-in phase during which the neuron can’t be dissolved, ensuring long-term dedication to the DAO.
Hence, assessing the proposed vesting duration is a crucial consideration before participating in any specific SNS swap.
As you have rightly pointed out, currently, we do not have measures in place to prevent the development team from acquiring tokens during the SNS decentralization swap.
One way to foster long-term commitment of developers to the DAO, as discussed earlier, is to use vesting periods for the SNS developer neurons.
However, this does not rule out the possibility of a malicious development team orchestrating a ‘rug pull’ with the intention of draining all ICP from the SNS treasury. At present, the most effective countermeasure I see against this scenario is due diligence on the part of swap participants. Careful evaluation of the project team and the proposed token distribution can aid in determining whether to place trust and support in a particular SNS.
IC contributors get rewarded soulbound tokens with which they can purchase SNS during the sale at a discount. A % of the sale is reserved for them. This will incentivize the community to contribute.
IC neuron holders can manually buy SNS tokens based on their neuron voting power. If a person has 10k ICP 8year neuron, then can buy SNS tokens with a discount for 10k ICP. Again % of the sale is reserved for them. This will incentivize the community to stake ICP. It will also provide some of the CF decentralization benefits, without over-relying on CF.
Other SNSes can also participate in the sale. % is reserved for them. This will incentivize SNSes to integrate with each other.
Great thread and I agree its a real challenge for IC projects especially those looking to SNS. The general community wants audits before SNS votes (agree 100%) but the who, what (as in what can they actually audit), and how much seems to be the challenge for most projects.
At Catalyze we are watching all these threads and learning how to properly and thoughtfully approach our SNS raise, vesting models/protections, and ultimately the DAO launch.
On the audit front we are seeing the same challenges with really high audit fees which are all coming from firms with good overall web3 reputations but on other chains.
Our audits bids have ranged from 20K to 150K depending on scope. Full line by line audits of the entire app trend on the high end of that range. Focused audits on those canisters where assets or access controls are paramount run at the lower end. So think 3 canisters and 7-10K lines of code.
I agree we need a IC experienced audit firm (with experience IC devs) that is made up of enough FT devs that they can handle the coming onslaught of requests. I know CodeandState has spun one up and there a few new ones coming but resourcing is likely a challenge.
The bigger web3 audit firms can start sooner and throw more resources at audit requests but for a price.
All that said we have narrowed our auditor choices to a few firms who understand the basics of canisters and have done 1000s Rust SC audits. We hope this will address folks concerns but we are by no means delusional enough to think some will be concerned about their lack of previous IC experience or engagement on forums like these. All fair points!
So I would close by say. I agree we need this. It is a large opportunity. In fact we have looked at this area as well since one of our devs is a former Rust and Solidity auditor with a PhD in engineering. He has lobbied internally for this as a business opportunity.
Feel free to DM me here or on TG @rlaracue bc this is a crucial area for all of us to work out. In the meantime Catalyze is trying to learn from all this and be transparent on our approach. In a few weeks our new website will be up with v1 of the white paper, audit plans, and vesting safeguards for SNS token buyers. From there we expect to learn a lot and make the needed changes so when we do get put up for and SNS approval vote people know what they are voting for and who.
Essentially, you are proposing that participants in the IC ecosystem (such as NNS stakers, IC contributors) could be given preferential access to an upcoming SNS token swap.
As a side thought: This concept could possibly be integrated into the SNS configuration. Some projects might prefer an SNS swap that is as accessible as possible, while others may want to use this feature as a security layer.
I believe this is a great way to tackle the ‘attack voter’ problem described earlier, while leveraging web3-like incentives.
In fact, your proposal aligns well with suggestions from other projects requesting that SNS airdrop eligibility be linked to NNS neuron attributes (for instance, members of the ‘8-year gang’ would qualify for an SNS airdrop). This is certainly something to review as part of SNS roadmap planning.
cc: @lara
These are valid concerns,
Sonic has thoroughly addressed these concerns. Firstly, the attacker graph presented assumes a 50% participation rate, meaning only half of the DEX participants are actively voting. Therefore, the actual voting power of the attacker would be reduced to 37%.
Additionally, there is a valid concern about the attacker acquiring more tokens from other pools, such as teams and investors. To mitigate this, time-locked token issuance is a solution. As @bjoernek mentioned, “The current SNS framework allows for the specification of a vesting period for neurons allocated to developers and seed investors. This vesting period serves as a lock-in phase during which the neuron can’t be dissolved, ensuring long-term dedication to the DAO”. At Sonic we put 4 vesting to the team and up to one year to all other allocations, so it will avoid a huge jump in circulating supply or tokens coming to market.
In terms of trading and LP rewards, Sonic has designed its system to base rewards on the value generated within the ecosystem. For example, trading rewards are directly linked to the fees contributed to the platform. This approach discourages artificial trading solely for the purpose of earning rewards.
Although the chances of such an attack occurring are very low, Sonic acknowledges the possibility over an extended period.
