ADR 002: Dry Run Safety Mode¶
Status¶
Accepted
Context¶
A trading bot with automated execution capabilities presents significant financial risk if misconfigured. The user requested a --dry-run or backtesting capability to safely verify the "Saga" logic (Order creation, signing, sequencing) without submitting actual orders to the exchange.
Decision¶
We implemented a --dry-run CLI flag that places the system into a "Safe Mode."
Design¶
- CLI Flag: Added
--dry-runtomain.rs. - State Propagation: The boolean flag is passed into the constructors of
PolymarketClientandKalshiClient. - logic:
- Normal Operation:
place_orderconstructs the payload, authenticates headers/signatures, andPOSTs to the exchange. - Dry Run Operation:
place_orderconstructs the payload, performs ALL cryptographic signing operations (to verify keys and algo correctness), prints the signed JSON payload tostdout, and returns a simulatedFillDetailssuccess response.
- Normal Operation:
- Mocking vs. Dry Run:
- Mock Client: Used when NO API keys are present. Logic is entirely fake.
- Dry Run: Used WITH valid API keys. Real logic, Real signing, Fake submission.
Decision Drivers¶
- Safety: Critical requirement for "real money" verification.
- Verifiability: Allows the user to inspect the exact JSON payload and signature that would have been sent.
- Confidence: Enables testing the full
Executor -> Client -> Signerpipeline.
Consequences¶
- Positive:
- Enables safe "Production" configuration testing.
- Verifies cryptographic correctness without gas costs or financial risk.
- Negative:
- "Fake Fills" are instantaneous, which doesn't model network latency reality.
- Does not verify if the Exchange would accept the order (e.g., insufficient balance, invalid nonce).
Verification¶
- Validated by running
cargo run -- --dry-run. - Confirmed payloads are printed to stdout and no network requests are sent.