<100 subscribers

Foundry has emerged as a game changer in the world of Ethereum application development. If you're a developer looking to build, test, deploy, and interact with smart contracts efficiently, this toolkit is worth exploring. In this post, we'll dive deep into the fundamentals of Foundry from what it is and why you should use it, to its core tools, installation, project initialization, folder structure, and more. Whether you're a beginner or an experienced Solidity developer, this guide will equip you with the basics to get started.
What is Foundry?
Foundry is a blazing fast, portable, and modular toolkit for Ethereum application development, written in Rust. It provides a comprehensive suite of tools designed to streamline the entire smart contract lifecycle: from writing and testing code to deploying and interacting with on chain applications. Unlike traditional frameworks that rely on JavaScript ecosystems, Foundry leverages Rust's performance and safety features to deliver speed and reliability.
At its core, Foundry consists of four essential tools that cover all the needs of a blockchain app developer:
Forge: For building, testing, debugging, deploying, and verifying smart contracts.
Cast: A command-line interface (CLI) for interacting with EVM smart contracts, sending transactions, and retrieving chain data.
Anvil: A fast local Ethereum development node, similar to Ganache or Hardhat Network, with support for forking live chains.
Chisel: A utilitarian Solidity REPL (Read-Eval-Print Loop) for quickly prototyping, testing, and debugging Solidity code snippets on local or forked networks
Foundry emphasizes simplicity, with no heavy dependencies like node_modules and support for both Solidity and Vyper out-of-the-box. It's developed by Paradigm, a crypto-focused investment firm, and is actively maintained with a vibrant community.

In a landscape dominated by tools like Hardhat, Truffle, and Remix, Foundry stands out for several compelling reasons, as highlighted by developers and benchmarks:
Blazing Speed: Written in Rust, Foundry compiles and tests contracts significantly faster than JavaScript-based alternatives. For example, benchmarks show Forge outperforming Hardhat by 2x to 5x in compilation times, and it's even quicker than DappTools in testing. This is due to incremental compilation, parallel processing, and efficient handling of dependencies.
Solidity-Native Testing: Write tests directly in Solidity, eliminating context switching between languages. This reduces boilerplate, improves productivity, and lowers the barrier for Solidity-focused developers. Features like fuzz testing (random input generation with shrinking for edge cases), invariant testing, gas tracking, and coverage reports are built-in.
Modularity and Portability: Foundry uses Git submodules for dependencies, making it easy to integrate libraries like OpenZeppelin without complex setups. It's lightweight, with no need for large runtime environments, and supports non-standard project structures (e.g., importing Hardhat repos).
Powerful Features for Real-World Development:
Forking: Simulate live chain states for realistic testing without deploying to testnets.
Cheatcodes: VM manipulations (e.g., prank for impersonating accounts or store for overriding storage) to explore edge cases.
No Context Switching: Everything from testing to deployment happens in a unified CLI environment.
Ease of Use: User-friendly for beginners, with integrations for VSCode, CI/CD pipelines, and shell autocompletion. It's also more secure and efficient for advanced tasks like optimizing DeFi contracts.
Community and Ecosystem: Backed by Paradigm, Foundry has a growing list of resources, tutorials, and projects. It's ideal for high-quality contract engineering, with features like runtime debug logging and compatibility with tools like ds-test and forge-std.
Compared to Hardhat (JavaScript-heavy, slower) or Truffle (more opinionated), Foundry minimizes overhead, maximizes flexibility, and delivers better performance—making it a top choice for serious Ethereum developers in 2025.
Getting started with Foundry is straightforward. It uses a simple installer script:
Download the installer:
curl -L https://foundry.paradigm.xyz | bashInstall the tools (Forge, Cast, Anvil, Chisel):
For the latest nightly release (for cutting-edge features):
foundryup -i nightlyFoundry requires Rust to be installed (via rustup if not already present). Once set up, verify with forge --version, cast --version, etc. No additional packages are needed it's self-contained.

