Full shielded write lifecycle from deployment to receipt verification
This example demonstrates the full lifecycle of a shielded write: deploy a contract (transparent), send a shielded write (encrypted setNumber), verify the result with a signed read (encrypted isOdd), and inspect the receipt type.
Prerequisites
# Set environment variablesexportPRIVATE_KEY="0xac0974bec39a17e36ba4a6b4d238ff944bacb478cbed5efcae784d7bf4f2ff80"exportRPC_URL="https://gcp-1.seismictest.net/rpc"
The SeismicSignedProvider is created with a wallet and RPC URL. During construction, it generates an ephemeral secp256k1 keypair and fetches the TEE public key from the node. Both are cached for all subsequent operations.
2. Contract deployment (transparent)
Contract deployment uses TxKind::Create and does not call .seismic(). Create transactions cannot be seismic -- the Seismic protocol does not support encrypting deployment bytecode.
3. Shielded write
The setNumber call is encoded using the sol!-generated struct, wrapped in a SeismicTransactionRequest with .seismic(), and sent via send_transaction(). The filler pipeline automatically encrypts the calldata.
4. Receipt inspection
Seismic transactions produce a SeismicReceiptEnvelope::Seismic receipt. You can pattern-match on the receipt's inner envelope to confirm the transaction was processed as a shielded (type 0x4A) transaction.
5. Signed read
The isOdd() view function is called via seismic_call(), which encrypts the calldata, sends a signed eth_call, and decrypts the response. The result is ABI-decoded into the return type.
Expected Output
Error Handling Variant
For production code, wrap each step with error handling: