One of the most prominent events that took place before the long-awaited DevCon 2024 was DeFi Security Summit. This summit taught me how far ahead the many malevolent actors are in this adversarial game of cat-n-mouse that we continuously play, not only by developing crypto products, but even by just OWNING crypto assets.

DeFi Security Summit was definitely an eye-opening information therapy delivered by those at the frontlines of the technical battle between attackers and defenders, hackers and builders, value-creators and thieves, security apprentices and wizards.

Sadly, as of Q2 2025 there doesn’t seem to be many curated articles about the event, that’s why I took the task of sharing my own recap by compiling the most important takeaways of DFSS, DeFi World and DevCon, then contrasting them with up-to-date information, alongside my own perspective as a DeFi developer.

The talks focused on different specific topics but the topics could all be classified within few patterns:

As of 2025, common smart contract vulnerabilities include access control flaws, price oracle manipulation, logic errors, lack of input validation, reentrancy attacks, unchecked external calls, flash loan attacks, and integer overflow/underflow. These vulnerabilities can be exploited to steal funds, manipulate contract behavior, or cause other issues. The most notorious dApp-specific vulnerabilities are:

• First depositor inflation attack in ERC-4626 vaults

• Using transfer() instead of safeTransfer()

• Missing access control validation (anywhere)

• Missing check for active L2 sequencers

• Fee-on-transfer in rebasing tokens

• Rounding & precision loss issues in ERC-20 tokens

• Using spot price instead of TWAP on DEXs

• Incorrect implementation of UUPSI upgradeability

• Missing slippage check in custom vaults & pools

How the social surface is being exploited like never before. Such an outbreak of attacks are historically outstanding even for the web2.

Back at DeFi Security Summit, which was held in Bangkok back in November, in a workshop called “Hardening dev environments against backdoor attacks”, Tincho and Matta taught the audience about how to avoid getting rekt while going through a recruitment coding challenge (or interacting with any repo for any purpose whatsoever).

There are many ways fake recruiters can deceive, phish and attack web3 devs through poisoned repositories, like by lockfile injection, evil GitHub hooks/actions, arbitrary command execution and dependency substitution which can be caused by the user when blindly upgrading packages, confusing dependency names, failing to properly configure the IDE or simply running a malicious script hidden in package.json.

They shared examples of such weaponized dev tools:

• Evil GitHub hooks that allow for impersonation and code execution

• Malicious VS Code extensions that take advantage of poor configuration

• Backdoored Foundry repositories

• Malicious Node.js dependencies (npm squatting)

• Obfuscated code inside the repo that leaks secrets

• Weaponized Docker containers, and more…

After looking at past instances of these attacks we were taught some good practices to harden our development environments.

Back at DeFi Security Summit one of the talks couldn’t stress more on all the opportunities that are there for the taking: Unmet invariants and static-analysis issues in deployed smart contracts.

Many protocols and projects have deployed contracts in production that don’t meet invariants considered obvious and absolutely necessary. Also, many of them present code issues that simple static analysis could find, and to make it even worse: Some of those issues are warnings that the compiler itself tells you to fix! 🤦‍♂️ SMH…

Anyway, this is good news… (for us, lol)

Certainly, this guy sounded just like a viking from the 7th century or a pirate from the 1680s while speaking to their people about the prosperous coastal villages all around the North Sea or all the riches that traveled unprotected aboard Spanish ships, with the major difference that our kind of piracy is incentivized to be way more moral and law-abiding than real piracy was back then. (👈🏻 Black-hat hacking is bad ‘mkay!)

Certainly, looking for unmet invariants in smart contracts is an excellent strategy to find bugs more easily and potentially report them to their teams as white hat hackers. It’s also a good strategy to use when participating at bug bounties or auditing contests on platforms like Code4rena, Sherlock or Immunefi, where hundreds of thousands of USD in bounties and prizes are rewarded every month in aggregate.

