Status: Ongoing incident response
Dear aelf Community,
On August 18, we notified the community that aelf had detected malicious smart-contract activity affecting the AELF MainChain and the tDVV dAppChain. We immediately began an incident response and moved the network into a controlled recovery process.
This is a progress update, not the final post-incident review. It summarises what we have confirmed so far, the current impact on users, the actions already taken, and the work that must be completed before services reopen. Some conclusions may change as forensic and security reviews continue.
We recognise the disruption and uncertainty this incident has caused for users, node operators, developers, and ecosystem partners. We take responsibility for the security gaps exposed by this incident, and we apologise for the impact on the community.
At a glance
- The AELF MainChain and tDVV remain in a controlled recovery process. Public query endpoints may be reachable, but this does not mean that block production, transaction submission, or ecosystem services have formally reopened.
- Based on the asset-integrity review of the identified incident-related on-chain activity and addresses, and the wallet-key exposure evidence assessed as of this update, we have not identified evidence that this incident caused unauthorised transfers of ordinary users’ assets or exposed ordinary user wallet keys. This conclusion does not extend to unresolved node and infrastructure credential exposure, and the investigation remains active.
- Node signing keys and infrastructure credentials accessible from relevant node environments are being treated as potentially exposed. Key rotation, credential revocation, forensic review, and clean environment rebuilds are in progress.
- We have identified 155 transactions associated with the malicious activity across AELF and tDVV and analysed five unique .NET payload assemblies.
- Ordinary users do not need to take additional on-chain action based on the current findings. Please continue to rely only on official aelf channels.
What happened
Our current technical assessment is that an unauthorised smart contract could use blockchain transaction parameters to deliver encoded .NET assemblies and instructions into the node contract-execution path. The analysed payloads included capabilities for host command execution, collection and attempted transmission of results, access to node-related key and configuration objects, and infrastructure reconnaissance.
The presence of these capabilities does not by itself prove that every payload was successfully executed on every node, that every targeted credential was obtained, or that sensitive data was successfully transmitted. Those questions remain subject to host, cloud, identity, and network forensics.
The incident exposed gaps in the coverage of runtime reflection and dynamic-loading paths during contract code checks, as well as weaknesses in the isolation between contract execution and sensitive node or infrastructure resources. Our final root-cause assessment will be published after the relevant fixes and recovery evidence have been validated.
What we have confirmed so far
Our investigation has identified:
- 155 transactions associated with the malicious activity: 127 on AELF and 28 on tDVV;
- five unique .NET payload assemblies after deduplication across both chains;
- payload capabilities involving host command execution, result collection, attempted outbound communication, node-key access, and infrastructure reconnaissance; and
- activity extending risk into the trust boundaries of node execution environments and related infrastructure.
Node signing keys, keystore credentials, and infrastructure credentials accessible from relevant environments are being handled under a potential-exposure standard and are being rotated or revoked as a precaution. This does not mean that every credential has been confirmed as accessed or exfiltrated.
Current network and service status
As of this update, the production networks have not formally reopened for public use, and public transaction submission remains disabled. Validation is continuing in an isolated recovery environment. BP key rotation, preparations for BP onboarding, infrastructure remediation, and security verification are progressing.
Some public read-only or status endpoints may be reachable. Their availability should not be interpreted as confirmation that block production, transaction submission, cross-chain operations, exchange deposits or withdrawals, or other ecosystem services have reopened. Users and partners should wait for a separate official reopening notice for each service.
Actions taken
Since detecting the incident, we have:
- restricted network access and moved recovery work into an isolated environment;
- identified the associated on-chain activity and analysed the known payload assemblies;
- introduced temporary containment for the known malicious contract activity and begun validating it in the isolated recovery environment;
- begun rotating BP and dAppChain signing keys, keystore credentials, and related infrastructure credentials;
- begun preserving forensic evidence and rebuilding relevant environments from trusted sources;
- blocked connections to known associated network indicators within environments under our control, and expanded host, cloud, identity, and outbound-connection monitoring;
- begun permanent hardening of contract code checks and execution isolation.
Temporary containment is not the permanent fix, and implementation work or an open code review does not mean that the fix has been fully deployed across all participating nodes. We will only mark a remediation item as complete after deployment and validation evidence is available.
Work still in progress
Before reopening affected services, we are working to complete:
- onboarding and validating all BPs that will participate in the restored network;
- rotation and revocation of relevant signing keys and infrastructure credentials;
- clean rebuild and re-entry checks for relevant node and supporting environments;
- deterministic replay and ledger-continuity validation across participating BPs, including transaction outcomes, balances, fees, logs, and state commitments;
- permanent CodeOps and runtime-isolation fixes, including testing against the known payloads and equivalent variants; and
- independent security review and closure of any blocking findings.
Services will reopen in stages only after the applicable recovery gates have been met. We will not treat a single node producing blocks, a reachable status endpoint, or the existence of a code patch as proof that recovery is complete.
What users and partners should do
Ordinary users
- No additional on-chain action is required based on the current findings.
- Do not use unverified RPC endpoints or links claiming to offer asset recovery, compensation registration, or security upgrades.
- aelf will never ask for a seed phrase, private key, keystore file, or keystore password through a direct message. Do not provide these credentials to anyone.
If a wallet key or keystore was stored or used on a BP node, node host, or related operations environment, it should be treated as an operator credential rather than an ordinary user wallet and handled under the relevant rotation process.
Node operators and ecosystem partners
Node operators, exchanges, bridges, wallets, dApps, and custodial services should continue to follow the authenticated operational guidance provided through official channels. Services should not be reopened solely because a public endpoint is reachable. Relevant parties should verify the official recovery baseline, signed node build, checksums, ledger status, and any pending business records before resuming operations.
Next update and final post-incident review
We will publish our next progress update on August 27, 2026 (UTC), even if there is no material change. Any material change affecting user assets, required user action, network integrity, or service availability will be communicated sooner.
Once the investigation, recovery validation, credential remediation, permanent fixes, and independent review are complete, we will publish a full post-incident review and a technical appendix. These will include the verified timeline, root cause, impact scope, recovery decisions, remediation evidence, and defensive technical indicators that can be shared safely.
Defensive information needed by node operators and ecosystem partners is being shared through authenticated channels during the response; it will not be delayed until the final public report.
Thank you for your patience and for holding us accountable. We will continue to prioritise security, evidence, and transparent communication over recovery speed.