You can play around with shielded types using our starter repository. This assumes you went through everything in Installation.

git clone "https://github.com/SeismicSystems/seismic-starter.git"
cd seismic-starter/packages/contracts
sforge test -vv

Or if you prefer a more detailed walkthrough of building on Seismic, check out our Tutorials section.

In this chapter, you’ll set up the foundation for the Walnut App using a clean and modular monorepo-style workspace. This structure separates concerns into distinct areas, making your project easier to navigate and maintain. You’ll create a contracts directory to house your Seismic smart contracts and tests, and a cli directory to serve as the command-line interface for interacting with those contracts. By the end of this chapter, you’ll have a fully initialized project, complete with dependencies, formatting tools, and a seamless environment for both contract development and interaction.

In this section, you will write a CLI to interact with the deployed Walnut smart contract from scratch, simulating a multiplayer, multi-round game consisting of two players, Alice and Bob. At the end of this section, you will be able to see a full game play out on your local Seismic node! Estimated time: ~30 minutes

Seismic is an EVM blockchain with native on-chain privacy. Write Solidity. Deploy with Foundry. Interact with Viem. The only difference: your users' data stays private.

One letter changes everything

The difference between a public ERC20 and a private SRC20 is one letter:

The s prefix tells the Seismic compiler to shield the underlying value. Observers see 0x00...0 instead of actual balances and amounts. Everything else — the Solidity syntax, the EVM execution model, the deployment flow — stays exactly the same.

What you can build

• Shielded tokens — ERC20s where balances and transfer amounts are hidden from observers

• Confidential DeFi — AMMs and lending protocols where positions, prices, and liquidation thresholds are shielded

• Compliant finance — Privacy with built-in access control so regulators can verify without exposing user data

3-minute quickstart

Already have Rust and the ?

You just ran shielded contract tests locally. See the for next steps.

Find what you need

Pre-requisite knowledge

Our documentation assumes some familiarity with blockchain app development. Before getting started, it'll help if you're comfortable with:

If you're new to blockchain app development or need a refresher, we recommend starting out with the tutorial.

Work with us

If you might benefit from direct support from the team, please don't hesitate to reach out to [email protected]. We pride ourselves in fast response time.

You can also check out our for the latest updates, or join our community.

As shown on the , shielding a Solidity contract can be as simple as adding an s prefix to your types. But why does that matter?

The transparency problem

Blockchains are public ledgers. Every balance, every transaction, every contract interaction is visible to anyone with a block explorer. This transparency was a design choice -- but it creates real problems:

Before continuing, ensure that you have completed the steps in the section to install all necessary Seismic developer tools:

• sforge: Framework for testing and deploying smart contracts.

• sanvil : Local Seismic node.

• ssolc: The Seismic Solidity compiler.

Run each of the above commands in your terminal with a --version flag to ensure that they're installed correctly.

Mappings to foundry

Seismic's development toolkit closely mirrors Foundry (it's a fork!). The mapping is as follows:

You should use the righthand version of all tools when developing for Seismic to get expected behavior. Our documentation assumes familiarity with foundry.

Quick actions

Substitute sforge for forge to execute against Seismic's superset of the EVM. More on this in the next section.

Local node

Use sanvil to run a local Seismic node for development and testing:

This starts a local node at http://localhost:8545 with pre-funded accounts, similar to Foundry's anvil.

This section dives into the heart of the Walnut App—the shielded smart contract that powers its functionality. You’ll start by building the foundational pieces of the Walnut, including the kernel and the protective shell, before implementing more advanced features like rounds, reset mechanisms, and contributor-based access control. By the end of this section, you’ll have a fully functional, round-based Walnut contract that is secure, fair, and replayable.

What You'll Learn

In this section, you’ll:

• Define and initialize the kernel, the hidden value inside the Walnut.

• Build the shell, the protective layer that hides the kernel, and implement a hit() function to help crack it, and a shake function to increment the kernel value by an encrypted amount.

• Add a look() function to conditionally reveal the kernel.

• Implement a reset mechanism to restart the Walnut for multiple rounds.

• Track player contributions in each round, ensuring that only contributors can access the kernel.

Overview of Chapters

You’ll define the kernel using a shielded state variable (suint256) and implement a shake() function to increment its value. This chapter introduces shielded writes.

