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.
50 lines
2.2 KiB
Markdown
50 lines
2.2 KiB
Markdown
# 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:
|
|
|
|
1. observe live market and intent flow
|
|
2. persist raw and normalized events durably
|
|
3. replay the same history for analytics and backtests
|
|
4. score candidate actions from the same canonical data model
|
|
5. 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
|