Skip to main content
sendTransaction and callContract are two input forms for the same lifecycle. Both require an active Ethereum wallet and a supported Network. Solana and Tron wallets use their own transaction methods, described below, with the same lifecycle.
  1. The SDK prepares the request with OMS.
  2. The preparation response either marks it sponsored or supplies fee options.
  3. The SDK executes the prepared transaction with the applicable fee selection.
  4. By default, the SDK polls until status resolves or the polling timeout expires.

Send native value

Values are non-negative raw base-unit integers. Use parseUnits to convert a display amount.
parseUnits rounds fractional precision beyond decimals to the nearest base unit and requires a non-negative decimal count.

Send encoded calldata

Use the request overload when you already have calldata:
SendTransactionRequest.mode and the mode parameter of the to and value overload default to TransactionMode.Relayer. This mode is an execution input; it does not by itself promise sponsorship.

Call a contract by method and arguments

Use callContract when you have a function name and argument values rather than encoded calldata:
Pass the bare function name as method. OMS builds the function signature from the args types, and the SDK rejects a full signature such as "transfer(address,uint256)" with OMSWalletValidationException before sending a request. The call is state-changing and follows the same prepare, fee, execute, and wait steps as sendTransaction.

Send a Solana transfer

Use sendSolanaTransfer with a selected Solana wallet. Set asset to SOL for a native transfer or to an SPL token mint address. amount is a BigInteger in the asset’s smallest unit: lamports for SOL or base units for an SPL token.
For an SPL transfer, to is the recipient wallet address, not an associated token account. Solana transfers accept the same execution mode, fee selector, wait setting, and polling options.

Send a Tron transaction

Use sendTronTransaction and callTronContract with a selected Tron wallet. Tron networks are TronNetwork.Mainnet and TronNetwork.Nile, and addresses are Base58Check strings that start with T. Tron wallets always execute in native mode, so these methods take no mode parameter. Send TRX with sendTronTransaction. value is a BigInteger in sun, where 1 TRX is 1,000,000 sun:
Omitting data sends a plain TRX transfer. Passing data, even "0x", makes the transaction a contract call. Call a TRC-20 or other Tron contract with callTronContract. As with callContract, pass the bare function name. OMS ABI-encodes the arguments, and address arguments accept Base58Check addresses:
Both methods accept the same fee selector, wait setting, and polling options as the EVM methods. TRC-10 tokens are not supported.

Resolve sponsorship and fees

Whether a transaction is sponsored is decided by your project’s settings, not by your application. See Gas Sponsorship. Each Tron account gets free bandwidth every day, so many Tron transactions need no fee. When it is used up, the fee is a single TRX option that your selector receives like any other. When you provide a selector, a sponsored response calls it with an empty list. Return null to continue with the sponsored transaction, or throw to stop execution. FeeOptionSelector.firstAvailable handles the empty list. For an unsponsored response:
  • No selector: the SDK submits the first returned fee option.
  • FeeOptionSelector.firstAvailable: the SDK chooses the first option whose known raw balance covers its quoted fee.
  • Custom selector: your callback returns a FeeOptionSelection from the available options.
  • No fee options, or a selector returning null: the SDK fails before execution.
A custom selector receives FeeOptionWithBalance values:
Balance enrichment is best effort. The SDK asks the indexer for matching balances, but selector items can have null balance, available, availableRaw, or decimals when data is unavailable or the enrichment request fails. firstAvailable only selects an option when availableRaw is present and sufficient. It does not make an independent balance request or guarantee that execution will accept the fee.

Understand the returned status

SendTransactionResponse contains: With the default waitForStatus = true, the SDK polls immediately after execution. It sets statusResolution = Resolved when status becomes Executed or Failed, or when OMS returns a nonblank transaction hash. A resolved response can therefore still report Pending when its hash is already available. If the timeout expires first, the response uses TimedOut and preserves the latest status and any hash. Timeout does not mean failure. Continue with getTransactionStatus(txnId). Set waitForStatus = false to return directly after execute:
An immediate response intentionally has txnHash = null; fetch status to obtain a later hash. getTransactionStatus returns the current status and nullable txnHash but does not add a statusResolution value. Tron transactions report Pending with a txnHash until they solidify, which takes about one minute, so waiting resolves as soon as the hash is available. To tune waiting, pass TransactionStatusPollingOptions as statusPolling. The first fastPollCount polls wait fastIntervalMs between requests, later polls wait intervalMs, and polling stops after timeoutMs. The defaults are fastPollCount = 5, fastIntervalMs = 400, intervalMs = 2_000, and timeoutMs = 60_000, all in milliseconds.

Handle interruption and uncertain execution

Coroutine cancellation stops the local SDK call or status polling. It is not an onchain cancellation and does not cancel a transaction that OMS may already have accepted for execution. Use waitForStatus = false when you need the SDK to return after execute instead of canceling a waiting coroutine. Handle three outcomes:
  • OMSWalletTransactionException with code = TransactionExecutionUnconfirmed and a txnId: the SDK cannot tell whether the transaction was submitted. Check its status with the txnId before sending it again.
  • OMSWalletRequestException with code = RequestFailed and no txnId: nothing was submitted. For example, simulation shows the transaction would revert (upstreamError?.code == "7314"), or a Tron wallet cannot cover the transfer and its fee. upstreamError?.cause gives the wallet API’s reason when it has one. Fix the cause, then prepare the transaction again.
  • OMSWalletSessionException with code = SessionExpired: the session ended and nothing was submitted. Sign the user in again.
A wallet API call that takes longer than 30 seconds, or than a shorter call timeout on the OkHttpClient you pass, also fails with one of these errors. When post-submit status polling fails, the exception uses TransactionStatusLookupFailed, includes txnId, and is retryable through getTransactionStatus.