Interfaces and Abstract Contracts

Analogy categoryAnalogies

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.

solidity

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.

solidity

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.