Skip to main content
This walkthrough uses a local private key from an imported mnemonic so every step is reproducible. In production, you’ll keep the same prepare → sign → broadcast shape, but sign with your existing key-management system (KMS, HSM, custodian) instead of the SDK’s private-key helper. See Bring your own signer below.
1

Initialize

2

Import wallet and get Ethereum account

3

Read USDT balance on Ethereum

Response fields
  • amount is human-readable (decimals applied)
  • smallestUnit is the raw token integer balance
4

Prepare USDT transfer (fees, nonce, calldata, simulation)

This stage produces a signing payload that your UI can display and confirm.Server side actions
  • Resolve nonce if not provided
  • Build ERC20 calldata
  • Select fee mode (EIP1559 by default, legacy fallback when required)
  • Run a simulation check
Client side actions
  • Display fee information to the user
  • If user confirms, sign the payload locally using the SDK signer
If the simulation fails, prepareTransferSign throws a structured SDK error with backend code SIMULATION_FAILED.
5

Sign transaction

In this walkthrough, signing happens entirely on the client using a raw private key - this is the SDK’s External Signing (BYO) path, useful for tests and integration spikes. For MPC threshold signing, use the WalletSuite MCP server instead.
  • No network requests are made during signing
  • Private keys are provided by the client application at call time
  • WalletSuite SDK does not persist keys
The SDK’s signEvmTransaction / signTronTransaction helpers accept a raw private key — useful for tests and integration spikes. If your signer lives in a KMS, HSM, or custodian, skip these helpers: pass prepared.data to your signer, take the signed hex back, and continue to the broadcast step. sendSignedTransaction accepts any valid signed hex. See Security Best Practices → Key Management for backend key-storage guidance.
6

Broadcast signed transaction

7

Check transaction status

The SDK does not provide any waiting or polling helpers.After broadcasting the transaction, the client application is responsible for deciding when and how to check the status. A common approach is to wait ~10 seconds (Ethereum) or few seconds other chains before the first check and then poll periodically until a terminal state is reached.
8

Read USDT balance again

Notes
  • Balance updates depend on chain finality and node/indexer freshness.
  • If you transfer the full balance, account level gas costs are paid in ETH and do not affect USDT amount.
Common failure modes — Simulation failed.
  • Typical causes: insufficient token balance, invalid recipient, token restrictions
  • Expected SDK error: a structured error with backend code SIMULATION_FAILED

Bring your own signer

The prepare-sign → broadcast surface of the SDK is signer-agnostic. prepareTransferSign returns a typed unsigned payload and sendSignedTransaction accepts any valid signed hex — how you sign in between is up to you.

Local private key

For tests, integration spikes, or cases where the private key legitimately belongs in your application’s process. sdk.transfer() handles the whole prepare → sign → broadcast flow in one call:
Use the step-by-step flow above when you need to display fee details to the user before signing, or when you want to split preparation and signing across processes.

External signer (KMS, HSM, custodian)

The production pattern, equivalent to External Signing in the architecture model. Prepare with sdk.api.prepareTransferSign, hand the payload to your existing signer, broadcast with sdk.api.sendSignedTransaction. The SDK never sees the key.
See Add Wallet Operations to Your Application for a worked backend-integration example.