Sending a Transaction

Once a dApp is connected, it can prompt the user to send a transaction with eth_sendTransaction.

const provider = window.starkey?.ethereum ?? window.ethereum
 
const txHash: string = await provider.request({
  method: 'eth_sendTransaction',
  params: [
    {
      from: accounts[0],
      to: '0x709979...9B685',
      value: '0x2386f26fc10000', // 0.01 ETH, in wei, hex-encoded
    },
  ],
})

Returns: Promise<string> — the transaction hash, resolved as soon as the user approves and the node accepts the transaction. This does not wait for the transaction to be mined — see Waiting for a receipt below.

eth_sendTransaction(params) — full signature

interface TransactionParams {
  from: string // sender address, must match the connected account
  to: string // recipient address, or a contract address when calling a method
  value?: string // hex-encoded wei; omit or '0x0' for a contract call with no ETH transfer
  data?: string // hex-encoded calldata for a contract call
  gas?: string // hex-encoded gas limit; StarKey estimates one if omitted
  gasPrice?: string // hex-encoded, legacy (pre-EIP-1559) gas pricing
  maxFeePerGas?: string // hex-encoded, EIP-1559 gas pricing
  maxPriorityFeePerGas?: string // hex-encoded, EIP-1559 gas pricing
}

Omit gas/gasPrice/maxFeePerGas/maxPriorityFeePerGas to let StarKey estimate and let the user adjust them in the confirmation UI — only set these explicitly when your dApp needs precise control (e.g. a known gas-intensive call).

To call a contract method instead of a plain transfer, ABI-encode the call as data and leave value unset:

const txHash = await provider.request({
  method: 'eth_sendTransaction',
  params: [
    {
      from: accounts[0],
      to: contractAddress,
      data: encodedFunctionCall, // 0x-prefixed calldata
    },
  ],
})

Waiting for a receipt

The raw provider doesn’t expose a built-in “wait for confirmation” call — poll eth_getTransactionReceipt until it resolves with a non-null result:

const receipt = await provider.request({
  method: 'eth_getTransactionReceipt',
  params: [txHash],
})
// null until the transaction is mined

interface TransactionReceipt {
  transactionHash: string
  status: '0x1' | '0x0' // 0x1 success, 0x0 reverted
  blockNumber: string
  gasUsed: string
}

status: '0x0' means the transaction was mined but reverted on-chain — this is not a JavaScript exception, check status explicitly.

Error handling

• eth_sendTransaction rejects with code: 4001 if the user declines the confirmation prompt — wrap the call in try/catch.
• A resolved transaction hash does not mean the transaction succeeded — poll for the receipt and check status before treating it as confirmed. See Errors.

Notes

• from must match the currently connected account — see Establish a Connection.
• Read the target chain with eth_chainId before sending, rather than assuming which network the wallet is on — StarKey supports Ethereum, Base, Polygon, and Monad Testnet.

Best practices

• Let StarKey estimate gas/fee fields unless your dApp has a specific reason to override them.
• Show an optimistic “pending” state immediately after the hash resolves, then confirm it once the receipt’s status comes back 0x1.

Related pages

• Establish a Connection
• Network
• Signing Messages
• Errors