Ethernaut and Speedrun Ethereum are 2 of the most widely known challenges to learn Solidity out there. If you still haven’t mastered this language be sure to check them out!

Once you’re confident about your Solidity skills you will definitely have fun solving Damn Vulnerable DeFi

Johnny Time’s Smart Contract Hacking Course is a great starting point for those looking to debut as Smart Contract Security specialists:

https://smartcontractshacking.com/

Cyfrin Updraft is a free, and very complete Smart Contract Security course taught by the great and only Patrick Collins:

https://updraft.cyfrin.io/courses/security

Static analysis can save you auditor hours by saving them the time to detect obvious surface-level vulnerabilities, so that they can concentrate in the more intricate and harder-to-find vulnerabilities in your smart contracts.

Fuzzing involves sending a large volume of random, unexpected, or invalid inputs to a smart contract to trigger unexpected behaviors or vulnerabilities. Basically, this could be explained as brute-forcing a system under a controlled environment.

Fuzzing has a high bug discovery rate and is particularly good at finding edge cases and unexpected input scenarios. It improves the probability of identifying edge cases missed by manual testing. However, writing effective and efficient fuzzing invariants and configuring parameters demands a lot of effort from the security auditor.

Runtime analysis involves monitoring and analyzing the execution of a program in real-time to identify vulnerabilities. This method inspects how a smart contract behaves when executed on the blockchain or a simulated environment.

Runtime Analysis has a limited code coverage in comparison to fuzzing, as only the executed paths are analyzed, potentially missing untested paths. However, it could prove to be more efficient in terms of time and effort.

The 2016 Shanghai Attacks: Were a series of attacks against the Ethereum network during Devcon2 in Shanghai. Those were harrowing nights where the power of client diversity saved the Ethereum network from halting.

The DAO hack: The DAO was one of Ethereum’s first decentralized autonomous organizations, designed as a venture fund for the crypto community. However, a reentrancy bug in its smart contract allowed attackers to repeatedly withdraw funds before the contract updated its balance. A staggering 3.6 million ETH ($60 million at the time) were drained from The DAO. Nearly one-third of the total funds raised. It exposed critical vulnerabilities in smart contract security and marked a turning point in the history of Ethereum.

Lessons learned for me and you:

• Security is non-negotiable: As a founder, you must prioritize security from day one. Smart contracts are immutable by design. Once deployed, vulnerabilities can have irreversible consequences. Partnering with top-tier auditing firms like Cyfrin, CertiK or Quantstamp is an investment in your web3 project’s longevity.

• Adopt secure coding practices: Implement patterns like Checks-Effects-Interactions to mitigate risks like reentrancy attacks. These practices should be ingrained into your development lifecycle.

• Prepare for Governance Challenges: Crises often expose governance weaknesses. Ensure your DAO or protocol has clear processes for emergency responses while maintaining transparency with your community.

As cryptocurrency has gained greater acceptance, illicit on-chain activity, too, has become more varied. For example, some illicit actors primarily operate off-chain, but move funds on-chain for laundering.

New potential attack vectors are introduced by new smart contract engineering trends and blockchain protocol features that come with hardforks, this means there are new security considerations that users, developers and auditors need to keep in mind to avoid scams and vulnerabilities.

Oracle Vulnerabilities can lead to a range of serious consequences, including financial losses, system instability, and the compromise of sensitive data. Attackers can exploit these vulnerabilities to manipulate prices, drain liquidity, and exploit business logic, leading to significant financial harm. Furthermore, they can gain unauthorized access to critical user and company data to perform further attacks.

Some solutions include:

• 🤪👀 Sanity Checkers

• 🔌🤔 Pluggable Second-Opinion Oracles

• 🕰🏋️‍♂️ TWAP [Time-Weighed Average] Price Oracles

Learn more: "Enhancing Protocol Security with ZK-Oracles"

Cross-chain challenges: Bridges normally require a 5 step process:

1. ChainA: You send a tx message to the bridge.

2. Offchain: Trusted oracles compile the message into a trusted root.

