arrow-right-arrow-leftTransfers

Shielded transfer patterns for SRC20 tokens

Send SRC20 tokens privately using shielded transfers, approvals, and transferFrom patterns.

Overview

SRC20 transfers work similarly to ERC20 transfers, but with calldata encryption to hide amounts from observers. The SeismicSignedProvider handles encryption automatically when you mark a transaction with .seismic().

Prerequisites

All transfer examples require a SeismicSignedProvider and the SRC20 interface definition:

use seismic_prelude::foundry::*;
use alloy::sol;
use alloy::providers::Provider;
use alloy::sol_types::SolCall;
use alloy_primitives::{Address, U256};
use alloy_rpc_types_eth::TransactionRequest;
use alloy_signer_local::PrivateKeySigner;

sol! {
    interface ISRC20 {
        function balanceOf(address account) public view returns (suint256);
        function transfer(address to, suint256 amount) public returns (bool);
        function approve(address spender, suint256 amount) public returns (bool);
        function allowance(address owner, address spender) public view returns (suint256);
        function transferFrom(address from, address to, suint256 amount) public returns (bool);

        event Transfer(address indexed from, address indexed to, suint256 value);
        event Approval(address indexed owner, address indexed spender, suint256 value);
    }
}

Direct Transfer

The simplest pattern: transfer tokens directly from your wallet to a recipient.

Approval + TransferFrom

The two-step pattern for delegated transfers: first approve a spender, then the spender calls transferFrom.

Step 1: Owner Approves Spender

Step 2: Spender Executes TransferFrom

Check Balance Before Transfer

Always verify sufficient balance before sending a transfer to avoid wasted gas:

Full Approve-Check-Transfer Workflow

A complete workflow showing approval, allowance check, and delegated transfer:

Batch Transfers

Send tokens to multiple recipients in sequence:

Notes

  • All transfer amounts are encrypted via the .seismic() builder

  • The SeismicSignedProvider filler pipeline handles calldata encryption automatically

  • Transaction receipts are returned as normal -- only the calldata is encrypted

  • transferFrom requires prior approval from the token owner

  • Each transaction has its own encryption nonce managed by the filler pipeline

Warnings

  • Insufficient balance -- The transaction will revert on-chain if the sender does not have enough tokens. Check the balance first to avoid wasted gas.

  • Insufficient allowance -- transferFrom reverts if the spender's allowance is less than the transfer amount

  • Nonce management -- When sending multiple transactions rapidly, the NonceFiller handles nonce assignment. Await each transaction's receipt before sending the next to avoid nonce conflicts.

See Also

Last updated