Learn how to build the shell, which protects the kernel from being accessed prematurely. You’ll implement the hit()function to crack the shell and the look() function to reveal the kernel once conditions are met.

This chapter introduces a reset mechanism to enable multiple rounds of gameplay. You’ll track contributions per round and ensure that only players who helped crack the Walnut in a specific round can reveal the kernel. This chapter introduces shielded reads.

In this chapter, you’ll learn to create and initialize the kernel, a hidden value inside the Walnut, and increment it by implementing a shake function. Estimated time: ~10 minutes.

Defining the kernel

The kernel is the hidden number inside the Walnut. Using Seismic’s suint256 type, the kernel is shielded on-chain. Open up packages/contracts/Walnut.sol and define the kernel as a state variable and initialize it in the constructor:

Add a shake function

Next, let’s implement a function to increment the kernel. The shake function takes an suint256 parameter, _numShakes which specifies the amount to increment the kernel by.

What's happening here?

Since shake takes a shielded type as a parameter, you should use a Seismic transaction to keep the input private. The value of _numShakes is known only to the function caller and is shielded on-chain.

The function also updates a shielded state variable (kernel), so you should use a Seismic transaction (a shielded write) when calling it.

The s suffix lets you write shielded integer constants directly, without explicit casting. The compiler infers the concrete shielded type (suint8, suint256, sint128, etc.) from context.

This is equivalent to:

Both forms are valid. The s suffix is syntactic sugar — it produces the same bytecode.

Supported formats

The s suffix works with all numeric literal forms:

Type inference

The shielded type is inferred from the assignment target or surrounding expression:

Rules

No mixed arithmetic. You cannot mix shielded and non-shielded literals in the same expression:

No implicit conversion to non-shielded types. A shielded literal cannot be assigned to a regular type:

No immutable or constant. Shielded literals follow the same restriction as all shielded types — they cannot be used in immutable or constant declarations. See .

Compiler warning

All shielded literals emit warning 9660. This is intentional — literal values are embedded in the contract bytecode, which is publicly visible. The warning reminds you that the value is leaked at deployment time.

If the literal value is sensitive, do not hardcode it. Introduce it via encrypted calldata instead. See for more detail.

Seismic provides two TypeScript packages:

seismic-react depends on seismic-viem — install both if you're building a React app, or just seismic-viem for everything else.

Imagine you’re holding a walnut, an unassuming object. Inside it lies a number, a secret only revealed when you crack the shell. There are primarily two actions you can take on this walnut: either shaking it or hitting it. Shaking the walnut some n number of times increments the number inside by n, while hitting the walnut brings it one step closer to the shell cracking. You can only see the number inside if you have contributed to the cracking the shell, i.e., you have hit the walnut at least once. This collaborative challenge is the heart of the Walnut App, and it’s all powered by the Walnut smart contract. Let’s dive into the inner workings of the contract and uncover how each part fuels this game.

The contract can be found in the packages/contracts/Walnut.sol file of the .

Now that the contracts subdirectory has been initialized, you should now initialize the cli subdirectory that will be used to interact with the deployed contracts.

1. Navigate to the contracts subdirectory:

1. Initialize a new bun project

1. Navigate to the contracts subdirectory:

1. Initialize a project with sforge :

This command will:

In this chapter, you will learn about defining and constants and utility functions which we will frequently use throughout the project. Estimated time: ~10 minutes

First, navigate to the root of the directory/monorepo and run bun install to install all the dependencies.

Now, create a lib folder inside packages/cli with the files constants.ts and utils.ts:

constants.ts

Shielded Arrays

Arrays of shielded types work like standard Solidity arrays. Keys (indices) must be non-shielded — using a shielded type as an array index is a compiler error.

They come in two forms:

System requirements

Before you begin, make sure your machine meets the following requirements:

• x86_64 or arm64 architecture

• MacOS, Ubuntu, or Windows (other Linux distros may work but are not officially tested)

Install the local development suite

The local development suite uses sforge as the testing framework, sanvil as the local node, and ssolc as the compiler.

1. Install and on your machine if you don't already have them. Default installation works well.

1. Download and execute the sfoundryup installation script.

1. Install sforge, sanvil, ssolc. Expect this to take between 5-20 minutes depending on your machine.

1. (Optional) Remove old build artifacts in existing projects. You can ignore this step if you aren't working with existing foundry projects.

