Smart contract risk: what can break when code holds your funds

What a smart contract actually does with a deposit

A smart contract is a program stored on a blockchain. When you deposit into a lending market, a liquidity pool or a staking vault, you are sending tokens to an address that only that program controls. The program decides who can withdraw, how interest is calculated, when collateral is sold and what fees are charged. Nobody at a branch can override it on your behalf.

That design has a real benefit: the rules are public and are applied the same way to everyone. It also has a hard edge. If the rules contain a mistake, the mistake is applied the same way to everyone too, often within seconds, and transactions on most public blockchains cannot be reversed once they are final.

So smart contract risk is the chance that the code, its settings or the systems it depends on behave in a way nobody intended, and that deposits are lost, frozen or diluted as a result. It sits on top of ordinary market risk; a contract can fail even when prices are calm.

Six ways contract risk shows up

Contract failures tend to fall into a handful of recurring patterns. Knowing the pattern makes it easier to see which questions apply to a given deposit.

Most of these patterns can exist at the same time in one product. A vault that has been running for years with clean code can still be exposed through an upgrade key, a price feed or a website it does not control.

Audits: useful, but not a guarantee

An audit is a paid review of the code by an outside security firm. It is one of the few independent signals available, and a project with no audit at all is asking depositors to take its word. Still, an audit is a snapshot: it covers a particular version of the code, within a defined scope, over a limited time.

Reading the report rather than the badge tells you much more. Many audit reports list findings by severity and note whether each one was fixed, acknowledged or left open. Some reports state that parts of the system, such as price feeds or upgrade contracts, were out of scope.

• Does the audited version match the version that is actually deployed?
• Were high-severity findings fixed, or only acknowledged?
• Was the code changed after the audit date?
• Were the oracle, bridge or admin contracts inside the scope?
• Has more than one independent reviewer looked at the code?

Upgradeability and admin keys

Many protocols use upgradeable contracts so that bugs can be patched. The trade-off is that whoever controls the upgrade can, in principle, replace the logic entirely. That turns a code question into a people-and-process question: how many signers are needed, who they are, and how quickly a change can take effect.

A time lock delays changes for a set period, so depositors can see a proposed upgrade and leave before it applies. A multisig requires several keys to approve an action instead of one. Neither removes the risk, but both make a sudden, quiet change much harder.

Composability: the risk you inherit

DeFi protocols are often stacked like building blocks. A yield vault might deposit into a lending market, which accepts a wrapped token from a bridge, which is priced by an oracle. Each layer adds its own failure modes, and a failure anywhere in the stack can reach the depositor at the top.

This is why the risk library covers oracle risk and bridge risk separately: they are the most common inherited dependencies. When a product advertises a single yield figure, it can help to list every protocol that yield passes through and ask what happens if each one pauses.

Layering also stacks fees and incentives. The yield farming calculator shows how reward-token declines, impermanent loss and gas can turn a headline rate into something much smaller, even before any contract failure is considered.

An illustrative cover comparison

Some DeFi cover products pay out if a named contract suffers a qualifying exploit. Pricing them is a useful way to make an abstract risk concrete. Suppose, for illustration only, you buy $10,000 of cover for 12 months at a 2.5% annual premium, and the cover pays 90% of the insured amount after a qualifying event.

The premium is $10,000 × 2.5% = $250. If your own estimate of the chance of a qualifying event over the year is 2%, the expected payout is $10,000 × 2% × 90% = $180. The breakeven probability, where expected payout equals premium, is $250 ÷ ($10,000 × 90%) = 2.78% a year. Below that estimate the cover costs more than it is expected to return; above it, the reverse.

The point is not whether to buy cover. It is that the price of cover implies a view about how likely failure is, and that view can be compared with your own. The insurance premium calculator runs the same arithmetic. Cover terms often exclude front-end attacks, governance actions or price-feed events, and the cover provider is itself a set of smart contracts with its own risk.

Why Canadian investor protections rarely reach a contract

Canadian securities regulators warn that crypto assets can be very volatile and risky and that you could lose some or all of your money. When you deposit directly into a smart contract, there is generally no registered firm standing between you and the code, so the protections that come with a registered dealer, such as suitability questions and complaint processes, may not apply.

Neither the Canada Deposit Insurance Corporation nor the Canadian Investor Protection Fund covers crypto assets. The Ontario Securities Commission's investor site notes that CIPF eligibility explicitly excludes crypto. The regulation overview explains how platform registration works in Canada and what it does and does not cover.

Reading the signals without overreading them

Some signals carry more information than others. Time in operation with significant deposits is a form of ongoing testing, though not proof. A public bug bounty shows a project is paying people to find flaws. Clear documentation of admin roles and incident history shows a team willing to be specific about what could go wrong.

Other signals are weaker than they look. A large total value locked shows popularity, not safety, and can attract attackers. A high yield often reflects higher risk or temporary incentives rather than a better design. Endorsements on social media are not a security review.

Questions to ask before you deposit

• Is there a public audit for the exact version deployed, and were serious findings fixed?
• Who can upgrade or pause the contract, and is there a time lock before changes take effect?
• Which other protocols, tokens, bridges or price feeds does this product depend on?
• How long has this exact code held meaningful deposits?
• Is there a bug bounty, and does the team publish incident reports?
• What happens to deposits if the front-end website goes offline or is compromised?
• Does any cover available exclude the failure patterns that worry you most?