To kick off a new project:
Initialize the project:
forge init myprojectThis creates a new directory named myproject with a basic structure, including a sample contract (e.g., Counter.sol). Navigate into it:
cd myprojectBuild the project:
forge build
This compiles your contracts using the appropriate Solidity version (auto detected or configurable).
To initialize (create) a new contract:
Contracts live in the src/ folder. Create a new file, e.g., src/MyContract.sol:
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.28;
contract MyContract {
uint256 public value;
function setValue(uint256 _value) public {
value = _value;
}
}Foundry doesn't have a specific "init contract" command; you simply write Solidity files in src/. For dependencies (e.g., OpenZeppelin), install via Git submodules:
forge install OpenZeppelin/openzeppelin-contracts This adds them to lib/.
Test your contract:
Create a test file in test/, e.g., test/MyContract.t.sol
// SPDX-License-Identifier: UNLICENSED
pragma solidity ^0.8.28;
import "forge-std/Test.sol";
import "../src/MyContract.sol";
contract MyContractTest is Test {
MyContract myContract;
function setUp() public {
myContract = new MyContract();
}
function testSetValue() public {
myContract.setValue(42);
assertEq(myContract.value(), 42);
}
}Run tests:
forge testFor verbose output or forking a live chain:
forge test -vvvv --fork-url https://your-rpc-urlDeploy a contract
Use a script in script/, e.g., modify script/Counter.s.sol for your contract.

After running forge init, Foundry generates a standardized folder structure optimized for Ethereum development. Here's the default layout and the purpose of each component:
src/:
Purpose: Houses your main smart contract source files.
Typical Contents: Solidity files like Contract.sol. This is where you write your core logic. Example: A simple storage contract.
test/:
Purpose: Contains test files for your contracts, written in Solidity.
Typical Contents: Files ending in .t.sol (e.g., Contract.t.sol). Tests use forge-std/Test.sol for assertions, setups, and cheatcodes. Foundry auto detects and runs these.
script/:
Purpose: Stores deployment and interaction scripts.
Typical Contents: Files ending in .s.sol (e.g., Deploy.s.sol). These are run with forge script for tasks like deploying to networks or batch operations.
lib/:
Purpose: Manages external dependencies via Git submodules.
Typical Contents: Folders like forge-std/ (testing library) or openzeppelin-contracts/ (for ERC standards). Installed with forge install.
This structure is flexible Foundry supports custom layouts via foundry.toml. Best practice: Keep contracts modular, use submodules for deps, and regularly clean cache with forge clean for fresh builds.
Basic Commands:
Compile: forge build
Test with fuzzing: forge test --fuzz-runs 1000
Interact: cast call CONTRACT_ADDRESS "function()" --rpc-url RPC_URL
Local node: anvil (starts with 10 pre-funded accounts)
REPL: chisel for interactive Solidity (e.g., test variables or functions live).
Best Practices:
Use cheatcodes in tests for robust coverage (e.g., vm.prank(address) to simulate users).
Fork mainnet for realistic testing: anvil --fork-url MAINNET_RPC.
Optimize gas: Track with forge test --gas-report.
Integrate with VSCode: Use the Solidity extension and configure remappings.
CI/CD: Foundry works seamlessly with GitHub Actions for automated testing.
Security: Leverage fuzzing and invariants to catch vulnerabilities early.
Common Workflows:
Foundry's ecosystem is expanding, with resources like the official Foundry Book (book.getfoundry.sh), GitHub repo, and community tutorials. If you're tired of slow tools and want a modern, efficient workflow, give Foundry a try it's transforming how we build on Ethereum.
If you have questions or want to dive into a specific example, drop a comment! 🚀
Deploy:
forge script script/MyContract.s.sol --rpc-url http://127.0.0.1:8545 --broadcast --private-key YOUR_PRIVATE_KEYcache/:
Purpose: Stores compilation caches to speed up incremental builds.
Typical Contents: Temporary files for Solidity compiler outputs. Foundry uses this for faster recompilation only changed files are rebuilt.
out/:
Purpose: Holds build artifacts.
Typical Contents: JSON files with ABI, bytecode, and deployment info (e.g., out/MyContract.sol/MyContract.json). Used for deployment and verification.
foundry.toml:
Purpose: The main configuration file for your project.
Typical Contents: Settings like Solidity version, test verbosity, RPC endpoints, or remappings. Example:
[profile.default]
src = 'src'
out = 'out'
libs = ['lib']
solc_version = '0.8.28'remappings.txt:
Purpose: Defines import path remappings for cleaner code.
Typical Contents: Lines like forge-std/=lib/forge-std/src/ to simplify imports (e.g., import "forge-std/Test.sol";).
.gitmodules:
Purpose: Git configuration for submodules in lib/.
Typical Contents: Auto-generated; tracks dependency repos.
src/test/script/For production: Verify contracts on Etherscan with forge verify-contract.
Share Dialog
cypherpulse.base.eth
No comments yet