Set up the VSCode extension

We recommend adding syntax highlighting via the (or for Open VSX) extension from the VSCode marketplace. If you already have the solidity extension, you'll have to disable it while writing Seismic code.

1. Create the project folder and navigate into it:

1. Create the packages directory with subdirectories for contracts and cli

The contracts subdirectory will house the Seismic smart contract(s) and test(s) for the project, while the cli will house the interface to interact with the contracts.

1. Initialize a bun project in the root directory:

We remove the default index.ts and tsconfig.json files created by bun init -y to keep the root directory clean and focused on managing the monorepo structure rather than containing code. We also create a .prettierrc file for consistent code formatting and a .gitmodules file to manage contract submodules.

1. Replace the default package.json with the following content for a monorepo setup:

1. Add the following to the .prettierrc file for consistent code formatting:

1. Replace the.gitignore file with:

1. Add the following to the .gitmodules file to track git submodules (in our case, only the Forge standard library, forge-std):

In this chapter, you’ll deploy your Walnut contract to a local Seismic node for testing. By the end of this guide, you’ll have a fully deployed contract that you can interact with using your CLI or scripts. Estimated Time: ~15 minutes.

Writing the deploy script

Open packages/contracts/script/Walnut.s.sol and add the following:

and add the following to it:

This script will deploy a new instance of the Walnut contract with an initial shell strength of 3 and an initial kernel value of 0.

Deploying the contract

1. In a separate terminal window, run

in order to spin up a local Seismic node.

1. In packages/contracts , create a .env file and add the following to it:

The RPC_URL denotes the port on which sanvil is running and the PRIVKEY is one of the ten standard sanvil testing private keys.

1. Now, from packages/contracts, run

Your contract should be up and deployed to your local Seismic node!

Before proceeding to write the CLI, you need to be acquainted with some of the functions and utilities used to enable Seismic primitives (e.g. shielded reads, shielded writes etc.) through our client library, seismic-viem , which we will be using heavily to write the CLI. The detailed docs for seismic-viem can be found here. Estimated time: ~15 minutes

Shielded wallet client

The shielded wallet client is the shielded/Seismic counterpart of the wallet client in viem . It is used to enable extended functionality for interacting with shielded blockchain features, wallet operations, and encryption. It can be initialized using the createShieldedWalletClient function as follows:

createShieldedWalletClient takes in the following parameters:

1. chain : a well-defined object

2. transport : the method of transport of interacting with the chain (http /ws along with the corresponding RPC URL)

Once initialized, it can then be used to perform wallet operations or shielded-specific .

Shielded contract

A shielded contract instance provides an interface to interact with a shielded contract onchain. It has extended functionality for performing shielded write operations, signed reads, and contract interaction for a specific contract performed by a specific wallet client that it is initialized with. It can be initialized with the getShieldedContract as follows:

It takes in the following parameters:

1. abi : the ABI of the contract. After running sforge build, the ABI is in out/<ContractName>.sol/<ContractName>.json. You can also generate it manually with ssolc --abi <file>.sol. To use it in your code, you can import the JSON file directly, or copy the ABI array into a constant in your source (more tedious, but gives you better type inference).

2. address : the address of the deployed contract it is interacting with.

This function extends the base getContract functionality by adding:

• Shielded write actions for nonpayable and payable functions.

• Signed read actions for pure and view functions.

We will extensively use shielded writes (for shake ) and shielded reads (for look()) in our CLI.

Seismic maintains client libraries for three languages.

TypeScript

seismic-viem

composes with to add Seismic transaction support, encrypted calldata, and signed reads. See the .

seismic-react

composes with to provide React hooks for shielded reads, writes, and wallet management. See the .

Python — seismic-web3

composes with to interact with Seismic nodes from Python. See the .

Rust — seismic-alloy

composes with to provide Seismic transaction types and encryption-aware providers. See the .

Complete working examples demonstrating common Seismic React patterns. Each example is self-contained and can be copied into a new project.

Available Examples

Common Setup

Every example uses the same provider wrapper that combines RainbowKit, wagmi, and Seismic:

Prerequisites

• Node.js 18+

• A project ID

• seismic-react and peer dependencies installed

See Also

• - Hook API reference

• - RainbowKit, AppKit, and Privy integration

• - Full dependency setup

