Smart-contract development

abstract contract

An abstract contract is a partially built contract — a template with some functions left as blanks for child contracts to fill in. Because at least one piece of behaviour is unspecified, you cannot deploy it on its own; it exists to be inherited and completed.

A contract becomes abstract in either of two ways: it declares at least one function without an implementation (just a signature ending in a semicolon), or it is explicitly marked with the abstract keyword. Any unimplemented function must be marked virtual so children can override it. The key difference from an interface is that an abstract contract may carry real state variables, a constructor, modifiers, and fully implemented functions — so it is the right tool when you want to share concrete logic while forcing each subclass to supply a few specific pieces. This is exactly the template-method pattern: the base defines the overall flow and leaves named holes.

A contract that inherits an abstract base stays abstract itself until it implements every inherited unimplemented function (each with override). Only once nothing is left blank does it become concrete and deployable. Marking a contract abstract on purpose, even when fully implemented, is also a deliberate way to say 'this is only ever meant to be a base, never deployed directly'.

abstract contract Base {
  function fee() public view virtual returns (uint256); // no body
  function net(uint256 x) public view returns (uint256) {
    return x - fee();   // relies on the child's fee()
  }
}

Shared logic now, enforced blanks for later.

Interface vs abstract contract: an interface can hold no state and no implemented functions; an abstract contract can hold both, so reach for it when you need shared logic plus a few enforced blanks.