Transactions, fees & receipts
Get a current fee quote
Section titled “Get a current fee quote”Use eth_gasPrice rather than hardcoding 1. V2 fee pricing is dynamic; older wallet versions that sign a fixed gas price can fail admission under load.
Fee distribution and fee pricing are separate concerns. The V1-compatible V2 implementation credits fees to the configured collector; that does not make the quoted gas price fixed. Confirm the deployed release before relying on implementation-specific behavior.
Submission is admission, not finality
Section titled “Submission is admission, not finality”Before accepting a transaction, V2 checks canonical encoding and signatures, the network, balance, nonce, fee eligibility, intrinsic gas and applicable block/protocol limits.
| Result | What to do |
|---|---|
| Insufficient balance | Account for value plus the maximum applicable fees. |
| Stale nonce | Read the account state and coordinate concurrent senders. |
| Fee too low | Obtain a fresh fee quote and sign again. |
| Intrinsic gas too low | Re-estimate using the actual call data. |
| Gas exceeds the limit | Check the deployed block limit and active protocol cap. |
| Hash returned | Track the transaction; do not report it as finalized yet. |
Future nonces can wait behind a gap. Acceptance does not reserve every pending spend or guarantee later inclusion. A same-nonce replacement must satisfy the pool’s replacement rules.
Track the result
Section titled “Track the result”Save the transaction hash, then request eth_getTransactionReceipt or the matching Tolar receipt method. For Ethereum receipts, inspect status: 0x1 indicates successful execution and 0x0 indicates failed execution.
A failed or reverted execution can still consume gas. A null lookup may mean not yet included, unknown to this node, or unavailable due to retention; use the network and node context to distinguish them.
Simulate, but still handle failure
Section titled “Simulate, but still handle failure”Simulation does not update live state and cannot guarantee a later transaction’s result. State can change between simulation and execution. Always handle submission errors, timeouts, missing receipts and execution failure separately.
See RPC compatibility for request conventions. For release-specific limits or replacement behavior not covered here, contact your node operator or Tolar support.