Skip to main content
A single user action — “launch this grid” — fans out across the stack like this.

​
Launch flow

1

User confirms in Telegram

The bot has shown the AI-proposed config plus expected risk metrics. User taps confirm.
2

Pre-trade validation

Backend validates that the user’s Bybit key is alive, trade-only, and has the required market access. Risk caps are sanity-checked against account size.
3

Commit on Mantle

CommitRegistry.commit(runId, configHash, capsHash, marketId, timestamp) is sent. Backend waits for inclusion.
4

Engine handoff

On commit confirmation, the grid engine is allocated the runId, loads the config, and subscribes to fills from the Bybit adapter.
5

Ladder placement

Engine places the initial ladder of orders through the adapter. Each intent passes through cap enforcement.
6

Live state

Fills stream in over WebSocket. PnL, drawdown, and risk metrics update in real time. Telegram pushes status updates and alerts.
7

End of run

Triggered by target, stop, or user. Engine cancels open orders, snapshots the verified outcome, and hands it to the proof layer.
8

Attest on Mantle

AttestationRegistry.attest(runId, outcomeHash, pnl, maxDrawdown, riskScore, status) is sent and confirmed. Telegram shows the user a link to the attestation.

​
Stop flow

  • User sends /stop in Telegram.
  • Engine cancels open orders.
  • Outcome is snapshotted and attested on Mantle.
  • Run is closed in the operational store; track record lives on-chain.

​
Failure modes

  • Venue outage: adapter surfaces the error, engine pauses placement, user is notified. Existing positions remain on Bybit under user control.
  • Mantle slow: launch waits on commit inclusion before any order goes out. No silent trading.
  • Cap breach attempt: rejected at the cap-enforcement layer; engine logs the rejection and alerts the user.