Events vs Storage
Gas trade-offs.
Events vs Storage is a free Web3 & DApp Development Fundamentals lesson on CoddyKit — lesson 4 of 4. You can read the complete lesson below for free — then practise it hands-on in the browser with a built-in code editor and a 24/7 AI tutor. It is part of the Web3 & DApp Development Fundamentals learning path, one of 4 lessons in the course, and your progress syncs across the web and the CoddyKit app.
Two Ways to Record Data
When something happens in a contract you can record it in storage or in an event log. Choosing wisely is a core gas-optimization skill.
This lesson compares the trade-offs so you know when to use each.
Storage Recap
Storage is the contract's permanent state. It is the only data the contract itself can read back later, but writing to it is very expensive.
<code>mapping(address => uint256) public balances; // contract can read this</code>Events Recap
Events write to the transaction log. They are far cheaper, but the contract cannot read them back on-chain - only off-chain clients can.
<code>event BalanceChanged(address indexed who, uint256 newBalance);
// off-chain apps read this; the contract cannot</code>Gas Cost Difference
Writing a fresh storage slot (an SSTORE from zero) costs around 20,000 gas. Emitting a log topic or word costs only a few hundred gas. Events can be an order of magnitude cheaper.
The Golden Rule
A simple guideline:
- Store data the contract needs to read or use in future logic
- Emit data only the outside world needs (history, UI, analytics)
Do not store data purely for display - emit it instead.
What Must Be Storage
Balances, ownership, allowances, and any value used in require checks or future calculations must live in storage, because the contract reads them.
<code>function transfer(address to, uint256 amt) public {
require(balances[msg.sender] >= amt); // needs storage
balances[msg.sender] -= amt;
balances[to] += amt;
}</code>What Can Be Events Only
A transaction history, audit trail, or notification feed is perfect for events. The contract never needs to revisit those records, so storing them would waste gas.
<code>event Logged(address indexed user, string action, uint256 time);
function act(string memory a) public {
emit Logged(msg.sender, a, block.timestamp); // no storage
}</code>Use Both Together
The most common pattern is to store the new state and emit an event describing the change. The storage value drives logic; the event keeps the UI in sync.
<code>function deposit() public payable {
balances[msg.sender] += msg.value; // storage for logic
emit BalanceChanged(msg.sender, balances[msg.sender]); // event for UI
}</code>Logs Cannot Be Queried On-Chain
A critical limitation: another contract cannot read your emitted logs. If contract B needs a value, contract A must expose it via storage or a return value, never via an event.
Avoid Storing for History
A common beginner mistake is pushing every action into a storage array to build a history. This grows unbounded and becomes hugely expensive. Emit events instead and let an off-chain indexer rebuild the history.
<code>// Anti-pattern: unbounded, costly
// historyArray.push(record);
// Better:
emit ActionRecorded(msg.sender, block.timestamp);</code>Decision Checklist
Ask: Does any on-chain code read this value later?
- Yes - storage (and optionally emit too)
- No, it is only for display or audit - event only
This single question resolves most design choices.
Quick Check
Test your understanding of events versus storage.
Recap
You learned the storage vs events trade-off:
- Storage is readable on-chain but expensive (~20k gas per fresh slot)
- Events are cheap but only off-chain clients can read them
- Store what the contract needs; emit what only the outside world needs
- The common pattern: update storage AND emit an event
Never store data purely for history or display.
Frequently asked questions
Is the “Events vs Storage” lesson free?
Yes — the full text of “Events vs Storage” is free to read here on the web, and the Web3 & DApp Development Fundamentals course includes 4 lessons in total. To practise it interactively (a built-in code editor and a 24/7 AI tutor) and unlock the rest of the Web3 & DApp Development Fundamentals course, upgrade to CoddyKit PRO.
What will I learn in “Events vs Storage”?
Gas trade-offs. You practise Web3 & DApp Development Fundamentals with hands-on code you run directly in the browser, and a 24/7 AI tutor answers your questions as you work through the lesson.
Do I need any experience to start Web3 & DApp Development Fundamentals?
No prior experience is required. Web3 & DApp Development Fundamentals on CoddyKit is structured for beginners through advanced learners; this is — lesson 4 of 4, so you can start here or from the beginning and move at your own pace.
How long does the “Events vs Storage” lesson take?
Most CoddyKit lessons take about 5–10 minutes. Each one is bite-sized and interactive, so you make steady progress and pick up exactly where you left off across the web and the app.
Can I write and run code in this Web3 & DApp Development Fundamentals lesson?
Yes. Every Web3 & DApp Development Fundamentals lesson includes a built-in code editor, so you write and run real code right in your browser and get instant AI feedback — no local setup required.
All lessons in this course
- Declaring Events
- Indexed Parameters
- Listening for Events
- Events vs Storage