Incident Report - Smart Contract ESDT Bug

• On May 14th, at around 08:32AM UTC, we detected attempts to interact with an unanticipated edge case in the protocol. In response, we immediately initiated containment procedures and implemented corrective measures
• The vulnerability originated from a VM opcode which lacked a validation check, allowing unauthorized modifications to the ESDT balance
• Preventive actions included temporarily turning off nodes in collaboration with 25+ staking providers to prevent further exploitation while a patch was developed, tested, and securely deployed
• The incident was resolved swiftly and effectively, with minimal impact, thanks to the prompt coordination among our internal teams, community members, and network validators

Now that the dust has mostly settled, we want to provide a detailed analysis of the issue, its root cause, and how we minimized impact to prevent any misuse of funds.

Root Cause

The affected code segment belongs to an older system component that manages value transfers and smart contract execution.

At the core of the edge case is the interaction between the transferValueAndExecute opcode and the generation of Smart Contract Results (SCRs), which together created an unintended execution path that exposed the flaw.

Detailed Description of the Bug

The incident was triggered by a transaction originating from a multi-signature (multiSig) smart contract, which invoked the transferValueAndExecute opcode with a specifically crafted data payload. This payload was designed to mimic an ESDT transfer operation.

The core issue was that the transferValueAndExecute function lacked proper validation to restrict or reject such payloads in this context. As such, the following things occurred:

• A SCR was generated using the malicious payload
• Although this SCR did not execute on the originating shard (where the multiSig contract is located), it was forwarded to the destination shard
• On the destination shard, the SCR executed a built-in function, updating balance on the destination account
• This execution caused the specified ESDT amount to be credited to the recipient's balance, bypassing the expected transactional safeguards and effectively enabling unauthorized asset creation

The behavior occurred in a rare circumstance, requiring a very specific combination of inputs and cross-shard interaction states to manifest, factors that made it difficult to detect through several specialized audits, deep reviews and heavy testing.

That explains why the vulnerability was not detected in at least three formal security audits and multiple automated AI-based verification scans, which all included full VM and ESDT token standard verification. 

Impact

The direct impact of the incident was limited to a small number of user-initiated actions. Specifically, the vulnerability enabled an unauthorized increase in ESDT token balance at a particular address, bypassing the system’s intended validation and execution paths.

The rapid containment, achieved in collaboration with validators and trusted community members, successfully prevented wider exploitation. Still, the extraordinary steps taken to contain the threat reflect the severity of the situation and the urgency with which it was handled.

Chronological summary of events

Initial Detection:

• Internal monitoring tools flagged a suspicious token balance change. A large amount of wrappedUSDC (150 quadrillion) was erroneously credited to a user wallet
• Engineering teams initiated investigations
• Community reports also began to surface

‍Immediate Action:

• During the early stages of analysis, we noticed that the respective amount of wrappedUSDC was transferred to a dead wallet, indicating 'white-hack' behavior
• Launched a deeper technical investigation to confirm the exploit’s mechanics

‍Issue Confirmed:

• After validating the issue, we proceeded with the following simultaneous actions:
  
  • Analyzed and reproduced the suspected vulnerability to pinpoint the root cause
  • Initiated direct communication with the broader validators community
  • Engaged community members to help identify the exploiter
  • Continuously monitored on-chain activity for replication attempts
  • Began assessing the impact of the incident

‍Second Exploiter:

• A new set of alerts informed us of a second faulty balance change for wrapped USDT from another user account and other suspicious activity from wallets being newly created and funded from a CEX

‍Validator Coordination:

• Shared findings with most validators that have verified identities on the explorer and with whom we have red-line connections. Achieved social consensus on emergency measures

‍Additional Measures:

• Initiated node pause for community delegation nodes
• Initiated the same procedure for 25+ other staking entities. Collectively, the percentage of nodes exceeded the Nakamoto coefficient threshold required for liveness
• Validator nodes that remained active tried proposing blocks but couldn’t reach consensus, as less than 66% of nodes were available for the quorum

‍Bug Fix Deployment:

• By this point, the root cause had been fully diagnosed
• A patch (v1.8.13.0) was reviewed internally and pushed to the main branch
• With all validation checks completed, we immediately began coordinating the rollout of the upgrade with the validators community
• The network returned to regular functioning within 2 hours and 30 minutes

‍Conclusions:

• The user who discovered the edge case has cooperated fully and agreed to all requested standard procedures
• Collaborated successfully with both and recovered 99.999% of funds
• Recovered funds were either burned or wiped, as applicable.
• Thanks to swift efforts from the entire community, the impact has been practically negligible, with NO users directly affected

Lessons Learned

‍Continuous Reviews, Audits and Extra Testing

Even stable, long-standing components need to be re-evaluated periodically. Over time, assumptions made in older code can become unsafe as the broader system evolves. 

Special attention should be given to modules that handle critical operations, such as value transfers or cross-shard communication.

‍Double Down Auditing Efforts

Three major audits were conducted on the VM and the entire ESDT standard. Additionally, all intra-cross shard components have undergone audits and multiple formal verifications since genesis. Moving forward, special attention will be given to edge cases that only appear in specific cross-shard scenarios.

Additional audits will carefully examine how different parts of the system interact, such as how opcodes work with SCRs, or how data payloads behave across shards. 

‍Strengthen Input Validation

All inputs, especially those that influence state changes or control flow, will be subject to stricter validation. This is especially critical in areas like shard boundaries or opcode handlers, where subtle edge cases can have system-wide consequences.

‍Speed and Resilience

While we are implementing immediate measures to enhance detection and prevention of highly unusual edge cases, Thursday’s incident has demonstrated the astute strength, responsiveness and resilience of the network, with the validator community addressing the vulnerabilities within minutes of detection. We are grateful for this excellent effort and proud to work with such amazing individuals and teams.

‍