The below post can also be found as a PDF.
1. Summary
On December 27, 2025, an attacker exploited a vulnerability in the Flow network to counterfeit tokens, extracting approximately $3.9 million USD. No existing user balances were accessed or compromised—the attack duplicated assets but did not touch legitimate holdings. Validators executed a coordinated halt within six hours of the first malicious transaction, and the vast majority of counterfeit assets were contained onchain or frozen by exchange partners before they could be liquidated. Network validators have ratified a decentralized governance action authorizing the permanent destruction of 100% of counterfeit assets.
The network resumed operations on December 29th, and is operating as expected.
The attack demonstrated significant technical sophistication. The attacker deployed over 40 malicious smart contracts in a coordinated sequence, exploiting a three-part attack chain: (1) attachment import validation bypass, (2) circumvention of defensive checks on built-in types, and (3) exploitation of contract initializer semantics. It was a multi-stage targeted attack at distinct security boundaries.
Flow operates two integrated programming environments: the Cadence environment, which uses a resource-oriented programming model (akin to Move), and a fully EVM-equivalent environment, enabling developers to build in either Solidity or Cadence while sharing state across both. The exploit targeted Cadence specifically. In Cadence, tokens are not simple ledger entries but programmable objects that cannot be copied or implicitly destroyed—only moved. This resource-oriented design provides strong safety guarantees under normal operation. The root cause was a type confusion vulnerability in the Cadence runtime (v1.8.8), now patched (v1.8.9 and later). The flaw allowed the attacker to disguise a protected asset (which should be non-copyable) as a standard data structure (which can be copied), bypassing the runtime's safety checks and enabling token counterfeiting.
The attack began on December 26, 2025, at 23:25 PST (Block 137363398), when the attacker deployed the initial malicious contracts. Counterfeit token creation began minutes later. By 23:42 PST, counterfeit FLOW was being transferred to centralized exchange deposit accounts. Validators executed a coordinated network halt at 05:23 PST on December 27 (Block 137390190), severing all exit paths within six hours of the first malicious transaction.
Remediation is proceeding in coordination with Flow Foundation, the Community Governance Council, and network validators. 1.094 billion counterfeit FLOW was deposited by the attacker across multiple centralized exchanges –– of this, 484,434,923 FLOW has already been returned by cooperative exchange partners (OKX, Gate.io, MEXC) and destroyed. Of the remaining counterfeit supply, 98.7% has been isolated onchain pending destruction. Coordination with additional exchange partners is ongoing and full resolution is expected within the next 30 days. As a protocol-level backstop, all attacker-linked deposit addresses are restricted at the execution layer: these assets cannot be withdrawn, bridged, or transferred until returned for destruction.
The network was restored on December 29, 2025, via an Isolated Recovery Plan that preserves all legitimate transaction history. This approach was selected—following community evaluation of multiple recovery options including checkpoint restoration—through ecosystem-wide consultation with exchanges, bridge operators, and infrastructure partners. The Isolated Recovery Plan was chosen specifically to avoid reconciliation risk for off-chain custodial systems and cross-chain protocols maintaining independent state.
A comprehensive series of patches have been deployed to Flow mainnet addressing all three stages of the exploit chain. The transaction argument validation logic has been overhauled to enforce strict static type verification for all nested fields, including attachments, during contract initialization. Defensive runtime checks have been extended to cover all types, including built-in types. The contract deployment function now mandates strict matching between static argument types and initializer parameter types. These exploit vectors have been integrated into the Flow core regression test suite, and advanced static analysis tooling has been deployed to detect similar patterns in future development cycles.
The Foundation is cooperating with blockchain forensic partners including zeroShadow and Find Labs and relevant law-enforcement authorities to support ongoing investigations.
Full technical details of the vulnerability, exploit mechanism, forensic analysis, and remediation architecture are provided in subsequent sections.
2. Incident Timeline (PST)
2.1 Exploit execution
2025-12-26 23:25 (Block height: 137363398)
- Attacker deploys and configures exploitable contracts.
2025-12-26 23:35
- Counterfeit token duplication begins.
2025-12-26 23:36
- Counterfeit FLOW transfers to secondary Flow accounts controlled by the attacker.
2025-12-26 23:42
- Large FLOW transfers are sent to centralized exchange deposit accounts, the majority of which get frozen on receipt due to the size and irregularity of the activity.
2025-12-27 00:06
- A small number of assets are bridged off-network via Celer, deBridge and Stargate.
2025-12-27 01:00
- Centralized exchanges experience significant sell pressure as counterfeit FLOW is liquidated.
2.2 Detection and assessment
2025-12-27 01:30
- Initial detection signal is raised: anomalous cross-VM FLOW movements correlate with exchange deposits.
- Standard totalSupply invariants do not trigger.
- The exploit duplicates existing resource vaults rather than exercising the protocol's minting logic.
- Early onchain signals are initially indistinguishable from legitimate high-volume activity, such as large-holder liquidation.
2025-12-27 03:56
- Secondary swaps and additional bridging activity occurs, confirming exploit-driven asset movement.
2025-12-27 05:21
- Final attacker-controlled onchain transfer.
- The exploit path and affected execution surface is isolated.
2.3 Containment
2025-12-27 05:23 (Block height: 137390190)
- Community validators halt transaction ingestion, requiring coordination amongst multiple globally distributed network validators.
- All exit paths are severed and further counterfeit token duplication is prevented.
- The network enters a controlled read-only mode to preserve ledger consistency and enable deterministic forensic analysis.
2025-12-27 05:30 – 2025-12-29
- The network remains online in read-only mode.
- Security hardening underway as developers patch the vulnerability.
- Stakeholders assess recovery options to determine the optimal path forward.
2.4 Network Recovery
2025-12-29 05:00 - Phase 1: Containment of Incident-Affected State
- Flow Cadence environment restores read and write access.
- Flow EVM environment remains read-only pending remediation.
- 1,060 addresses are temporarily restricted at network restart.
- Over 99.99% of accounts in the network regain full functionality.
2025-12-30 07:00 - Phase 2: Cadence Environment Remediation
- Height Coordinated Upgrade (HCU) is executed under validator-authorized recovery.
- Over 98.7% of coutnerfeit assets on both Flow Cadence and Flow EVM are recovered, remaining assets are frozen by exchange partners.
- The Community Governance Council coordinates the recovery and permanent destruction of the remaining supply.
2026-01-02 07:00 - Phase 3: EVM Environment Remediation
- Flow network fully operational.
- Validator-authorized remediation actions begin.
- Unrestriction of non-exploit-related accounts.
- Temporary allow-listing of specific EVM EOAs required for DEX pool rebalancing.
- Preparatory steps for restoring full EVM read/write functionality.
At Operator Discretion - Phase 4: Resumption of Normal Operations
- Validators revoke elevated Community Governance Council privileges.
- Bridges and centralized exchanges resume integrations following independent determinations and a period of verified network stability.
- Flow Foundation provides ongoing coordination and status verification to facilitate ecosystem-wide re-enablement.
3. Financial Impact Assessment
The exploit targeted the execution layer's type-validation logic, allowing it to impact multiple fungible token (FT) contracts. For the primary assets targeted—specifically FLOW and a subset of FTs instantiated — the duplication occurred at 87.96 billion units per asset. A broader range of ecosystem tokens was also affected (see section 6 for table), though these were duplicated in materially smaller quantities. Importantly, because this was a runtime exploit that duplicated existing resource objects, the attacker bypassed the high-level minting logic and supply-cap invariants defined within the individual smart contracts.
It is critical to distinguish between nominal value (the face value of counterfeit tokens) and realized financial damage (value extracted). While the attacker duplicated tokens with a high nominal value (including 87.96B FLOW), the vast majority were successfully contained onchain or frozen by exchange partners. The confirmed realized financial damage to the ecosystem is approximately USD 3.9 million, representing the value successfully bridged off-network via Celer, LayerZero, and deBridge prior to the halt. The discrepancy between this figure and onchain transfer volumes represents counterfeit assets deposited to centralized exchanges that were successfully frozen before they could be liquidated, preventing actual financial loss to the market.
4. Root Cause Analysis
The attacker had to go through great lengths to circumvent existing safeguards that are meant to prevent type confusion attacks. The attack required a complex three-part exploit chain, the deployment of dozens of smart contracts, and a sophisticated understanding of Cadence, resulting in the attacker using the exploit to duplicate resources. Analyzing this exploit requires a foundational understanding of how Cadence manages asset integrity through move-only semantics and account-based storage.
4.1 Context on Cadence
Flow utilizes a resource-oriented programming model via its native language, Cadence (a language that offers linear-type move semantics like in Move, Rust, etc.). Unlike many blockchains where tokens are simple entries in a ledger (a map of balances), tokens on Flow are programmable objects that exist directly in a user's account storage. Resources effectively mimic physical assets that cannot be copied or implicitly discarded, only moved or explicitly destroyed.
To enforce this, the Cadence runtime employs rigorous static and dynamic checks to ensure resource integrity. Furthermore, all tokens on Flow, including the native FLOW token, adhere to a single Fungible Token Standard. This provides a unified, hardened code path for securing assets, which simplifies auditing and obviates the need for "wrapped" versions of native assets.
More information on Cadence and its unique properties can be found at the Cadence site.
4.2 How the Exploit Happened
On December 26, 2025, at 23:25 PST (Block 137363398), the Flow network experienced a security exploit targeting the execution layer. An attacker utilized a Type Confusion Attack to bypass Cadence’s resource linearity guarantees, resulting in the unauthorized duplication of multiple fungible tokens.
By crafting malformed transaction arguments that bypassed runtime validation, the attacker caused Cadence to statically treat a value as a struct (copy semantics) while dynamically executing it as a resource (move semantics).
This resulted in resources being duplicated, enabling arbitrary duplication of fungible tokens.
Part 1: Attachment Import Validation Bypass
Attachments are a feature of Cadence designed to allow developers to extend a struct or resource type (even one that they did not create) with new functionality, they are essentially values that can be ‘attached’ to another value. These can be imported alongside structs when passed as transaction arguments and are stored in non-statically-declared fields.
As attachment fields were not being fully validated during argument import:
- Attachments were allowed to contain fields with incorrect runtime types
- These fields were not checked against their declared static types
By sending a struct with an attachment which contains invalid fields, the attacker was eventually able to confuse Cadence into believing that statically a value is a struct type (which is copied), even though the actual value at run-time is a resource (which should be moved). This allowed the attacker to duplicate resources.
Example of Malformed Argument Input: The following JSON-CDC payload demonstrates how the attacker provided an Int value (123) for a field statically declared as a String, which the argument validator failed to reject:
// transaction arguments demonstrating the validation bypass:
[
A.0000000000000123.SomeContract.SomeStruct(
// The system failed to validate the fields within this attachment field
$A.0000000000000123.SomeContract.SomeAttachment:
A.0000000000000123.SomeContract.SomeAttachment(
// CRITICAL: statically expected `String`, but runtime provided `Int`
string: 123
)
)
]
Although this issue was promptly patched, by itself it could only introduce objects to the runtime that would be rejected by later dynamic checks.
Part 2: Circumvention of Defensive Checks by Using Built-In Types
Cadence intentionally employs a series of defensive checks to handle unforeseen scenarios where type-confused values could potentially be introduced via an exploit. The runtime did not include these dynamic checks on certain internal types since most internal types can only be created by the runtime itself. However, a small number of internal types (including "PublicKey", used in this exploit) can be created by user code, and thus were bypassed in the dynamic checks.
The attacker exploited this by:
- Declaring a value as a PublicKey
- Encoding a resource-containing structure in its place
Because PublicKey is partially user-constructible, the runtime:
- Skipped deep validation
- Allowed a resource type to exist inside an object declared to be a value type
Thereby allowing for resource smuggling inside a struct context.
Part 3: Exploitation of Contract Initializer Semantics
Even though the first issue allowed the user to create resource types that were masquerading as value types (and could therefore be duplicated), and then allowed those types to avoid checks when accessed (by hiding the malicious data inside an internal type), the language doesn’t allow arbitrary casting between types. Those duplicated resource objects would be trapped forever inside value objects except for the 3rd circumvention: Contract Initializer Static-Type Mismatch.
When deploying a new smart contract, the arguments passed to the contract initializer are passed as-is from the deploying code to the initializer. The initializer only looked at the dynamic type of the object (“resource type” in this attack), even though at the point of deployment, the object was statically a “value type”.
To illustrate this, contract deployment in Cadence uses:
account.contracts.add(
name: "...",
code: "...",
<initializer args>
)
The initializer arguments are copied if statically typed as values, and moved if statically typed as resources.
The attacker exploited the fact that:
- The add() call did not verify that the static types of initializer arguments matched the contract’s initializer signature (parameters)
- The calling context believed the argument was statically a struct
- The contract initializer treated it as a resource
- Only the dynamic type of the argument was checked against the parameter type
This resulted in a copy of a resource, violating linearity guarantees and duplicating the resource.
Token Duplication
The attacker then obtained a small number of each of the 13 fungible tokens, and then duplicated these small amounts 42 times in a sequence. The token duplication transaction can be seen here (Note that all token amounts are multiples of 242 = 4398046511104). It’s important to also note that these assets were duplicated, not minted, therefore total token supply values for each of the tokens remained unchanged; minting logic was entirely bypassed in the attack.
The total amount of counterfeit tokens duplicated by the attacker was, in most cases, far beyond the total legitimate supply of those tokens. However, this incident does not undermine the underlying safety of the Fungible Token standard; the standard’s interface correctly enforced move-only semantics for all other transactions. The vulnerability resided strictly within a low-level runtime type-confusion issue that allowed for the unauthorized duplication of the objects themselves, bypassing the standard's logic entirely rather than exposing any flaws in the standard's design.
5. Security Hardening (Mainnet 28)
The following protocol upgrades and patches to the Cadence runtime were implemented to address the three-part exploit chain and harden the execution layer against future type-confusion vectors.
5.1 Hardened Argument Validation
The transaction argument validation logic was overhauled to eliminate the "smuggling" vector found in part 1 of the exploit chain.
onflow/cadence#4389: Fix argument import: This patch updates the transaction argument validation logic to forbid the import of attachments and composite values with fields that are not statically declared. This ensures that all data entering the runtime matches the expected static type before execution begins.
5.2 Extended defensive checks for built-in types
onflow/cadence#4392: Extend defensive check for member accesses on values of built-in types: Cadence now performs member access defensive checks on all types, whether they are user-defined or built-in (e.g., PublicKey). This enforcement explicitly forbids resource types from residing inside value types. Any attempt to access a type-confused object now triggers an immediate runtime panic, terminating the transaction and protecting asset linearity.
5.3 Strict Deployment Semantics
onflow/cadence#4394: Check static types of arguments passed to contract constructor: The defensive checking of argument/parameter types was extended to account.contracts.add(), so the function now mandates a strict match between the static type of the deployment argument and the parameter type defined in the contract's init function. By verifying these types at the boundary of contract instantiation, the runtime ensures that copy semantics (for values) and move semantics (for resources) are never interchanged, preserving the fundamental linearity of all assets.
5.4 Regression and Forensic Testing
onflow/cadence#4391: A specialized regression test suite was integrated into the core Cadence repository. These tests specifically simulate the December 26 exploit pattern to ensure that future language updates do not reintroduce these vulnerabilities.
5.5 Bug Bounty Program
By increasing visibility and rewards for vulnerabilities in the execution layer, Flow is fostering a continuous, decentralized audit of the protocol. This program encourages researchers to explore the same "defensive blind spots" identified in this incident, ensuring that future protocol changes and additions undergo rigorous external testing.
6. Forensic Analysis
To ensure a transparent and neutral audit of the incident, an independent forensic investigation by zeroShadow was launched to map the resulting fund flows. The attacker-controlled wallets were traced across Flow Cadence, Flow EVM, and external networks to determine where duplicated assets moved and which portions resulted in off-network settlement. The investigation focused on concrete outcomes: deposits to centralized exchanges, swaps executed on DEXs, bridge deposits that finalized off-chain, and assets that remained recoverable on Flow.
Key Forensic References
The attacker’s addresses have been flagged with major analytics providers and are under active monitoring.
6.1 Total Counterfeit Tokens
* Locked in bridges: Refers to counterfeit assets that were deposited into the Celer bridge contracts, but did not complete cross-chain finalization and were therefore not released to attacker-controlled accounts on destination networks. These recoverable assets are currently escrowed within the Celer bridge contracts and are not in circulation on external chains.
6.2 Assets sent to Centralized Exchanges (CEX)
Roughly 98.7% of the counterfeit FLOW tokens never left the attacker’s accounts, and an even smaller amount left the actual network. In total, 1.094B FLOW were transferred to centralized exchanges. When these assets reached CEX deposit addresses, the vast majority were successfully frozen by exchange partners upon receipt, many of whom were in contact with the Foundation. As part of the Community Governance Council remediation process, all exchange deposit wallets linked to the attacker were temporarily restricted. These wallets remain in a strictly restricted state to ensure total containment until the surgical remediation is finalized.
Consequently, the overwhelming majority of counterfeit assets never entered active circulation, having been successfully isolated within attacker-controlled accounts or frozen at the point of deposit.
Attacker Direct Deposits to Centralized Exchanges
Data derived from third-party forensic tracing of direct transfers from attacker-controlled wallets to exchange infrastructure.
Centralized exchanges receiving large-volume deposits from novel addresses bear an independent duty of inquiry under standard anti-fraud and AML procedures. The velocity and magnitude of the attacker's deposits—in several cases exceeding 100 million FLOW to a single venue within hours—constituted constructive notice of abnormal activity. Venues that implemented immediate freezes successfully contained the counterfeit assets. The Foundation is coordinating with exchange partners to facilitate retrieval and destruction as a matter of ecosystem integrity.
6.3 Assets swapped on Decentralized Exchanges (DEXs)
Approximately, 47.9M of the counterfeit FLOW had been swapped through the following paths:
- Flow Cadence environment
- IncrementFi (DEX): 11,300,000 FLOW swapped to $558,651.75 in stables: USDF, stgUSDC, USDC.e.
- The attacker did not move the funds.
- The funds have been recovered by the Community Governance Council.
- Flow EVM environment
- KittyPunch (DEX): 36,600,530.12 FLOW swapped to 159.71 ETH and $1,814,703.16 in stables: USDF, stgUSDC.
- The swapped assets exited the network via bridges and is included in the total $3.9M of bridged-out assets.
Assets bridged out
Bridged out refers to counterfeit assets that exited the Flow network via cross-chain bridge protocols and were finalized on external chains. Once those assets were bridged out to another network, they were no longer recoverable through the remediation plan. The net total of assets bridged out of the network amounted to approximately $3.9M USD.
In parallel with technical containment and remediation, Flow Foundation initiated standard incident-response procedures, including coordination with relevant bridge operators and appropriate external authorities. This process aims to support potential recovery actions and to assist ongoing investigations related to the off-network movement of assets.
Assets Bridged Off-network
The ~$3.9M USD worth of bridged-out assets were laundered through THORChain and Chainflip.
7. Restricted Accounts
During the exploit, 1,060 incident related accounts were flagged as having interacted with, and obtained, counterfeit tokens. These accounts were temporarily restricted to prevent the broader dissemination of the assets.
7.1 Restricted Account Methodology
A Restricted Account is defined as:
- An account placed into a temporary read-only state.
- The account cannot execute transactions, transfer funds, or mutate smart contract state.
- The account remains fully visible onchain. State queries (scripts) and balance verifications function normally to allow for auditing.
A list of approximately 1,500 addresses was generated through a conservative risk management process in collaboration with Find Labs. The forensic team cast a wide net, tagging not only the attacker’s direct wallets but also any account with secondary, and greater degree interactions to ensure zero leakage of counterfeit assets. Subsequent analysis on December 29 further narrowed down the list to 1,060 accounts, restoring access to more legitimate users. Accounts controlled by the attacker, or that were used in the creation of counterfeit assets, were also included in the restricted accounts list. However, the attacker accounts represented only a small percentage of overall accounts in the list, the majority of accounts involved were contaminated through swapping regular tokens with counterfeit tokens on exchanges.
For many accounts, the restriction was lifted within 24 hours of the network reopening, following the verification that no counterfeit assets were present in the account's storage. For the remaining restricted accounts, restrictions will be resolved as part of Phase 4, following final ecosystem-wide reconciliation and confirmation that no counterfeit assets remain.
7.2 Account Identification Process
The steps taken to identify accounts by forensic analysis included:
- Identify accounts that directly received transfers from the attacker.
- Identify accounts that interacted with a contaminated swap pair, bridge, or lending contract.
- Fan out direct transfers from the attacker to identify accounts that definitely should have funds recovered.
- Follow cross VM bridged tokens and fan out direct transfers from the attacker to identify accounts that definitely should have funds recovered.
- Determine if any tokens were bridged back on different accounts (none were).
This ensured a thorough and complete list of accounts that potentially held counterfeit assets, to ensure the incident was properly contained before the network reopened.
7.3 Restricted Account List
The identification process resulted in a final list of 1,060 accounts that required temporary restriction to facilitate remediation, while the network would be re-opened for all other users. This final list of accounts represented under 0.01% of the total accounts on the network. Furthermore, the vast majority of these accounts held only nominal amounts of counterfeit assets.
The full list of restricted accounts is available for technical audit, along with the associated transaction (note: this transaction adds an additional two accounts required for network recovery and operations but those accounts have later been unrestricted).
8. Remediation and Recovery
Immediately following containment, Flow Foundation and the Community Governance Council prepared different prospective recovery paths including a full rollback to a pre-exploit checkpoint and isolated recovery. Following consultation with exchanges, bridge operators, and infrastructure partners, Flow Foundation and the ecosystem opted for the latter remediation approach, preserving all legitimate transaction history, while enabling targeted neutralization of counterfeit assets. The Isolated Recovery Plan was selected to preserve all legitimate transaction history, thereby mitigating reconciliation risks for off-chain custodial systems and cross-chain protocols. With the strategic path solidified, once community validators ratified it, the network immediately transitioned to the implementation of a surgical remediation to neutralize the counterfeit assets.
8.1 The Four Phases of The Isolated Recovery Plan
Phase I: Containment of Incident-Affected State
On December 29, 2025, at 6 AM PST, Flow Cadence environment was restored to read and write status, and began processing transactions. Upon network resumption, immediate restriction of contaminated accounts was enacted to prevent the propagation of counterfeit assets.
- Flow EVM Environment: Flow EVM was restricted to read-only mode while more complex EVM remediation was prepared.
- Flow Cadence Environment: Cadence operations resumed immediately.
- Temporary Account Restriction: 1,060 Cadence accounts were placed in a restricted read-only state.
Phase II: Cadence Environment Remediation
On December 30, 2025, at 7 AM PST, a Height Coordinated Upgrade (HCU) was executed with validator-authorized recovery permissions to allow the Community Governance Council the ability to recover counterfeit assets on the Flow network.
- Governance Authorization: A temporary software upgrade was proposed to validators. On December 31 2025, a contract was upgraded to expose a limited governance interface, specifically granting the Community Governance Council the capability to recover and destroy counterfeit tokens from restricted accounts.
- Asset Recovery: Following validator consensus, the Community Governance Council executed transactions to:
- Recover the counterfeit assets in Flow Cadence as well as Flow EVM.
- Emit an onchain event for verification.
- Account Unrestriction: Accounts confirmed to be free of counterfeit assets were unrestricted.
Phase III: EVM Environment Remediation
On January 2, 2025, at 7 AM PST, a HCU was executed under validator-authority to re-enable and begin remediation on the EVM environment.
- Bridge & Recovering of Counterfeit Tokens: The Community Governance Council executed transactions to vm-bridge counterfeit tokens from EVM addresses back to the Cadence layer for permanent destruction.
- DEX Pool Rebalancing: Proceeds generated by the attacker through trades against legitimate pools were recovered from the attacker-controlled addresses and designated for liquidity pool rebalancing along with funds from the Foundation treasury.
Phase IV: Resumption of Normal Operations
To mitigate the economic impact of the exploit, the final phase includes the Foundation executing a stabilization plan for liquidity providers. This will include:
- Residual Supply Check: A net-transfer analysis conducted to identify any residual supply imbalances resulting from regular trades.
- Permanent Destruction: The Foundation commits to recovering and destroying counterfeit tokens associated with the hackers accounts to neutralize any remaining discrepancy.
- Privilege Revocation: Upon the conclusion of remediation, a subsequent protocol update will be deployed to revoke the elevated permissions from the Community Governance Council.
The execution of the Isolated Recovery strategy successfully neutralized the security incident without compromising the network or users assets. By prioritizing surgical state remediation, the network preserved the finality of all legitimate transactions while removing counterfeit through transparent, governance-authorized intervention. This coordinated response also minimized reconciliation overhead for ecosystem partners.
On January 2, 2025, at 7 AM PST, the network returned to standard operation with the underlying vulnerabilities fully patched. The forensic data, restricted account lists, and remediation transaction logs remain accessible for ongoing technical audit and full transparency regarding the incident's resolution.
8.2 Exchange-Held Asset Remediation
The remediation of counterfeit assets deposited to centralized exchanges operates within the governance framework jointly established by Flow Foundation, the Community Governance Council, and ratified by network validators.
Protocol-Level Enforcement
All exchange deposit addresses linked to the exploit were restricted via the validator-authorized HCU process described above. This restriction is enforced at the execution layer:
- Assets cannot be withdrawn to Flow addresses
- Assets cannot be bridged to external networks
- Assets cannot be transferred within Flow EVM
This enforcement persists regardless of individual exchange cooperation status.
Remediation Status
Governance Escalation Path
For venues where coordination does not reach resolution within a reasonable timeframe, Flow Foundation and the Community Governance Council may propose additional measures, subject to validator consensus via the standard governance process.
9. Guarantees going forward
The foundation has committed to the following guarantees to strengthen network security and resilience:
- Runtime type validation boundaries have been hardened and covered by regression tests to prevent recurrence of this exploit class.
- Elevated recovery permissions for Community Governance Council introduced during remediation will be revoked following completion of all recovery phases.
- Supply anomaly detection and execution-layer monitoring will be expanded to surface similar conditions earlier.
- Review the bug-bounty program and increase rewards to align closely with the increased TVL.
- Enhance the security procedure to provide timely and accurate communication with all partners and establish feedback channels early on.
- Future incident responses will clearly distinguish between proposals under consideration and finalized decisions. A process to align with all stakeholders and converge on a decision.
10. Acknowledgements
The recovery of the Flow network was a collective effort that spanned the entire global Flow ecosystem day and night throughout the holiday season. We want to thank the Flow team as well as individuals and organizations who worked around the clock to ensure the integrity of the network and the security of its users.
Technical & Forensic
Find Labs & zeroShadow: For their tireless, 24/7 dedication to forensic reconstruction. Their expertise in recursive graph traversal and cross-chain fund flows was instrumental in swiftly isolating the exploit and identifying the incident accounts for remediation. The forensic reconstruction demanded significant effort, necessitating analysis across two separate environments (Cadence and EVM) to trace asset movements.
Deniz Mert Edincik for the critical breakthrough in the Root Cause Analysis. Identifying the blind spots within the attachment import logic and existing defensive checks was the turning point that allowed us to patch the runtime and resume the network safely.
Ecosystem & Community Partners
Our Exchange & Bridge Partners: We thank the security teams at Kraken, Coinbase, OKX, Huobi, Gate.io, MEXC, Bitget, Bitmart, and Bybit, as well as the operators of Celer, deBridge, and Stargate. Their rapid response to our coordination requests was vital in containing the movement of counterfeit assets.
Technical Community Contributors: A special thank you to Noah Naizir, Libruary, Diamond, and other independent researchers who provided real-time feedback, monitoring, and support during the assessment and recovery phases. Alongside many engineers from the Dapper Labs team.
The Flow Community
Finally, we want to thank the Flow community of developers, validators, and users. This incident was a test of the network's resilience and its decentralized governance. Your patience during the read-only period, your support for the Isolated Recovery Plan over a state rollback, and your unwavering belief in the future of the protocol allowed us to emerge from this challenge stronger.
The transparency and collaboration witnessed over these past days reinforce our commitment to building the most secure and scalable environment for the next generation of consumer DeFi.
