What Is a Smart Contract and How Do You Use One?

The 50-Million-Contract Question

Each one is a self-executing program that lives at a deterministic address, holds its own state, and waits for an externally owned account to submit a transaction that triggers a state transition. Every lending pool, every automated market maker, every wrapped token, every on-chain governance vote — they all reduce, in the final accounting, to this primitive. Yet despite their centrality to the post-2020 crypto economy, smart contracts remain widely misunderstood. They are routinely described as "unbreakable," as "legally binding agreements," and as "mini-programs that run on their own." None of these formulations is correct, and the gap between the popular mental model and the engineering reality is precisely where exploits live. This article walks through the actual architecture: what a smart contract is, how it executes, how users interact with it, where it breaks, and what the next phase of scale implies for network security and regulatory posture.

From Vending Machines to Ethereum: The Evolution of Self-Executing Code

The term "smart contract" was introduced by computer scientist Nick Szabo in 1994, more than two decades before a single contract had ever been deployed on a live network. Szabo used a vending machine as the reference device: drop in coins, select a product, the machine's internal logic executes, and the state change is irreversible. The analogy is precise in a way the crypto industry often forgets. The vending machine does not negotiate. It does not adjudicate. It runs a finite set of pre-registered instructions, and the only thing the outside world can do is submit inputs and observe outputs.

For roughly twenty years, this idea had no substrate. Bitcoin, launched in 2009, included a constrained scripting language, but it was deliberately limited — no loops, no general computation, no state beyond UTXO tracking. Real programmable contracts became viable only with the Ethereum mainnet launch in 2015, which introduced the Ethereum Virtual Machine (EVM): a quasi-Turing-complete execution environment where any program, given enough gas, can run. The EVM is what turned a thought experiment into an industrial primitive.

Szabo proposed the concept in 1994, but the concept required a Turing-complete execution environment to become economically meaningful. That environment arrived twenty-one years later, and the entire DeFi stack is its downstream consequence.

The conceptual lineage matters because it explains the architectural choices that follow. A smart contract is not a digital agreement in the legal sense; it is a deterministic program whose behavior is fully determined by its deployed bytecode. Legal wording, dispute resolution, and intent interpretation are not encoded. The code does what the code does — and only that.

Anatomy of a Smart Contract: ABIs, Bytecode, and Automated Logic

A deployed smart contract is, at the binary level, a string of EVM bytecode stored at a 20-byte address on the blockchain. Bytecode is what the network's validator nodes actually execute. It is not human-readable, and writing it by hand is impractical. In practice, contracts are written in a high-level language — most commonly Solidity, occasionally Vyper — then compiled down to bytecode by a toolchain such as solc. The compiler produces two artifacts: the bytecode itself, which is what gets deployed, and an ABI (Application Binary Interface).

The ABI is a JSON-formatted specification that defines the contract's public interface: which functions exist, what arguments they accept, what types they return, and which events they emit. When a wallet, a frontend, or a block explorer needs to construct a transaction targeting the contract, the ABI is what tells that external application how to encode the call. Without an ABI, the binary on-chain is effectively opaque to anything but raw bytecode tooling.

Two properties of this architecture deserve emphasis because they are routinely glossed over in retail-facing material:

• Determinism. Given the same input transaction and the same on-chain state at a given block, every node executing the contract must produce the same output. There is no source of randomness, no external API call, no clock reading — the EVM is a closed system, and any oracle integration is an explicit, carefully designed out-of-channel dependency.
• Immutability by default. Once bytecode is deployed at an address, it cannot be modified. There is no git pull for live contracts. Upgradeability, where it exists, is achieved through proxy patterns — a thin dispatcher contract that delegates calls to an implementation address, with the implementation address itself being the variable that governance can rotate. The deployed implementation, however, stays frozen at its original bytecode forever, and an audit of an upgradeable system must include the upgrade mechanism, not only the implementation logic.

These two properties — deterministic execution and immutable storage — are the source of both the power and the risk. Determinism is what allows thousands of nodes to reach consensus on the outcome. Immutability is what makes the system trust-minimized. Together, they also mean that a bug in the deployed code cannot be patched in place; remediation requires either a migration to a new contract, a governance vote to rotate a proxy, or, in the worst case, a community-coordinated fork — which is what happened after the 2016 DAO exploit, and which remains a politically radioactive option.

Interacting with the Blockchain: Wallets, Gas Fees, and Block Explorers

Most users never see bytecode. They interact with smart contracts through one of two layers: a Web3 wallet, or a block explorer's contract interface. Both deserve a precise description.

A Web3 wallet — MetaMask, Trust Wallet, Rabby, WalletConnect-compatible mobile wallets — is a key manager and transaction signer. It holds the user's private keys locally and constructs, signs, and broadcasts transactions to the network. When a user approves a token swap on a decentralized exchange, for example, the wallet is constructing a transaction whose target is the DEX router contract, encoding the function call (typically something like swapExactTokensForTokens) using the router's ABI, attaching a gas limit, and offering a gas price. The user signs, the transaction is broadcast, validators include it in a block, the EVM executes the contract code, the state transition settles, and the wallet reflects the new balances.

