From a Typed Trading Action to Settlement

At 10:00:04, a trading runtime submits an order. The request times out before an acknowledgement returns. The venue may have accepted it. Retrying immediately risks a duplicate trade; treating the timeout as a rejection risks acting on a portfolio that has already changed.

That blank response is an execution state, not an answer. The runtime has to preserve the request identity, query the venue, reconcile any fill and fee, then decide whether another submission is still valid under the active mandate.

This page follows a typed action through validation, submission, acknowledgement, settlement, and reconciliation. It is the execution spoke in our trading-agent harness and runtime framework. The mandate compiler establishes authority, while the state and memory contract establishes what the agent knew. Execution has a different job: prove what reached the venue and what changed afterward.

Download the execution and reconciliation test matrix or the CSV edition. Four fixtures cover payload binding, request identity, ambiguous timeouts, and acknowledgements. Four more cover partial fills, fees, reconciliation, and controlled recovery.

Evidence boundary: DX Terminal Pro reported 99.9% settlement success for policy-valid submitted transactions in one bounded 21-day onchain deployment. Malformed and policy-rejected outputs sit outside that denominator and were counted separately. The framework below does not establish trading skill, profitability, universal safety, or transfer to another venue.

The Timeout Is an Unknown Order

A transport error says what the client observed. It does not say what the venue did.

The distinction matters because submission crosses an authority boundary. Before submission, the runtime controls the payload. After the venue accepts it, the venue's order record and the resulting ledger become authoritative. A timeout can land between those facts.

We treat that interval as an unresolved order state. New dependent exposure pauses while the runtime queries the venue using a stable client request ID. If the venue returns an order ID, fill, or terminal rejection, the local record advances from evidence. If no authoritative result is available, the uncertainty remains visible rather than being converted into a guessed failure.

This is the first execution rule: retry follows reconciliation. A retry policy based only on elapsed time can turn one intended action into two market actions.

A Typed Action Is Still Upstream

The model's output is a proposal. Even a schema-valid proposal can change as it passes through symbol resolution, unit conversion, price protection, route selection, and venue serialization.

Consider a model action that says:

The venue-ready payload may express the asset as a contract address and the spend as an integer in wei. It may include a route, deadline, minimum output, and account nonce. Those transformations are necessary, yet each can alter the economic meaning of the request.

Deterministic policy should therefore inspect the final payload, not only the earlier model object. The check binds the payload hash to the compiled mandate, current state, policy version, and stable action ID. A mismatch causes rejection or recompilation before submission.

The enforcement point belongs as close to the venue boundary as practical. Earlier checks still help operators diagnose bad proposals. The final check establishes that the exact bytes sent remain inside the approved action.

Keep the Denominator Attached

DX Terminal Pro produced roughly 300,000 onchain actions during a 21-day event. The paper reports 99.9% settlement success for policy-valid submitted transactions.¹

That phrase carries the denominator. A parsed model action first passed policy checks for token validity, balances, slippage bounds, position limits, and possible trade parameters. Malformed responses and policy denials were measured elsewhere in the harness. The settlement statistic begins after those gates and asks whether a valid submission reached chain outcome successfully.

Collapsing those stages into one "agent success rate" would erase the mechanism. A model can produce an invalid action that correctly never reaches the venue. Policy can approve a valid payload that later fails to settle. A transaction can settle exactly as submitted and still express a poor trading decision.

We keep three rates separate:

None of these rates is a return metric. Together they show where reliability changed.

Acknowledgement Comes Before Finality

Order lifecycles differ by venue, but the trace still needs explicit transitions. "Sent" is a local event. "Acknowledged" means the venue recognized the request. "Filled" describes executed quantity. "Settled" describes the authoritative transfer or ledger effect. "Reconciled" means the runtime's portfolio view agrees with that effect.

A single status field cannot carry this history. We preserve an append-only sequence with source and observation time:

1. The runtime creates an action and final payload hash.
2. The adapter records the submission attempt and transport result.
3. The venue supplies an acknowledgement or queryable order identity.
4. Fill events record quantity, price, fee, and remaining amount.
5. Reconciliation advances balances and positions into the next state snapshot.

