A smart contract is code and state deployed on a blockchain to execute programmed rules for transactions, balances, assets, or financial protocols.
A smart contract is code and associated data deployed on a blockchain to execute programmed rules for transactions, balances, assets, or financial protocols. Despite the name, a smart contract is not automatically a legally binding contract, and its code cannot determine whether every real-world legal obligation has been satisfied.
In finance, smart contracts can exchange tokens, hold collateral, calculate debt, distribute payments, record ownership claims, or liquidate positions. Their output is only as reliable as the code, inputs, permissions, network, and assets on which they depend.
flowchart LR
A["Developer deploys code and initial state"] --> B["Contract receives blockchain address"]
U["User or another contract submits signed transaction"] --> V["Network validates authorization and available resources"]
O["Oracle or other contract supplies permitted inputs"] --> E["Contract executes programmed rules"]
B --> E
V --> E
E -->|"Rules succeed"| S["Balances and state update on-chain"]
E -->|"Rules fail or resources run out"| R["State changes revert"]
S --> N["Receipt, events, and resulting position can be reviewed"]
A user normally does not alter contract code when interacting with it. The user signs a transaction calling a public function with specified inputs. Network execution applies the contract’s logic to the current state. If the call succeeds, the blockchain records the new state. If it reverts, intended state changes do not take effect, although some networks can still charge a transaction fee for the attempted computation.
Another smart contract can make the call instead of a person. This contract-to-contract interaction enables composability, such as exchanging collateral, repaying debt, and closing a position within one transaction. It also means that a defect or failure in one component can affect every strategy that depends on it.
| Financial function | Programmed action | Evidence to verify | Main limitation |
|---|---|---|---|
| Token transfer | Check authorization and update balances | Contract address, token address, sender, recipient, and receipt | A token balance does not prove redemption rights or asset value |
| Exchange | Calculate an output and move assets between users or pools | Route, reserves, quoted output, minimum output, fees, and final balances | Price impact, transaction ordering, and thin liquidity can worsen execution |
| Collateralized loan | Record collateral, generate debt, accrue charges, and enforce thresholds | Collateral value, debt, oracle, rate, threshold, and liquidation record | Oracle error or volatility can cause rapid liquidation |
| Derivative | Apply margin, price, payoff, funding, and settlement rules | Position size, margin, reference price, maturity, and settlement state | Code cannot remove market, leverage, liquidity, or model risk |
| Escrow-like transfer | Hold an asset until programmed conditions are met | Depositor, beneficiary, amount, condition, and release transaction | Real-world performance may require a trusted data source or dispute process |
| Asset-management vault | Allocate deposited assets according to a strategy | Holdings, strategy calls, claim tokens, fees, and withdrawals | Integrations, leverage, administrator control, and valuation may be complex |
| Governance | Record proposals, votes, delays, and parameter changes | Voting power, quorum, execution address, and effective block | Token concentration and delegation can concentrate control |
The code automates specified rules. It does not decide whether those rules are commercially reasonable, legally valid, or suitable for a particular user.
Blockchain nodes need a common result to agree on the ledger state. A contract therefore cannot directly call an ordinary website at execution time and accept whatever response one node happens to receive. External data generally enter through an oracle or another signed transaction that places a value where the contract can read it.
This preserves deterministic execution but does not make the input correct. A lending contract can apply its liquidation formula exactly and still produce a harmful result if the price feed is delayed, manipulated, misconfigured, or inappropriate for a stressed market.
Random outcomes require the same care. A contract may use a committed value, verifiable randomness mechanism, or external provider, but the final input must be processed in a way that network participants can validate. Labeling a contract “non-deterministic” usually confuses uncertain inputs with deterministic execution.
The statement “smart contracts cannot be changed” is incomplete. The transaction history and deployed bytecode may be tamper-evident, while the effective system can still change through several designs.
| Design | What can change | Control question |
|---|---|---|
| Immutable contract | Original code does not expose an upgrade path | Can funds migrate safely if a defect is found? |
| Parameterized contract | Rates, limits, addresses, or permissions can change within existing code | Who can change each parameter, by how much, and with what delay? |
| Proxy architecture | A stable address delegates execution to replaceable implementation code | Who controls the upgrade key, and can users exit before an upgrade? |
| Governance-controlled system | Token voters, delegates, councils, or other actors approve changes | How concentrated is voting power and who executes approved actions? |
| Pausable or emergency design | Authorized actors can stop selected functions | Can a pause protect assets, freeze users, or block withdrawals? |
| Multisignature administration | A threshold of signers controls sensitive actions | Who are the signers, how independent are they, and what happens if keys are lost? |
Upgradeability can allow defect correction and adaptation. It also creates administrator, governance, key-compromise, and adverse-change risk. Immutability removes some control risk but can leave users exposed to permanent defects or obsolete assumptions.
Consider a simplified liquidity pool containing 100,000 units of Token A and 200,000 units of Token B. Its contract uses the constant-product rule:
The starting product is:
Assume a trader supplies 1,000 units of Token A and, for clarity, the example ignores fees. The pool’s new Token A reserve is 101,000. The contract calculates the Token B reserve needed to preserve the product:
The trader receives the reduction in Token B reserves:
The starting reserve ratio suggested 2 units of Token B per Token A, which would imply 2,000 Token B for 1,000 Token A. The contract instead outputs about 1,980.20 because the trade moves the pool price. The difference is price impact, not a coding error.
A real transaction may also deduct a protocol fee, face adverse transaction ordering, route through several pools, or revert if output falls below the user’s minimum. The example shows deterministic calculation; it does not show that the resulting price is fair or that either token is valuable.
| Question | Smart-contract code | Legal contract |
|---|---|---|
| Primary form | Executable code and blockchain state | Legally recognized agreement expressed through words, conduct, or other evidence |
| Core function | Produce programmed state transitions | Create or evidence rights and obligations between parties |
| Interpretation | Network executes formal instructions | Parties, lawyers, arbitrators, or courts interpret terms and context |
| External facts | Requires submitted data or oracle inputs | Can use evidence, testimony, standards, and legal presumptions |
| Error response | Revert, pause, upgrade, migrate, or accept the programmed result | Rescission, damages, rectification, injunction, or other available remedy |
| Jurisdiction | Network may operate across borders | Governing law, forum, parties, and facts determine jurisdiction and remedies |
A smart legal contract uses code to define or perform some obligations of a legally binding agreement. The legal agreement may exist partly in natural-language terms and partly in code. Whether legal obligations formed, what the code means, and what remedy applies are jurisdiction- and fact-specific questions.
Calling code a contract does not prove offer, acceptance, consideration, authority, capacity, disclosure, consumer compliance, or enforceability.
For a finance review, identify:
An interface label such as “deposit” or “stake” may hide several contract calls and token approvals. Review the actual authorization and resulting claim rather than relying only on the button text.
This article provides general financial, technical, and legal education. It is not individualized investment, trading, software-security, tax, or legal advice and does not recommend deploying or interacting with any contract or protocol.