Solidity is a high-level, statically typed programming language for writing smart contracts that run on the Ethereum Virtual Machine (EVM). It is the most widely used language for building on Ethereum and on the many Ethereum-compatible blockchains, and most token contracts, lending protocols, exchanges and NFT collections on those networks are written in it.
The language uses curly-brace syntax similar to JavaScript, C++ and Java, and its official documentation names C++, Python and JavaScript as influences. Solidity is developed in the open by a team originally formed within the Ethereum Foundation, and its compiler, solc, is open-source software released under the GNU General Public License version 3. Its main alternative on the EVM is Vyper, a Python-like language designed to be simpler to audit.
Solidity in plain terms
A smart contract is like a vending machine that holds money and follows rules nobody can change once it is installed. Solidity is the language engineers use to write those rules: "if someone sends this much, release that item; if the deadline passes, refund everyone".
Because the machine cannot be repaired once it is on the street, a typing mistake in the rules can lock up or give away the money inside. That is why Solidity programmers test, review and often pay outside firms to audit their code before it goes live.
History
Solidity was proposed in August 2014 by Gavin Wood, then Ethereum's chief technology officer, and developed by a team led by Christian Reitwiessner. Early Ethereum also had other languages, such as Serpent and LLL, but Solidity quickly became the default.
The language's early years were shaped by security failures. In June 2016 an attacker exploited a reentrancy bug in "The DAO", a Solidity-based investment decentralized autonomous organization (DAO), draining about 3.6 million ether. Ethereum's response, a hard fork to reverse the theft, split the network and left the original chain running as Ethereum Classic (ETC). Later releases added safety features; version 0.8.0, released in December 2020, made integer overflow and underflow revert by default. As of November 2026 the current release line is still 0.8.x, with frequent minor versions.
How Solidity code becomes a contract
- A developer writes a contract in a
.solfile, declaring state variables (data stored on chain), functions, events and modifiers that control who may call what. - The
solccompiler turns the source into EVM bytecode and an Application Binary Interface (ABI), a description of the contract's functions that other software uses to call it. - The bytecode is deployed in a transaction sent from an externally owned account (EOA), paying gas like any other transaction. The contract receives its own address.
- Wallets, websites and back-end services call the contract through the ABI, usually via a library in an Ethereum software development kit (SDK).
Every operation in the compiled code costs gas, so code design affects users' gas fees directly. Writing to storage is among the most expensive actions, and experienced developers organise data to keep the gas limit needed by common functions low. Solidity also works natively in wei, with the literals 1 ether and 1 gwei converted to integers at compile time.
Uses and ecosystem
Most token standards are defined as Solidity interfaces. Fungible tokens follow the ERC-20 standard, unique collectibles follow ERC-721, and games and mixed collections often use ERC-1155. Major decentralized finance (DeFi) protocols, including Uniswap and Aave, and the contracts behind fiat-backed tokens such as USDC, are written in Solidity.
The surrounding toolset includes:
- Development frameworks. Hardhat and Foundry compile, test and deploy contracts; Remix is a browser-based editor widely used for learning.
- Libraries. OpenZeppelin Contracts provides reviewed, open-source implementations of token standards, access control and upgrade patterns that many projects reuse instead of writing their own.
- Other networks. Because many chains run the EVM, the same Solidity code can be deployed to Polygon, Arbitrum, BNB Chain and others, which is one reason the language dominates smart-contract development.
Security and limitations
Contracts are public, hold real value and are hard to change once deployed, so bugs are costly. Common classes of error include reentrancy, faulty access control (for example an exposed admin key), unchecked external calls, price manipulation through unreliable oracle inputs and logic errors in upgradeable proxies. Many large hacks in DeFi traced back to such mistakes rather than to flaws in Ethereum itself.
Critics point out that Solidity's flexibility makes subtle bugs easy, which is why languages such as Vyper chose a smaller feature set. Supporters reply that the size of its developer base, its tooling and the volume of audited code make Solidity the safer choice in practice. Payment and treasury teams that rely on Solidity contracts typically ask for independent audits, test coverage and a clear upgrade and pause policy before integrating them.