Ah, yes — depending on the project direction, there may be different libraries or components to rely on.
However, based on my past experience leading or participating in the development of various applications and infrastructure — such as NFT marketplaces, DeFi (swaps or staking), storage systems, identity systems, cross-chain solutions, etc. — they all tend to share similar needs:
Regarding Identity :Should we use Internet Identity (II), and what are its pros and cons?(I’ve found that the vast majority of people in the community actually don’t understand the security assumptions or core principles of II — what’s good about it and what’s not.)If we don’t use II, are there any third-party solutions that are reliable and secure (reliability and security are extremely important for identity systems) that can let users authenticate with MetaMask or Bitcoin Wallet on the IC?(In fact, using Delegation Identity makes this entirely feasible.)But as far as I know, very few people actually understand how Delegation Identity works. I’ve already decided to write a detailed article explaining this system.
Regarding Storage :For a long time, Canister storage and upgrades have been a headache — especially for developers coming from Ethereum or other blockchains.Canister storage is a brand new concept to them, and many struggle with it initially — let alone understanding things like WASM memory and stable memory.Of course, for us, we know that excellent libraries like canister-snapshot and stable-structure exist to help manage this.But for new developers, these are cognitive barriers, and it takes time to learn.I believe we should provide well-defined solutions (recommended libraries and key considerations) to help them transition into IC development smoothly and efficiently.
Regarding the IC’s financial system :The traps of the ICRC token — such as the roles of archive canisters and indexer canisters.Do they need to deploy their own archive or indexer? What are the implications?These are also things developers need to understand early on.
I believe these three areas are the first and foremost concerns for any developer working on the IC.
Of course, there are other topics — like certified data, threshold signatures, HTTP outcalls, etc.
(For example, I must mention a project I was involved in once kept setting the max response size to 2MB (None), which cost them a lot of money — and they didn’t know why. It was only resolved after they asked me.)
Many people are simply not familiar with the IC’s vast development ecosystem, and so they can’t fully grasp the IC’s capabilities.
My goal in creating this repository and article is to serve as a booster — to help developers get into IC development.
I want to make it possible to go from zero to hero in just one week .
Additionally, I think the relationship between awesome-internet-computer and the repository we’re planning to create is that of a parent and child.
Of course, awesome-internet-computer aims to include as many IC projects as possible — it plays more of a directory-like role (at least that’s how I currently see it).
In contrast, the new repository we want to create should be highly streamlined — the fewer the contents, the more essential they become, and the more directly they address the fundamental problems developers face. The fewer issues developers have to deal with, the smoother their experience will be.
if you need help/feedback setting this up let me know. but I think this needs to evolve into a specific format that the community likes most.
the most important thing is to get this started somehow.
maybe a good start really just is the forum thread that you proposed where everybody can share their experiences and their personal DOs and DON’Ts. collect as many information as possible what worked best for devs, what they struggled most with, what limitations they faced and how they solved it. ideally everybody participates on this (newcomers and well experienced ICP devs)
going on from there you could start thinking about how to structure the repository you want to create.
these are just some quick thoughts on this. but we really need to unlock the knowledge of the community and I am very happy that you brought this topic up!
Templates: code examples that demonstrate ICP’s capabilities. It’s been categorized into the different languages, i.e, Motoko, Rust, and TypeScript. Libraries: It has examples of popular libraries that are normally used in development, such as the Rust, Motoko, and Javascript libraries.
Dev Tools: This section contains examples of popular tools that are used to improve the developer experience on IC
We’re currently planning to start working on examples/tutorials repository that has a list of “How to” do particular things on IC.
It would be great if we collaborated on this rather than having separate projects that are each trying to accomplish the same goal.
Marco, @C-B-Elite please do not re-invent the wheel, what is needed is clear, straight-forward, code specific advice regarding full stack IC DAPPs. Indeed, it could be long forum post, but eventually it has to look like a Wiki, or a at least a page that accepts comments. The main weakness of these DFINITY pages: What are security best practices? | Internet Computer is that the information is static, there are no comments, no questions, no updates, except the ones done directly by DFINITY.
The best easy idea would be to add a commenting system, so that the information is more relevant, and up to date. This requires some work, but it would be invaluable.
For our small consultancy, we are doing this ourselves, meaning we are taking the available content, and adding a wiki system around it, so that we can ourselves properly understand, comment, and use the security information. FWIW I am using Wiki.js, and I am quite happy with it, it runs on my own Mac:
Also, please let us not ignore THE ELEPHANT in the room which is TOKEN security, how do we make sure Canisters, and the software that connects to them is not hacked!
the forum post would be a start. I don’t think that sharing experiences and best practices in a simple comment section is the right way.
also, we are not discussing security best practices only. this discussion here moved into a way more broader scope of education. no matter what devs aim to achieve, they should be able to figure out how to achieve this as streamlined as possible. and OF COURSE, security best practices as described in the internetcomputer docs should always be considered.
I do not think that we are discussing to re-invent the wheel. it is just a completely different approach of education and collaboration among the community.
I kind of disagree that a comment section helps so much on these pages. if this is for example just a feedback which results in an updated page - what do you do? delete the comment because it is resolved?
of course we do not want to ignore security, no matter whether it’s about data leaks or token related stuff.
I agree that this thread was kind of hijacked to discuss other things. @C-B-Elite I propose you create a new thread to kickstart your efforts
let’s get this thread back on track
yes
@josephgranata unfortunately it will always be hard to prevent hacks. the best you can do is get peer reviews of trusted parties as soon as your dapp gains significant traction. ideally you do this before that is the case. I fully agree that not everybody can afford audits from the get go.
regarding tokens we should definitely educate users about the risk of ICRC-2 approvals. your tokens can be secured through the best wallet out there. if you as a user approve some random canister to access all of your tokens, these are absolutely at risk! ideally dapps do not “force” the user to approve more tokens than needed and wallets provide respective warnings if that is the case.
in general I would always be careful adding too much funds to “in-dapp wallets”. especially if they are not open source and not audited.
Interesting. I agree that the use of Internet Identity should remain the primary standard, especially in applications involving user assets. However, One strategic step we can take moving forward is to foster active collaboration between developers, project founders, and security experts within the IC ecosystem.
Instead of waiting for expensive formal audits, we could:
Voluntary Community Reviews / Competitive Audit
Rather than relying on costly audits convesional, we could learn from competitive audit models like Cantina, Sherlock, and Code4rena — embracing the collaborative spirit of open source.
Open Security Best Practices Handbook for IC Developers
A community-based, openly accessible, and jointly moderated guide — containing best practices, secure code examples, and real-world security checklists that are continuously updated.
Workshop & Open Discussion Sessions
A space to share the latest attack vectors, security tools, and important updates from DFINITY — while continuously raising security awareness among IC developers.
With this approach, we’re not only strengthening IC’s technical foundations but also building a culture of collaboration and shared responsibility to secure the entire ecosystem.
what is the concrete gap you see that should be filled? all DFINITY can really do is provide best practices. I am sure that if it makes sense to add, the security team will be happy to provide better docs.
I still do not understand what exactly you mean if you talk about “token security”, please elaborate a bit more. as @skilesare already pointed out, the hack on Odin had nothing to do with ICRC-1.
I am not sure if I agree here. of course Internet Identity is an awesome way to integrate user authentication into a dapp, still the dapp should be free to decide what authentication method to choose. in case of Odin it was SIWB which had a serious bug that could be exploited
however, when it comes to storing assets and actually using (ICRC-1) assets on ICP across different applications, then it might be better to store these in a separate wallet/signer (e.g. OISY) and handle token related activities with the signer-standard which is being adopted by many DeFi related dapps as we speak. please note that you could still use II for authentication/login and then request to access funds from another wallet/signer only for token related activities.
Björn actually provided his point of view in a relevant post here in the forum back in November: PoV: Do not use ICRC-28 for Defi
And again, this is still not at all related to what happened to Odin.
Yes, you’re right—we are indeed free to choose the authentication method we use, including SIWB. However, this is where the importance of proper auditing and security review comes in, especially for methods that have direct access to user assets.
Additionally, I’d like to highlight how the ICRC-28 flow can serve as a trusted origin in a more secure system, as it enables a clear separation between authentication and asset transaction signing.
I fully agree with your statement that:
This approach not only enhances security, but also provides greater flexibility for both users and developers when building dapps
Today @robin-kunzler who leads DFINITY’s Security team has provided a clear diagnosis of what happened behind the hack of the Odin.fun canister.
These are the most important paragraphs, but I suggest you carefully read the whole post, and follow his advice:
Whenever possible, use vetted libraries or platform features for security-critical functionality and do not implement it on your own. If you use third-party components that are security-critical, make sure they went through a security audit and ideally have a bug bounty program in place. A bug bounty program can incentivize and motivate people to look for and responsibly report bugs they find (see e.g. DFINITY’s bug bounty program).
Similarly, if you write security-critical components yourself and stakes are high, perform security audits and consider running a bug bounty program. Furthermore, ideally the development processes aim at high quality and security. Thorough design and peer reviews and testing increase confidence. The ICP security best practices should be used as a reference. What can be done to be better prepared for attacks?
Observability - make sure you notice attacks. Ideally, projects implement automated alerting for suspicious activities, such as exceptionally large transfers, spikes in usage or logins, etc.\
Store data to enable forensic investigations. Logging important user actions such as authentication, transfers, withdrawals, etc. can prove very useful to retrospectively understand an attack, identify victims and attackers, trace funds and enable forensic investigations in general.
The key part where the code contained an implementation error that made the hack, and the stealing of funds is explained here:
Here is the link to the full post:
Joseph Hurtado
Founder Satoshi Notes
Founder Granata Consulting
Thank you. I’ve spoken with @marc0olo , and I’ll soon open a new forum thread to explore how long-time IC developers can share the common pitfalls that new IC developers often encounter.
I’ll also share my various insights into the Canister development process and how to quickly “keep everything under control” when building Canisters, so that developers aren’t tripped up by the IC’s unique characteristics.This will make it easier for developers to get started with IC development.
As a project producer, I often struggle with the conflict between canister upgrades and data preservation when communicating with the back-end, a problem that always plagues me and makes it difficult to effectively gather solutions to deal with.
All in all, thanks for the summary.
This topic can be quite complex—for example, which data lives in the Wasm heap memory versus in stable memory, and how to make trade-offs between them.
For most ordinary applications, you can simply store everything in stable memory and upgrades aren’t a problem. But once your data volume grows, neither storage efficiency nor subnet load considerations make that a good solution—after all, a subnet’s stable memory is under 500 GB in total.
I’ll open a dedicated thread to explain the Canister storage model and how to work with snapshots, stable memory, stable structures, and Wasm memory, sharing my own experiences. I also hope other seasoned developers will contribute their insights. A community-driven set of Canister development best practices will cover more and finer‐grained details than the official IC documentation.
Security audit ≠ Fighting alone — How to collaborate with the community to build a safer IC ecosystem @josephgranata, thank you for initiating this crucial discussion! I completely agree with your core point: security is the result of joint ecosystem building, not just the responsibility of audits or a particular team. As a security auditor, I’d like to supplement a few points from another perspective, hoping to complement the developer community.
The “irreplaceability” and “optimizability” of security audits
The “high cost” of security audits you mentioned is a fact, but its core value lies in:
Systematic Blind Spot Discovery: Community collaboration and peer review (Peer Review) rely on the breadth of participants’ experience, while professional audits cover “non-intuitive vulnerabilities” (such as permission configuration chains, cross-contract dependency issues) through systematic methods like attack tree analysis, fuzz testing, and compliance checks.
Independent Perspective: Developers are prone to “self-logic verification,” while auditors challenge design assumptions with an “attacker mindset” (e.g., “If the admin key is leaked, is there a circuit break mechanism?”).
Compliance Trustworthiness: Audit reports are transparent commitments of the project to users and investors, especially when dealing with funds (e.g., exchanges), and third-party verification can significantly reduce trust costs.
But I completely agree: Audits should not be the only method! We can optimize processes, for example:
Layered audit strategy: Prioritize auditing core modules (asset custody, permission control), rely on community review for non-critical features.
Auditing crowdfunding: Multiple projects jointly hire auditors to share costs.
Open-source audit tools: Toolize common detection items (e.g., Motoko anti-patterns) to lower self-audit barriers.
From the Odin.fun incident, the collaborative space of “audit + community”
If Odin.fun had undergone a security audit in advance, the following issues might have been intercepted in advance:
Authentication logic: Is session timeout enforced? Does the key derivation for social login meet entropy requirements?
Implementation vulnerabilities in multi-signature mechanisms: Has the threshold signature library been verified? Is the storage of split private keys physically isolated?
Privilege escalation risks: Does the founder’s account have excessive permissions? Can time locks be used to restrict emergency operations?
Audits cannot cover all scenarios! For example:
Long-term governance games (such as community takeovers of malicious proposals) require continuous social consensus supervision.
The trade-off between user experience and security (such as hiding NNS wallets) depends on the contextual experience of the developer community.
Therefore, audits are a “defense baseline,” while the community is a “continuous immune system.”
Direct suggestions for the developer community
If resources are limited, you can adopt the following low-cost, high-return strategies:
a. Phased audit:
Design phase: Architecture review (1-2 person-days, focusing on attack surface analysis).
Testnet Phase: Core Contract Auditing (3-5 person-days, priority check on asset flow).
b. Shared Audit Report:
Audit results (anonymized) will be open-sourced for other projects to reuse test items. For example: Common Anti-Patterns List for ICP.
c. Bug Bounty + Community Verification:
Set up a bounty with 10% of the audit budget to incentivize white-hat participation (e.g., HackerOne/Immunefi platforms).
Conclusion
Security audits are not just “submitting homework,” but a process of building a risk consensus with developers. We are willing to provide the following support for the IC ecosystem:
Free architecture consulting (limited to early-stage projects): Help design permission models and disaster recovery plans.
Open source self-check toolkit: includes ICP contract security checklist, Motoko secure coding guide.
Looking forward to collaborating with you and more developers to make security a competitive advantage for IC rather than a cost!
Third-party smart contract vulnerability led to unauthorized user account access
If no one reviewed the third-party software, then the code shouldn’t be considered audited. To put it in a much better context for people, were the software to seek insurance coverage, it would find it impossible to find an underwriter for a policy.
All these applications deal with money, but have seem to have zero consideration about something like insurance.
