Defining Contracts by Their Behavior
Interfaces and abstract contracts both let you define what a contract must do separately from how it does it — programming to a contract's behavior rather than its implementation. This separation is the backbone of composability in Ethereum: a lending protocol can accept any token that behaves like an ERC-20 without knowing its source code. Both constructs act as a specification that concrete contracts must fulfill, but they differ sharply in how much they may implement.
Cricket analogy: Both act like a role spec sheet — 'a wicketkeeper must catch, stump, and appeal' — defining required behavior before any player fills the role.
Interfaces
An interface, declared with the interface keyword, is a pure behavioral contract: it lists external function signatures with no bodies, holds no state variables, and has no constructor. Its functions are implicitly virtual and must be external. Interfaces exist chiefly to interact with other contracts: by casting a deployed contract's address to an interface type — IERC20(tokenAddress).transfer(to, amount) — your code can call that contract's functions in a type-safe way without importing its full source. This is exactly how DeFi protocols compose with arbitrary tokens.
Cricket analogy: An interface is a pure rulebook with no players in it — it lists what a wicketkeeper must do but supplies no technique, and you can point it at any keeper to call those actions, like casting an address to IERC20.
interface IERC20 {
function balanceOf(address account) external view returns (uint);
function transfer(address to, uint amount) external returns (bool);
event Transfer(address indexed from, address indexed to, uint value);
}
contract Payer {
function pay(IERC20 token, address to, uint amt) external {
// point the interface at any ERC-20 and call it
require(token.transfer(to, amt), "transfer failed");
}
}Interface functions are implicitly virtual and must be external. You detect whether a contract supports an interface at runtime with ERC-165 and type(IERC20).interfaceId — the same mechanism marketplaces use to check if a contract is an ERC-721.
Abstract Contracts
An abstract contract sits between an interface and a concrete contract. It is marked abstract (and has at least one unimplemented function), which means it cannot be deployed on its own. Unlike an interface, it may hold state variables, define a constructor, and provide fully implemented functions alongside the unimplemented ones. This makes it ideal as a partial base that supplies shared logic — a Shape base implementing describe() while leaving area() for each concrete shape to define — so derived contracts inherit real behavior and only fill in the gaps.
Cricket analogy: An abstract contract is a half-finished coaching manual — it fully explains fielding drills but leaves the batting technique blank for each player to complete, and you can't field the manual itself.
abstract contract Shape {
string public name;
constructor(string memory _name) { name = _name; }
// unimplemented -> the contract is abstract
function area() public view virtual returns (uint);
function describe() public view returns (string memory) {
return name; // shared, implemented logic
}
}
contract Square is Shape {
uint side;
constructor(uint _s) Shape("Square") { side = _s; }
function area() public view override returns (uint) {
return side * side;
}
}Interface vs Abstract: When to Use Which
Reach for an interface when you need only a clean, implementation-free API for interoperability, or to declare the shape of an external contract you call. Reach for an abstract contract when derived contracts should share substantial, ready-made implementation while still being required to supply a few specifics. The two are complementary — an abstract contract commonly inherits an interface, implementing the shared parts and leaving contract-specific functions abstract — which is precisely the pattern OpenZeppelin uses with IERC20 and its ERC20 base.
Cricket analogy: Choose an interface when you only need to define how to talk to any keeper, and an abstract contract when you want to share real fielding drills across all your keepers — often an abstract base implements the interface.
An abstract contract with any unimplemented function cannot be deployed — attempting to do so is a compile error. Likewise, an interface may not declare a constructor, state variables, or function bodies, and all its functions must be external; violating any of these rules fails compilation.
- An interface declares external function signatures with no implementation and is used to interact with other contracts.
- Interface functions are implicitly virtual and must be external; interfaces cannot have constructors, state variables, or bodies.
- Casting an address to an interface type (e.g. IERC20(token)) lets you call another contract's external functions type-safely.
- An abstract contract has at least one unimplemented function (or the abstract keyword) and cannot be deployed on its own.
- Abstract contracts can hold state variables, constructors, and fully implemented functions as a partial base for shared logic.
- Use an interface for a pure behavioral API/interop and an abstract contract to share implementation across derived contracts.
- An abstract contract can implement an interface, combining a standard API with reusable base logic.
Practice what you learned
1. Which of these is NOT allowed in a Solidity interface?
2. Interface functions are implicitly which visibility, and what override marker?
3. How do you call another deployed contract's function type-safely?
4. What makes a contract abstract?
5. Which can an abstract contract have that an interface cannot?
Was this page helpful?
You May Also Like
Inheritance in Solidity
Inheritance lets contracts reuse and extend each other with the is keyword, virtual/override, super, C3-linearized multiple inheritance, and ordered constructor chaining.
ERC-20 Token Standard
The interface and mechanics behind fungible tokens on Ethereum, covering core functions, the approve/allowance pattern, events, and safe implementation.
Access Control Patterns
Techniques for restricting who can call privileged contract functions, from simple Ownable to role-based access control, safe ownership transfer, and timelocks.
Related Reading
Related Study Notes in Programming
Browse all study notesApache Spark Study Notes
Programming · 30 topics
ProgrammingApache Flink Study Notes
Programming · 30 topics
ProgrammingHadoop Study Notes
Programming · 30 topics
ProgrammingSnowflake Study Notes
Programming · 30 topics
ProgrammingApache Airflow Study Notes
Programming · 30 topics
Programmingdbt (Data Build Tool) Study Notes
Programming · 30 topics