:::info See the [`anvil` Reference](/anvil/reference) for in depth information on Anvil and its capabilities. ::: ### Notes #### EIP-7702 and Default Accounts Since the advent of EIP-7702, Anvil's default accounts have been delegated to drainers such as [https://etherscan.io/address/0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266#authlist7702](https://etherscan.io/address/0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266#authlist7702) This can negatively impact developer experience when users are running Anvil in fork mode and are making RPC calls that involve one of the default anvil accounts. To avoid this issue, use a different mnemonic when starting Anvil: ```bash anvil --mnemonic "
:::info See the [`cast` Reference](/cast/reference/cast) for a complete overview of all the available subcommands. ::: ### Chisel Chisel is a fast, utilitarian, and verbose Solidity REPL. The `chisel` binary can be used both within and outside of a Foundry project. If the binary is executed in a Foundry project root, Chisel will inherit the project's configuration options. Chisel is part of the Foundry suite and is installed alongside `forge`, `cast`, and `anvil`. If you haven't installed Foundry yet, see [Foundry installation](/introduction/installation). #### Getting started To use Chisel, simply type `chisel`. ```sh chisel ``` From here, start writing Solidity code! Chisel will offer verbose feedback on each input. Create a variable `a` and query it: ```console ➜ uint256 a = 123; ➜ a Type: uint256 ├ Hex: 0x7b ├ Hex (full word): 0x000000000000000000000000000000000000000000000000000000000000007b └ Decimal: 123 ``` Finally, run `!source` to see `a` was applied: ```solidity // SPDX-License-Identifier: UNLICENSED pragma solidity ^0.8.28; import {Vm} from "forge-std/Vm.sol"; contract REPL { Vm internal constant vm = Vm(address(uint160(uint256(keccak256("hevm cheat code"))))); /// @notice REPL contract entry point function run() public { uint256 a = 123; } } ``` To see available commands, type `!help` within the REPL.
:::info See the [`chisel` Reference](/chisel/reference) for in depth information on Chisel and its capabilities. ::: ### chisel #### NAME `chisel` - Test and receive verbose feedback on Solidity inputs within a REPL environment. #### SYNOPSIS `chisel` \[*options*] ##### Subcommands (bin) 1. `chisel list` * Displays all cached sessions stored in `~/.foundry/cache/chisel`. 2. `chisel load
:::info See the [`foundry.toml` Reference](/config/reference/default-config) for a complete overview of what you can configure. ::: ### Shell Autocompletion You can generate autocompletion shell scripts for `bash`, `elvish`, `fish`, `nushell`, `powershell`, and `zsh`. #### zsh First, ensure that the following is present at the end in your `~/.zshrc` file (if not, add it): ```sh autoload -U compinit compinit -i ``` Then run: ```sh forge completions zsh | sudo tee /usr/local/share/zsh/site-functions/_forge cast completions zsh | sudo tee /usr/local/share/zsh/site-functions/_cast anvil completions zsh | sudo tee /usr/local/share/zsh/site-functions/_anvil ``` For macOS: ```sh forge completions zsh > /opt/homebrew/share/zsh/site-functions/_forge cast completions zsh > /opt/homebrew/share/zsh/site-functions/_cast anvil completions zsh > /opt/homebrew/share/zsh/site-functions/_anvil ``` #### fish ```sh mkdir -p $HOME/.config/fish/completions forge completions fish > $HOME/.config/fish/completions/forge.fish cast completions fish > $HOME/.config/fish/completions/cast.fish anvil completions fish > $HOME/.config/fish/completions/anvil.fish source $HOME/.config/fish/config.fish ``` #### bash ```sh mkdir -p $HOME/.local/share/bash-completion/completions forge completions bash > $HOME/.local/share/bash-completion/completions/forge cast completions bash > $HOME/.local/share/bash-completion/completions/cast anvil completions bash > $HOME/.local/share/bash-completion/completions/anvil exec bash ``` #### nushell ```sh mkdir -p $HOME/.config/nushell/completions forge completions nushell > $HOME/.config/nushell/completions/forge.nu cast completions nushell > $HOME/.config/nushell/completions/cast.nu anvil completions nushell > $HOME/.config/nushell/completions/anvil.nu ``` Then add the following to your `config.nu` file: ```nu use ~/.config/nushell/completions/forge.nu * use ~/.config/nushell/completions/cast.nu * use ~/.config/nushell/completions/anvil.nu * ``` ### Static Analyzers #### Slither To test your project using [slither](https://github.com/crytic/slither), here is a sample `slither.config.json`: ```json { "filter_paths": "lib" } ``` To run Slither on the entire project, use this command in the root of the project: ```sh slither . ``` By default (as of version 0.10.0), this will skip tests and scripts. To force inclusion of the tests and scripts, add the `--foundry-compile-all` flag. To run Slither on a single file, use this command: ```sh slither src/Contract.sol ``` Note, this requires configuring the [solc version in the foundry config file](https://book.getfoundry.sh/config/reference/solidity-compiler#solc_version). You do not need to provide remappings via the `solc_remaps` option as Slither will automatically detect remappings in a Foundry project. Slither will invoke `forge` to perform the build. See the [Slither wiki](https://github.com/crytic/slither/wiki/Usage) for more information. In order to use a custom configuration, such as the sample `slither.config.json` mentioned above, the following command is used as mentioned in the [slither-wiki](https://github.com/crytic/slither/wiki/Usage#configuration-file). By default slither looks for the `slither.config.json` but you can define the path and any other `json` file of your choice: ```sh slither --config-file
> 💡 **Tip** > > Use Cast's [`abi-encode`](/cast/reference/abi-encode) to ABI-encode arguments. > > In this example, we ran `cast abi-encode "constructor(string,string,uint8,uint256)" "ForgeUSD" "FUSD" 18 1000000000000000000000` to ABI-encode the arguments.
#### Troubleshooting ##### `missing hex prefix ("0x") for hex string` Make sure the private key string begins with `0x`. ##### `EIP-1559 not activated` EIP-1559 is not supported or not activated on the RPC server. Pass the `--legacy` flag to use legacy transactions instead of the EIP-1559 ones. If you do development in a local environment, you can use Hardhat instead of Ganache. ##### `Failed to parse tokens` Make sure the passed arguments are of correct type. ##### `Signature error` Make sure the private key is correct. ##### `Compiler version commit for verify` If you want to check the exact commit you are running locally, try: ` ~/.svm/0.x.y/solc-0.x.y --version` where `x` and `y` are major and minor version numbers respectively. The output of this will be something like: ```bash solc, the solidity compiler commandline interface Version: 0.8.12+commit.f00d7308.Darwin.appleclang ``` Note: You cannot just paste the entire string "0.8.12+commit.f00d7308.Darwin.appleclang" as the argument for the compiler-version. But you can use the 8 hex digits of the commit to look up exactly what you should copy and paste from [compiler version](https://etherscan.io/solcversions). ##### `Invalid API Key` With [Etherscan API V2](https://docs.etherscan.io/etherscan-v2), only Etherscan keys are valid, this can be used for similar explorers eg BscScan/BaseScan/Polygonscan. Legacy keys from other explorers have been deprecated. #### Known Issues ##### Verifying Contracts With Ambiguous Import Paths Forge passes source directories (`src`, `lib`, `test` etc) as `--include-path` arguments to the compiler. This means that given the following project tree ```text |- src |-- folder |--- Contract.sol |--- IContract.sol ``` it is possible to import `IContract` inside the `Contract.sol` using `folder/IContract.sol` import path. Etherscan is not able to recompile such sources. Consider changing the imports to use relative import path. ## Linting `forge lint` is a command that analyzes Solidity source files in your project to identify potential issues, and enforce coding standards It helps maintain code quality and consistency across your codebase. ### Examples 1. Lint all Solidity files in the project: ```sh forge lint ``` 2. Lint only files in a specific directory: ```sh forge lint src/contracts/ ``` 3. Lint with only `high` and `gas` severity lints: ```sh forge lint --severity high --severity gas ``` 4. Lint with specific lint ID and output as JSON: ```sh forge lint --only-lint incorrect-shift --json ``` ### Supported Lints This section details the lints supported by `forge lint`. Each lint includes an ID, a description of the issue it checks for, its severity, and examples of incorrect and correct code. #### High Severity ##### `incorrect-shift` Warns against shift operations where the operands might be in an unconventional or potentially erroneous order, specifically when a literal is shifted by a non-literal. In Solidity, bitwise shift operations (`<<` for left shift, `>>` for right shift) take the value to be shifted as the left operand and the number of bits to shift as the right operand. This lint rule uses a heuristic to flag potentially incorrect shift oferations. To do so, it identifies expressions where literal is shifted by a variable, which can often be an indication of a logical error where the operands were intended to be reversed. If that was indeed intended, it is recommended to replace literals by constants. Alternatively, the lint rule can be disabled. ```solidity // SPDX-License-Identifier: MIT pragma solidity ^0.8.0; contract IncorrectShift { uint64 const LARGE_NUM = 1 ether; uint256 foo = 100; function correct() public view returns (uint256) { // Shifting 'foo' by a literal '2'. return foo << 2; // Shifting a const 'LARGE_NUM' by a variable 'foo'. return LARGE_NUM << foo; } function incorrect() public view returns (uint256) { // Shifting a literal '2' by a variable 'foo'. This is likely an error. return 2 << foo; } } ``` To disable this lint for your project, you can add its ID to the `exclude_lints` array within the `[lint]` section of the `foundry.toml` configuration file: ```toml [lint] # ... rest of lint config ... exclude_lints = ["incorrect-shift"] ``` Alternatively, you can also disable this individual occurrence using [inline configuration](/config/reference/linter#inline-configuration). ##### `unchecked-call` Warns when low-level calls (`.call()`, `.delegatecall()`, `.staticcall()`) do not check the success return value. Low-level calls in Solidity return a tuple `(bool success, bytes memory data)`. Not checking the `success` value can lead to silent failures where the called function reverts but execution continues, potentially resulting in unexpected behavior or security vulnerabilities. ```solidity // SPDX-License-Identifier: MIT pragma solidity ^0.8.0; contract UncheckedCall { function correct() public { (bool success, ) = address(target).call(""); require(success, "Call failed"); // Or using if statement (bool ok, bytes memory data) = address(target).call(abi.encodeWithSignature("foo()")); if (!ok) revert("Call failed"); } function incorrect() public { // Unchecked call - success value is ignored address(target).call(""); // Unchecked call - only data is used (, bytes memory data) = address(target).call(""); } } ``` To disable this lint for your project, you can add its ID to the `exclude_lints` array within the `[lint]` section of the `foundry.toml` configuration file: ```toml [lint] # ... rest of lint config ... exclude_lints = ["unchecked-call"] ``` Alternatively, you can also disable this individual occurrence using [inline configuration](/config/reference/linter#inline-configuration). ##### `erc20-unchecked-transfer` Warns when ERC20 `transfer` or `transferFrom` calls do not check the return value. While the ERC20 standard specifies that these functions should return a boolean indicating success, not all implementations follow this pattern correctly. Some tokens revert on failure, while others return false. Not checking the return value can lead to situations where a transfer fails silently, causing loss of funds or incorrect contract state. ```solidity // SPDX-License-Identifier: MIT pragma solidity ^0.8.0; contract ERC20UncheckedTransfer { IERC20 public token; function correct() public { // Check return value with require require(token.transfer(recipient, amount), "Transfer failed"); // Or capture and check explicitly bool success = token.transferFrom(sender, recipient, amount); if (!success) revert("Transfer failed"); } function incorrect() public { // Unchecked transfer - return value ignored token.transfer(recipient, amount); // Unchecked transferFrom - return value ignored token.transferFrom(sender, recipient, amount); } } ``` To disable this lint for your project, you can add its ID to the `exclude_lints` array within the `[lint]` section of the `foundry.toml` configuration file: ```toml [lint] # ... rest of lint config ... exclude_lints = ["erc20-unchecked-transfer"] ``` Note that this lint could fire false positives, as it only checks the function name, but it doesn't ensure that the called address is an ERC20 contract. Because of that, you may have to disable individual occurrences using [inline configuration](/config/reference/linter#inline-configuration). #### Medium Severity ##### divide-before-multiply Warns against performing division before multiplication within the same expression, especially with integer arithmetic. In Solidity, integer division truncates (rounds down towards zero). Performing division before multiplication can lead to a loss of precision that might be unintended and could have been avoided by reordering operations. For example, `(a / b) * c` might result in `0` if `a < b`, even if `(a * c) / b` would have yielded a non-zero result. ```solidity // SPDX-License-Identifier: MIT pragma solidity ^0.8.0; contract DivideBeforeMultiply { function correct() public pure returns (uint256) { return (1 * 3) / 2; // Results in 1. } function incorrect() public pure returns (uint256) { return (1 / 2) * 3; // Results in 0. } } ``` To disable this lint for your project, you can add its ID to the `exclude_lints` array within the `[lint]` section of the `foundry.toml` configuration file: ```toml [lint] # ... rest of lint config ... exclude_lints = ["divide-before-multiply"] ``` Alternatively, you can also disable this individual occurrence using [inline configuration](/config/reference/linter#inline-configuration). ##### `unsafe-typecast` Warns against unsafe type conversions that may result in data loss or unexpected behavior. In Solidity, typecasts are unchecked and can introduce unexpected behavior when converting between types of different sizes. For example, casting from a larger type to a smaller one (such as `uint256` to `uint8`) will silently truncate the higher-order bits. This may result in data loss and subtle, hard-to-detect bugs. ```solidity // SPDX-License-Identifier: MIT pragma solidity ^0.8.0; contract UnsafeTypecast { function safe(uint256 largeValue) public pure { if (largeValue > type(uint8).max) revert(); // casting to 'uint8' is safe because we ensure 'largeValue' can fit above. // forge-lint: disable-next-line(unsafe-typecast) uint8 smallValue = uint8(largeValue); } function unsafe(uint256 largeValue) public pure { // This cast is unsafe: it truncates `largeValue` to fit into 8 bits, // discarding all but the lowest 8 bits (i.e., `largeValue % 256`). // Any value greater than 255 will lose data, which can lead to bugs. uint8 truncated = uint8(largeValue); } } ``` To disable this lint for your project, you can add its ID to the `exclude_lints` array within the `[lint]` section of the `foundry.toml` configuration file: ```toml [lint] # ... rest of lint config ... exclude_lints = ["unsafe-typecast"] ``` Alternatively, you can also disable this individual occurrence using [inline configuration](/config/reference/linter#inline-configuration). #### Informational / Style Guide ##### `pascal-case-struct` Ensures that struct names adhere to `PascalCase` (e.g., `MyStruct`) convention. This is a common styling guideline in Solidity to improve code readability and maintain consistency. Useful resources: [Solidity Style Guide - Struct Names](https://docs.soliditylang.org/en/latest/style-guide.html#struct-names) ```solidity // SPDX-License-Identifier: MIT pragma solidity ^0.8.0; contract PascalCaseStruct { // Correct struct MyStruct { uint256 data; } // Incorrect struct my_struct { uint256 data; } struct myStruct { uint256 data; } } ``` To disable this lint for your project, you can add its ID to the `exclude_lints` array within the `[lint]` section of the `foundry.toml` configuration file: ```toml [lint] # ... rest of lint config ... exclude_lints = ["pascal-case-struct"] ``` Alternatively, you can also disable this individual occurrence using [inline configuration](/config/reference/linter#inline-configuration). ##### `mixed-case-function` Ensures that function names adhere to `mixedCase` (e.g., `myFunction`) convention. This helps in differentiate functions from other identifiers like structs or events and is a standard practice. Useful resources: [Solidity Style Guide - Function Names](https://docs.soliditylang.org/en/latest/style-guide.html#function-names) ```solidity // SPDX-License-Identifier: MIT pragma solidity ^0.8.0; contract MixedCaseFunction { // Correct function myFunction() public pure returns (uint256) { return 1; } // Incorrect function MyFunction() public pure returns (uint256) { return 1; } function my_function() public pure returns (uint256) { return 1; } } ``` To disable this lint for your project, you can add its ID to the `exclude_lints` array within the `[lint]` section of the `foundry.toml` configuration file: ```toml [lint] # ... rest of lint config ... exclude_lints = ["mixed-case-function"] ``` Alternatively, you can also disable this individual occurrence using [inline configuration](/config/reference/linter#inline-configuration). ##### `mixed-case-variable` Ensures that mutable variable names (local variables and state variables that are not `constant` or `immutable`) adhere to `mixedCase` (e.g., `myVariable`) convention. This aligns with the general Solidity style for variable naming. ```solidity // SPDX-License-Identifier: MIT pragma solidity ^0.8.0; contract MixedCaseVariable { // Correct uint256 stateVariable; function correct() public { uint256 localVariable = 10; } // Incorrect uint256 state_variable; function incorrect() public { uint256 local_variable = 20; } } ``` To disable this lint for your project, you can add its ID to the `exclude_lints` array within the `[lint]` section of the `foundry.toml` configuration file: ```toml [lint] # ... rest of lint config ... exclude_lints = ["mixed-case-variable"] ``` Alternatively, you can also disable this individual occurrence using [inline configuration](/config/reference/linter#inline-configuration). ##### `screaming-snake-case-const` Ensures that `constant` variable names adhere to `SCREAMING_SNAKE_CASE` (e.g., `MY_CONSTANT`). This is the standard convention for constants in Solidity, making them easily identifiable. Useful resources: [Solidity Style Guide - Constants](https://docs.soliditylang.org/en/latest/style-guide.html#constants) ```solidity // SPDX-License-Identifier: MIT pragma solidity ^0.8.0; contract ScreamingSnakeCaseConstant { // Correct uint256 constant MY_CONSTANT = 1; // Incorrect uint256 constant myConstant = 2; uint256 constant my_constant = 3; } ``` To disable this lint for your project, you can add its ID to the `exclude_lints` array within the `[lint]` section of the `foundry.toml` configuration file: ```toml [lint] # ... rest of lint config ... exclude_lints = ["screaming-snake-case-constant"] ``` Alternatively, you can also disable this individual occurrence using [inline configuration](/config/reference/linter#inline-configuration). ##### `screaming-snake-case-immutable` Ensures that `immutable` variable names adhere to `SCREAMING_SNAKE_CASE` (e.g., `MY_IMMUTABLE_VAR`). Similar to constants, this convention helps in distinguish immutable variables and maintaining consistency. ```solidity // SPDX-License-Identifier: MIT pragma solidity ^0.8.0; contract ScreamingSnakeCaseImmutable { // Correct uint256 immutable MY_IMMUTABLE_VAR; // Incorrect uint256 immutable myImmutableVar; address immutable my_immutable_var; } ``` To disable this lint for your project, you can add its ID to the `exclude_lints` array within the `[lint]` section of the `foundry.toml` configuration file: ```toml [lint] # ... rest of lint config ... exclude_lints = ["screaming-snake-case-immutable"] ``` Alternatively, you can also disable this individual occurrence using [inline configuration](/config/reference/linter#inline-configuration). ##### `unused-import` Warns when imported symbols are not used anywhere in the source file. Unused imports increase deployment costs unnecessarily and reduce code clarity. This lint checks for: * Unused named imports: `import {Symbol} from "file.sol";` * Unused aliased imports: `import "file.sol" as Alias;` * Unused aliased named imports: `import {Symbol as Alias} from "file.sol";` > Note: Plain imports without aliases (`import "file.sol";`) are not checked by this lint as they might be used for their side effects. To disable this lint for your project, you can add its ID to the `exclude_lints` array within the `[lint]` section of the `foundry.toml` configuration file: ```toml [lint] # ... rest of lint config ... exclude_lints = ["unused-import"] ``` Alternatively, you can also disable this individual occurrence using [inline configuration](/config/reference/linter#inline-configuration). ##### `unaliased-plain-import` Warns when using plain imports without an alias. Plain imports like `import "file.sol";` can make it unclear where symbols are coming from and can lead to naming conflicts. Best practice is to either: * Use named imports: `import {Symbol1, Symbol2} from "file.sol";` * Use aliased imports: `import "file.sol" as FileAlias;` ```solidity // SPDX-License-Identifier: MIT pragma solidity ^0.8.0; // Correct - using named imports import {SafeMath, Math} from "./Math.sol"; // Correct - using aliased import import "./Utils.sol" as Utils; // Incorrect - plain import without alias import "./Helpers.sol"; ``` To disable this lint for your project, you can add its ID to the `exclude_lints` array within the `[lint]` section of the `foundry.toml` configuration file: ```toml [lint] # ... rest of lint config ... exclude_lints = ["unaliased-plain-import"] ``` Alternatively, you can also disable this individual occurrence using [inline configuration](/config/reference/linter#inline-configuration). #### Gas Optimizations ##### `asm-keccak256` Recommends using inline assembly for `keccak256` hashing when possible. The Solidity global function `keccak256()` involves memory allocation and copying which can be less gas-efficient than a direct inline assembly implementation that operates on memory directly, especially for hashing small, fixed-size data. For production use, consider using [Vectorized's EfficientHashLib](https://github.com/Vectorized/solady/blob/main/src/utils/EfficientHashLib.sol) from the Solady library, which provides highly optimized implementations for common hashing patterns. ```solidity // SPDX-License-Identifier: MIT pragma solidity ^0.8.0; contract HashOptimization { // Correct - inline assembly function correct(uint256 a, uint256 b) public pure returns (bytes32 hashedVal) { assembly { mstore(0x00, a) mstore(0x20, b) let hashedVal := keccak256(0x00, 0x40) } } // Alternative - using EfficientHashLib from Solady // import {EfficientHashLib} from "solady/utils/EfficientHashLib.sol"; // function efficient(uint256 a, uint256 b) public pure returns (bytes32) { // return EfficientHashLib.hash(a, b); // } // Incorrect function incorrect(uint256 a, uint256 b) public pure returns (bytes32) { return keccak256(abi.encodePacked(a, b)); } } ``` To disable this lint for your project, you can add its ID to the `exclude_lints` array within the `[lint]` section of the `foundry.toml` configuration file: ```toml [lint] # ... rest of lint config ... exclude_lints = ["asm-keccak256"] ``` Alternatively, you can also disable this individual occurrence using [inline configuration](/config/reference/linter#inline-configuration). #### Codesize Optimizations ##### `unwrapped-modifier-logic` Warns when modifiers contain logic that isn't wrapped between the `_` placeholder. In Solidity, code in modifiers that appears before or after the `_` is inlined at every function using that modifier, which can significantly increase contract size when the modifier is used multiple times. Moving complex logic into internal functions that are called from the modifier can reduce bytecode size by avoiding code duplication, especially for modifiers used across many functions. ```solidity // SPDX-License-Identifier: MIT pragma solidity ^0.8.0; contract UnwrappedModifierLogic { address owner; // Correct - Complex logic is wrapped in an internal function modifier onlyOwner() { _checkOwner(); _; } function _checkOwner(address who) internal view { require(who == owner, "Not owner"); // Additional complex checks... } // Incorrect - Logic directly in modifier gets duplicated modifier onlyOwnerIncorrect() { require(msg.sender == owner, "Not owner"); // This code is inlined at every function using this modifier _; } } ``` To disable this lint for your project, you can add its ID to the `exclude_lints` array within the `[lint]` section of the `foundry.toml` configuration file: ```toml [lint] # ... rest of lint config ... exclude_lints = ["unwrapped-modifier-logic"] ``` Alternatively, you can also disable this individual occurrence using [inline configuration](/config/reference/linter#inline-configuration). #### See Also [Lint config](/config/reference/linter) ### Forge Forge is a command-line tool that ships with Foundry. Forge tests, builds, and deploys your smart contracts. Forge is part of the Foundry suite and is installed alongside `cast`, `chisel`, and `anvil`. If you haven't installed Foundry yet, see [Foundry installation](/introduction/installation). #### Getting started The best way to understand Forge is to simply try it (in less than 30 seconds!). First, let's initialize a new `counter` example repository: ```sh forge init counter ``` Next `cd` into `counter` and build : ```sh forge build ``` ```console [⠊] Compiling... [⠔] Compiling 27 files with Solc 0.8.28 [⠒] Solc 0.8.28 finished in 452.13ms Compiler run successful! ``` Let's [test](https://book.getfoundry.sh/forge/tests#tests) our contracts: ```sh forge test ``` ```console [⠊] Compiling... No files changed, compilation skipped Ran 2 tests for test/Counter.t.sol:CounterTest [PASS] testFuzz_SetNumber(uint256) (runs: 256, μ: 31121, ~: 31277) [PASS] test_Increment() (gas: 31293) Suite result: ok. 2 passed; 0 failed; 0 skipped; finished in 5.35ms (4.86ms CPU time) Ran 1 test suite in 5.91ms (5.35ms CPU time): 2 tests passed, 0 failed, 0 skipped (2 total tests) ``` Finally, let's run our deployment script: ```sh forge script script/Counter.s.sol ``` ``` [⠊] Compiling... No files changed, compilation skipped Script ran successfully. Gas used: 109037 If you wish to simulate on-chain transactions pass a RPC URL. ``` :::info See the [`forge` Reference](/forge/reference/forge) for a complete overview of all the available subcommands. ::: ### Deterministic deployments using `CREATE2` Enshrined into the EVM as part of the [Constantinople fork](https://ethereum.org/en/history/#constantinople) of 2019, `CREATE2` is an opcode that started its journey as [EIP-1014](https://eips.ethereum.org/EIPS/eip-1014). `CREATE2` allows you to deploy smart contracts to deterministic addresses, based on parameters controlled by the deployer. As a result, it's often mentioned as enabling "counterfactual" deployments, where you can interact with an addresses that haven't been created yet because `CREATE2` guarantees known code can be placed at that address. This is in contrast to the `CREATE` opcode, where the address of the deployed contract is a function of the deployer's nonce. With `CREATE2`, you can use the same deployer account to deploy contracts to the same address across multiple networks, even if the address has varying nonces. For the best user experience it is recommended to avoid having different addresses of the same deployment across different EVM chains. :::note This guide is intended to help you get started with configuring deterministic deployments using `CREATE2`. By default, `new Counter{salt: salt}()` will use the deterministic deployer at [`0x4e59b44847b379578588920ca78fbf26c0b4956c`](https://github.com/Arachnid/deterministic-deployment-proxy). Note that the deployer may not be available on all EVM chains. A different deployer address can be configured by setting `create2_deployer` in `foundry.toml` or by using `--create2-deployer` argument. ::: Follow these steps to set up deterministic deployments: :::steps #### Configure your `foundry.toml` In order to reliably deploy to deterministic addresses we will need to make sure our bytecode stays the same. To do so configure our `foundry.toml` as follows: ```toml [profile.default] solc = "
| *Blockchain Developer, Solidity, Foundry Full Course 2023* \~ Learn Solidity, Blockchain Development, & Smart Contracts Powered By AI - Full Course | Patrick Collins |
| 
| *Foundry* \~ Playlist of beginner level videos on Foundry | Smart Contract Programmer |
| 
| A Complete Introduction to Smart Contract Development With Foundry | Axelar |
| 
| Cyfrin Updraft - Foundry Fundamentals | Cyfrin Updraft |
| 
| Cyfrin Updraft - Advanced Foundry | Cyfrin Updraft |
### Getting Started
Foundry is a blazing fast, portable and modular toolkit for Ethereum application development written in Rust. It consists of four essential tools that suffice all the needs a blockchain app developer will ever have.
Here's an overview of the tools available at your disposal after [running foundryup](/introduction/installation#using-foundryup):
| Tool | What it enables |
| -------------------------------- | ------------------------------------------------------------------- |
| **[`forge`](/forge/overview)** | Build, test, debug, deploy and verify smart contracts |
| **[`anvil`](/anvil/overview)** | Run a local Ethereum development node with forking capabilities |
| **[`cast`](/cast/overview)** | Interact with contracts, send transactions, and retrieve chain data |
| **[`chisel`](/chisel/overview)** | Fast Solidity REPL for rapid prototyping and debugging |
:::tip
You can always view detailed help for any command or subcommand by appending `--help` to it.
:::
***
#### Forge
Forge is a command-line tool for building, testing, and deploying smart contracts.
##### Initialize a new project
```bash
# Create a new project called Counter
forge init Counter
cd Counter
```
##### Build and test contracts
```bash
# Compile your contracts
forge build
# Run your test suite
forge test
# Run tests against live chain state by forking
forge test --fork-url https://reth-ethereum.ithaca.xyz/rpc
```
##### Deploy contracts
```bash
# Use forge scripts to deploy contracts
# Set your private key
export PRIVATE_KEY="0xac0974bec39a17e36ba4a6b4d238ff944bacb478cbed5efcae784d7bf4f2ff80"
# Deploy to local anvil instance
forge script script/Counter.s.sol --rpc-url http://127.0.0.1:8545 --broadcast --private-key $PRIVATE_KEY
```
`forge` also enables more advanced workflows such as:
* [Table testing](/forge/advanced-testing/table-testing) - Property-based testing with test cases inputs organized into a table format
* [Fuzz testing](/forge/advanced-testing/fuzz-testing) - Property-based testing with randomized inputs
* [Invariant testing](/forge/advanced-testing/invariant-testing) - Test system-wide properties across function call sequences
* [Gas tracking](/forge/gas-tracking/overview) - Monitor and optimize gas consumption across your contracts
* [Coverage reports](/forge/reference/coverage) - Generate detailed test coverage analysis with `forge coverage`
Learn more about `forge` [here](/forge/overview).
***
#### Anvil
Anvil is a fast local Ethereum development node that is perfect for testing your contracts and other blockchain workflows in a controlled environment.
##### Start a local development node
```bash
# Start anvil with 10 pre-funded accounts
anvil
```
##### Fork mainnet state
```bash
# Fork latest mainnet state for testing
anvil --fork-url https://reth-ethereum.ithaca.xyz/rpc
```
`anvil` comes up with other advanced capabilities such as:
* **Custom `anvil_` methods** - Advanced node control including [account impersonation](/anvil/reference#anvil_impersonateaccount), [state manipulation](/anvil/reference#anvil_setbalance), and [mining control](/anvil/reference#anvil_mine)
* **Forking capabilities** - Fork anvil off another live chain
All of the above is provided while maintaining full compliance with the Ethereum JSON-RPC spec.
Learn more about `anvil` [here](/anvil/overview).
#### Cast
Cast is your Swiss army knife for interacting with Ethereum applications from the command line. You can make smart contract calls, send transactions, or retrieve any type of chain data.
##### Read contract data
```bash
# Check ETH balance
cast balance vitalik.eth --ether --rpc-url https://reth-ethereum.ithaca.xyz/rpc
# Call a contract function to read data
cast call 0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2 \
"balanceOf(address)" 0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045 \
--rpc-url https://reth-ethereum.ithaca.xyz/rpc
```
##### Send transactions
```bash
# Set your private key
export PRIVATE_KEY="0xac0974bec39a17e36ba4a6b4d238ff944bacb478cbed5efcae784d7bf4f2ff80"
# Send ETH to an address
cast send 0x70997970C51812dc3A010C7d01b50e0d17dc79C8 --value 10000000 --private-key $PRIVATE_KEY
```
##### Interact with JSON-RPC
```bash
# Call JSON-RPC methods directly
cast rpc eth_getHeaderByNumber $(cast 2h 22539851) --rpc-url https://reth-ethereum.ithaca.xyz/rpc
# Get latest block number
cast block-number --rpc-url https://reth-ethereum.ithaca.xyz/rpc
```
Learn more about `cast` [here](/cast/overview).
***
#### Chisel
Chisel is a fast, utilitarian, and verbose Solidity REPL for rapid prototyping and debugging. It's perfect for testing Solidity snippets and exploring contract behavior interactively.
##### Start the REPL
```bash
# Launch chisel REPL
chisel
```
##### Interactive Solidity development
```solidity
// Create and query variables
➜ uint256 a = 123;
➜ a
Type: uint256
├ Hex: 0x7b
├ Hex (full word): 0x000000000000000000000000000000000000000000000000000000000000007b
└ Decimal: 123
// Test contract functions
➜ function add(uint256 x, uint256 y) public pure returns (uint256) { return x + y; }
➜ add(5, 10)
Type: uint256
└ Decimal: 15
```
Learn more about `chisel` [here](/chisel/overview).
### Installation
If you encounter any issues during installation, refer to the [FAQ](/misc/faq) for assistance.
#### Precompiled Binaries
Precompiled binaries can be downloaded from the [GitHub releases page](https://github.com/foundry-rs/foundry/releases). For easier management, we recommend using [Foundryup](#using-foundryup).
#### Using Foundryup
Foundryup is the official installer for the Foundry toolchain. You can learn more about it [here](https://github.com/foundry-rs/foundry/blob/master/foundryup/README.md).
To install Foundryup, open your terminal and run the following command:
```sh
curl -L https://foundry.paradigm.xyz | bash
```
This will install Foundryup. Simply follow the on-screen instructions, and the `foundryup` command will become available in your CLI.
Running `foundryup` will automatically install the latest `stable` version of the [precompiled binaries](#precompiled-binaries): `forge`, `cast`, `anvil`, and `chisel`. If you wish to use the latest `nightly` build run `foundryup --install nightly`. For additional options, such as installing a specific version or commit, run `foundryup --help`.
If you want to install the binaries distributed by [Tempo's fork of Foundry](https://github.com/tempoxyz/tempo-foundry) run:
```sh
foundryup -n tempo
```
This will install the latest `nightly` version of the [precompiled binaries](#precompiled-binaries): `forge` and `cast`.
> ℹ️ **Note**\
> If you're using Windows, you'll need to install and use [Git BASH](https://gitforwindows.org/) or [WSL](https://learn.microsoft.com/en-us/windows/wsl/install) as your terminal, since Foundryup currently doesn't support Powershell or Command Prompt (Cmd).
##### Verifying the integrity and provenance of binaries
Foundry binaries are attested by using [GitHub artifact attestations](https://docs.github.com/en/actions/security-for-github-actions/using-artifact-attestations/using-artifact-attestations-to-establish-provenance-for-builds).
When installing a release using `foundryup` we match the hashes of the binaries against the hashes of the Github attestation artifact. This guarantees that the binaries were built by our automated release process in the official Foundry repository. We also use these hashes to check whether you already have the version of the binary installed. If so, we will skip the downloading.
You can pass the `--force` flag to skip the verification step. This also forces the installer to install a fresh version of the binaries as it has no hashes to match against.
Note that in the case you install an older release you may find that no `*attestation.txt` are available in the release for `foundryup` to verify against. In this case verification is skipped at installation. You can at any time manually verify the integrity as follows:
For example, `forge`:
```shell
gh attestation verify --owner foundry-rs $(which forge)
✓ Verification succeeded!
The following 1 attestation matched the policy criteria
- Attestation #1
- Build repo:..... foundry-rs/foundry
- Build workflow:. .github/workflows/release.yml@refs/tags/stable
- Signer repo:.... foundry-rs/foundry
- Signer workflow: .github/workflows/release.yml@refs/tags/stable
```
This is also the case for older releases.
#### Building from Source
##### Prerequisites
You'll need the [Rust](https://rust-lang.org) compiler and Cargo, Rust's package manager. The easiest way to install both is by using [`rustup.rs`](https://rustup.rs/).
Foundry generally supports building only with the latest stable version of Rust. If you're using an older version of Rust, you can update it with `rustup`:
```sh
rustup update stable
```
For Windows users, you'll also need a recent version of [Visual Studio](https://visualstudio.microsoft.com/downloads/), with the "Desktop Development With C++" workload installed.
##### Building
You can either use the various flags provided by [Foundryup](#using-foundryup):
```sh
foundryup --branch master
foundryup --path path/to/foundry
```
Alternatively, you can install via Cargo with the following command:
```sh
cargo install --git https://github.com/foundry-rs/foundry --profile release --locked forge cast chisel anvil
```
You can also manually build from a local copy of the [Foundry repository](https://github.com/foundry-rs/foundry):
```sh
# clone the repository
git clone https://github.com/foundry-rs/foundry.git
cd foundry
# install Forge
cargo install --path ./crates/forge --profile release --force --locked
# install Cast
cargo install --path ./crates/cast --profile release --force --locked
# install Anvil
cargo install --path ./crates/anvil --profile release --force --locked
# install Chisel
cargo install --path ./crates/chisel --profile release --force --locked
```
#### CI Installation with GitHub Actions
For instructions on setting up Foundry in a CI pipeline, refer to the [foundry-rs/foundry-toolchain](https://github.com/foundry-rs/foundry-toolchain) GitHub Action.
#### Using Foundry with Docker
:::note
Some systems, including those with M1 chips, may experience issues when building the Docker image locally. This is a known issue.
:::
Foundry can also be run inside a Docker container. If you don't have Docker installed, you can download it from [Docker's website](https://docs.docker.com/get-docker/).
Once Docker is installed, you can pull the latest Foundry release by running:
```sh
docker pull ghcr.io/foundry-rs/foundry:latest
```
You can also build the Docker image locally by running the following command from the Foundry repository:
```sh
docker build -t foundry .
```
For examples and guides on using this image, refer to the [Docker guide](/guides/foundry-in-docker).
#### Uninstalling
Foundry contains everything in a `.foundry` directory, usually located in `/home/