What Smart Contracts Can and Cannot Enforce

The phrase smart contract does a lot of unearned work. It suggests something legal, something intelligent, something that watches over an agreement. What is actually deployed is a program stored on a blockchain that runs when triggered and moves assets according to its own code. Understanding the gap between the name and the mechanism explains most of the risk.

What is actually deployed

A smart contract is code and stored data living at an address on a chain. Anyone can send it a transaction that calls one of its functions. Every node executes the same code against the same state and reaches the same result, which is what makes the outcome verifiable rather than trusted.

Execution costs a fee, generally proportional to the computational work performed. That fee is not an accounting detail: it caps how complex on-chain logic can practically be and pushes developers toward minimal contracts with as much as possible handled off-chain. It also means a contract can fail simply because it ran out of budget mid-execution.

Two properties follow. Execution is deterministic, so the same inputs always give the same outputs. And on most chains the deployed code is immutable, so what you deploy is what runs forever.

What a smart contract genuinely enforces

Within its own chain, a contract’s enforcement is very strong. It can hold assets and release them only when stated conditions are satisfied. It can enforce ordering, so step two cannot happen before step one. It can enforce arithmetic rules such as supply caps or issuance schedules. It can enforce access control, restricting functions to particular addresses. And it can do all of this without an operator who might change their mind.

That is a real capability. Escrow that no intermediary can raid, token supply nobody can quietly inflate, and automated market making that runs without an order book are all genuine achievements of the model. The value comes from removing discretion, not from adding intelligence.

What it cannot do

A contract has no senses. It cannot see a delivery arrive, a shipment clear customs, or a service be performed. It only knows what is written into its chain’s state. Any interaction with the physical world requires someone to attest to it, and at that point you are trusting the attester.

A contract also has no reach. It cannot seize property, garnish wages or compel behaviour. If an agreement needs enforcement against a person rather than against a pot of on-chain assets, code does not provide it. In practice this means smart contracts work well where the entire subject of the agreement is already on-chain, and work poorly the further you move from that.

Nor can a contract exercise judgement. It cannot recognise that a counterparty acted in bad faith within the letter of the terms, or that circumstances changed in a way nobody anticipated. Human contracts survive on interpretation. Code has none.

Where risk actually concentrates

The underlying cryptography is rarely the problem. Failures cluster in a few recognisable places.

Logic that does what it says, not what was meant

The classic case is a function that can be re-entered before it finishes updating its own bookkeeping, letting a caller withdraw repeatedly against a balance that has not yet been decremented. The code executed correctly. The design was wrong. Immutability then makes the mistake permanent unless there is a rescue path built in.

Access control

Many incidents come down to a privileged function that was not properly restricted, or an administrative key that was more powerful or less protected than users assumed. A contract may be flawless in its core logic while an owner address quietly retains the power to drain it.

Bad inputs

Contracts that reference prices, rates or outcomes depend on oracles. Where a price is read from a source that can be pushed around cheaply, an attacker can distort the input and let the contract do the damage on their behalf. The contract behaves correctly throughout.

Composition

Protocols build on each other, and a contract that is safe alone may not be safe when another contract can call it in an unexpected sequence within a single transaction. Emergent behaviour across independently sound components is one of the harder classes of risk to reason about.

Immutability as a double-edged property

Immutability is why a smart contract can be trusted without trusting its author. It is also why a bug can be unfixable. Teams respond with upgradeable patterns, timelocks that delay changes so users can exit, and multi-signature control of administrative keys. Each mitigation is a partial reintroduction of trust, deliberately chosen.

There is no configuration that removes the trade-off. Fully immutable means fully committed to whatever was deployed. Upgradeable means someone can change the rules. The honest position is to know which model a given protocol uses, who holds the keys, and what delay exists before changes take effect.

Where this touches mining and consensus

Contracts execute inside blocks, which means their guarantees are only as strong as the settlement guarantees of the chain underneath. On a chain where reorganisations are cheap, a transaction that looked final can be undone, and any contract state that depended on it goes with it. Chain security, whether from accumulated proof of work or from committed stake, is therefore part of a contract’s security model, not a separate topic. The relationship is set out further in our blockchain technology coverage.

A practical way to assess one

Before interacting with a contract, a few questions do most of the work. Is the source code verified and readable, or only a compiled blob? Is it upgradeable, and if so who can upgrade it and how quickly? What external data does it depend on, and how is that data sourced? Has it been reviewed, at which version, and were the findings addressed? How much value has it held, and for how long?

None of that guarantees safety. It moves you from trusting a description to assessing a mechanism, which is the most that is honestly available. For the surrounding terminology see the glossary, and for how we approach this material generally see our methodology. Nothing here is financial advice.