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.
- The SDK prepares the request with OMS.
- The preparation response either marks it sponsored or supplies fee options.
- The SDK executes the prepared transaction with the applicable fee selection.
- By default, the SDK polls until status resolves or the polling timeout expires.
Send native value
Values are non-negative raw base-unit integers. UseparseUnits 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
UsecallContract when you have a function name and argument values rather than encoded calldata:
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
UsesendSolanaTransfer 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.
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
UsesendTronTransaction 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:
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:
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. Returnnull 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
FeeOptionSelectionfrom the available options. - No fee options, or a selector returning
null: the SDK fails before execution.
FeeOptionWithBalance values:
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:
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. UsewaitForStatus = false when you need the SDK to return after execute instead of canceling a waiting coroutine.
Handle three outcomes:
OMSWalletTransactionExceptionwithcode = TransactionExecutionUnconfirmedand atxnId: the SDK cannot tell whether the transaction was submitted. Check its status with thetxnIdbefore sending it again.OMSWalletRequestExceptionwithcode = RequestFailedand notxnId: 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?.causegives the wallet API’s reason when it has one. Fix the cause, then prepare the transaction again.OMSWalletSessionExceptionwithcode = SessionExpired: the session ended and nothing was submitted. Sign the user in again.
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.