Every state-changing operation costs gas. Gas is paid in the network's native asset (ETH on Ethereum mainnet, MATIC on Polygon, and so on) and serves two functions: it compensates validators for the computational work, and it prices scarce blockspace. Gas fees are volatile, tied to base fee dynamics and priority fee bidding, and they are the single most common friction point in practical DeFi usage.

Block explorers such as Etherscan provide a second interaction surface, one that bypasses third-party frontends entirely. For verified contracts — those whose source code has been published and matched against the deployed bytecode — Etherscan exposes two tabs:

The Read tab is, in effect, a free read-only API. The Write tab is functionally equivalent to what a frontend would do, but it skips the UI layer. For technical users — auditors, debugging engineers, incident responders — the Write tab is also the fastest way to confirm that a contract does what its documentation claims, because the interaction goes directly to the bytecode without any indirection. It is also, correspondingly, the fastest way for an inexperienced user to send a transaction they do not understand, and the typical "approved unlimited allowance to a malicious contract" exploit path frequently begins with a direct Write Contract call.

The Dark Side of Automation: Reentrancy and the Cost of Design Error

Automation removes intermediaries. It also removes the safety nets that intermediaries provide. The history of high-impact smart contract exploits is essentially a chronicle of what happens when the implicit assumptions of centralized systems are imported into an environment where code is law and state transitions are final.

The canonical case is reentrancy. A reentrancy vulnerability exists when a contract performs an external call to another contract before updating its own state — for example, debiting a user's balance after sending them the funds. The receiving contract, maliciously constructed, can use a fallback function to call back into the original contract, which still sees the original (undebited) balance, and withdraw again. The recursion continues until the contract's liquidity is drained. This is the attack pattern that took down The DAO in 2016, with a loss of approximately $60 million, and it has remained a persistent failure mode: the GMX V1 exploit in July 2025, which cost roughly $42 million, was also a reentrancy issue. Nearly a decade apart, the same architectural mistake.

A contract calls into the unknown before its own state has settled — and that single ordering assumption is what made the 2016 DAO lose $60 million and the 2025 GMX V1 pool lose $42 million.

A qualitative analysis of 50 high-impact exploits between 2022 and early 2025 found cumulative losses of approximately $1.09 billion, with the failure modes distributed across four broad categories. Implementation weaknesses — bugs in the code, often the reentrancy class, but also integer overflow, mishandled access control, and unsafe type casting — accounted for the largest share. Flawed economic design, where the protocol's incentive structure permitted value extraction under adversarial conditions, was the second. External dependencies, particularly oracle manipulation, were the third. Governance failures, where administrative keys were compromised or where the voting mechanism itself was gamed, were the fourth. Notably, no single category is dominant. The implication is that security is not a property of a single audited contract; it is a property of the system, and the system includes oracles, admin keys, upgrade paths, and the liquidity assumptions embedded in the economic model.

This is the trade-off the field rarely surfaces in its marketing. Immutability means a deployed contract is not a piece of software that can be patched next Tuesday; it is a permanent commitment to a specific set of behaviors. A security audit reduces the probability of an implementation bug but cannot eliminate it — auditors are reasoning about a complex state space, and the codebase evolves. The standard mitigation, the checks-effects-interactions pattern for reentrancy specifically, requires discipline at the function level, and the absence of that discipline is what has cost the ecosystem hundreds of millions of dollars across roughly a decade.

Scale, Staking, and the Coming Regulatory Question

The 50-million-contract figure cited at the start is not a vanity metric. It is a measure of how thoroughly the DeFi and broader Web3 economy has committed to the smart contract primitive. Lending and borrowing dapps, automated market makers, yield farming strategies, liquidity pool staking, governance token voting, synthetic assets, wrapped tokens — every one of these applications is, in implementation terms, a set of smart contracts that hold custody of user funds and execute predetermined logic on those funds. The user is not depositing money into a corporate balance sheet; the user is depositing into a contract account whose bytecode defines exactly when funds move.

This shift in custody model has long-term implications that are no longer theoretical. From a network security perspective, scale creates new pressure on validator hardware and on state bloat — the cumulative growth of on-chain state that every full node must maintain. From a regulatory perspective, the question of whether the bytecode itself constitutes a legal contract, whether the deployer has liabilities analogous to a financial intermediary, and whether a front-end operator is responsible for user-facing risks is moving from abstract debate to active rulemaking. Smart contracts execute code. They do not execute law, and the distinction is now a live policy question in multiple jurisdictions, with the answer likely to be protocol-specific rather than universal.

The honest assessment, after thirty years of theory and a decade of production, is that smart contracts are a powerful but narrow primitive. They are deterministic, immutable by default, transparent, and — in the precise sense in which the vending machine is reliable — exactly as secure as the code that defines them. They are not intelligent, not legal documents, not immune to design error, and not exempt from the regulatory environment in which their users reside. The next phase of the space will be shaped less by additional cryptographic novelty — though zero-knowledge proofs and post-quantum signature schemes will matter — and more by how protocols handle the boring, consequential questions of upgrade governance, oracle integrity, and incident response at scale.