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

Transfers

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. Functions like transfer, approve, and transferFrom have shielded parameters (suint256), so the sol! macro wraps them in a ShieldedCallBuilder that auto-encrypts — just call .send() directly.

Prerequisites

All transfer examples require a signed provider and the SRC20 interface definition:

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

sol! {
    #[sol(rpc)]
    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 auto-encrypted because transfer, approve, and transferFrom have shielded parameters (suint256)

  • The provider's 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 allowancetransferFrom 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