Operations on shielded types return shielded types. For example, comparing two suint256 values produces an sbool, not a bool. Arithmetic on sint256 returns sint256, and so on.

The Seismic public testnet is the primary network for development and testing. seismicTestnet is a RainbowKit-compatible chain object that wraps the seismic-viem testnet definition with RainbowKit metadata.

Configuration

Seismic's shielded types let you add privacy to any smart contract pattern. Below are five categories with code snippets showing how each looks in Seismic Solidity.

Private tokens (SRC20)

An ERC20 with shielded balances and transfer amounts. Users can check their own balance through signed reads, but no one else can see it.

The only difference from a standard ERC20: uint256 becomes suint256. The compiler routes all balance reads and writes through shielded storage automatically. Observers see 0x00...0 for all balances and amounts.

For a full walkthrough, see the .

Confidential DeFi

An AMM where liquidity positions, reserves, and swap amounts are hidden from observers. This prevents front-running and MEV extraction because bots cannot see the pool state or pending swaps.

The constant-product formula is standard AMM logic. Shielding the reserves and amounts means no one can compute the price impact of a pending swap or sandwich a user's trade.

Compliant finance (Intelligence Contracts)

Contracts can optionally implement access control over shielded data — for example, exposing a view function that only authorized addresses can call. This pattern is sometimes called an "Intelligence Contract": a shielded contract that selectively reveals information to specific parties.

In this example, balances are stored as suint256 so they are shielded by default. The getBalance function casts the shielded value to a regular uint256 for return, but only if the caller is the account owner or holds the COMPLIANCE_ROLE. Everyone else is rejected.

Private voting

Secret ballot governance on-chain. Votes are hidden during the voting period. The tally can be revealed when voting ends, but individual votes remain private.

During voting, both the individual votes (hasVoted) and the running tallies (yesVotes, noVotes) are shielded. No one can see which way the vote is trending. After the deadline, getResults() casts the shielded tallies to public uint256 values so the outcome can be read.

Sealed-bid auctions

Bids are hidden until the auction closes. No bidder can see what others have bid, eliminating bid sniping and strategic underbidding.

Each bid is stored as a suint256, and the highest bidder's address is stored as an saddress. During the auction, the contract tracks the leading bid internally, but no one outside the TEE can see any bid amounts or the current leader. After the auction ends, getWinner() reveals the result by casting shielded values to their public counterparts.

The SRC20 contract stores balances as suint256, which means there is no public getter. This chapter shows how to let users query their own balance securely using signed reads. Estimated time: ~15 minutes.

The problem

In a standard ERC20, balanceOf is a public mapping. Anyone can call balanceOf(address) and see any account's balance. In the SRC20, two things prevent this:

1. Shielded types cannot be public. The suint256 value type means the automatic getter would try to return a shielded type from an external function, which the compiler rejects.

2. Vanilla eth_call has no sender identity. On Seismic, the from field is zeroed out for unsigned eth_call

So you need two things: a way for the contract to verify who is asking, and a way to return the value only to that person.

Signed reads

A signed read solves both problems. It is a Seismic transaction (type 0x4A) sent to the eth_call RPC endpoint instead of eth_sendRawTransaction. Because it is a valid signed transaction:

• The from field is cryptographically verified, so the contract can trust msg.sender.

• The response is encrypted to the sender's encryption public key (included in the Seismic transaction's elements). Even if someone intercepts the response, they cannot decrypt it.

• The signed_read

From the contract's perspective, a signed read looks like a normal view function call. The difference is entirely at the transport layer.

Contract implementation

Add a balanceOf function that requires the caller to be the account owner:

This function does three things:

1. Checks msg.sender -- Only the account owner can query their own balance. With a vanilla eth_call, msg.sender would be address(0) and this check would always fail. With a signed read, msg.sender is the actual caller.

2. Casts to

Allowance checking

The same pattern applies to allowances:

Here, either the owner or the spender can check the allowance. Both parties have a legitimate reason to know the value.

Client-side code

On the client side, seismic-viem handles signed reads automatically under the hood. When you use a ShieldedWalletClient or a ShieldedContract, read calls are sent as signed reads. If you need an unsigned read (a vanilla eth_call), use contract.tread instead.

Using a shielded contract instance

