Overview
DynamicEvmWalletClient::sendTransaction signs an EIP-1559 transaction with the MPC ceremony and broadcasts the result via JSON-RPC in one call. Returns the transaction hash as a 0x-prefixed hex string.
sendTransaction is the recommended path for most apps. Reach for signTransaction only if you need the signed RLP out-of-band — co-signing, custom relayers, or assembling the raw tx yourself.
Prerequisites
- Created an EVM wallet
- A JSON-RPC endpoint for the target chain
Sign + Broadcast in One Call
signTransaction with your own pooled Web3j instance instead.
Broadcast a Pre-Signed Transaction
When the transaction is signed elsewhere — for example on a client via the embedded wallet — and the server only needs to relay it, use the staticEvmRpc.sendRawTransaction. It broadcasts an already-signed transaction via eth_sendRawTransaction with no wallet, MPC ceremony, or key shares required — just the serialized signed transaction and an RPC URL:
sendTransaction uses internally after signing. It’s the right fit for a sign-on-client / broadcast-on-server split: the client signs with its embedded wallet and your backend only relays the signed payload to the network.
Building the Nonce
Fetch the current pending nonce from your RPC before each send — concurrentsendTransaction calls against the same wallet without nonce coordination will conflict:
Gas Estimation
EIP-1559 fees vary block to block — query the latest base fee + tip estimate, then bake them into the transaction:Common Transaction Types
ETH Transfer
Contract Interaction
Error Handling
sendTransaction returns the JSON-RPC error verbatim when the broadcast itself fails (e.g. nonce too low, replacement transaction underpriced) — match on the error message or retry with a refreshed nonce.
Next Steps
- Sign transactions — get the signed RLP without broadcasting
- Sign messages
- Sign typed data (EIP-712)
- Delegated access