sendTransaction and callContract require an active wallet session. They accept different transaction inputs but run the same lifecycle.
Follow the transaction lifecycle
- The SDK prepares the transaction for the selected
Network. The default mode isTransactionMode.Relayer. - OMS marks the prepared transaction as sponsored or returns fee-token options. Sponsored transactions need no fee selection. Unsponsored transactions need one option.
- The SDK executes the prepared OMS transaction and receives its latest status.
- Unless
waitForStatusisfalse, the SDK polls for a transaction hash or terminal status and returns the latest result.
Choose a transaction input
UsesendTransaction for a native transfer, pre-encoded calldata, or a viem-compatible ABI call. Use callContract when your input is a method signature plus typed argument objects.
value amounts are bigint values in raw base units. A calldata or ABI transaction can also include value. All forms require a recipient or contract address; these methods do not expose a recipient-free contract deployment input.
Select fees accurately
Testnet transactions are sponsored and do not call your selector. On mainnet, a preparation withsponsored: true also sends no fee option and does not call your selector.
For an unsponsored transaction:
- With no selector, the SDK chooses the first fee option returned by OMS. It does not check whether the wallet can afford that option.
FeeOptionSelector.firstAvailablequeries indexer balances and chooses the first returned option whose raw balance covers its raw fee value.- A custom selector receives the same enriched
FeeOptionWithBalance[]and returns one option’sselection.
firstAvailable returns no selection when balance data is unavailable or no option is affordable. The transaction then fails before execution with a fee-selection error.
feeOption, its ready-to-return selection, and optional balance fields. feeOption.value and availableRaw are raw integer strings. available is formatted with known token decimals. balance, available, availableRaw, and decimals can be undefined when the indexer or token metadata cannot supply them.
Interpret the result
SendTransactionResponse contains:
txnId: the OMS transaction ID returned during preparation. Keep it for later status checks.status: the latest OMS status:quoted,pending,executed,failed, orunknown.txnHash: the EVM transaction hash when OMS has one. It is optional.statusResolution:resolved,timed-out, ornot-requested.
resolved means polling observed executed, failed, or a transaction hash. It does not mean the chain has reached application-specific confirmation depth. A response can have status: 'pending' and statusResolution: 'resolved' once a hash exists.
timed-out returns the last observed status without treating the transaction as failed. The transaction can still progress after the SDK returns.
Control status waiting
Waiting is enabled by default. The SDK performs a status request immediately, waits 400 ms between early polls, then 2 seconds between later polls, with a 60-second total timeout. These defaults correspond to:txnHash. Use getTransactionStatus until OMS returns the status your application requires.
Handle uncertain execution
If the execute request fails after preparation, the SDK throwsOMS_TRANSACTION_EXECUTION_UNCONFIRMED and includes txnId. The SDK cannot confirm whether submission occurred, so do not blindly send an identical transaction again.
If execution succeeds but automatic status lookup fails, the SDK throws OMS_TRANSACTION_STATUS_LOOKUP_FAILED with txnId. Retry getTransactionStatus for that ID. An onchain failed status is returned as a normal transaction result rather than thrown as an SDK request error.