TL;DR

  • A smart contract is a program deployed to a blockchain that holds value and releases it according to rules written in its code, executed by the network's validators under the chain's rules, with no company or operator approving each step. It runs as its currently deployed code dictates, and that code decides whether anyone, such as an admin, holds special powers over it or can replace it.
  • A contract enforces anything expressible in code about assets and data on its own chain: balances, deadlines, thresholds, signatures. It cannot see the outside world unaided, cannot exercise judgement, and cannot enforce what you meant where it differs from what you signed.
  • It depends on how the contract was built. On chains such as Ethereum, the code of a contract deployed with no upgrade mechanism cannot be altered through the contract by anyone, including its authors, although any admin functions written into it, such as a pause switch, still work as coded. A contract deployed behind a proxy, or with an owner or governance role, can have its logic replaced by whoever holds that power, and many widely used contracts are built that way.
  • In a contract with no upgrade path, the flaw becomes part of the contract. Immutability protects users from quiet code changes and preserves mistakes with the same indifference, which is why serious contracts are audited before deployment and why "audited" still does not mean the risk has gone.
en una cuadra

A smart contract is a program that runs on a blockchain under that chain's rules, holds assets and transfers them when a transaction calls it and its coded conditions are met. Every validator executes the same code against the same data, so no operator approves each step.

What is a smart contract, in plain terms?

Respuesta rápida

A smart contract is a program deployed to a blockchain that holds value and releases it according to rules written in its code, executed by the network's validators under the chain's rules, with no company or operator approving each step. It runs as its currently deployed code dictates, and that code decides whether anyone, such as an admin, holds special powers over it or can replace it.

The classic comparison, older than blockchains themselves, is a vending machine. The computer scientist Nick Szabo, who coined the term in the 1990s, called the vending machine "the primitive ancestor of smart contracts" because it executes an agreement without a shopkeeper: money goes in, the mechanism checks it, the product comes out, and the rules are the same for every customer whether the owner is watching or asleep (Szabo, Smart Contracts: Building Blocks for Digital Markets, 1996). A smart contract is that mechanism made of code and given a ledger: it can receive crypto, hold it, and pay it out when the coded conditions are satisfied. One difference matters: a contract's code can reserve some functions for particular addresses, so whether every caller is treated alike depends on how it was written.

Where it lives matters as much as what it does. In Ethereum's own definition, a contract is "code (its functions) and data (its state) that resides at a specific address" on the chain, copied across every node (ethereum.org, Introduction to smart contracts). When someone calls the contract, every validator runs the same code against the same state and must reach the same result, which removes the operator from execution: no company approves each transaction and there is no single server to switch off. Any power to intervene has to be written into the code itself, for example an owner who can pause the contract or a list of addresses that decides who may use it (OpenZeppelin, Access Control). A contract has an address, the way a wallet does, and anyone can send transactions to it. It also waits to be called: in ethereum.org's description, user accounts interact with a contract "by submitting transactions that execute a function defined on the smart contract" (ethereum.org, Introduction to smart contracts). "Smart" and "automatic" describe how outcomes follow once a call arrives; they do not mean the code acts on its own initiative, and how it executes, what it costs and whether it can be replaced all depend on the chain it runs on and how it was deployed. The guide to gas and network fees explains what running that code costs; the point here is who runs it: every validator, following the deployed rules.

A simple example makes it concrete. Imagine a contract holding an escrow: a buyer deposits payment, and the code releases it to the seller only when the buyer confirms delivery, or returns it after a deadline passes with no confirmation. Written as a smart contract with no admin override, that arrangement needs no escrow agent and cannot be talked into releasing early; add an owner function that can release funds, and that owner becomes the agent you are trusting. Multiply that pattern and you get the real catalogue: a token is a contract keeping balances, a decentralised exchange is a contract swapping deposits by formula, a lending market is a contract holding collateral and enforcing liquidation rules. The academy's DeFi guide walks those uses; each one is this same mechanism wearing different rules.

Diagram of smart contract anatomy showing a contract at its own address on the blockchain containing code with its deployed rules and state such as balances and records, with users sending transactions in, every validator executing the same code on the same state, and outcomes such as released or returned funds following from those rules, annotated with the point that no company approves each step while any admin roles written into the code, such as pause, upgrade or address allowlists and blocklists, remain part of the rules
Figure 1. What a smart contract is: code plus state at its own address, executed identically by every validator and following whatever rules were deployed, including any admin roles.

What can a smart contract actually enforce, and what can it not?

Respuesta rápida

A contract enforces anything expressible in code about assets and data on its own chain: balances, deadlines, thresholds, signatures. It cannot see the outside world unaided, cannot exercise judgement, and cannot enforce what you meant where it differs from what you signed.

