Sabitlenmiş Tweet
The Mechanism of sUSDC on Seismic under the SRC20 Standard
sUSDC can be understood as a version of USDC implemented as a shielded token on Seismic. Instead of operating like a regular ERC20 token, where wallet balances, transfer amounts, and allowances can be publicly observed, sUSDC uses Seismic SRC20 standard to hide sensitive on-chain data.
One important point to note is that Seismic SRC20 should not be confused with SRC-20 on Bitcoin Stamps. In the Bitcoin ecosystem, SRC-20 is a token standard based on Bitcoin Stamps. Meanwhile, on Seismic, SRC20 refers to a type of private ERC20 token running on Seismic’s EVM-compatible blockchain. Seismic describes SRC20 as a private ERC20 token where balances, transfer amounts, and allowances are shielded from external observers.
1. Core Difference: uint256 → suint256
mapping(address => suint256) balanceOf;
This means that anyone can read the balance of any wallet.
With SRC20 on Seismic, the value is changed into a shielded type:
Only changing from uint256 to suint256 may look simple, but the underlying mechanism changes significantly. According to Seismic, when the compiler detects shielded types such as suint256, it uses CSTORE/CLOAD instead of SSTORE/SLOAD. This marks the storage slot as private. As a result, when external observers read the state, block data, or transaction trace, they only see 0x00...0 instead of the real value.
2. sUSDC Transfer Flow
When a user transfers sUSDC, the mechanism can be understood as follows:
- The user calls the transfer(to, amount) function.
- The amount is a suint256, so it is processed as private data.
- The transaction is sent as Seismic transaction type 0x4A.
- The calldata is encrypted before it leaves the user’s device.
- The Seismic node running inside a TEE decrypts the calldata within a secure environment.
- The smart contract checks the balance, subtracts the amount from the sender, and adds it to the receiver.
- The result is stored in shielded storage.
External observers can only see that a transaction occurred, but they cannot see the exact amount of sUSDC transferred.
According to Seismic’s documentation, transaction type 0x4A encrypts calldata before broadcasting. The node decrypts it inside the TEE, executes the transaction, and writes the result into shielded storage. Plaintext calldata does not appear in the mempool, block data, or transaction trace.
3. How Users View Their Own Balance
Because balanceOf is no longer public, external users cannot call balanceOf(address) like they normally would with an ERC20 token. Instead, Seismic uses a mechanism called signed reads.
A signed read allows users to sign a read request to prove that they are the true owner of the wallet. The contract can check msg.sender, then return the balance only to the correct user. The returned result is also encrypted for the caller, so other parties cannot read the response.
4. The Role of TEE in Securing sUSDC
Seismic does not only encrypt data at the smart contract level. The Seismic network runs nodes inside Trusted Execution Environments, specifically referring to Intel TDX in its documentation. A TEE creates a secure execution environment that prevents code and data inside the enclave from being directly observed by node operators or the host operating system.
For sUSDC, this means that:
- calldata is encrypted before being sent;
- the node only decrypts it inside the TEE;
- balances and amounts are processed through shielded execution;
- private storage is written using CSTORE;
- public RPC cannot directly read shielded storage slots.
@SeismicSys @xealistt @NoxxW3
English
