54dc05a94c
Proof: Preserve the completed first live BTC/EURe trade loop and establish the next approved implementation proof around pre-credit funding visibility and operator alerts. Assumptions: The live-trade loop is sufficiently proven by the recorded deposits, withdrawals, durable command/result chain, and successful mainnet quote responses; the next highest-value slice is operational visibility rather than new execution breadth. Still fake: The newly opened funding-visibility and alert turn is planning only; no pre-credit watcher or durable alert evaluator is implemented yet.
2.2 KiB
2.2 KiB
unrip thesis
Purpose
Build a data-first trading system whose first-class artifact is trustworthy market and execution history.
The bot is one consumer of that truth. Analytics and backtesting are not bolted on later; they are part of the product from the beginning.
Product nucleus
The nucleus of the system is one shared truth pipeline:
- observe live market and intent flow
- persist raw and normalized events durably
- replay the same history for analytics and backtests
- score candidate actions from the same canonical data model
- execute only behind explicit safety gates and full auditability
Architectural invariants
- Live decisions and historical analysis must share the same canonical event model whenever practical.
- Raw events are kept alongside normalized and derived records.
- Every important decision should be reproducible from stored inputs and explicit assumptions.
- Execution must not outpace observability. If the system cannot explain what happened, it is not ready to trade.
- Quote collection and analytics are core product work, not support work.
Near-term thesis
Near term, unrip should become a narrow but truthful trading-data and decision pipeline for one real pair on one venue.
That means:
- real upstream data
- durable storage beyond transient bus retention
- replayable history
- measurable candidate decisions
- no pretending that execution is safe before the data and analysis path is trustworthy
Long-term thesis
Long term, the same system should support:
- automated trading on selected pairs
- analytics and backtesting from retained ground-truth data
- cross-chain and cross-asset execution routing
Non-goals right now
- polished operator UI before the data loop is truthful
- broad multi-venue coverage before one core loop is real
- strategy claims without named assumptions and falsification criteria
- live trading with real funds before paper or tightly gated execution is trustworthy
Approval boundaries
The agent may propose changes to the thesis, but the user must approve:
- changes to the core product definition
- changes that raise the risk class of the system
- changes that create lasting infra cost or operational burden