The enforcement power is real and narrow. Within its chain, a contract's rules are as hard as the chain's own: if the code says funds release only with three of five signatures and gives no one an override, no plea, court order or keyboard shortcut addressed to the contract changes that. The exception is a change to the chain itself, such as the 2016 hard fork described below, which is rare and needs the network's participants to adopt it. This is why some institutions build custody controls out of contract rules, and why the academy's multisig guide treats an on-chain quorum as a rule the chain enforces; that guide also covers what such a design adds, including coordination between signers and a recovery process that has to work.

The limits deserve equal precision, because most smart-contract disappointments live there. First, a contract knows only its chain. Blockchains are deterministic systems: every node must reach the same result from the same input, so a contract cannot fetch the weather, a share price or a delivery status by itself. That information must be fed in by an oracle, a service that writes outside data onto the chain, and the contract then trusts the feed (ethereum.org, Oracles). Whoever controls the feed controls what the contract believes, which is why oracle failures have their own guide to oracle risk. Second, a contract has no judgement. A human arbiter can notice that an agreement is being honoured in letter and violated in spirit; code enforces the letter, including when the letter is a bug. Third, and most practical for a holder: the contract enforces what was signed. Approve a contract to spend your tokens and it can move them later within the approval's terms, with no further signature from you, whatever you believed those terms were: in the ERC-20 token standard, approve sets an allowance for a spender and transferFrom moves tokens against it (OpenZeppelin, ERC-20 API reference). The guide to blind signing exists because of this property, and the explainer on how wallet-draining and approval attacks work shows what happens when it is exploited.

There is also a boundary with the legal world: a smart contract is a mechanism, and whether it also creates a contract in the legal sense depends on the jurisdiction and the circumstances. Code settles what happens on the chain; it does not settle what a court would say afterwards.

Can the code be changed after it is deployed?

Respuesta rápida

It depends on how the contract was built. On chains such as Ethereum, the code of a contract deployed with no upgrade mechanism cannot be altered through the contract by anyone, including its authors, although any admin functions written into it, such as a pause switch, still work as coded. A contract deployed behind a proxy, or with an owner or governance role, can have its logic replaced by whoever holds that power, and many widely used contracts are built that way.

Immutable by default

On Ethereum and chains like it, deployed code is immutable by design: the protocol offers no way to edit a contract in place, and interactions with it are irreversible (ethereum.org, Upgrading smart contracts). Immutability is what lets users rely on a contract's rules without trusting an operator; where an operator can rewrite the rules at will, users are trusting that operator as well. A contract written without any owner, admin or upgrade function is fixed for as long as the chain exists, short of a chain-level intervention, and the same is true of its bugs. That default is chain-specific. On Solana, for example, programs deployed with the upgradeable loader "can be upgraded when an upgrade authority is set; revoking that authority makes the program immutable" (Solana, Programs). Whether code is fixed therefore depends on the chain's rules as well as on how the contract was deployed.

Unchangeable code and ownerless code are separate properties. A contract whose code can never be edited may still give an owner or named roles powers written in from the start: OpenZeppelin's access-control library exists so developers can decide who is allowed to mint tokens, pause activity or change settings, through a single owner or through roles granted to several accounts (OpenZeppelin, Access Control). Its pausable ERC-20 extension, for example, lets an authorised account halt transfers, minting and burning (OpenZeppelin, ERC-20 API reference). Code can also keep allowlists or blocklists that decide which addresses may use a function. Knowing whether a contract is immutable answers half the question; the other half is which roles its code grants and who holds them.

Upgradeable by design: proxies

Developers who want to fix or extend a contract use patterns that work around that default without breaking it. One widely used approach is the proxy pattern. Users interact with a proxy contract at a permanent address; the proxy holds the state and forwards every call, through an instruction called delegatecall, to a separate implementation contract that holds the logic. An admin can point the proxy at a new implementation, so "the logic contract can be replaced while the proxy, or the access point is never changed" (OpenZeppelin, Proxy Upgrade Pattern). From the outside the address and balances stay put; underneath, the rules can be swapped. Other approaches exist, including migrating to a new contract, separating data from logic, and the diamond pattern that delegates to several logic contracts at once, and all of them share the same consequence: somebody has the power to change what the code does (ethereum.org, Upgrading smart contracts).

Who holds the upgrade power: admin keys, multisigs and governance

