For the complete documentation index, see llms.txt. This page is also available as Markdown.

SeismicSignedProvider

Full-featured Seismic provider with wallet integration, encryption, and response decryption

Full-featured provider with wallet integration, automatic calldata encryption, and response decryption.

Overview

SeismicSignedProvider<N: SeismicNetwork> is the primary provider type for interacting with Seismic nodes. It wraps an Alloy provider with a filler chain that automatically:

  1. Signs transactions with the attached wallet

  2. Populates nonce, chain ID, and Seismic-specific fields

  3. Encrypts calldata using AES-GCM with an ECDH shared secret

  4. Decrypts seismic_call / seismic_call_raw responses using the same shared secret

At creation time, the provider generates a provider-scoped secp256k1 keypair (the "provider keypair"), fetches the TEE public key from the node, and caches both for all subsequent operations. The provider keypair lives for the lifetime of the provider, not per-message.

Construction

All signed providers are created via SeismicProviderBuilder:

use seismic_prelude::client::*;
use seismic_alloy_network::reth::SeismicReth;

let signer: PrivateKeySigner = "0xYOUR_PRIVATE_KEY".parse()?;
let wallet = SeismicWallet::<SeismicReth>::from(signer);

HTTP

WebSocket

With Pre-fetched TEE Pubkey

If you already have the TEE public key, skip the initial RPC call. connect_http_with_tee_pubkey is synchronous; connect_ws_with_tee_pubkey is async because of the WS handshake.

connect_http() and connect_ws() are async because they make an RPC call to seismic_getTeePublicKey. Use connect_http_with_tee_pubkey() or connect_ws_with_tee_pubkey() to supply a pre-fetched key and avoid this call.

Local Development with sanvil

Use .foundry() to select the SeismicFoundry network type:

Contract Interaction

The primary way to interact with contracts is via the ShieldedCallBuilder, which integrates with Alloy's #[sol(rpc)] macro. Functions with shielded parameters (e.g., suint256) auto-encrypt. For functions without shielded parameters, use .seismic() to opt in:

Per-Call Overrides (ShieldedCallBuilder)

Customize encryption parameters on individual calls via ShieldedCallBuilder methods:

Method
Description

.expires_at(block)

Set transaction expiration block number

.recent_block_hash()

Pin to a specific chain state

.encryption_nonce()

Override AEAD nonce (testing only)

.eip712()

Use EIP-712 typed data signing (browser wallets)

.eip712() lives on ShieldedCallBuilder only. SecurityParams holds the first three fields (expires_at_block, recent_block_hash, encryption_nonce) and is applied via .with_params(...) on the builder or passed to the provider-level _with methods.

For provider-level calls, use SecurityParams with the _with methods from SignedProviderExt:

EIP-712 (Browser Wallet Compatibility)

For wallets that cannot sign custom RLP-encoded transaction types (e.g., MetaMask):

Low-Level Trait Methods

For cases where the #[sol(rpc)] pattern doesn't fit, use SignedProviderExt (for shielded operations) and SeismicProviderExt (for transparent operations) directly:

Via Standard Alloy Provider

All standard Alloy provider methods are available:

Filler Chain

Listed in operational order — what actually happens to the transaction as it's prepared:

Step
Filler
Purpose

1

NonceFiller + ChainIdFiller

Composed together; fetch and set the nonce and chain ID in parallel

2

SeismicElementsFiller

Populates Seismic-specific fields (encryption nonce, TEE pubkey, recent block hash, expiry) and encrypts the calldata

3

SeismicGasFiller

Signs the encrypted tx and calls eth_estimateGas against the RPC so the node can authenticate msg.sender

4

WalletFiller

Produces the final signature over the fully-filled transaction

In source (crates/provider/src/builder.rs) the chain is composed Wallet → (Nonce + ChainId) → SeismicElements → Gas. That's the chain-composition order, not the execution order: each filler's status() gate decides when it fires, and WalletFiller only fires once everything else has run.

Examples

Shielded Write

Signed Read

Pre-fetched TEE Pubkey

How It Works

  1. Construction — Generates a provider-scoped secp256k1 keypair (the "provider keypair") and fetches (or accepts) the TEE public key. Computes the ECDH shared secret between the provider key and the TEE pubkey.

  2. Transaction building — The filler chain populates all transaction fields: nonce, chain ID, Seismic elements (encryption nonce, block hash, expiry), and gas.

  3. Encryption — Before sending, calldata is encrypted using AES-GCM. The encryption key is derived from the ECDH shared secret. Additional Authenticated Data (AAD) binds the ciphertext to the transaction context.

  4. Sending — The encrypted transaction is signed by the wallet and sent to the node.

  5. Response decryption — For seismic_call() / seismic_call_raw() requests, the response is decrypted using the same ECDH shared secret.

Notes

  • The provider keypair is generated once at provider creation and reused for all operations (it is provider-scoped, not per-message)

  • The TEE public key is cached after the initial fetch

  • All standard Alloy Provider methods work unchanged — only transactions with calldata are encrypted

  • Both HTTP and WebSocket transports are supported

See Also

Last updated