The token.read.balanceOf() call is sent as a signed read under the hood. The wallet client signs the request, the node verifies the signature, executes the view function with the correct msg.sender, and encrypts the response to the caller's key.

Using the wallet client directly

You can also call readContract on the wallet client:

Both approaches produce the same signed read.

Security model

The signed read has several layers of protection:

The result is that only the account owner can view their balance, and the balance is never exposed in plaintext outside the TEE.

A note on privacy tradeoffs

With this implementation, each user can only see their own balance. They cannot see anyone else's balance. This is the strictest privacy model. In the next chapter, , we will add authorized roles (such as compliance officers) who can view specific balances when required -- without compromising privacy for everyone else.

In this chapter, you’ll build the shell, the protective layer that hides the kernel. You’ll initialize the shell’s strength and implement a hit function to decrement it. Additionally, you’ll add a look() function with a requiredCracked modifier to ensure the kernel can only be viewed once the shell is fully broken. Estimated Time: ~10 minutes.

Defining the shell

The shell determines the Walnut’s resilience. It has an integer strength (shellStrength), which represents how many hits it can withstand before cracking. Let’s define the shell and initialize it in the constructor:

Adding the hit function

Each time the Walnut is hit, the shell strength decreases, simulating damage to the protective shell. This is crucial for revealing the kernel, as the shell must be fully broken for the kernel to be accessed:

What’s happening here?

• The requireIntact modifier: Ensures that the function cannot be called if the Walnut’s shell is already broken (shellStrength == 0). This prevents underflow and unnecessary calls after the shell is fully cracked. We also add this modifier to the shake function:

• Decrementing the shell: Each call to hit decreases the shell’s strength (shellStrength) by one.

• Logging the action: The Hit event records the hitter’s address (msg.sender) and the remaining shell strength.

Example call:

Here’s how calling the hit function works in practice:

• Initial State: The shell strength is set to 5.

• First Hit: A player calls hit(). The shell strength decreases to 4.

• Subsequent Hits: Each additional hit reduces the shell strength by 1 until it reaches 0

Revealing the Kernel

Now that we have implemented the shell’s durability and the ability to break it using the hit function, we can introduce a new condition: the kernel should only be revealed once the shell is fully cracked.

Currently, there is no way to access the kernel’s value. However, now that we have a shell with a decreasing strength, we can apply a condition that restricts when the kernel can be seen. Specifically:

• The kernel should remain hidden while the shell is intact.

• The kernel can only be revealed once the shell’s strength reaches zero, i.e. when it is cracked.

To enforce this, we will create a function called look() , which will return the kernel’s value, but only if the Walnut has been fully cracked.

Here’s how we define look() with a requireCracked modifier:

What's happening here?

• Restricting Access with a Condition: The requireCracked modifier ensures that look() can only be called if shellStrength == 0, meaning the Walnut has been fully cracked.

• Revealing the Kernel: Once the condition is met, look() returns the unshielded value of the kernel.

Updated contract with hit, shake and look

In this chapter, you’ll write the core logic to interact with the Walnut contract by creating an App class. This class will initialize player-specific wallet clients and contracts, and provide easy-to-use functions like hit, shake, reset, and look. Estimated time: ~20 minutes

Create a file called app.ts in packages/cli/src/ which will contain the core logic for the CLI:

Import required dependencies

Start by importing all the necessary modules and functions at the top of app.ts:

Define the app configuration

The AppConfig interface organizes all settings for the Walnut App, including player info, wallet setup, and contract details. It supports a multiplayer environment, with multiple players having distinct private keys and contract interactions.

Create the App class

The App class manages player-specific wallet clients and contract instances, providing an easy-to-use interface for multiplayer gameplay.

Add initialization logic to App

The init() method sets up individual wallet clients and contract instances for each player, enabling multiplayer interactions. Each player gets their own wallet client and a direct connection to the contract.

Add helper methods to App

These helper methods ensure that the app fetches the correct wallet client or contract instance for a specific player, supporting multiplayer scenarios.

getWalletClient :

getPlayerContract :

Implement Contract Interaction Methods

reset

Resets the Walnut for the next round. The reset is player-specific and resets the shell and kernel values.

shake

Allows a player to shake the Walnut, incrementing the kernel. This supports multiplayer scenarios where each player’s shakes impact the Walnut. Uses signed writes.

hit :

A player can hit the Walnut to reduce the shell’s strength. Each hit is logged for the respective player.

