Transaction Best Practices

Recommendations

Fetching

Check Transaction Type

Always verify the OPNetType field before casting a transaction to a specific interface to avoid runtime errors.

Handle Not Found

Transactions may not exist if the hash is invalid, or may still be pending in the mempool. Wrap lookups in error handling to manage these cases gracefully.

Check Revert Status

Always inspect the revert field to determine whether a transaction failed and to retrieve the failure reason.

Use Block Prefetch

Set prefetchTxs to true when fetching blocks that require transaction data to avoid additional round trips for each transaction.

Cache Confirmed Transactions

Confirmed transactions are immutable and can be cached indefinitely to reduce redundant API calls.

Receipts

Decode Events with ABI

Use contract ABIs for proper event decoding to access typed properties and avoid manual parsing of raw event data.

Handle Missing Events

Not all transactions emit events. Check for the presence of events before iterating to avoid errors on transactions with no event output.

Verify Proofs

For critical operations, verify receipt proofs to ensure the execution result has not been tampered with.

Cache Receipts

Receipts are immutable once the transaction is confirmed and can be cached indefinitely to reduce redundant API calls.

Challenge

Cache Challenges

Challenges can be cached for short periods to reduce API calls, but should be refreshed before expiration to ensure validity.

Handle Expiration

Challenges expire after a defined period. Always be prepared to fetch a fresh challenge if the current one has become invalid.

Monitor Difficulty

Track challenge difficulty to estimate solving time and plan transaction submission accordingly during periods of high network activity.

Include in Transactions

The library handles challenge inclusion automatically when sending transactions. Manual challenge management is only required for advanced use cases.

Error Handling

Handle challenge-related errors gracefully, including expiration and difficulty changes, to ensure reliable transaction submission.

Broadcasting

Validate Before Broadcast

Ensure transactions are properly signed and formatted before submitting to avoid rejected broadcasts and wasted network requests.

Handle Errors Gracefully

Different errors require different handling strategies. Distinguish between permanent failures like double spends and temporary issues that may resolve with retries.

Retry on Network Errors

Network issues are often temporary. Implement retry logic with exponential backoff for transient failures while avoiding retries for permanent errors.

Batch Wisely

Avoid broadcasting too many transactions at once. Respect the 25 transaction limit per package and consider network capacity when submitting large batches.

Verify Propagation

Confirm transactions are visible on the network after broadcast. A successful broadcast response does not guarantee network-wide propagation.

Track Peer Count

Monitor the peer count returned in broadcast results. Higher peer counts indicate better transaction propagation across the network.