
## Which is data integrity?

Data integrity refers to the accuracy, consistency, and reliability of data throughout its lifecycle. In modern applications, maintaining data integrity is crucial as data flows through different layers of the application, from API endpoints to database operations.

## Getting started with Zod

Zod is a TypeScript-first schema declaration and validation library. It allows you to define schemas that describe the shape of your data, and then use those schemas to validate data at runtime. What makes Zod stand out is its seamless integration with TypeScript: it can infer TypeScript types directly from your schemas, ensuring that your validation logic is always in sync with your type definitions.

Key benefits of using Zod include:

- **Runtime Validation**: Ensure that your data conforms to expected shapes at runtime, catching potential bugs early.
- **Type Safety**: Keep TypeScript types and runtime validation in perfect harmony, eliminating discrepancies between the two.
- **Improved Code Quality**: Write cleaner and more maintainable code by centralizing validation logic with Zod schemas.

![](assets/data-first-approach-with-zod-00.jpg)

To get started with Zod, install it via npm or Yarn:

```bash
npm install zod
# or
yarn add zod
```

Let’s look at a basic example of defining and using a schema:

```typescript
import { z } from 'zod';

// Define a schema for a user object
const userSchema = z.object({
  name: z.string(),
  age: z.number(),
});

type User = z.infer<typeof userSchema>; // { name: string; age: number; }

const validUser = { name: 'Alice', age: 30 };
const invalidUser = { name: 'Bob', age: 'thirty' };

userSchema.parse(validUser); // No error
userSchema.parse(invalidUser); // Throws ZodError
```

Here, `userSchema` is a Zod schema that expects an object with `name` (string) and `age` (number). The parse method throws a `ZodError` if the data doesn’t match the schema. Alternatively, you can use `safeParse` to get a result object instead of throwing:

```typescript
const result = userSchema.safeParse(invalidUser);
if (!result.success) {
  console.log(result.error);
}
```

## Core concepts of Zod

### Primitive types

Zod supports all primitive types, such as `z.string()`, `z.number()`, `z.boolean()`, `z.date()`, etc.

### Objects

Use `z.object({ ... })` to define object schemas. Each property can have its own schema.

### Arrays

Use `z.array()` to define arrays of a specific type, e.g., `z.array(z.string())`.

### Optional and nullable types

Mark fields as `optional` with `.optional()` or nullable with `.nullable()`:

```typescript
z.object({
  name: z.string().optional(),
  age: z.number().nullable(),
});
```

### Default values

Set default values with `.default()`:

```typescript
z.string().default("hello");
```

### Coercion

Coerce input to a specific type with `z.coerce`:

```typescript
z.coerce.string(); // Coerces input to string
z.coerce.number(); // Coerces input to number
```

### Custom error messages

Provide custom error messages for validation failures:

```typescript
z.string({ required_error: "Name is required" }).min(5, "Name must be at least 5 characters");
```

## Advanced schema validation

### Chaining validations

Add custom validation logic with `.refine()` or `.superRefine()`:

```typescript
z.string().refine(val => val.length <= 255, "String can't be more than 255 characters");
```

### Transforming data

Modify data after validation with `.transform()`:

```typescript
z.string().transform(val => val.toUpperCase());
```

### Composing schemas

Extend, merge, or pick/omit fields from existing schemas:

```typescript
const baseSchema = z.object({ name: z.string() });
const extendedSchema = baseSchema.extend({ age: z.number() });
```

### Discriminated unions

Handle different shapes of data with `z.discriminatedUnion()`:

```typescript
z.discriminatedUnion("type", [
  z.object({ type: z.literal("A"), a: z.string() }),
  z.object({ type: z.literal("B"), b: z.string() }),
]);
```

### Custom schemas

Define custom schemas with `z.custom()` for cases not covered by built-in methods.

## Integration with Typescript

Zod’s killer feature is its ability to infer TypeScript types from schemas. Use z.infer to get the type of a schema:

```typescript
const userSchema = z.object({ name: z.string(), age: z.number() });
type User = z.infer<typeof userSchema>; // { name: string; age: number; }
```

This ensures that your types and validation are always in sync. You can use these types in function signatures, API responses, and more.

## Real-world use cases

### Validating API inputs / responses

In an Express.js route, we can validate request bodies:

```typescript
const UserSchema = z.object({
  email: z.string().email(),
  password: z.string().min(8),
  age: z.number().min(18),
  role: z.enum(['admin', 'user'])
});

app.post('/register', (req, res) => {
  const result = UserSchema.safeParse(req.body);
  if (!result.success) {
    return res.status(400).json({ errors: result.error.issues });
  }
  // Proceed with valid data
});
```