3. ChainB: Trusted oracles return the trusted root to you.

4. Offchain: You produce a proof of the trusted root and send it to the bridge.

5. Chain B: Bridge sends your tx+proof and it’s executed.

Keeping this in mind we get several attack vectors:

• Risk of replay attacks: An attacker could replay your transactions on his behalf. However, bridges require nonces to be submitted alongside txs for this reason.

• Unrestricted external calls allowing arbitrary calldata: Some devs choose to tradeoff UX over security and that backfires. Bridge functions should always use access control modifiers.

• ERC-20 token decimals: A very common source of pain. Tokens in some chains have 6 decimals, while in others they have 18. There’s a plethora of ways things can go wrong because of the fact that decimals are not even part of ERC-20. This is a problem I’ve addressed myself.

Watch his talk: "Common Vulnerabilities in Bridges"

At DeFi Security Summit 2024 we had current Privy Security Engineer and former Uniswap Head of Security Andrew MacPherson deliver an absolutely insightful talk titled "Web3 Security is Embarrassing" where he urged the industry to adopt better practices and move beyond outdated security paradigms.

“We’re failing our users and it’s our fault. As sec people, protecting our users is our job and we have to do better”

-- Andrew MacPherson

As we know, the sole idea of having to ask for permission to perform operations with our own funds is outrageously nasty in crypto… But, that’s also the reason why draining the entirety of people’s funds is so easy. This is why drainers have become as popular as they are by 2025.

Also, phishing is very prevalent: During the first quarter of 2024 $314M USD were lost in phishing, and by the end of the year $1B were lost across 296 incidents.

“These numbers are embarrassment-worthy.”

The lack of safety nets like those in retail banking allows hackers, phishers and scammers to succeed in their operations with significantly less hassle. As much as your everyday ATM is unbearably slow and limited, it’s still safer when your PIN gets compromised than your wallet when your private key gets leaked.

Bearing in mind that -as I’d like to paraphrase Andrew- security in web3 sucks… big time… hands down… And it is obvious that web2 black-hats are already aware of this and a wave of web2 black hat hackers is imminently coming to web3.

Web3 provides high return of investment for attackers: Therefore web3 is obviously going to attract all those super highly-skilled digital thieves who are having a progressively boring and harder time breaching traditional web platforms as well as local environments and devices for booties that look like crumbles besides “low-reward” DeFi heists.

Shift towards invariant-driven testing: Unit testing is good and can help improve the quality of web3 applications, however, more and more decentralized apps are shifting towards an invariant-driven approach to developing around smart contracts.

Fuzzing + Runtime Analysis + Static Analysis: There is an already lengthy debate still ongoing over whether fuzzing is better than runtime analysis or it’s the other way around. Many security professionals advocate blending fuzz testing, static analysis, and symbolic runtime execution for more comprehensive security.

Building Invariant-focused Codebases: The classic Hardhat or Scaffold-ETH repos are obsolete! Foundry has established itself as the most reliable dev environment due to its amazing variety of built-in tools and specially its compatibility with fuzzing engines.

Many critical bugs found in security audits could have been identified earlier by developers with runtime analysis or targeted fuzz testing.

Collaboration between teamsThe importance of aligning developers and auditors to avoid misaligned priorities. Bringing security closer to the development process will certainly raise the standard across the space.

Project all along the web have traditionally relied on external audits to protect themselves. But, despite undergoing multiple external audits, high-profile projects like Penpie ($27M hack), Ronin ($12M hack), and Euler ($197M hack) have all suffered devastating exploits.

This highlights the need for rigorous testing pre-deployment.

DevSecOps is a new trend that integrates security into DevOps pipelines which projects can use to reduce reliance on external audits. Frameworks like Olympix enable DevSecOps workflows for proactive smart contract security.

Proactive security measures and tools for risk mitigation are solutions like Venn Network, a decentralized cybersecurity infrastructure that protects blockchain applications and protocols from malicious transactions and economic risks by acting like a transaction firewall.

