After multiple DeFi attack incidents in April, security discussions in the decentralized finance industry are showing a clear shift. In the past, the DeFi protocols most often scrutinized were whether smart contracts had been audited and whether the code had vulnerabilities; but Flying Tulip founder Andre Cronje, in a recent interview with Cointelegraph, said that today’s risks for many DeFi protocols no longer lie only in on-chain code—they come from upgrade permissions, multisig governance, off-chain infrastructure, and the team’s operating processes.
DeFi is no longer immutable code
Cronje said bluntly that if we use the strict early DeFi definition of “decentralized, immutable, and does not require trust,” many current protocols can no longer be called pure DeFi. He even included Flying Tulip in this judgment, saying the industry today is more like team-run, profit-seeking financial services rather than fully immutable public financial infrastructure.
He said: “I think what we have today, including Flying Tulip, is no longer DeFi. It isn’t decentralized finance, and it isn’t tamper-proof code—it’s a team running a for-profit business.”
These remarks highlight the most awkward reality in the DeFi industry right now: many protocols still use DeFi narratives, valuations, and brand language, but in actual operation they have long relied on extensive human control and off-chain processes.
DeFi’s biggest risk is no longer just contract bugs
Cronje believes the security model of early DeFi was relatively simple: after a protocol was deployed, the smart contracts were immutable, and users mainly bore the risk of the code logic. But today’s DeFi systems are usually far more complex—protocols may use proxy upgrades to change contracts, manage key permissions through multisig, rely on external infrastructure providers, and, when something goes wrong, have the core team handle crisis response.
This means security issues have expanded from “whether the code has a bug” to “who has the authority to upgrade the contract,” “who controls the multisig,” “whether the timelock is sufficient,” “whether off-chain servers or management interfaces could be attacked,” and “whether the team can respond correctly in abnormal situations.”
Cronje noted that the industry in the past still put excessive attention on smart contract audits, but many recent attacks look more like traditional Web2 security problems—or TradFi—such as compromised infrastructure access permissions, social engineering attacks, misuse of management processes, or the takeover of a single privileged permission node.
In other words, DeFi doesn’t mean it doesn’t need audits; it’s that audits alone are no longer enough. When a protocol can be upgraded, managed, and manually intervened with, it must admit it also has operational risks that traditional financial institutions face.
Flying Tulip adds a withdrawal circuit breaker
Against this backdrop, Flying Tulip recently added a withdrawal circuit breaker mechanism, so that when it detects abnormal outflows, the protocol can delay or queue withdrawals. Cronje emphasized that this mechanism is not meant to permanently block users from withdrawing, nor to let the team arbitrarily freeze funds; rather, it is intended to give the protocol a short response window in abnormal situations.
Taking Flying Tulip as an example, this mechanism can give the team roughly 6 hours. Cronje believes that if the team is smaller and members are not distributed enough globally, it may require 12 to 24 hours, or even longer, to complete internal verification, signing, and contingency response when an attack occurs.
The logic behind this design is close to transaction halts or risk-control gates in traditional financial markets: when abnormal liquidity or asset outflow appears, it doesn’t immediately judge all transactions invalid—it first slows down the system to prevent an attacker from moving all funds within a few minutes.
However, Cronje also stressed that a circuit breaker mechanism can only be one part of a multi-layer security architecture and cannot be treated as a cure-all. Real protection still must include audits, multisig decentralization, timelocks, governance processes, monitoring, and strict permission controls.
The cost of circuit breakers: protecting users or creating new centralized backdoors?
However, circuit breakers immediately sparked a route dispute within the DeFi developer community. Curve Finance and Yield Basis founder Michael Egorov agreed that recent attacks did expose off-chain centralized risks, but he was highly cautious about the solution of “adding human-driven emergency controls.”
Egorov pointed out that many major recent DeFi incidents were not caused by the smart contracts themselves being breached; they came from single points of failure off-chain. He cited an rsETH-related incident, saying that the smart contracts of Aave, Kelp, and LayerZero were not hacked—the real problem was the off-chain infrastructure.
Therefore, in Egorov’s view, if the biggest risk already comes from people and off-chain permissions, then adding a human-controlled circuit breaker mechanism may just concentrate even more power in the hands of a small number of signers or administrators.
Egorov is concerned that if emergency control permissions allow signers to modify contracts, pause withdrawals, or interfere with fund flows, then once the signers are attacked, the mechanism originally intended to protect users could instead become a tool for hackers to drain funds—or become a backdoor for centralized asset freezes. His conclusion is that DeFi design should reduce human single points of failure as much as possible, rather than using more human permissions to solve problems caused by human permissions.
DeFi must admit what it has become
The disagreement between Cronje and Egorov, on the surface, is a debate over circuit breaker mechanisms; in reality, it is a debate over DeFi identity. Cronje is more realistic: since many protocols are no longer immutable contracts but financial products with upgrade permissions, governance processes, and team operations, this reality should be acknowledged and appropriate risk controls introduced.
Egorov is closer to DeFi originalists: if DeFi security comes from decentralization, then the solution should not be to give more control to humans, but to design systems that rely less on manual intervention.
Both actually acknowledge the same thing: the biggest problem with DeFi today is no longer just whether the code is well written, but who users are actually trusting. If a protocol can be upgraded, paused, queue withdrawals, and change core logic via multisig, then the risk users bear is not just smart contract risk, but team governance risk, signer risk, infrastructure risk, and operational risk.
Is this article still decentralized DeFi? Andre Cronje: Admit it—most protocols are tamperable code. First appeared on Chain News ABMedia.
