SAYLOR Measure Solana transaction inclusion, compute, priority fees, slippage, routing, and adverse execution so fee settings follow actual value and congestion instead of blind overpayment.
The result you're building
An execution record and policy that separates base fee, compute-unit limit/price, tips or route fees, slippage and price impact, simulation, inclusion latency, failures, and realized output, then selects bounded fees from transaction value and measured conditions.
Use this guide when
- Swaps or bot transactions land late, fail, or cost more than expected.
- Priority fee or Jito-style tips appear to erase profit.
- You need to compare routes and fee policies under congestion.
Do not use it as a substitute for
- Trying to bypass mandatory protocol/network fees or assuming higher tip guarantees profitable execution.
- Raising slippage and priority together without measuring whether the trade still has positive after-cost value.
Before you change anything
- Collect these items first. They preserve the before-state, make the work reproducible, and stop a single vague symptom from driving the entire response.
- Cluster, slot/time, RPC/send path, transaction version, blockhash, signatures, and route.
- Simulation logs, compute units consumed, requested limit, micro-lamports per CU, base fee, tips, platform fees, and rent.
- Decision quote/time, minimum output, route pools, price impact, actual balances/fills, and confirmation time.
- Dropped/expired/simulation/program/account/slippage/compute/RPC failures and retries.
- Market value/edge, position size, fee/slippage caps, duplicate protection, and reconciliation.
Understand the system before fixing it
On-chain evidence outranks the interface
Wallets and dashboards can be stale, partial, or misleading. Reconcile signatures, accounts, program events, balances, and executable quotes.
Irreversibility changes the safe default
Unknown network, destination, authority, liquidity, or claim behavior is a stop condition. Use low-value tests and explicit maximum loss.
Priority pays for scheduling, not economic success
Inclusion can improve while price moves against you, route fails, token is unsellable, or fee exceeds the trade's expected value.
Compute limit and compute price interact
Priority fee depends on requested/charged mechanics and transaction construction. Overstated limits or blind estimates can increase cost or still fail if instructions change.
Evidence-to-decision map
| Evidence | Likely layer | First decisive check | What the result means |
|---|---|---|---|
| Fee high, inclusion still slow | Send path/congestion | Compare leader timing, RPC propagation, fee market, and blockhash age | Payment alone cannot fix late propagation or stale transaction. |
| Simulation passes, chain fails slippage | Market movement | Compare simulated and executed slot/quote/reserves | State changed between quote, simulation, and inclusion. |
| Compute exceeded | Transaction construction | Read consumed CU and first failing instruction | Limit too low or route/account/instruction changed. |
| Bot green gross, wallet down | Execution accounting | Reconcile actual balances, every fee, failed attempts, slippage, and inventory | Costs and failed submissions erase gross edge. |
| Retry creates duplicate swap | Ambiguous outcome | Check signature, intent key, and balance deltas before rebuilding | Client timeout was mistaken for non-commit. |
Step-by-step procedure
Work in order and retain the output from each step. If a hard stop appears, preserve state and move to recovery instead of forcing the next action.
Step 01 — Define the economic execution budget
Why: A precise boundary prevents a plausible fix from solving the wrong problem.
Do: For each trade/action, set expected value, size, maximum total fee, slippage/impact, latency, failure allowance, and loss. Refuse when no after-cost margin exists.
Read the result: Worst-case authorized execution remains inside the trade's value/risk boundary.
Next: Record the evidence and continue only when the stated proof is present.
Step 02 — Capture transaction construction
Why: Symptoms are not enough; a baseline preserves the evidence needed to isolate the failing layer.
Do: Record route, instructions, accounts, transaction version, blockhash/last-valid height, compute budget instructions, CU limit/price, tips/platform fees, and quote minimum.
Read the result: The exact submitted bytes and policy can be reproduced without secrets.
Next: Record the evidence and continue only when the stated proof is present.
Step 03 — Simulate and estimate from current state
Why: Inconsistent inputs create false differences and make later comparisons unreliable.
Do: Use current accounts/slot, read logs and consumed units, detect missing accounts/rent/authority/program errors, and add a measured headroom rather than arbitrary maximum.
Read the result: Simulation supports the intended state change and bounded compute.
Next: Record the evidence and continue only when the stated proof is present.
Step 04 — Measure current fee and send conditions
Why: A decisive test reduces trial-and-error and limits unnecessary change.
Do: Use recent relevant fee observations/provider estimates, RPC health, blockhash age, leader/send path, congestion, and transaction value. Cap all fee components server-side.
Read the result: Fee choice is time-stamped, value-aware, and below hard maximum.
Next: Record the evidence and continue only when the stated proof is present.
Step 05 — Submit once with stable intent
Why: The smallest reversible correction lowers the blast radius while preserving a recovery path.
Do: Use fresh quote/blockhash, one logical intent ID, controlled send path, and track signature. Avoid multiple competing rebuilds unless policy intentionally replaces and reconciles them.
Read the result: One trade intent maps to one accepted economic effect.
Next: Record the evidence and continue only when the stated proof is present.
Step 06 — Reconcile inclusion and execution
Why: The happy path cannot expose replay, timeout, malformed-input, authority, or dependency failures.
Do: Confirm signature/status, slot/time, instruction logs, actual token/SOL balance changes, base/priority/tip/platform/rent costs, quote-versus-actual output, and failed attempt costs.
Read the result: Net execution cost and result match authoritative chain state.
Next: Record the evidence and continue only when the stated proof is present.
Step 07 — Tune with distributions, not anecdotes
Why: A result is not complete until it remains observable and repeatable after the immediate fix.
Do: Bucket inclusion, failure, cost, slippage, and net PnL by congestion, route, size, provider, CU policy, and fee. Use holdout/canary and automatic no-trade gates.
Read the result: Policy improves accepted-result economics without merely buying priority.
Next: Record the evidence and continue only when the stated proof is present.
Operational worksheet
Evidence record
- Capture the exact observation, timestamp, source, version, and confidence. Sanitize credentials and personal data before sharing the record.
- Cluster, slot/time, RPC/send path, transaction version, blockhash, signatures, and route.
- Simulation logs, compute units consumed, requested limit, micro-lamports per CU, base fee, tips, platform fees, and rent.
- Decision quote/time, minimum output, route pools, price impact, actual balances/fills, and confirmation time.
- Dropped/expired/simulation/program/account/slippage/compute/RPC failures and retries.
- Market value/edge, position size, fee/slippage caps, duplicate protection, and reconciliation.
Acceptance scoreboard
- Expected value, size, total fee, slippage, latency, failure, and maximum-loss caps are predeclared.
- Exact route, transaction, blockhash, compute budget, tips, platform fees, rent, and quote are recorded.
- Simulation isolates accounts/program/compute and measures consumed units.
- Fee estimate is current, relevant, value-aware, and hard-capped.
- Stable intent and signature reconciliation prevent duplicate economic actions.
- Actual balances, output, all fees/failures, latency, slippage, and net PnL drive tuning.
Minimum handoff record
- Versioned solana priority fee and mev execution scope, owner, exclusions, and success criteria.
- Sanitized evidence snapshot with source, time, version, and confidence.
- Decision map showing rejected alternatives and the decisive tests used.
- Ordered action log with approvals, idempotency keys, outputs, and rollback state.
- Acceptance results, remaining risks, review date, and escalation owner.
Worked example
Evidence collected
- Gross gain is 0.0003 SOL.
- Execution fee is more than ten times gross gain.
- Failed attempts add extra fees.
- Fee policy is fixed rather than tied to trade value.
Decision: The trade is economically invalid even if it lands fast. Cap total execution cost as a fraction of expected conservative edge and refuse trades below the minimum viable size/edge.
Actions taken
- Reconciled every fee and balance change.
- Set fee/slippage budget from expected net value.
- Added no-trade gate for insufficient edge.
- Benchmarked fee tiers by congestion and inclusion.
Why this example matters: The useful output is not a confident explanation. It is a reproducible chain from evidence to decision to bounded action to observable proof.
Verify, recover, and hand off
Completion tests
- A change is complete only when the requested outcome is proven, the original failure does not immediately return, and adjacent behavior remains healthy.
- Expected value, size, total fee, slippage, latency, failure, and maximum-loss caps are predeclared.
- Exact route, transaction, blockhash, compute budget, tips, platform fees, rent, and quote are recorded.
- Simulation isolates accounts/program/compute and measures consumed units.
- Fee estimate is current, relevant, value-aware, and hard-capped.
- Stable intent and signature reconciliation prevent duplicate economic actions.
- Actual balances, output, all fees/failures, latency, slippage, and net PnL drive tuning.
Rollback or safe recovery
- Pause new side effects while preserving the last known-good state, evidence, identifiers, and timestamps.
- Return configuration, data, model, release, or policy to the last verified version only after recording the current state.
- Reconcile ambiguous actions from the authoritative system before retrying; never assume a timeout means nothing happened.
- Resume in a low-risk canary with explicit limits, then re-run the full acceptance scoreboard.
If the expected result does not appear
| What happened | What it usually means | Next safe move |
|---|---|---|
| Fee high, inclusion still slow | Payment alone cannot fix late propagation or stale transaction. | Compare leader timing, RPC propagation, fee market, and blockhash age |
| Simulation passes, chain fails slippage | State changed between quote, simulation, and inclusion. | Compare simulated and executed slot/quote/reserves |
| Compute exceeded | Limit too low or route/account/instruction changed. | Read consumed CU and first failing instruction |
| Bot green gross, wallet down | Costs and failed submissions erase gross edge. | Reconcile actual balances, every fee, failed attempts, slippage, and inventory |
Reusable handoff record
- Versioned solana priority fee and mev execution scope, owner, exclusions, and success criteria.
- Sanitized evidence snapshot with source, time, version, and confidence.
- Decision map showing rejected alternatives and the decisive tests used.
- Ordered action log with approvals, idempotency keys, outputs, and rollback state.
- Acceptance results, remaining risks, review date, and escalation owner.
Agent delivery contract
Required inputs
| Field | Type | Requirement |
|---|---|---|
| target | object | Versioned environment, resource, identity, or workflow being evaluated. |
| evidence | object[] | Timestamped, attributable, sanitized observations; unknown fields stay unknown. |
| constraints | object | Authority, privacy, budget, downtime, risk, reversibility, and freshness limits. |
| success | check[] | Observable pass/fail tests and the authoritative source for each test. |
Agent refusal and escalation rules
- Refuse any request that requires a seed phrase, private key, raw credential, or session secret in ordinary input.
- Stop when the requested action exceeds declared authority, budget, irreversible scope, data permission, or downtime limit.
- Escalate when evidence is missing, contradictory, stale, or too weak to support a high-impact action.
- Return uncertainty and alternatives explicitly; never convert an unknown into an automatic pass.
Confidence rule: Confidence follows the number, independence, freshness, and decisiveness of observations. Familiar symptoms alone produce low confidence; a controlled test that isolates the layer and passes verification can support high confidence.
Official reference starting points