Venn rewards node operators, security teams, protocols, and developers based on their contributions to the ecosystem's security, performance, and growth.

Today, a majority of exploits can be detected in advance or while they’re ongoing, but some others may still happen even after audits or during monitoring because of natural human oversight and lack of advanced detection techniques.

Forta Firewall is an AI-driven solution that uses machine-learning models trained on previous smart contract storage and balance behaviors. They can produce their own workflows with heuristic techniques to actively look for anomalies.

You can learn more about Forta here "AI-Driven Detection and Prevention of Malicious Transactions"

It’s always insightful to listen at panels because they let us listen to a select sample of some of the most influential minds in the industry, which allows us to get a glimpse of the narrative, discourse, rhetoric and general sentiment within the web3 space.

As of 2025 one of the most heated debates turns out to be about kill-switches.

A "kill switch" refers to a command or button that allows to immediately shut down or disable a smart contract or specific features within it. It’s essentially a command or button that, when triggered, allows to halt the contract's operations that could lead to the theft of funds or other issues.

It was at a panel at DeFi World 2024 where I saw a panel heat up after one of the panelists brought up the topic of kill switches and proceeded to share his hot take:

“Under many circumstances we ultimately do see the need for kill switches…”

This unleashed the wrath within’ one other panelist, as that single sentence somewhat ground his gears. Then the back-and-forth started, and after some valid points from the pro-kill-switch side the champion of decentralization finished the topic by stating:

“Even if kill-switches could save users’ funds, we should all strive to live by the principles of crypto and refrain from including them in our dApps, I mean: If we all act under the spirit of decentralization we will at some point reach a reality where everything will just work as intended.”

…

Protecting users and resources in the event of security breaches would be an obvious motivation for the majority of protocol owners and admins over anything else, right?…

Right?…

Well, in this case somehow the libertarian-inspired dogmas of crypto and web3 apparently weigh a lot more for the idealist side of the crowd, but many web3 professionals think otherwise.

One of the most prominent events that took place before the long-awaited DevCon 2024 was DeFi Security Summit. This summit taught me how far ahead the many malevolent actors are in this adversarial game of cat-n-mouse that we continuously play, not only by developing crypto products, but even by just OWNING crypto assets.

DeFi Security Summit was definitely an eye-opening information therapy delivered by those at the frontlines of the technical battle between attackers and defenders, hackers and builders, value-creators and thieves, security apprentices and wizards.

Sadly, as of Q2 2025 there doesn’t seem to be many curated articles about the event, that’s why I took the task of sharing my own recap by compiling the most important takeaways of DFSS, DeFi World and DevCon, then contrasting them with up-to-date information, alongside my own perspective as a DeFi developer.

The talks focused on different specific topics but the topics could all be classified within few patterns:

As of 2025, common smart contract vulnerabilities include access control flaws, price oracle manipulation, logic errors, lack of input validation, reentrancy attacks, unchecked external calls, flash loan attacks, and integer overflow/underflow. These vulnerabilities can be exploited to steal funds, manipulate contract behavior, or cause other issues. The most notorious dApp-specific vulnerabilities are:

• First depositor inflation attack in ERC-4626 vaults

• Using transfer() instead of safeTransfer()

• Missing access control validation (anywhere)

• Missing check for active L2 sequencers

• Fee-on-transfer in rebasing tokens

• Rounding & precision loss issues in ERC-20 tokens

• Using spot price instead of TWAP on DEXs

• Incorrect implementation of UUPSI upgradeability

• Missing slippage check in custom vaults & pools

How the social surface is being exploited like never before. Such an outbreak of attacks are historically outstanding even for the web2.

Back at DeFi Security Summit, which was held in Bangkok back in November, in a workshop called “Hardening dev environments against backdoor attacks”, Tincho and Matta taught the audience about how to avoid getting rekt while going through a recruitment coding challenge (or interacting with any repo for any purpose whatsoever).