look :

Reveals the kernel for a specific player if they contributed to cracking the shell. This ensures fairness in multiplayer gameplay. Uses signed reads.

Hook that consumes the ShieldedWalletProvider context. Returns the shielded public client, wallet client, connected address, error state, and a loaded flag indicating whether initialization is complete.

Return Type

Usage

Basic

Handling loading state

The loaded flag is false until the shielded clients have been fully initialized. Use it to avoid rendering components that depend on the wallet client before it is ready.

Error handling

If initialization fails (for example, the node is unreachable or the wallet connector is incompatible), the error field contains the error message.

Accessing clients for direct seismic-viem calls

The returned publicClient and walletClient are full seismic-viem client instances. You can use them directly for operations not covered by the higher-level hooks.

See Also

• -- Context provider that supplies the shielded clients

• -- Create a contract instance using the wallet client

• -- Send encrypted write transactions

Instantiation

The ABI works the same as in web3.py. If your contract uses shielded types (suint256, sbool, saddress), the SDK remaps them to their standard counterparts for parameter encoding while keeping the original shielded names for function selector computation.

Namespaces

ShieldedContract gives you five namespaces:

Write namespaces accept optional keyword arguments for transaction parameters:

Example Contract

All code snippets in the Python SDK docs reference the interface below.

Token examples use the real / ERC20 specs (balanceOf, transfer, approve, allowance, totalSupply, etc.).

Encoding calldata manually

If you need to encode calldata outside of a contract call — for example, to pass it to the — you can use . This computes the function selector using the original shielded type names (like suint256) but encodes the parameters using standard types (like uint256):

seismic-react provides pre-configured chain objects compatible with RainbowKit's getDefaultConfig. Each chain wraps a seismic-viem chain definition with RainbowKit metadata (icon, etc.).

Import

Available Chains

Usage with RainbowKit

Choosing a Chain

Relationship to seismic-viem Chains

Each chain export is a thin wrapper around the corresponding seismic-viem chain object. The wrapper adds RainbowKit-specific metadata (such as iconUrl) while preserving all underlying chain properties -- chain ID, RPC URLs, native currency, block explorers, and transaction formatters.

Pages

See Also

• - Provider that accepts chain config

• - RainbowKit and wallet setup guides

• - Package setup

Protocol constant representing the transaction type byte for Seismic custom transactions.

Overview

SEISMIC_TX_TYPE is the EIP-2718 transaction type identifier used by Seismic's custom transaction format. This byte prefixes all serialized Seismic transactions.

Value

Definition

EIP-2718 Context

EIP-2718 introduced typed transaction envelopes to Ethereum. Transaction types are identified by a single byte prefix:

Transaction Format

A serialized Seismic transaction has the format:

Where 0x4A is the SEISMIC_TX_TYPE prefix.

Protocol Notes

• The SDK automatically sets this type for all shielded writes

• Seismic nodes recognize and process transactions with this type

• Standard Ethereum nodes will reject transactions with unknown types

See Also

• - Seismic transaction structure

• - Transaction signing

• - Chain configuration with chain IDs

In this chapter, you’ll write tests to verify that the Walnut contract behaves as expected under various scenarios. Testing ensures the functionality, fairness, and access control mechanisms of your contract work seamlessly, particularly in multi-round gameplay. Estimated Time: ~15 minutes.

Getting Started

Open packages/contracts/test/Walnut.t.sol. This is where you’ll write all the test cases for the Walnut contract. Start with the following base code:

Prerequisites

Hook that creates a ShieldedContract instance from seismic-viem's getShieldedContract. Provides a contract object with type-safe methods for both shielded writes and signed reads.

Config

Hook for performing signed reads -- authenticated eth_call requests where the caller proves their identity. This allows contracts to return caller-specific shielded data (for example, a balance that depends on msg.sender).

Synchronous contract wrapper for read-only transparent access to Seismic contracts.

Overview

PublicContract provides a simplified interface for reading public contract state without requiring encryption or a private key. It exposes only the .tread namespace for standard eth_call operations. Use this class when you only need to read public contract data and don't need shielded operations.

Chain configuration for connecting to a locally-running Seismic Anvil (Sanvil) instance. sanvil is a RainbowKit-compatible chain object pre-configured for the default Sanvil endpoint.

Configuration