The Bracket Replay Identifies an Engineering Priority

A fixed 2% stop and 4% target attached at entry improved replayed returns by +39.0 basis points per position in our historical fleet, with a paired, day-clustered interval of [+21.3, +56.5]. The strongest implication is an engineering priority: a protective exit must exist on the execution path for a replayed benefit to become a deployed capability.

The continuous record reports the result for the pre-alpha fleet studied through the August 15, 2026 cutoff. Most fleet fills were paper under simplified cost and margin assumptions. Excluding every liquidation left an improvement of +16.6 basis points, with an interval of [+2.1, +30.8]. The comparison therefore retained a positive estimate under that exclusion while much of the original gain came from preventing extreme losses.

A result with an operational blocker

A separate 48-hour window showed 24 of 35 successful opens missing their protective trigger after a non-retryable trigger-quota error. Successful entry and successful protection were different events. A log recording an open alone would have made the trade appear complete while concealing the relevant failure.

The fraction 24/35 is approximately 68.6% for that specific window. Its complement, 11/35 or 31.4%, describes opens outside the stated missing-trigger count. These calculations explain the observed incident’s severity. The small, bounded window supplies no estimate of a general long-run product failure rate.

Our proposed audit gives every entry three separate states: protection intended in the action, protection acknowledged by the execution adapter, and protection confirmed active by authoritative venue state. Only the final state supports the claim that an open position has the expected exit order. This framework is an engineering proposal derived from the incident rather than a report of a shipped repair.

Replay and deployment answer different questions

A paired replay asks what a declared rule would have done to saved positions under stated fill assumptions. Deployment asks whether the rule was actually submitted, remained active and executed correctly. Both are necessary for a practical conclusion, with different evidence.

We would preserve entry identity across the replay and execution test. A venue rejection needs an explicit disposition, including what happens to an already opened position. Retrying must preserve request identity and avoid duplicate exposure. The desired outcome is an entry path whose protection state is immediately inspectable, with recovery behavior tested before risking live capital.

The controls paper connects typed actions to validation, submission and reconciled state. It supplies the relevant design discipline without establishing that a particular bracket implementation now exists.

What DXAP readers should ask

Current DXAP’s public description includes policy checks outside the model and Hyperliquid execution. That separation is useful when evaluating an agent platform, because it creates a place to enforce protection mechanically. The historical replay supports investigating atomic open-with-protection behavior; a current production claim needs current implementation and venue receipts. We would report simulation improvement and protection reliability separately, then test whether their combination survives actual execution costs and margin rules.