There are many ways fake recruiters can deceive, phish and attack web3 devs through poisoned repositories, like by lockfile injection, evil GitHub hooks/actions, arbitrary command execution and dependency substitution which can be caused by the user when blindly upgrading packages, confusing dependency names, failing to properly configure the IDE or simply running a malicious script hidden in package.json.

They shared examples of such weaponized dev tools:

• Evil GitHub hooks that allow for impersonation and code execution

• Malicious VS Code extensions that take advantage of poor configuration

• Backdoored Foundry repositories

• Malicious Node.js dependencies (npm squatting)

• Obfuscated code inside the repo that leaks secrets

• Weaponized Docker containers, and more…

After looking at past instances of these attacks we were taught some good practices to harden our development environments.

Back at DeFi Security Summit one of the talks couldn’t stress more on all the opportunities that are there for the taking: Unmet invariants and static-analysis issues in deployed smart contracts.

Many protocols and projects have deployed contracts in production that don’t meet invariants considered obvious and absolutely necessary. Also, many of them present code issues that simple static analysis could find, and to make it even worse: Some of those issues are warnings that the compiler itself tells you to fix! 🤦‍♂️ SMH…

Anyway, this is good news… (for us, lol)

Certainly, this guy sounded just like a viking from the 7th century or a pirate from the 1680s while speaking to their people about the prosperous coastal villages all around the North Sea or all the riches that traveled unprotected aboard Spanish ships, with the major difference that our kind of piracy is incentivized to be way more moral and law-abiding than real piracy was back then. (👈🏻 Black-hat hacking is bad ‘mkay!)

Certainly, looking for unmet invariants in smart contracts is an excellent strategy to find bugs more easily and potentially report them to their teams as white hat hackers. It’s also a good strategy to use when participating at bug bounties or auditing contests on platforms like Code4rena, Sherlock or Immunefi, where hundreds of thousands of USD in bounties and prizes are rewarded every month in aggregate.

Ethernaut and Speedrun Ethereum are 2 of the most widely known challenges to learn Solidity out there. If you still haven’t mastered this language be sure to check them out!

Once you’re confident about your Solidity skills you will definitely have fun solving Damn Vulnerable DeFi

Johnny Time’s Smart Contract Hacking Course is a great starting point for those looking to debut as Smart Contract Security specialists:

https://smartcontractshacking.com/

Cyfrin Updraft is a free, and very complete Smart Contract Security course taught by the great and only Patrick Collins:

https://updraft.cyfrin.io/courses/security

Static analysis can save you auditor hours by saving them the time to detect obvious surface-level vulnerabilities, so that they can concentrate in the more intricate and harder-to-find vulnerabilities in your smart contracts.

Fuzzing involves sending a large volume of random, unexpected, or invalid inputs to a smart contract to trigger unexpected behaviors or vulnerabilities. Basically, this could be explained as brute-forcing a system under a controlled environment.

Fuzzing has a high bug discovery rate and is particularly good at finding edge cases and unexpected input scenarios. It improves the probability of identifying edge cases missed by manual testing. However, writing effective and efficient fuzzing invariants and configuring parameters demands a lot of effort from the security auditor.

Runtime analysis involves monitoring and analyzing the execution of a program in real-time to identify vulnerabilities. This method inspects how a smart contract behaves when executed on the blockchain or a simulated environment.

Runtime Analysis has a limited code coverage in comparison to fuzzing, as only the executed paths are analyzed, potentially missing untested paths. However, it could prove to be more efficient in terms of time and effort.

The 2016 Shanghai Attacks: Were a series of attacks against the Ethereum network during Devcon2 in Shanghai. Those were harrowing nights where the power of client diversity saved the Ethereum network from halting.

The DAO hack: The DAO was one of Ethereum’s first decentralized autonomous organizations, designed as a venture fund for the crypto community. However, a reentrancy bug in its smart contract allowed attackers to repeatedly withdraw funds before the contract updated its balance. A staggering 3.6 million ETH ($60 million at the time) were drained from The DAO. Nearly one-third of the total funds raised. It exposed critical vulnerabilities in smart contract security and marked a turning point in the history of Ethereum.