That power has to sit with someone. In the simplest deployments it is a single admin address, often a ProxyAdmin contract owned by one key. OpenZeppelin's documentation describes the ProxyAdmin as "the administrative interface of the proxy, including the ability to change who can trigger upgrades by transferring ownership" (OpenZeppelin, Proxies API reference), so whoever controls it controls what the contract does next. Ethereum's developer documentation lists ways to reduce that trust assumption, such as "using a multi-sig wallet contract to control upgrades, or requiring members of a DAO to vote on approving the upgrade" (ethereum.org, Upgrading smart contracts). With a multisig, several parties must agree; with on-chain governance, holders of a governance token vote on proposals that, if they pass a quorum, are executed by the governance contract itself. Each arrangement still leaves someone to trust: a multisig's signers can lose keys or act together, and a governance vote reflects whoever controls enough voting tokens when it is held. A timelock is commonly placed in between: it enforces a minimum delay between a change being approved and taking effect, so users who dislike the change have time to withdraw before it lands, at the cost of slowing down emergency patches too (ethereum.org, Upgrading smart contracts; OpenZeppelin, Governance).

None of this makes an upgradeable contract worse or better than a fixed one. It changes what you are trusting. With an immutable contract that grants no special roles you trust the code as written and nothing else; where the code grants roles, you also trust whoever holds them. With an upgradeable contract you also trust the key holders, the voting process and the timelock, and the honest description is that the rules can change under you, with notice if a timelock exists and without it otherwise.

What happens when the code is wrong?

Respuesta rápida

In a contract with no upgrade path, the flaw becomes part of the contract. Immutability protects users from quiet code changes and preserves mistakes with the same indifference, which is why serious contracts are audited before deployment and why "audited" still does not mean the risk has gone.

Code that mishandles an edge case does not fail gracefully; it does exactly what it says, and on a public chain, anyone can read the code and probe it with real transactions. Value held by a vulnerable contract is available to the first person who works out how to satisfy its conditions in a way its authors never intended.

The history is not hypothetical. In June 2016 an attacker exploited The DAO, a large investment fund written as a smart contract on Ethereum, by calling its "split" function recursively inside itself and collecting ether many times over in a single transaction (Ethereum Foundation blog, 17 June 2016). Ethereum.org's history page puts the drained amount at over 3.6 million ETH (ethereum.org, History, checked 24 September 2026). The contract had no admin who could stop it, so the response had to come from outside the contract: after a community vote, the network hard forked at block 1,920,000 on 20 July 2016, moving the affected ether into a recovery contract from which DAO token holders could withdraw it (Ethereum Foundation blog, 20 July 2016). Some participants rejected the fork on the grounds that the flaw lay in the contract and the protocol had worked as designed, and continued the original chain as Ethereum Classic (ethereum.org, History). The case shows both halves of the property at once: the code could not be patched, and the fix the community adopted was one that rewrote the chain's state, which is exactly the kind of intervention immutability was meant to make impossible.

Two nuances complete the picture. Where a contract is upgradeable, its operators may patch a flaw, at the price of being operators, and a compromised or careless admin key is itself a way to lose everything a contract holds. And auditing, the practice of paying specialists to hunt for flaws before deployment, genuinely reduces risk while guaranteeing nothing; the academy's guide to smart contract audits explains what a clean report covers and what it systematically cannot.

Two-panel diagram of the immutability trade-off, one panel showing the protective side where no one can quietly replace the code, though any admin roles written into it at deployment, such as pause or address restrictions, still apply as coded, the other showing the hazard side where a bug becomes permanent, the code is public for attackers to study, and value in a flawed contract is available to whoever first satisfies its conditions, with The DAO drain of June 2016 and the July 2016 hard fork as the example, and a footer noting that upgradeable contracts restore fixes by reintroducing an operator to trust
Figure 2. The same property, seen from both sides: code that cannot be changed protects users from quiet code changes and preserves flaws for whoever finds them first.

How should a beginner think about relying on a smart contract?

Respuesta rápida

Treat every contract as a machine you are placing value into, and ask three questions before you do: what exactly am I authorising, who can change or drain this machine, and how long has it survived in public with value inside. Those three cover most of the risk a non-specialist can assess.

The first question is about your signature, because your authorisations are the main way a contract you use gains access to your funds, and an approval keeps working after you sign it. Before approving or signing, know what the request grants: a one-off transfer is a different commitment from an open-ended spending approval, which the contract can draw on later without asking again. The blind signing guide turns this into concrete habits.

The second question is about the machine's owners. An immutable contract with no admin key cannot be changed under you by its authors and cannot be patched either; an upgradeable contract can be fixed and can be changed. Neither is automatically better. Many projects publish which they are, what admin powers the code grants, such as pausing or blocking addresses, who holds the admin or governance role, whether it is a single key or a multisig, and whether a timelock applies, and that documentation tells you whom you are trusting.

