Smart Contract Defect

How it happens

Smart contracts are programs that hold assets and execute automatically once deployed, and the deployed code is the final authority on who can move what. Defects come from reentrancy, arithmetic that overflows or rounds the wrong way, missing access control on a privileged function, faulty price or share math, and assumptions about how a third-party contract will behave. Because contract state is public and calls are permissionless, anyone can simulate an exploit path cheaply and then execute it in a single transaction, often funded by a flash loan that requires no capital of its own. Audits reduce this risk but do not remove it, because they sample a specific commit at a point in time and cannot cover interactions with contracts that are deployed later.

What you can actually observe

Check whether the deployed bytecode matches published verified source, when the implementation last changed, and how much value the contract has held without incident, since value held multiplied by time live is a cruder but harder-to-fake signal than an audit badge. Look at how many independent audits exist, whether findings were fixed or formally accepted, and whether a funded bug bounty with a published scope and payout history is in place. An immutable contract and an upgradeable one carry different failure modes, so establish which you are looking at before reading anything else.

Precedent

The 2016 DAO exploit on Ethereum used a reentrancy defect to drain a large share of the funds that had been raised, and the response, a contentious hard fork, permanently split the network into Ethereum and Ethereum Classic.

What makes it more or less material

Materiality depends on how much value the contract custodies, whether it is immutable, how long the current code has been live unchanged, whether a failure would be contained to one pool, and how many other protocols compose on top of it.