Partial fills make the sequence especially important. A partially filled order can leave reserved capital, open exposure, and a live remainder. Treating it as fully rejected frees too much capital. Treating it as complete hides the outstanding order. The next agent invocation should receive the reconciled fill and the unresolved remainder as separate facts.

Fees Belong in Portfolio State

Settlement is more than a position change. Fees, rebates, gas, funding, and rounding can alter available capital even when gross trade quantity looks correct.

The historical Terminal Pro market made this visible because each swap carried a 2.3% total fee. Fee salience affected model reasoning before execution, but the paid fee also changed the balance after settlement. Those are two separate records: expected cost in decision context and realized cost in reconciled state.

Our reconciliation check compares the local action record with the authoritative venue or chain result. It accounts for filled quantity and realized price. It then applies fees and verifies the resulting balance or position marker. A discrepancy becomes an exception with a named owner and recovery state. It does not get smoothed away in the next prompt.

This closes a common loop error. If the next invocation begins from the pre-fee balance, the agent can size a second action against capital it no longer has.

Force the Breaks Before They Find You

The downloadable matrix contains eight failure fixtures. They are designed for deterministic replay with the model and mandate frozen.

A passing run produces more than a green status. It preserves the state transition, evidence source, policy decision, and next allowed action. That record is what makes a later regression test useful.

In our fixtures, we preserve a compact before-and-after packet. It carries the approved action, final payload hash, every venue response, authoritative ledger marker, and next snapshot. The packet also names the observer that supplied each event. This matters during recovery because two services can observe the same fill at different times. Without lineage, a newer local timestamp can wrongly outrank an older authoritative settlement marker. With lineage, we can compare sources and rebuild the transition without asking the model to narrate what happened.

Recovery Is a State Machine

Kill switches and retries are often described as buttons. The difficult part is the state around the button.

An interruption should revoke new execution authority while leaving observation and reconciliation available. The runtime inventories unresolved requests, queries venue state, applies fills and fees, then rebuilds the portfolio snapshot. Only after the root cause is bounded and the failing fixture passes should an operator restore authority.

FINRA Regulatory Notice 15-09 discusses monitoring, alerts, reconciliation, retrievable code versions, and rapid-disable capability for member firms using algorithmic strategies.² Its scope is specific to covered firms and activity. We use it as a control parallel: interruption and recovery need versioned evidence and an enforcement point outside the trading logic.

The venue remains the source of truth for accepted orders and fills. The mandate remains the source of authority. Recovery joins those records without letting either one silently overwrite the other.

What the Execution Record Can Prove

An execution record can show that a particular payload matched a particular mandate and policy version. It can show that one request produced one venue order, that fills were accounted for, and that the next state reflects the authoritative result.

It cannot rescue a poor decision. A perfectly reconciled loss is still a loss. The record instead preserves attribution: decision quality belongs upstream, execution reliability belongs here, and realized market outcome remains its own evidence.

That separation makes agent improvement possible. The companion trace-feedback method turns an execution exception into a regression case without confusing transport success with trading skill. The Agentic Trading Evidence Ladder keeps replay and live execution claims distinct, while the DXRG Benchmark Card records the venue, costs, controls, and trace fields behind a result.

The complete path now reads cleanly. Compile the mandate, assemble current state, and produce a typed action. Then validate the final payload, submit once, reconcile the outcome, and return the evidence to evaluation. Each stage gets its own failure signal. Each correction gets its own test.

---

Version 1.0. Published July 24, 2026. Corrections: poof@dxrg.ai. This article is research and educational material, not financial, investment, legal, compliance, or security advice.

Footnotes

1. DXRG, Operating-Layer Controls for Onchain Language-Model Agents Under Real Capital, April 28, 2026. See the Abstract, System Setting and Runtime, Table 3, and Limitations. The 99.9% production statistic covers policy-valid submitted transactions. ↩

2. FINRA, “Regulatory Notice 15-09: Guidance on Effective Supervision and Control Practices for Firms Engaging in Algorithmic Trading Strategies”, March 26, 2015. The notice applies to FINRA member firms within its stated scope. ↩