The third question is about survival. Code that has held significant value on a public chain for years has been open to continuous probing by profit-motivated strangers, which is some evidence about its robustness and no guarantee against a flaw nobody has found yet. A new contract has had less of that exposure, so its age is one risk factor among several. The consequence for a holder is simple arithmetic: funds in a contract can be stuck or taken, so the amount placed in any single contract is also the amount exposed to that contract's flaws and to its key holders.

Frequently asked questions

Are smart contracts legally binding?

The code runs as written whatever a court later decides about the arrangement, and a court cannot edit a contract that has no upgrade path. Whether a smart contract is also a legally binding agreement is a separate question, answered by the law of the relevant jurisdiction and the facts of the case, and a court with jurisdiction can still make orders addressed to the people involved. For arrangements of real value, the code and any legal agreement around it are usually considered together, with advice from a qualified professional.

Can a smart contract steal my crypto?

An ordinary contract can move tokens out of your wallet only through a permission you have given, and that permission can be an allowance granted earlier: once you approve a spender, it can move tokens up to the approved amount later with no new signature (OpenZeppelin, ERC-20 API reference). That is why malicious contracts are built to obtain broad approvals from people who do not read them, and why the habits in the wallet security guide focus on the approval step. A token's own code may also give an admin powers such as pausing transfers or blocking addresses, which act on your balance without any signature from you. A further risk applies to upgradeable contracts: if the admin key is compromised, the logic behind a trusted address can be replaced with something that drains it.

If funds are taken, reporting is the factual first step: in the US, to the FBI's Internet Crime Complaint Center at ic3.gov; in England, Wales and Northern Ireland, to Report Fraud (formerly Action Fraud) at reportfraud.police.uk or on 0300 123 2040; in Scotland, to Police Scotland on 101 (City of London Police, 4 December 2025). A report does not guarantee recovery, and a confirmed on-chain transfer cannot be undone by the contract that made it. The FBI has warned that "Private sector recovery companies cannot issue seizure orders to recover cryptocurrency" and that recovery scheme fraudsters charge up-front fees (FBI IC3, public service announcement, 11 August 2023). The guide to responding if your crypto is hacked or stolen covers the steps in order.

What is a proxy contract?

A contract at a fixed address that holds the state and forwards calls to a separate implementation contract holding the logic. An admin can point the proxy at a new implementation, which is a widely used way to build upgradeable contracts (OpenZeppelin, Proxy Upgrade Pattern). If a project describes its contracts as upgradeable, a proxy is usually what it means.

Who writes smart contracts?

Developers, in languages built for the purpose, such as Solidity and Vyper on Ethereum (ethereum.org, Smart contract languages). The code is usually public, and for significant contracts, independent audit reports are published too. An audit report records what its reviewers examined, within an agreed scope and at a point in time; it does not certify that the contract is safe, and later upgrades fall outside it. Reading either is beyond most users, which is why survival time and documented ownership are the layperson's substitutes.

Do smart contracts run on every blockchain?

No. Chains built for programmability, such as Ethereum and Solana, run general-purpose contracts natively; Bitcoin supports a deliberately limited scripting system. The guide to how blockchains differ maps which chains do what and why the difference reflects a design choice.

What happens if a smart contract has a bug?

That depends on what the contract's own code allows, because nobody outside it has a switch. In a contract with no owner, pause or upgrade function, the bug stays and executes like every other line. Some contracts include an emergency stop: OpenZeppelin's library offers a Pausable module, described as an "emergency stop mechanism that can be triggered by an authorized account" (OpenZeppelin, Utilities API reference), which can halt the functions a developer chose to make pausable. In an upgradeable contract, the admin or governance process can also replace the faulty logic, after any timelock delay. A chain-level rescue such as Ethereum's July 2016 hard fork after The DAO exploit took a community decision and left a second chain, Ethereum Classic, running the original history (ethereum.org, History); it was a one-off event, and no contract or protocol offers users such a rescue as a matter of course.

Sources and further reading

Primary and reference sources for this guide. URLs were checked on 23 September 2026; the history, languages, upgrading and introduction pages and the OpenZeppelin proxy pages were rechecked on 24 September 2026, when the Pausable, IC3 and Report Fraud sources were added; the OpenZeppelin access-control and ERC-20 pages were added on 24 September 2026; the ethereum.org introduction was rechecked and the Solana programs page added on 7 October 2026.

Prueba rápida: ¿se mantuvo?

Llegaron algunas preguntas para comprobar los fundamentos. Siguen respuestas con explicaciones y nadie lo califica excepto su futuro portafolio.

1/5 pregunta
What executes a smart contract's code?

¿Fue esto útil?