Define three results
Delivery asks when a submission path accepted or forwarded a signed transaction. Inclusion asks whether it reached a block. Execution asks whether its instructions succeeded. A sender can return promptly while the transaction later expires, and an included transaction can fail execution. A fair comparison preserves all three results.
Create a transaction journal
signature, payload_class, recent_blockhash, last_valid_block_height
send_start_ns, acknowledgement_ns, endpoint, error
first_observed_slot, confirmation_status, execution_error
expired_or_unresolved, measurement_windowKeep sensitive signing material out of the journal. Record enough transaction context to explain contention and simulation errors without exposing private keys. Use a local monotonic clock for elapsed receive timing.
Control the experiment
- Use equivalent valid workloads, fee policy and observation conditions.
- Record preflight settings and transaction expiry data consistently.
- Observe statuses independently from the sending endpoint when possible.
- Score inclusion and execution across all submitted attempts, keeping unresolved cases visible.
Avoid misleading duplicates
Sending the identical signed transaction through two paths can help delivery robustness, but only one chain outcome follows. That outcome alone cannot identify which path caused inclusion. A benchmark needs a design that accounts for this attribution problem. Reconcile status before rebuilding an expired transaction into a new signed operation. Publish sample size, failure classes and expiry rules with the result, and avoid promising a landing-rate improvement from a lower acknowledgement time.