ReadMeFeed / Community knowledge
Real questions. Useful conversations. Find the people who know your stack.
Languages & runtimes · #solidity
Learn why transactions revert when using a Hardhat fork, how to check the fork block versus contract deployment, and what fixes or escalation steps to take.
Reentrancy attacks can drain a contract’s funds. The Checks‑Effects‑Interactions (CEI) pattern is a tried‑and‑true way to stop them. This post walks through a concrete withdraw example, shows how CEI works, and explains its limits and when to add a mutex.
Learn how to use Hardhat Ignition to replace fragile deployment scripts with a declarative, state-tracked system that prevents redundant transactions and manages contract dependencies.
A concise architecture note that outlines requirements, minimal design, trust boundaries, operational checks, and failure modes for using the checks‑effects‑interactions pattern to prevent reentrancy in Solidity contracts.
Learn how Solidity 0.8+ handles integer overflows, when to use unchecked blocks for gas savings, and where protection fails.
Solidity custom errors (v0.8.4+) replace revert strings with a 4‑byte selector and typed arguments, cutting bytecode size and gas on failure.
Hardhat's console.log brings print-style debugging to Solidity. Here's how it intercepts calls on the Hardhat Network, a working example, and why you must strip it before deploying.
Custom errors replace revert strings with typed, named parameters — saving ~500–800 gas per revert. Declare them in a shared file, trigger with revert ErrorName(args), and frontends decode automatically via the ABI. Includes a worked token example, gas comparison table, and verification steps.
Learn how Solidity’s `unchecked` block lets you skip automatic overflow checks for gas savings, when it’s safe to use, and a practical token transfer example that shows the trade‑offs and how to audit the code.
hardhat