Lessons learned for me and you:

• Security is non-negotiable: As a founder, you must prioritize security from day one. Smart contracts are immutable by design. Once deployed, vulnerabilities can have irreversible consequences. Partnering with top-tier auditing firms like Cyfrin, CertiK or Quantstamp is an investment in your web3 project’s longevity.

• Adopt secure coding practices: Implement patterns like Checks-Effects-Interactions to mitigate risks like reentrancy attacks. These practices should be ingrained into your development lifecycle.

• Prepare for Governance Challenges: Crises often expose governance weaknesses. Ensure your DAO or protocol has clear processes for emergency responses while maintaining transparency with your community.

As cryptocurrency has gained greater acceptance, illicit on-chain activity, too, has become more varied. For example, some illicit actors primarily operate off-chain, but move funds on-chain for laundering.

New potential attack vectors are introduced by new smart contract engineering trends and blockchain protocol features that come with hardforks, this means there are new security considerations that users, developers and auditors need to keep in mind to avoid scams and vulnerabilities.

Oracle Vulnerabilities can lead to a range of serious consequences, including financial losses, system instability, and the compromise of sensitive data. Attackers can exploit these vulnerabilities to manipulate prices, drain liquidity, and exploit business logic, leading to significant financial harm. Furthermore, they can gain unauthorized access to critical user and company data to perform further attacks.

Some solutions include:

• 🤪👀 Sanity Checkers

• 🔌🤔 Pluggable Second-Opinion Oracles

• 🕰🏋️‍♂️ TWAP [Time-Weighed Average] Price Oracles

Learn more: "Enhancing Protocol Security with ZK-Oracles"

Cross-chain challenges: Bridges normally require a 5 step process:

1. ChainA: You send a tx message to the bridge.

2. Offchain: Trusted oracles compile the message into a trusted root.

3. ChainB: Trusted oracles return the trusted root to you.

4. Offchain: You produce a proof of the trusted root and send it to the bridge.

5. Chain B: Bridge sends your tx+proof and it’s executed.

Keeping this in mind we get several attack vectors:

• Risk of replay attacks: An attacker could replay your transactions on his behalf. However, bridges require nonces to be submitted alongside txs for this reason.

• Unrestricted external calls allowing arbitrary calldata: Some devs choose to tradeoff UX over security and that backfires. Bridge functions should always use access control modifiers.

• ERC-20 token decimals: A very common source of pain. Tokens in some chains have 6 decimals, while in others they have 18. There’s a plethora of ways things can go wrong because of the fact that decimals are not even part of ERC-20. This is a problem I’ve addressed myself.

Watch his talk: "Common Vulnerabilities in Bridges"

At DeFi Security Summit 2024 we had current Privy Security Engineer and former Uniswap Head of Security Andrew MacPherson deliver an absolutely insightful talk titled "Web3 Security is Embarrassing" where he urged the industry to adopt better practices and move beyond outdated security paradigms.

“We’re failing our users and it’s our fault. As sec people, protecting our users is our job and we have to do better”

-- Andrew MacPherson

As we know, the sole idea of having to ask for permission to perform operations with our own funds is outrageously nasty in crypto… But, that’s also the reason why draining the entirety of people’s funds is so easy. This is why drainers have become as popular as they are by 2025.

Also, phishing is very prevalent: During the first quarter of 2024 $314M USD were lost in phishing, and by the end of the year $1B were lost across 296 incidents.

“These numbers are embarrassment-worthy.”

The lack of safety nets like those in retail banking allows hackers, phishers and scammers to succeed in their operations with significantly less hassle. As much as your everyday ATM is unbearably slow and limited, it’s still safer when your PIN gets compromised than your wallet when your private key gets leaked.

