Hi, is it possible for ic-py to become a bounty project at this point? I know the original developer of ic-py, and based on the experience of myself and my friend, I believe that if the community is interested, we could revisit and further develop the code.
I would be careful with such listings. IMO it quickly becomes overwhelming. I would try to reverse this and start with the question What does the developer want to achieve?
Underneath the goal of the developer, there might be different approaches to tackle this where the community can share their experiences and best practices. These experiences (ideally written in tutorial style) could be rated (thumbs up/down) by the community.
This is the direction I was thinking of. Would also love to get your opinion on this.
shared with the team. will come back on this
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 .
I love this! I agree with all of your points, go ahead!
I am very happy to collaborate on this one specifically. I have been looking into this area a lot recently.
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.
What do you think?
sounds good, can’t wait to see it.
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!
I love this initiative!
We’ve created something similar to this a while back (from the Hubs Dev Rels)
-
Awesome ICP Education Hub - this repository contains:
- 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
- Templates: code examples that demonstrate ICP’s capabilities. It’s been categorized into the different languages, i.e, Motoko, Rust, and TypeScript.
-
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.
What do you think @C-B-Elite ?
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.
Marco,
I salute other initiatives that bring better dev docs.
That said, there is a gap in docs that directly address how to prevent HACKS.
The rest exists in one way or another, but the focus on token security I have not seen anywhere. Will DFINITY start this? Or is all up to us?
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
that are truly resilient against exploitation.
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