Kraken Execution Validation Checklist

# Kraken Execution Validation Checklist

Last updated: 2026-07-06

## Purpose

This checklist answers one narrow question:

Can we prove that Kraken trading actually works end to end?

It is stricter than the general roadmap. Each item is marked as one of:

- `PROVEN`: supported by current tests plus direct runtime evidence
- `PARTIALLY PROVEN`: supported by tests or partial runtime evidence, but not
  the full live lifecycle
- `UNPROVEN`: not yet demonstrated with sufficient evidence
- `BLOCKED`: cannot be proven safely until another prerequisite is fixed

This document is about execution truth, not strategy quality. A profitable
strategy can still fail if order routing, fills, stops, or reconciliation are
wrong.

## Evidence Standard

An item is only `PROVEN` when we have the right level of evidence for that item:

1. code-level tests pass
2. the running service exposes the expected state
3. exchange-visible behavior matches local state
4. restart/recovery behavior is confirmed where relevant

If even one of those is missing for a critical execution path, the item stays
`PARTIALLY PROVEN` or `UNPROVEN`.

## Current Checklist

| Area | Status | What is currently proven | What is still missing |
| --- | --- | --- | --- |
| Kraken authentication | `PARTIALLY PROVEN` | The running public surface has reported `broker_provider=kraken_futures`, `health=ok`, `live_readiness.ready=true`, and account data loads. Client tests cover authenticated private requests and account parsing in [tests/test_kraken_futures_client.py](/Users/ramon/Documents/Bot/crypto_bot/tests/test_kraken_futures_client.py). | We still need one host-level check on the current droplet that confirms authenticated account access against the exact live credentials now in use, not just dashboard rendering. |
| Instrument metadata | `PARTIALLY PROVEN` | Kraken futures instrument parsing is covered in [tests/test_kraken_futures_client.py](/Users/ramon/Documents/Bot/crypto_bot/tests/test_kraken_futures_client.py), including normalization of `PF_XBTUSD` to `BTC-USD-PERP`. | We still need to confirm the live service is using the intended contract, tick size, step size, and minimum notional directly from the exchange on the current deployment. |
| Market data freshness | `PARTIALLY PROVEN` | Client tests cover warm quote cache and ticker-stream parsing in [tests/test_kraken_futures_client.py](/Users/ramon/Documents/Bot/crypto_bot/tests/test_kraken_futures_client.py). The dashboard has shown fresh status snapshots. | We do not yet have a strict production proof that the bot blocks entries when both stream and REST data are stale. |
| Read-only account and position sync | `PARTIALLY PROVEN` | The dashboard has shown flat position state, no pending production order, and no protective stop. Account snapshots parse correctly in tests. | We still need a host-side reconciliation check comparing Kraken account, Kraken open positions, and SQLite state on the same timestamp. |
| Order payload generation | `PARTIALLY PROVEN` | Kraken futures tests cover market and post-only entry payload behavior, reduce-only flags, order lookup, and fallback lookup by client order id in [tests/test_kraken_futures_client.py](/Users/ramon/Documents/Bot/crypto_bot/tests/test_kraken_futures_client.py). | Test coverage is not the same as live exchange acceptance. We still need exchange-accepted submissions on the current account. |
| Entry order accepted by Kraken | `UNPROVEN` | There is code and tests for Kraken order submission paths. | We do not yet have a fully documented live Kraken order accepted on the current account with matching exchange order id, local event, and persisted SQLite row. |
| Entry order filled correctly | `UNPROVEN` | The client can model fills and poll terminal status in tests. | We have not yet proven a real Kraken fill from the current deployment with correct quantity, price, fee, and side reconciliation. |
| Protective stop placement | `UNPROVEN` | The local stop state machine is well tested in [tests/test_exchange_protective_stop.py](/Users/ramon/Documents/Bot/crypto_bot/tests/test_exchange_protective_stop.py). | We have not yet proven that Kraken accepts the intended protective stop order type for a real filled position on this account. |
| Protective stop survives restart | `UNPROVEN` | The design expects restart reconciliation. | We do not yet have a live Kraken trade lifecycle where the service restarts while the position is open and successfully recovers the exchange-side stop. |
| Reduce-only discretionary exit | `UNPROVEN` | Code paths exist for reduce-only exits. | We have not yet observed a real Kraken exit placed, accepted, filled, and reconciled from this deployment. |
| Partial fill handling | `UNPROVEN` | There is code support for order-status lookups and fill parsing. | We do not yet have a controlled proof that a partial fill updates local state, stop sizing, and final reconciliation correctly on Kraken. |
| Duplicate-order prevention | `PARTIALLY PROVEN` | SQLite duplicate checks and prior broker work suggest the storage pattern is sound. | We still need one Kraken-specific forced retry or delayed-ack scenario to show the bot does not double-submit when exchange status is ambiguous. |
| Fee capture and contract math | `UNPROVEN` | Local code converts contract notional and reports filled base quantity in tests. | We have not yet reconciled a real Kraken fill fee, contract quantity, and resulting PnL against SQLite and dashboard values. |
| Dashboard reflects real Kraken state | `PARTIALLY PROVEN` | The public dashboard exposes Kraken provider, status, and decision state. | We still need to prove that dashboard order, position, stop, and fee fields match exchange reality during and after a real trade. |
| End-to-end live trade lifecycle | `UNPROVEN` | None. | We have not yet proven the full chain: signal -> submit -> accept -> fill -> stop armed -> position visible -> exit -> flat -> fees/PnL correct. |