We can also `parse` API response before using it.

### Validating configuration objects

Validate environment variables or configuration files:

```typescript
const envSchema = z.object({
  PORT: z.coerce.number().default(3000),
  NODE_ENV: z.enum(["development", "production"]),
});
const env = envSchema.parse(process.env);
```

### Form data validation

Use Zod with front-end form libraries (e.g., React Hook Form) to validate user input.

### Validating database query responses

When working with Firestore, you can ensure the data you retrieve matches the expected shape by defining a Zod schema and using a [Firestore converter](https://firebase.google.com/docs/reference/js/v8/firebase.firestore.FirestoreDataConverter). Here’s an example of how to set up a converter with Zod for a Firestore collection:

```typescript
import { getFirestore } from 'firebase/firestore';
import { getFirebaseApp } from './firebase'; // Your Firebase initialization
import { z } from 'zod';

// Define a converter using a Zod schema
const converter = <Z extends z.ZodTypeAny>(schema: Z, toLatest?: (data: any) => z.infer<Z>) => ({
  toFirestore: (data: z.infer<Z>) => schema.parse(data),
  fromFirestore: (snapshot: firebase.firestore.QueryDocumentSnapshot) => {
    const rawData = snapshot.data();
    // If a transformation function is provided, use it to convert the data to the latest version.
    const data = toLatest ? toLatest(rawData) : rawData;
    return schema.parse(data);
  },
});

// Example schema
const userSchema = z.object({
  name: z.string(),
  age: z.number(),
});

// Define a collection reference with the converter
const userCollectionRef = () => 
  getFirestore(getFirebaseApp())
    .collection('users')
    .withConverter(converter(userSchema));
```

Now, when you fetch data from `userCollectionRef`, it will automatically be validated against `userSchema`. If the data doesn’t match, `schema.parse` will throw a `ZodError`.

![](assets/data-first-approach-with-zod-01.jpg)

## Practices for maintaining data integrity with Zod

**Start Small**: Introduce Zod in a new module or a smaller part of your project first.

**Refactor Gradually**: Slowly replace existing validation logic with Zod schemas.

**Use `safeParse`**: Prefer safeParse over parse to handle errors gracefully.

**Single Source of Truth**: Keep schemas as the single source of truth for data shapes.

**Reusable Schemas**: Create reusable schemas for common types (e.g., email, ID).

## Conclusion & Next steps

Zod is a powerful tool for ensuring data integrity and type safety in TypeScript projects. Start by adding Zod to a small part of your project, and gradually expand its usage as you become more comfortable with it. The benefits of runtime validation and type safety are well worth the effort.

## References

- [Zod Official Documentation](https://zod.dev)
- [TypeScript Integration Guide](https://github.com/colinhacks/zod#typescript-integration)
- [Building Type-Safe APIs with Zod](https://blog.logrocket.com/schema-validation-typescript-zod/)
- [Zod Best Practices](https://github.com/colinhacks/zod#best-practices)
- [Zod Validation in React & Typescript](https://dev.to/silentvoice143/zod-validation-in-react-typescript-28k6)


This memo explores the importance of a data-first approach and how to maintain data integrity using Zod, a powerful TypeScript schema validation library

Data-first Approach & Maintaining Data Integrity with Zod Schema


## Overview of Foundry

Foundry is a blazingly fast, portable, and modular toolkit for Ethereum application development written in Rust. It consists of three main components:

- **Forge**: Testing framework for Ethereum smart contracts
- **Cast**: Swiss army knife for interacting with EVM smart contracts
- **Anvil**: Local Ethereum node designed for development

![](assets/web3-development-with-foundry-00.jpg)

## Why others not using Hardhat?

Foundry's Rust-based architecture makes testing much faster than JavaScript alternatives. Security teams and auditors prefer working directly in Solidity without translation layers. The framework's adoption has grown quickly in 2024, especially for high-value contracts where performance and reliability matter.

Foundry's terminal-based workflow cuts out JavaScript overhead, making it perfect for developers who want to work closer to the metal. Security teams love its deterministic environment when dealing with complex contracts.

![](assets/web3-development-with-foundry-01.jpg)

## Why we not using Hardhat?

Hardhat's lack of ESM support in TypeScript projects forced us to use outdated CommonJS modules. Since our frontend and services already use ESM, this created unnecessary friction in our development workflow. Foundry's language-agnostic approach lets us maintain a consistent ESM-based architecture across our entire stack.

## Core benefits of Foundry

**Development Speed**: Foundry accelerates development through fast compilation, native Solidity testing, and quick feedback loops, with benchmarks showing it's consistently 1.5-11x faster than Hardhat and up to 335x faster than Dapptools.

The platform offers **Modern Developer Experience** with built-in fuzzing that can run 10,000 tests in seconds to find edge cases, powerful debugging tools for precise error identification, and comprehensive gas optimization features that help create efficient contracts.

For **Flexibility**, Foundry seamlessly integrates with existing toolchains while supporting multiple EVM chains through its comprehensive toolkit consisting of Forge (for testing), Cast (for contract interaction), and Anvil (local Ethereum node), making it adaptable to various project requirements and easily incorporated into CI/CD pipelines for automated testing and deployment.

In our projects, we've seen these benefits firsthand. Our team uses Foundry's fast testing to catch issues early in development, while the native Solidity testing helps us write more accurate tests. The gas optimization features have helped us reduce deployment costs by up to 30% in some cases. We particularly value the deterministic environment when working on complex DeFi contracts where every gas optimization matters.

## What we actually do?

### Dealing with dependencies and remapping

![](assets/web3-development-with-foundry-02.jpg)

#### Git Submodules (Traditional Approach)

```bash
forge install OpenZeppelin/openzeppelin-contracts --no-commit
git submodule update --init --recursive
```

#### Modern package management with Bun

```bash
bun init
bun add -d @openzeppelin/contracts
```

Configure remappings in `remappings.txt`:

```text:remappings.txt
@openzeppelin/=node_modules/@openzeppelin/
ds-test/=lib/forge-std/lib/ds-test/src/
forge-std/=lib/forge-std/src/
```

### Deploying and testing a smart contract

We'll build an upgradeable ERC-1155 contract for game items (GOLD, SILVER, SWORD, SHIELD) using Foundry. This example shows how to:

- Implement and test smart contracts
- Set up deployment scripts
- Handle contract upgrades using the UUPS upgrade pattern

#### Implement a basic ERC-1155 contract

First, let's create an upgradeable ERC-1155 contract:

```solidity:src/GameItems.sol
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.13;

import "@openzeppelin/contracts-upgradeable/token/ERC1155/ERC1155Upgradeable.sol";
import "@openzeppelin/contracts-upgradeable/access/OwnableUpgradeable.sol";
import "@openzeppelin/contracts-upgradeable/proxy/utils/Initializable.sol";
import "@openzeppelin/contracts-upgradeable/proxy/utils/UUPSUpgradeable.sol";

contract GameItems is Initializable, ERC1155Upgradeable, OwnableUpgradeable, UUPSUpgradeable {
    // Item IDs
    uint256 public constant GOLD = 0;
    uint256 public constant SILVER = 1;
    uint256 public constant SWORD = 2;
    uint256 public constant SHIELD = 3;

    /// @custom:oz-upgrades-unsafe-allow constructor
    constructor() {
        _disableInitializers();
    }

    function initialize() public initializer {
        __ERC1155_init("https://game.example/api/item/{id}.json");
        __Ownable_init();
        __UUPSUpgradeable_init();

        // Mint initial items
        _mint(msg.sender, GOLD, 10**18, "");
        _mint(msg.sender, SILVER, 10**27, "");
        _mint(msg.sender, SWORD, 1000, "");
        _mint(msg.sender, SHIELD, 1000, "");
    }

    function mint(address account, uint256 id, uint256 amount)
        public
        onlyOwner
    {
        _mint(account, id, amount, "");
    }

    function _authorizeUpgrade(address newImplementation)
        internal
        onlyOwner
        override
    {}
}
```

#### Writing tests for our contract

Create comprehensive tests for the contract:

```solidity:test/GameItems.t.sol
// SPDX-License-Identifier: UNLICENSED
pragma solidity ^0.8.13;

import "forge-std/Test.sol";
import "../src/GameItems.sol";
import "@openzeppelin/contracts/proxy/ERC1967/ERC1967Proxy.sol";

contract GameItemsTest is Test {
    GameItems public implementation;
    GameItems public gameItems;
    address public owner;
    address public user1;

    function setUp() public {
        owner = address(this);
        user1 = address(0x1);

        // Deploy implementation
        implementation = new GameItems();

        // Deploy proxy
        bytes memory initData = abi.encodeWithSelector(
            GameItems.initialize.selector
        );
        ERC1967Proxy proxy = new ERC1967Proxy(
            address(implementation),
            initData
        );
        gameItems = GameItems(address(proxy));
    }

    function testInitialBalance() public {
        assertEq(gameItems.balanceOf(owner, gameItems.GOLD()), 10**18);
        assertEq(gameItems.balanceOf(owner, gameItems.SILVER()), 10**27);
        assertEq(gameItems.balanceOf(owner, gameItems.SWORD()), 1000);
        assertEq(gameItems.balanceOf(owner, gameItems.SHIELD()), 1000);
    }

    function testMinting() public {
        gameItems.mint(user1, gameItems.GOLD(), 100);
        assertEq(gameItems.balanceOf(user1, gameItems.GOLD()), 100);
    }

    function testFailMintingUnauthorized() public {
        vm.prank(user1);
        vm.expectRevert("Ownable: caller is not the owner");
        gameItems.mint(user1, gameItems.GOLD(), 100);
    }

    function testBatchTransfer() public {
        uint256[] memory ids = new uint256[](2);
        ids[0] = gameItems.GOLD();
        ids[1] = gameItems.SILVER();

        uint256[] memory amounts = new uint256[](2);
        amounts[0] = 100;
        amounts[1] = 200;

        gameItems.safeBatchTransferFrom(
            owner,
            user1,
            ids,
            amounts,
            ""
        );

        assertEq(gameItems.balanceOf(user1, gameItems.GOLD()), 100);
        assertEq(gameItems.balanceOf(user1, gameItems.SILVER()), 200);
    }
}
```

#### Add a deployment script

Create a deployment script that handles both the implementation and proxy deployment:

```solidity:script/GameItems.s.sol
// SPDX-License-Identifier: UNLICENSED
pragma solidity ^0.8.13;

import "forge-std/Script.sol";
import "../src/GameItems.sol";
import "@openzeppelin/contracts/proxy/ERC1967/ERC1967Proxy.sol";

contract GameItemsScript is Script {
    function run() public {
        uint256 deployerPrivateKey = vm.envUint("PRIVATE_KEY");

        vm.startBroadcast(deployerPrivateKey);

        // Deploy implementation
        GameItems implementation = new GameItems();

        // Prepare initialization data
        bytes memory initData = abi.encodeWithSelector(
            GameItems.initialize.selector
        );

        // Deploy proxy
        ERC1967Proxy proxy = new ERC1967Proxy(
            address(implementation),
            initData
        );

        // Log addresses
        console.log("Implementation deployed to:", address(implementation));
        console.log("Proxy deployed to:", address(proxy));

        vm.stopBroadcast();
    }
}
```

#### Run the deployment

```bash
# Deploy to local network
forge script script/GameItems.s.sol --fork-url http://localhost:8545 --broadcast

# Deploy to testnet (e.g., Sepolia)
forge script script/GameItems.s.sol \
    --rpc-url $SEPOLIA_RPC_URL \
    --broadcast \
    --verify \
    -vvvv
```

#### Contract lifecycle: from development to deployment

![](assets/web3-development-with-foundry-03.png)

## Limitations

While Foundry shines in performance, it has its drawbacks. The lack of multi-network config files makes cross-chain deployments more tedious than Hardhat. The debugging tools, though functional, can't match Truffle's step-by-step debugger. We've also felt the smaller plugin ecosystem - you'll often need to build custom tooling that would be readily available in Hardhat.

Writing tests in Solidity instead of JavaScript creates a steeper learning curve, especially for web developers on our team. The docs are improving but still leave gaps around advanced features, and community resources are still catching up to Hardhat's mature ecosystem.

## Our assessment

After months of wrestling with Hardhat's ESM limitations in our TypeScript stack, switching to Foundry was a game-changer. Sure, rewriting our JavaScript tests in Solidity took time, and we missed some familiar plugins. But the payoff was worth it - our test suite now runs in 40 seconds instead of 7 minutes.

Writing tests in Solidity turned out to be a blessing in disguise. It eliminated translation errors and made our tests more precise. For teams ready to invest in learning Foundry, it offers a rock-solid foundation that pays off in both development speed and contract quality.


Provides a comprehensive guide to Web3 development using Foundry, a modern, Rust-based toolkit for Ethereum smart contract development.

Web3 development with Foundry


## Introduction

Foundry is a blazing-fast, all-in-one toolkit built by developers and for developers. Crafted with the speed of Rust, Foundry streamlines your entire workflow:

- Write, test, deploy and script all within a single, unified environment.
- Experience lighting-fast compilation and test execution that leaves traditional tools in the dust.
- Harness the power of native Solidity scripting for automation & streamlined interactions.

To help everyone to adopt Foundry in your next projects and start forging the future of decentralized applications. This article will walk through the core concepts of Foundry.

## Why choosing Foundry?

**Streamlined Development Workflow:**

- Provides a unified environment for the entire development lifecycle, from writing and testing contracts to deploying and interacting with them, all within a single toolchain
- Allows you to write scripts directly in Solidity, simplifying tasks like deployments, contract interactions, and automated testing. This eliminates the need for external scripting languages.
- Foundry's CLI (using the forge and cast commands) offers a powerful and efficient way to interact with the toolchain, making it easy to integrate into existing workflows and automation scripts.

**Blazing fast performance:** Foundry is built with Rust, a language renowned for its performance. This translates to significantly faster compilation and test execution times compared to tools like Truffle or Hardhat, which rely on JavaScript.

![](assets/using-foundry-for-evm-smart-contract-developement_22ed3c2228f0f9355fcb48a2c63788ee_md5.webp)

## Managing dependencies

Currently, there are two ways of managing dependencies in a Foundry projects

- Using [Git Submodules](https://git-scm.com/book/en/v2/Git-Tools-Submodules)
- Using [Soldeer](https://soldeer.xyz/) - A Solidity native dependency manager

By default, Foundry uses _Git Submodules_ for managing dependencies. However, I prefer _Solder_ for my EVM repository template because it integrates well with _forge_ - A command-line tool included with Foundry.

## Toolbox overview

Foundry offers a powerful suite of tools to resolve our development development needs:

- [Forge](https://book.getfoundry.sh/forge/) - Builds, tests and deploys EVM smart contracts
- [Cast](https://book.getfoundry.sh/cast/) - Allows interaction with smart contracts, including making calls, sending transactions, and retrieving data.
- [Anvil](https://book.getfoundry.sh/anvil/) - Create local testnet node for deploying and testing smart contracts
- [Chisel](https://book.getfoundry.sh/chisel) - Provides an advanced Solidity REPL for rapid testing of code snippets.

In the scope of this memo, we'll focus on _Forge_ for constructing a template EVM contract repository.

## Showcase preparation

Let's create a fresh repository with the following files and folders:

```
- src
  - contracts
    - IcySwap.sol
  - scripts
    - IcySwap.s.sol
  - test
    - IcySwap.t.sol
- foundry.toml
```

Folder structure explaination:

- src/contracts: Contains all the smart contracts
- src/scripts: Contains all the scripts to interact with the contracts
- src/test: Contains all the test cases
- foundry.toml: Contains the Foundry configurations

### Configure Foundry

To make this guide more practical, a step closer to Mainnet deployments, we'll work on [Base Sepolia testnet](https://sepolia.basescan.org).

If you want to verify your contracts on `Basescan`, you must create a [Block Explorer API Key](https://docs.base.org/quick-start/block-explorer-api-key) and set it in `.env` file.

```
BLOCK_EXPLORER_API_KEY=<YOUR_KEY>
```

Then, insert below code into `foundry.toml` file

```toml
[profile.default]
src = 'contracts'
out = 'out'
script = 'scripts'
libs = ['node_modules', 'dependencies']
test = 'test'
cache_path  = 'cache_forge'

[rpc_endpoints]
base = "https://mainnet.base.org"
base_sepolia = "https://sepolia.base.org"
base_goerli = "https://goerli.base.org"

[etherscan]
base = { key = "${BLOCK_EXPLORER_API_KEY}" }
base_sepolia = { key = "${BLOCK_EXPLORER_API_KEY}" }
base_goerli = { key = "${BLOCK_EXPLORER_API_KEY}" }
```

### Install dependencies

_Make sure you have `Foundry toolchain` installed, if not, please follow [this guide](https://book.getfoundry.sh/getting-started/installation#using-foundryup) to install it._

**Soldeer** is a Solidity native package manager that helps us to manage dependencies in a more efficient way, just like using `npm` in Node.js.

Libraries that we'll use in this tutorial:

- [forge-std](https://v2.soldeer.xyz/project/forge-std) - a collection of helpful contracts and libraries used for writing tests or deployment scripts in native Solidity
- [@openzeppelin-contracts](https://v2.soldeer.xyz/project/@openzeppelin-contracts) - a library for secure smart contract development
  [@openzeppelin-contracts-upgradeable](https://v2.soldeer.xyz/project/@openzeppelin-contracts-upgradeable) - contains upgradeable variant of OpenZeppelin Contracts

**Steps to install above dependencies:**

1/ Append the following code into existing `foundry.toml` file:

```toml
[dependencies]
"@openzeppelin-contracts" = { version = "5.0.2", url = "https://soldeer-revisions.s3.amazonaws.com/@openzeppelin-contracts/5_0_2_14-03-2024_06:11:59_contracts.zip" }
"@openzeppelin-contracts-upgradeable" = { version = "5.0.2", url = "https://soldeer-revisions.s3.amazonaws.com/@openzeppelin-contracts-upgradeable/5_0_2_14-03-2024_06:12:07_contracts-upgradeable.zip" }
forge-std = { version = "1.9.1", url = "https://soldeer-revisions.s3.amazonaws.com/forge-std/v1_9_1_03-07-2024_14:44:59_forge-std-v1.9.1.zip" }
```

2/ Run `forge soldeer install` command to install libraries from `[dependencies]` section.

3/ Replace all content in `remappings.txt` file with the following code:

```bash
@openzeppelin/contracts=dependencies/@openzeppelin-contracts-5.0.2
@openzeppelin-contracts-upgradeable=dependencies/@openzeppelin-contracts-upgradeable-5.0.2
@forge-std=dependencies/forge-std-1.9.1
```

### Prepare some contracts

In this showcase, we'll utilize [IcySwap](https://github.com/dwarvesf/contract-icy-swap/blob/main/contracts/IcySwap.sol) contract, let's create a file called `IcySwap.sol` in `src/contracts` folder.

```solidity
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.24;

import "@openzeppelin/contracts/token/ERC20/IERC20.sol";
import "@openzeppelin/contracts/token/ERC20/ERC20.sol";
import "@openzeppelin/contracts/token/ERC20/utils/SafeERC20.sol";
import "@openzeppelin/contracts/utils/Pausable.sol";
import "@openzeppelin/contracts/utils/ReentrancyGuard.sol";
import "@openzeppelin/contracts/access/Ownable.sol";

contract IcySwap is Ownable, Pausable, ReentrancyGuard {
    using SafeERC20 for IERC20;

    IERC20 public immutable usdc;
    IERC20 public immutable icy;

    // This conversion is follow usdc decimals: 10**6
    // Let say we want 1 icy equal 2 usdc -> conversion rate should be 2 * 10**6
    uint256 public icyToUsdcConversionRate;

    event Swap(IERC20 indexed fromToken, uint256 indexed fromAmount);
    event ConversionRateChanged(uint256 conversionRate);
    event WithdrawToOwner(IERC20 indexed token, uint256 amount);

    constructor(address initialOwner, IERC20 _usdc, IERC20 _icy, uint256 _conversionRate)
        Ownable(initialOwner)
    {
        usdc = _usdc;
        icy = _icy;
        icyToUsdcConversionRate = _conversionRate;
    }

    // Swap methods
    function swap(uint256 _amountIn) external nonReentrant whenNotPaused {
        uint256 amountOut = (_amountIn * icyToUsdcConversionRate) / (10 ** 18);
        _swap(icy, _amountIn, usdc, amountOut);
        emit Swap(icy, _amountIn);
    }

    // Moderate methods
    function setConversionRate(uint256 _conversionRate) external onlyOwner {
        icyToUsdcConversionRate = _conversionRate;
        emit ConversionRateChanged(_conversionRate);
    }

    function pause() external onlyOwner {
        _pause();
    }

    function unpause() external onlyOwner {
        _unpause();
    }

    function withdrawToOwner(IERC20 _token) external onlyOwner {
        uint256 balance = _token.balanceOf(address(this));
        require(balance > 0, "contract has no balance");
        _token.safeTransfer(msg.sender, balance);
        emit WithdrawToOwner(_token, balance);
    }

    // Internal methods
    function _swap(IERC20 _fromToken, uint256 _fromAmount, IERC20 _toToken, uint256 _toAmount)
        internal
    {
        require(_toToken.balanceOf(address(this)) >= _toAmount, "out of money");
        _fromToken.safeTransferFrom(msg.sender, address(this), _fromAmount);
        _toToken.safeTransfer(msg.sender, _toAmount);
    }
}
```

Next, we'll create 2 sample ERC20 tokens to test our swapping logic.

- Create a file called `ICY.sol` in `src/contracts` folder.

```solidity
//SPDX-License-Identifier: Unlicense
pragma solidity ^0.8.24;

import "@openzeppelin/contracts/token/ERC20/ERC20.sol";

contract IcyToken is ERC20 {
    uint256 constant _initial_supply = 1000000000 * (10 ** 18);

    constructor() ERC20("IcyToken", "ICY") {
        _mint(msg.sender, _initial_supply);
    }

    function mint(address to, uint256 amount) public {
        _mint(to, amount);
    }
}
```

- Create a file called `USDC.sol` in `src/contracts` folder.

```solidity
//SPDX-License-Identifier: Unlicense
pragma solidity ^0.8.24;

import "@openzeppelin/contracts/token/ERC20/ERC20.sol";

contract UsdcToken is ERC20 {
    uint256 constant _initial_supply = 1000000000 * (10 ** 18);

    constructor() ERC20("UsdcToken", "USDC") {
        _mint(msg.sender, _initial_supply);
    }

    function mint(address to, uint256 amount) public {
        _mint(to, amount);
    }
}
```

## The fun part begins

In this part, we'll use `forge-std` library which provides a set of helpful [Cheatcodes](https://book.getfoundry.sh/forge/cheatcodes) to:

- Create test scripts to test `IcySwap` contract.
- Create deployment script to deploy `IcySwap` contract to `Base Sepolia` testnet.

### Testing `IcySwap` contract

Create a file called `IcySwap.t.sol` in `src/test` folder.

```solidity
// SPDX-License-Identifier: UNLICENSED
pragma solidity ^0.8.24;

import "@forge-std/src/Test.sol";
import "@forge-std/src/Vm.sol";
import "@forge-std/src/console2.sol";
import "@openzeppelin/contracts/proxy/transparent/ProxyAdmin.sol";
import "@openzeppelin/contracts/proxy/transparent/TransparentUpgradeableProxy.sol";
import "@openzeppelin/contracts/utils/cryptography/EIP712.sol";

import "../contracts/IcySwap.sol";
import "../contracts/ICY.sol";
import "../contracts/USDC.sol";

contract StreamPointsTest is Test {
    IcySwap internal icySwap;
    IcyToken internal icy;
    UsdcToken internal usdc;

    address internal user;
    address internal icySwapOwner;
    address internal ICY_ADDRESS;
    address internal USDC_ADDRESS;

    function setUp() public virtual {
        user = address(1);
        icySwapOwner = address(2);

        icy = new IcyToken();
        usdc = new UsdcToken();

        vm.startPrank(icySwapOwner);
        icySwap = new IcySwap(
            IERC20(address(usdc)),
            IERC20(address(icy)),
            2 * 10 ** 6
        );
        vm.stopPrank();
    }

    function test_swap() public virtual {
        vm.startPrank(user);

        // prepare balance
        icy.mint(user, 150 * 10 ** 18);
        usdc.mint(address(icySwap), 150000 * 10 ** 18);
        icy.approve(address(icySwap), type(uint256).max);

        // start swap
        icySwap.swap(100 * 10 ** 18);

        vm.stopPrank();
        assertEq(
            icy.balanceOf(address(icySwap)),
            100 * 10 ** 18,
            "failed to swap"
        );
    }

    function test_setConversionRate() public virtual {
        vm.prank(icySwapOwner);
        icySwap.setConversionRate(3 * 10 ** 6);
        assertEq(
            icySwap.icyToUsdcConversionRate(),
            3 * 10 ** 6,
            "failed to set conversion rate"
        );
    }

    function test_withdrawToOwner() public virtual {
        vm.startPrank(icySwapOwner);

        icy.mint(address(icySwap), 150 * 10 ** 18);
        icySwap.withdrawToOwner(icy);

        vm.stopPrank();
        assertEq(
            icySwap.icy().balanceOf(address(icySwap)),
            0,
            "failed to withdraw to owner"
        );
    }

    function test_RevertWhen_CallerIsNotOwner() public {
        vm.expectRevert();
        vm.prank(user);
        icySwap.setConversionRate(3 * 10 ** 6);
    }
}
```

**Explaination**

1/ In `setUp()` function, we deploy:

- Use cheatcode `vm.startPrank(icySwapOwner)` to start a transaction from `icySwapOwner` account to deploy `IcySwap` contract.
- Deploy 2 sample ERC20 tokens `ICY` and `USDC` used for `ICY/USDC` pair swapping.

2/ In each test function, we also use cheatcode `vm.startPrank(user)` to start a transaction from `user` account to interact with `IcySwap` contract. Then make assertions to check the expected results using provided methods from `forge-std` library.

**Run the test**

You can run the test with traces by using the following command:

```bash
forge test -vvvv
```

`Traces` is a feature that allows you to see the internal calls of a transaction. It's useful for debugging and understanding how a contract works.
![](assets/using-foundry-for-evm-smart-contract-developement_a5553a471de0e3b37e81f94efdf3f1c6_md5.webp)

### Deploying `IcySwap` contract to `Base Sepolia` testnet

Before deploying `IcySwap` contract to `Base Sepolia` testnet, we need to have following environment variables in `.env` file:

```
WALLET_PRIVATE_KEY=<your_wallet_private_key>
BLOCK_EXPLORER_API_KEY=<your_block_explorer_api_key_from_basescan>
```

Create a file called `IcySwap.s.sol` in `src/scripts` folder with the following content:

```solidity
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.24;

import { Script, console2 } from "@forge-std/src/Script.sol";
import "../contracts/IcySwap.sol";

contract IcySwapScript is Script {
    function setUp() public { }

    function run() public {
        uint256 privateKey = vm.envUint("WALLET_PRIVATE_KEY");
        address ICY_ADDRESS= 0x78a3f816a8e26af8c09F6Da3995Ee19bd69bf7fF;
        address USDC_ADDRESS = 0x036CbD53842c5426634e7929541eC2318f3dCF7e;
        vm.startBroadcast(privateKey);

        IcySwap icySwap = new IcySwap(IERC20(USDC_ADDRESS), IERC20(ICY_ADDRESS), 2 * 10**6);

        vm.stopBroadcast();
        console2.log("IcySwap address: ", address(icySwap));
    }
}
```

In above script:

- We can use `vm.envUint()` to get the value of `WALLET_PRIVATE_KEY` environment variable.
- Then, use `vm.startBroadcast()` to start a transaction from the account with the private key to deploy `IcySwap` contract.

Now, we can run the deployment script to deploy & verify our contract, by running:

```bash
forge script scripts/IcySwap.s.sol:IcySwapScript --broadcast --verify --rpc-url base_sepolia
```

And our `IcySwap` contract will be deployed to `Base Sepolia` testnet & will automatically be verified.

![](assets/using-foundry-for-evm-smart-contract-developement_edacb4045a35d14a161b41e829079199_md5.webp)

## Other usages

Foundry is not just be here to resolve our common tasks like compiling, testing and deploying smart contracts. It also provides a lot of other features that can be used to enhance our development workflow. One of them is `Fork testing`.

[Fork testing](https://book.getfoundry.sh/forge/fork-testing) is like a time machine that allows us to test our contracts on a forked mainnet and move to a specific block for testing.

I found an interesting repository that use Foundry to reproduce a lot of DeFi hacked incidents in the past - It's [DeFiHackLabs](https://github.com/SunWeb3Sec/DeFiHackLabs).

## References

- <https://book.getfoundry.sh/getting-started/first-steps>
- <https://milotruck.github.io/blog/Foundry-Cheatsheet/>
- <https://github.com/SunWeb3Sec/DeFiHackLabs>


Introduce Foundry's core functionalities & practices to develop, test and deploy EVM smart contracts

Using Foundry for EVM smart contract development


**Materialized view pattern**
TL,DR;
Versus "normal" view

- A normal view provides ease-of-use and flexibility features, but it DOES NOT speed up data access
- A Materialized view is the cache of views. It pre-computes, stores, and optimizes data access when created, and automatically refreshes to ensure real-time data availability

**Usecases**

- In data warehouses that have a large number of complex queries on large tables, consume a lot of time & resource, materialized views can eliminate the overhead of expensive joins and aggregations by responding to queries by pre-computed results.
- Especially useful for queries that can be anticipated and repeatedly use the same subquery results.

**Two main refresh strategies**
1/ Complete refresh

- Running within one transaction
- At the beginning, the old data of the materialized view is deleted
- Then, the new data is inserted by running the underlying SQL query.
- At the end of the refresh, the transaction is committed, and the new data is visible for all users.
  Pros: During this process, users can still use the materialized view and see the old data
  Cons: This process can take a long time as the number of rows that the materialized view contains

2/ Fast refresh (“incremental refresh” would be more appropriate)
In most cases, this method is much faster than a Complete Refresh

- A fast refresh requires having a materialized view log on each of the source tables that are referenced in the materialized view
- There are several preconditions to enable Fast Refresh, and if only one of them is missing, the Fast Refresh method does not work (can debug by using dbms_mview.explain_mview)

**References**

- https://learn.microsoft.com/en-us/azure/architecture/patterns/materialized-view
- https://docs.oracle.com/en/database/oracle/oracle-database/18/dwhsg/refreshing-materialized-views.html#GUID-BB945209-8D69-4FC7-844E-35C9ED7C8A80

#data
@brain master


Materialized view is the cache of views. It pre-computes, stores, and optimizes data access when created, and automatically refreshes to ensure real-time data availability.