:::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. ::: ## Additional Cheatcodes A few new cheatcodes have been added to the existing [Cheatcodes](/reference/cheatcodes/overview) list to help within the ZKsync context, ### Cheatcodes Interface This is the extended Solidity interface for all ZKsync-specific cheatcodes present in Forge. ```solidity interface CheatCodesExt { /// Registers bytecodes for ZK-VM for transact/call and create instructions. function zkRegisterContract( string calldata name, bytes32 evmBytecodeHash, bytes calldata evmDeployedBytecode, bytes calldata evmBytecode, bytes32 zkBytecodeHash, bytes calldata zkDeployedBytecode ) external pure; /// Enables/Disables use ZK-VM for transact/call and create instructions. function zkVm(bool enable) external pure; /// When running in zkEVM context, skips the next CREATE or CALL, executing it on the EVM instead. /// All `CREATE`s executed within this skip will automatically have `CALL`s to their target addresses /// executed in the EVM and need not be marked with this cheatcode at every usage location. function zkVmSkip() external pure; /// Enables the use of a paymaster for the next transaction. function zkUsePaymaster(address paymaster, bytes calldata paymaster_input) external pure; /// Marks a given contract as a factory dependency only for the next CREATE or CALL operation function zkUseFactoryDep(string calldata name) external pure; } ``` ### Usage Refer to the [forge-zksync-std](../forge-zksync-std) section on accessing these cheatcodes in your tests. ## zkRegisterContract ```solidity function zkRegisterContract( string calldata name, bytes32 evmBytecodeHash, bytes calldata evmDeployedBytecode, bytes calldata evmBytecode, bytes32 zkBytecodeHash, bytes calldata zkDeployedBytecode ) external pure; ``` ### Description Registers bytecodes for ZK-VM for transact/call and create instructions. This cheatcode allows you to manually register the mapping between EVM and zkEVM bytecodes for contracts. ### Parameters * `name`: Contract name identifier * `evmBytecodeHash`: Hash of the EVM bytecode * `evmDeployedBytecode`: The deployed EVM bytecode * `evmBytecode`: The creation EVM bytecode * `zkBytecodeHash`: Hash of the zkEVM bytecode * `zkDeployedBytecode`: The deployed zkEVM bytecode ### Examples ```solidity import {Test} from "forge-std/Test.sol"; import {TestExt} from "forge-zksync-std/TestExt.sol"; contract ZkRegisterTest is Test, TestExt { function testRegisterContract() public { // Get bytecodes from compilation artifacts bytes memory evmBytecode = vm.getCode("MyContract.sol"); bytes memory evmDeployedBytecode = vm.getDeployedCode("MyContract.sol"); bytes memory zkDeployedBytecode = vm.getDeployedCode("MyContract.sol:zksolc"); bytes32 evmHash = keccak256(evmBytecode); bytes32 zkHash = keccak256(zkDeployedBytecode); // Register the contract bytecodes vmExt.zkRegisterContract( "MyContract", evmHash, evmDeployedBytecode, evmBytecode, zkHash, zkDeployedBytecode ); // Now the contract can be deployed and executed on zkEVM vmExt.zkVm(true); MyContract myContract = new MyContract(); } } ``` ### Use Cases * Manually managing bytecode mappings for complex deployment scenarios * Working with pre-compiled contracts * Advanced testing scenarios requiring specific bytecode configurations * Debugging bytecode translation issues ### Notes * This is typically handled automatically by foundry-zksync during compilation * Manual registration is only needed for advanced use cases * Ensure bytecode hashes are calculated correctly * Both EVM and zkEVM bytecodes must be valid for the same contract logic ## zkUseFactoryDep ```solidity function zkUseFactoryDep(string calldata name) external pure; ``` ### Description Marks a given contract as a factory dependency only for the next CREATE or CALL operation. Factory dependencies are contracts that may be deployed by other contracts during execution. ### Parameters * `name`: The name of the contract to mark as a factory dependency ### Examples ```solidity import {Test} from "forge-std/Test.sol"; import {TestExt} from "forge-zksync-std/TestExt.sol"; contract FactoryDepTest is Test, TestExt { function testFactoryDependency() public { // Mark ChildContract as a factory dependency vmExt.zkUseFactoryDep("ChildContract"); // Deploy factory contract that will create ChildContract instances Factory factory = new Factory(); // The factory can now deploy ChildContract instances address childAddress = factory.createChild(); } } contract Factory { function createChild() external returns (address) { // This will work because ChildContract was marked as factory dependency ChildContract child = new ChildContract(); return address(child); } } contract ChildContract { uint256 public value = 42; } ``` ### Use Cases * Factory pattern implementations where contracts deploy other contracts * Complex deployment scenarios with nested contract creation * Testing contracts that use CREATE2 for deterministic deployments * Working with proxy patterns and upgradeable contracts ### Notes * Only affects the immediate next CREATE or CALL operation * The specified contract must exist in the compilation artifacts * Factory dependencies are automatically handled in most cases * Manual marking is needed for complex scenarios or edge cases * In zkEVM, all factory dependencies must be known at deployment time ## zkUsePaymaster ```solidity function zkUsePaymaster(address paymaster, bytes calldata paymaster_input) external pure; ``` ### Description Enables the use of a paymaster for the next transaction. The paymaster will pay for the gas costs of the subsequent operation. ### Parameters * `paymaster`: The address of the paymaster contract * `paymaster_input`: Encoded input data for the paymaster contract ### Examples #### General Flow Paymaster ```solidity import {Test} from "forge-std/Test.sol"; import {TestExt} from "forge-zksync-std/TestExt.sol"; contract PaymasterTest is Test, TestExt { function testGeneralPaymaster() public { address paymasterAddress = 0x1234...; // Encode paymaster input for general flow bytes memory paymasterInput = abi.encodeWithSelector( bytes4(keccak256("general(bytes)")), bytes("0x") ); // Enable paymaster for next transaction vmExt.zkUsePaymaster(paymasterAddress, paymasterInput); // This deployment will be paid by the paymaster MyContract contract1 = new MyContract(); } } ``` #### Approval-Based Paymaster ```solidity function testApprovalBasedPaymaster() public { address paymasterAddress = 0x3cB2b87D10Ac01736A65688F3e0Fb1b070B3eeA3; address tokenAddress = 0x5678...; // Encode paymaster input for approval-based flow bytes memory paymasterInput = abi.encodeWithSelector( bytes4(keccak256("approvalBased(address,uint256,bytes)")), tokenAddress, // ERC20 token address uint256(1 ether), // Amount to approve bytes("0x") // Additional data ); // Enable paymaster for next transaction vmExt.zkUsePaymaster(paymasterAddress, paymasterInput); // This call will be paid by the paymaster using ERC20 tokens myContract.someFunction(); } ``` ### Notes * Only affects the immediate next transaction * The paymaster input format depends on the specific paymaster implementation * Ensure the paymaster contract has sufficient funds to cover gas costs * For approval-based paymasters, ensure the account has approved sufficient tokens ### See Also * [General Paymaster Example](/zksync-specifics/examples/general-paymaster) * [Approval-based Paymaster Example](/zksync-specifics/examples/paymaster-approval-based) ## zkVmSkip ```solidity function zkVmSkip() external pure; ``` ### Description When running in zkEVM context, skips the next CREATE or CALL, executing it on the EVM instead. All `CREATE`s executed within this skip will automatically have `CALL`s to their target addresses executed in the EVM and need not be marked with this cheatcode at every usage location. ### Examples ```solidity import {Test} from "forge-std/Test.sol"; import {TestExt} from "forge-zksync-std/TestExt.sol"; contract ZkVmSkipTest is Test, TestExt { function testZkVmSkip() public { // Enable ZK-VM mode vmExt.zkVm(true); // This will execute on zkEVM MyContract contract1 = new MyContract(); // Skip the next operation - execute on EVM instead vmExt.zkVmSkip(); // This will execute on EVM despite zkVm being enabled MyContract contract2 = new MyContract(); // This will execute on zkEVM again MyContract contract3 = new MyContract(); } } ``` ### Use Cases * Testing contracts that have different behavior on EVM vs zkEVM * Debugging by comparing execution between both virtual machines * Working with contracts that may not be compatible with zkEVM * Performance comparisons between EVM and zkEVM execution ### Notes * Only affects the immediate next CREATE or CALL operation * Nested operations from the skipped operation will also execute on EVM * Does not permanently disable zkEVM mode - subsequent operations return to zkEVM ## zkVm ```solidity function zkVm(bool enable) external pure; ``` ### Description Enables or disables the use of ZK-VM for transact/call and create instructions. When enabled (`true`), subsequent `CREATE` and `CALL` operations in the test will be executed on the zkEVM instead of the regular EVM. When disabled (`false`), operations return to standard EVM execution. ### Examples ```solidity import {Test} from "forge-std/Test.sol"; import {TestExt} from "forge-zksync-std/TestExt.sol"; contract ZkVmTest is Test, TestExt { function testZkVmEnable() public { // Enable ZK-VM mode vmExt.zkVm(true); // This contract deployment will execute on zkEVM MyContract contract1 = new MyContract(); // Disable ZK-VM mode vmExt.zkVm(false); // This contract deployment will execute on EVM MyContract contract2 = new MyContract(); } } ``` ### Notes * Using `--zksync` flag is equivalent to having `vmExt.zkVm(true)` as the first statement in a test * Only `CREATE` and `CALL` operations are affected by this cheatcode * Once dispatched to zkEVM, all nested operations remain in zkEVM context * Cheatcodes are not supported within zkEVM execution context ### 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`, `powershell`, and `zsh`. #### zsh First, ensure that the following is present somewhere 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/completions/zsh/_forge cast completions zsh > /opt/homebrew/completions/zsh/_cast anvil completions zsh > /opt/homebrew/completions/zsh/_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 ``` ### 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. ::: ### Creating an NFT with Solmate This tutorial will walk you through creating an OpenSea compatible NFT with Foundry ZKsync and [Solmate](https://github.com/transmissions11/solmate/blob/main/src/tokens/ERC721.sol). A full implementation of this tutorial can be found [here](https://github.com/dutterbutter/foundry-zksync-nft-tutorial). ##### This tutorial is for illustrative purposes only and provided on an as-is basis. The tutorial is not audited nor fully tested. No code in this tutorial should be used in a production environment. #### Create project and install dependencies Start by setting up a Foundry project following the steps outlined in the [Getting started section](/introduction/installation). We will also install Solmate for their ERC721 implementation, as well as some OpenZeppelin utility libraries. Install the dependencies by running the following commands from the root of your project: ```bash forge install transmissions11/solmate Openzeppelin/openzeppelin-contracts ``` These dependencies will be added as git submodules to your project. #### Implement a basic NFT Next, we will remove the boilerplate contracts found in `src/Counter.sol`, `test/Counter.t.sol`, and `script/Counter.s.sol`. After that, create a new file in the `src/` directory named `NFT.sol` and replace its content with the following code: ```solidity // SPDX-License-Identifier: UNLICENSED pragma solidity ^0.8.10; import {ERC721} from "solmate/tokens/ERC721.sol"; import {Strings} from "openzeppelin-contracts/contracts/utils/Strings.sol"; contract NFT is ERC721 { uint256 public currentTokenId; constructor( string memory _name, string memory _symbol ) ERC721(_name, _symbol) {} function mintTo(address recipient) public payable returns (uint256) { uint256 newItemId = ++currentTokenId; _safeMint(recipient, newItemId); return newItemId; } function tokenURI(uint256 id) public view virtual override returns (string memory) { return Strings.toString(id); } } ``` Let's take a look at this very basic implementation of an NFT. We start by importing two contracts from our git submodules. We import solmate's gas optimized implementation of the ERC721 standard which our NFT contract will inherit from. Our constructor takes the `_name` and `_symbol` arguments for our NFT and passes them on to the constructor of the parent ERC721 implementation. Lastly we implement the `mintTo` function which allows anyone to mint an NFT. This function increments the `currentTokenId` and makes use of the `_safeMint` function of our parent contract. #### Compile & deploy with forge To compile the NFT contract run `forge build --zksync`. You might experience a build failure due to wrong mapping: ```text Error: Compiler run failed error[6275]: ParserError: Source "lib/openzeppelin-contracts/contracts/contracts/utils/Strings.sol" not found: File not found. Searched the following locations: "/PATH/TO/REPO". --> src/NFT.sol:5:1: | 5 | import {Strings} from "openzeppelin-contracts/contracts/utils/Strings.sol"; | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ``` this can be fixed by setting up the correct remapping. Create a file `remappings.txt` in your project and add the line ```text openzeppelin-contracts/=lib/openzeppelin-contracts/ ``` (You can find out more on remappings in [the dependencies documentation](/guides/project-setup/dependencies). By default the compiler output will be in the `zkout` directory. To deploy our compiled contract with Forge we have to set environment variables for the RPC endpoint and the private key we want to use to deploy. Set your environment variables by running: ```bash export RPC_URL=
| *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/matter-labs/foundry-zksync/releases). We recommend using [Foundryup](#using-foundryup-zksync) for easier management.
We are working on a polished versioning approach that will be released soon. However, we are also in a phase of active development.
#### Using Foundryup-zksync
Foundryup-zksync is the official installer for the Foundry-ZKsync toolchain. You can learn more about it [here](https://github.com/matter-labs/foundry-zksync/blob/main/foundryup-zksync/README.md).
To install Foundryup-zksync, open your terminal and run the following command:
```sh
curl -L https://raw.githubusercontent.com/matter-labs/foundry-zksync/main/install-foundry-zksync | bash
```
This will install Foundryup-zksync. Follow the on-screen instructions, and the `foundryup-zksync` command will become available in your CLI.
Running `foundryup-zksync` automatically installs the latest nightly versions of the [precompiled binaries](#precompiled-binaries), including `forge` and `cast`. Additionally, it fetches the most recent version of the precompiled binary `anvil-zksync` from the [anvil-zksync releases](https://github.com/matter-labs/anvil-zksync/releases).
Run ' foundryup-zksync—- help ' for additional options, such as installing a specific version or commit.
> ℹ️ **Note**
>
> Only `forge` and `cast` are currently supported for ZKsync. Other commands retain their original behavior but may not work as intended.
> ℹ️ **Note**
>
> If you're on Windows, you will need to install and use [Git BASH](https://gitforwindows.org/) or [WSL](https://learn.microsoft.com/en-us/windows/wsl/install)
> since Foundryup-zksync currently does not support Powershell or Cmd. Windows support is currently provided as best-effort.
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-ZKsync generally supports building only with the [configured](https://github.com/matter-labs/foundry-zksync/blob/main/rust-toolchain) nightly Rust version.
The presence of `rust-toolchain` file automatically downloads the correct nightly rust version when commands are run from the Foundry-ZKsync directory.
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 different [Foundryup-ZKsync](#using-foundryup) flags:
```sh
foundryup-zksync --branch main
foundryup-zksync --path path/to/foundry-zksync
```
Alternatively, you can install it via Cargo with the following command:
```sh
cargo install --git https://github.com/matter-labs/foundry-zksync --profile release --locked forge cast
```
Or, by manually building from a local copy of the [Foundry-ZKsync repository](https://github.com/matter-labs/foundry-zksync):
```sh
# clone the repository
git clone https://github.com/matter-labs/foundry-zksync.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
```
#### CI Installation with GitHub Actions
The latest binaries for the appropriate architecture can be installed directly using the following GitHub Action:
```yaml
steps:
- name: Install Foundry-ZKsync
uses: dutterbutter/foundry-zksync-toolchain@v1
```
For further details, visit the [foundry-zksync-toolchain repository](https://github.com/dutterbutter/foundry-zksync-toolchain).
#### Using Foundry with Docker
> ℹ️ **Note**
>
> No prebuilt images are available for docker yet.
### Foundry Overview
Foundry is a smart contract development toolchain.
Foundry manages your dependencies, compiles your project, runs tests, deploys, and lets you interact with the chain from the command-line and via Solidity scripts.
### Navigating the Documentation
#### Getting Started
Get up and running with Foundry by [installing the toolkit](/introduction/installation) and [get started](/introduction/getting-started) with the basics of each tool.
#### Guides
Comprehensive tutorials and best practices for building robust smart contracts and development workflows with Foundry.
* **Best Practices**
* [Writing Contracts](/guides/best-practices/writing-contracts) - Guidelines for clean, secure smart contract development
* [Writing Tests](/guides/best-practices/writing-tests) - Effective testing strategies and patterns
* [Writing Scripts](/guides/best-practices/writing-scripts) - Deployment and automation script best practices
* [Security](/guides/best-practices/security) - Security considerations and vulnerability prevention
* [Key Management](/guides/best-practices/key-management) - Safe handling of private keys and secrets
* [Commenting](/guides/best-practices/commenting) - Documentation and code commenting standards
* [Scripting with Solidity](/guides/scripting-with-solidity) - Advanced deployment and automation techniques
* [Deterministic deployments using CREATE2](/guides/deterministic-deployments-using-create2) - Predictable contract addresses
* [Forking Mainnet with Cast and Anvil](/guides/forking-mainnet-with-cast-anvil) - Test against live chain state
* [Running Foundry inside of Docker](/guides/foundry-in-docker) - Containerized development environments
* [Implementing and Testing EIP-712 signatures](/guides/eip712)
#### Project Setup
Learn how to organize your projects with the [forge project setup guides](/guides/project-setup/creating-a-new-project) for scaling smart contract codebases.
#### Forge
Master the core smart contract development tool with the [Forge overview](/forge/overview), covering building, testing, deploying, and verifying contracts.
#### Cast
Learn to interact with blockchain networks from the command line using [Cast](/cast/overview) for contract calls, transactions, and chain data retrieval.
#### Anvil
Set up local development networks with [Anvil](/anvil/overview), Foundry's fast Ethereum-compatible node with forking capabilities.
#### Chisel
Explore Solidity interactively with [Chisel](/chisel/overview), the integrated REPL for rapid prototyping and debugging.
#### Configuration
Customize your Foundry setup and integrate with other tools for an optimized development workflow.
* [Config Overview with `foundry.toml`](/config/overview) - Project configuration and settings
* [Continuous Integration](/config/continuous-integration) - CI/CD pipeline integration
* [Integrating with VSCode](/config/vscode) - Editor setup and extensions
* [Shell Autocompletion](/config/shell-autocompletion) - Command-line productivity enhancements
* [Static Analyzers](/config/static-analyzers) - Code analysis tool integration
* [Integrating with Hardhat](/config/hardhat) - Cross-framework compatibility
* [Vyper support](/config/vyper) - Alternative smart contract language support
#### Contributing
Help improve Foundry by contributing - see the [contribution guidelines](https://github.com/foundry-rs/foundry/blob/master/CONTRIBUTING.md) to learn more.
#### Reference
Complete command references, configuration options, and API documentation for all Foundry tools.
* [FAQ](/misc/faq) - Frequently asked questions and troubleshooting
* **Command References**
* [forge Commands](/forge/reference/forge) - Complete forge CLI reference
* [cast Commands](/cast/reference/cast) - Complete cast CLI reference
* [anvil Commands](/anvil/reference) - Complete anvil CLI reference
* [chisel Commands](/chisel/reference) - Complete chisel CLI reference
* **Configuration & APIs**
* [Config Reference](/config/reference/overview) - All configuration options
* [Cheatcodes Reference](/reference/cheatcodes/overview) - Testing utilities and helpers
* [Forge Standard Library Reference](/reference/forge-std/overview) - Standard library documentation
* [DSTest Reference](/reference/ds-test) - Legacy testing framework reference
:::tip
You can also check out [Awesome Foundry](https://github.com/crisgarner/awesome-foundry), a curated list of awesome Foundry resources, guides, tools, and libraries!
:::
## Prompting
One of the fastest ways to build smart contracts is by using AI to assist with writing boilerplate code, implementing complex testing patterns, and following security best practices. When building, iterating on, or debugging smart contracts using AI tools and Large Language Models (LLMs), a well-structured and extensive prompt helps provide the model with clearer guidelines and examples that can dramatically improve output quality.
Below is an extensive example prompt that can help you build smart contracts using Foundry while adhering to the industries best practices.
### Build smart contracts using a prompt
Use the structured prompt by copying and pasting it into your AI tool of choice (for example OpenAI's ChatGPT or Anthropic's Claude).
**Make sure to enter your specific requirements at the end between the `