The recent security incident involving Neemo Finance has raised questions within the community, particularly regarding the responsibilities of the Astar Community Council (ACC) in overseeing the dApps listed in the dApp Staking program. This post aims to clarify the Council’s role, the nature of Astar’s permissionless ecosystem, and outline process improvements moving forward.
A Permissionless Blockchain
Astar operates as a decentralized and permissionless network, meaning that any individual or team can deploy smart contracts without centralized approval. While this enables open innovation and inclusive participation, it also requires shared responsibility.
In the case of Neemo, the exploit stemmed from a contract deployed via an externally owned account (EOA), which was compromised. This architectural choice, while permissible, did not include additional layers of protection such as multisig wallets. The private key breach of this EOA led to the incident.
It is essential to note that Neemo had submitted a comprehensive security audit with spotless conclusions well before the hack . The audit, conducted by a reputable firm (Hacken), did not identify any critical vulnerabilities at the time of review. This audit remains publicly available:
Neemo Audit by Hacken
This reinforces an important point: a successful audit is not a guarantee of ongoing safety . Security is an evolving field, and new vulnerabilities can emerge through later updates or unforeseen circumstances — especially as technologies such as AI advance rapidly.
Clarifying the Role of the ACC
The ACC is tasked with evaluating the strategic alignment, transparency, and community contribution of dApps in the staking program. However, it is important to clarify that:
- The ACC does not conduct technical audits or code reviews.
- Our assessments are based on due diligence materials, public documentation, team activity, and ecosystem alignment.
- While we require audits from dApps, we do not validate or re-audit the code ourselves .
Even when a dApp provides a valid audit, updates to the code or changes in infrastructure — like switching wallets or deploying new contracts — can create new vulnerabilities beyond our scope of oversight.
Strengthening the Process
We recognize the need for more rigorous standards, especially for dApps that handle significant user funds. As such, the following improvements are being implemented:
Higher Standards for Risk-Prone dApps
- dApps in sensitive categories — including DEXs, lending protocols, LSTs, stablecoins, and platforms enabling bulk token transfers — must provide up-to-date third-party security audits and implement best practices (e.g., multisig wallets).
- Audits will now be part of the standard due diligence both at onboarding and during periodic reviews.
- While monthly audit reports are not feasible , updated audits will be required when major features or contracts are added .
This strikes a balance between practical feasibility and user protection. Our role will focus on reviewing the audit conclusions shared by external experts. The Council does not certify code safety — but ensures that audits are in place and risks are properly disclosed.
Final Remarks
The community’s concerns are valid, and this incident has prompted valuable reflection. However, we must uphold Astar’s core principles of decentralization and permissionlessness , where responsibility is distributed — not centralized.
Security is, and must remain, a shared responsibility between developers, the community, and governance bodies like the ACC. Our mission is to strengthen processes, foster transparency, and encourage industry standards — without compromising the open nature of the ecosystem.
We remain committed to learning, evolving, and supporting the long-term health of the Astar and Soneium ecosystems.
Thank you for your continued trust and engagement.
Astar Community Council