In this track: Write and read Solidity
Modifiers and access checks
Reusable wrappers can enforce conditions, but the full code path matters.
A service desk can apply the same membership check before several operations.
This example begins with count zero and a request to call increment(). No real contract is deployed.
Animated local teaching model. No wallet, RPC or live blockchain data. Some labels and hashes are abbreviated for readability.
A modifier can wrap execution
Solidity modifiers insert behavior around a function body at the placeholder. This can reduce duplicated checks while making the effective execution sequence less obvious to a casual reader.
Inspect the condition and placement
A check must examine the intended caller and be applied to the relevant function. An unused modifier does not secure anything. Code before or after the placeholder can also have important effects.
Authorization depends on configuration
The owner or role value must be initialized and changeable only under appropriate rules. A correct comparison against the wrong configured address can still produce unwanted control.
Do not generalize the toy
The sample checks an immutable owner for a simple setting. Production authorization can involve upgrades, inheritance, external calls and recovery policies beyond this small demonstration.
Read the example
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;
contract LearningExample {
address public immutable owner = msg.sender;
uint256 public value;
modifier onlyOwner() {
require(msg.sender == owner, "Owner only");
_;
}
function set(uint256 next) external onlyOwner {
value = next;
}
}The modifier is attached to set; its existence alone would not protect another unrestricted setter.
Does merely declaring onlyOwner secure every function automatically?
The condition must actually be applied on each relevant execution path.
Original explanations by EtherTools. Examples are educational and source-linked; this site is independent of the Ethereum Foundation. Our approach.