## What Is Already Solid

These are the parts I consider technically strong enough to build on:

- Kraken futures request signing and account parsing are covered by tests.
- Instrument normalization for `PF_XBTUSD` is covered by tests.
- Quote stream parsing and quote-cache preference are covered by tests.
- Local protective-stop replacement logic is covered heavily in tests.
- The public Kraken surface has at least shown healthy runtime status and a
  coherent flat-book state.

That means the system is not starting from zero. But it is not enough to call
Kraken execution proven.

## What Is Not Yet Proven

These are the hard execution unknowns:

1. Will Kraken accept our exact live entry payloads on this account?
2. Will a filled entry produce the exact local position state we expect?
3. Will Kraken accept the protective stop exactly as we intend?
4. If the process restarts mid-position, will the bot recover the position and
   stop correctly?
5. Will reduce-only exits and fee accounting reconcile cleanly?

Until those are demonstrated, live Kraken trading is still only partially
validated.

## Strict Validation Sequence

This is how I want to prove Kraken execution in the safest useful order.

### Phase A: Read-Only Host Validation

No orders. No capital movement.

- Confirm the current droplet can authenticate directly to Kraken from the live
  process environment.
- Pull and save:
  - account snapshot
  - instrument metadata
  - open positions
  - open orders
  - quote snapshot
- Compare those results with:
  - `status.json`
  - SQLite state
  - dashboard labels

Pass condition:

- all three surfaces agree on provider, instrument, position, and account state

### Phase B: Exchange Acceptance Validation

Tiny live exposure only, user-approved beforehand.

- Submit one deliberately tiny entry order.
- Verify:
  - local event log records submission
  - SQLite stores the order
  - Kraken shows the order
  - order id and client order id match across all surfaces

Pass condition:

- one accepted order with exact ID reconciliation

### Phase C: Fill And Stop Validation

Still tiny size.

- Let one real entry fill.
- Immediately verify:
  - position appears on Kraken
  - local position matches side and size
  - protective stop is placed on Kraken
  - local stop record matches Kraken stop

Pass condition:

- one filled entry with one correctly attached protective stop

### Phase D: Restart Recovery Validation

- While the tiny position is still open, restart the bot process once.
- Verify after restart:
  - the position is rediscovered
  - the stop is rediscovered
  - no duplicate order is sent
  - dashboard still shows one coherent open position

Pass condition:

- restart produces no duplicate state and no missing protection

### Phase E: Exit Validation

- Close the tiny position using the intended reduce-only path or let the stop
  close it if safer for the test.
- Verify:
  - fill appears on Kraken
  - local state returns to flat
  - stop is removed or marked terminal
  - fees and realized PnL reconcile

Pass condition:

- complete open-to-close lifecycle reconciles cleanly

### Phase F: Ambiguous-Status Validation

- Simulate or force one delayed/uncertain order-status path.
- Verify:
  - no duplicate entry is sent
  - the bot stays conservative
  - final state reconciles after delayed lookup

Pass condition:

- unknown status does not create duplicate live exposure

## Minimum Proof Before We Can Say "Kraken Works"

I do not want to call Kraken execution proven until all of these happen:

1. one accepted entry order
2. one filled entry order
3. one exchange-visible protective stop
4. one successful restart recovery during or immediately after open risk
5. one complete closed trade reconciliation
6. one ambiguous-status scenario handled without duplicate orders

## Practical Recommendation

Right now the correct statement is:

Kraken connectivity and some Kraken code paths are proven, but real Kraken
execution is still not proven end to end.

The next correct move is not a strategy change. It is a controlled execution
validation run with tiny size and a written evidence capture for each step
above.

## Immediate Next Actions

1. Run Phase A from the droplet and save the results.
2. Update this checklist with direct host evidence.
3. If Phase A is clean, prepare a tiny-user-approved live validation order plan.
4. Only after that should we judge whether Kraken trading itself is working.