Bearing in mind that -as I’d like to paraphrase Andrew- security in web3 sucks… big time… hands down… And it is obvious that web2 black-hats are already aware of this and a wave of web2 black hat hackers is imminently coming to web3.

Web3 provides high return of investment for attackers: Therefore web3 is obviously going to attract all those super highly-skilled digital thieves who are having a progressively boring and harder time breaching traditional web platforms as well as local environments and devices for booties that look like crumbles besides “low-reward” DeFi heists.

Shift towards invariant-driven testing: Unit testing is good and can help improve the quality of web3 applications, however, more and more decentralized apps are shifting towards an invariant-driven approach to developing around smart contracts.

Fuzzing + Runtime Analysis + Static Analysis: There is an already lengthy debate still ongoing over whether fuzzing is better than runtime analysis or it’s the other way around. Many security professionals advocate blending fuzz testing, static analysis, and symbolic runtime execution for more comprehensive security.

Building Invariant-focused Codebases: The classic Hardhat or Scaffold-ETH repos are obsolete! Foundry has established itself as the most reliable dev environment due to its amazing variety of built-in tools and specially its compatibility with fuzzing engines.

Many critical bugs found in security audits could have been identified earlier by developers with runtime analysis or targeted fuzz testing.

Collaboration between teamsThe importance of aligning developers and auditors to avoid misaligned priorities. Bringing security closer to the development process will certainly raise the standard across the space.

Project all along the web have traditionally relied on external audits to protect themselves. But, despite undergoing multiple external audits, high-profile projects like Penpie ($27M hack), Ronin ($12M hack), and Euler ($197M hack) have all suffered devastating exploits.

This highlights the need for rigorous testing pre-deployment.

DevSecOps is a new trend that integrates security into DevOps pipelines which projects can use to reduce reliance on external audits. Frameworks like Olympix enable DevSecOps workflows for proactive smart contract security.

Proactive security measures and tools for risk mitigation are solutions like Venn Network, a decentralized cybersecurity infrastructure that protects blockchain applications and protocols from malicious transactions and economic risks by acting like a transaction firewall.

Venn rewards node operators, security teams, protocols, and developers based on their contributions to the ecosystem's security, performance, and growth.

Today, a majority of exploits can be detected in advance or while they’re ongoing, but some others may still happen even after audits or during monitoring because of natural human oversight and lack of advanced detection techniques.

Forta Firewall is an AI-driven solution that uses machine-learning models trained on previous smart contract storage and balance behaviors. They can produce their own workflows with heuristic techniques to actively look for anomalies.

You can learn more about Forta here "AI-Driven Detection and Prevention of Malicious Transactions"

It’s always insightful to listen at panels because they let us listen to a select sample of some of the most influential minds in the industry, which allows us to get a glimpse of the narrative, discourse, rhetoric and general sentiment within the web3 space.

As of 2025 one of the most heated debates turns out to be about kill-switches.

A "kill switch" refers to a command or button that allows to immediately shut down or disable a smart contract or specific features within it. It’s essentially a command or button that, when triggered, allows to halt the contract's operations that could lead to the theft of funds or other issues.

It was at a panel at DeFi World 2024 where I saw a panel heat up after one of the panelists brought up the topic of kill switches and proceeded to share his hot take:

“Under many circumstances we ultimately do see the need for kill switches…”

This unleashed the wrath within’ one other panelist, as that single sentence somewhat ground his gears. Then the back-and-forth started, and after some valid points from the pro-kill-switch side the champion of decentralization finished the topic by stating:

“Even if kill-switches could save users’ funds, we should all strive to live by the principles of crypto and refrain from including them in our dApps, I mean: If we all act under the spirit of decentralization we will at some point reach a reality where everything will just work as intended.”

…

Protecting users and resources in the event of security breaches would be an obvious motivation for the majority of protocol owners and admins over anything else, right?…

Right?…

Well, in this case somehow the libertarian-inspired dogmas of crypto and web3 apparently weigh a lot more for the idealist side of the crowd, but many web3 professionals think otherwise.