Execution (L1)

The execution layer (L1) is where BLEEEP’s validated decisions meet real venues. Its design goal is narrow and deliberate: paper trading and live trading must run through the same decision path wherever possible, so that a strategy which forward-tests well on paper can be compared meaningfully against live execution instead of relying on a separate simulation path. Every decision and refusal is sealed by the proof layer before its outcome is known, while fills and execution results are recorded afterward and linked back to the original sealed decision. Live trading is off by default; a human promotes it only after paper out-of-sample validation passes.

The Executor abstraction

L1 exposes a single Executor interface. The engine that decides what to do never knows how the trade is carried out: it calls the same four methods regardless of whether it is simulating or trading real capital:

trait Executor {
    fn open(&mut self, sig: &Signal) -> Result<Fill>;
    fn close(&mut self, pos: &PositionId, reduce_only: bool) -> Result<Fill>;
    fn reconcile(&mut self) -> Result<AccountState>; // exchange = truth
    fn flatten_all(&mut self) -> Result<()>;         // panic
}

Two implementations satisfy this interface:

• PaperExecutor: 1x simulation against real prices, but places no real orders. Because it shares the decision path with live, paper is genuine forward validation rather than a separate code path that can silently diverge.
• LiveExecutor: real orders, plus the guards below, plus reconciliation against the exchange.

Same engine, same signals: only the execution differs. This logic parity is what makes a paper track record meaningful: there is no second decision engine that could behave differently once real money is involved. See Engine (L0) for how a strategy earns the right to be executed at all.

Venues

L1 is designed to route to venues at a high level, keeping the abstraction the same across them:

Execution is on-chain-first: every venue settles on-chain, so the trade is its own proof, not just the sealed decision. This is deliberate. A centralized exchange could only offer tamper-evident self-attestation of a fill absent an exchange-signed receipt, so BLEEEP routes to on-chain venues where the fill verifies trustlessly. That distinction is stated plainly in the validation methodology rather than glossed over.

The Safety Vault (least privilege)

BLEEEP’s stance is that in this era the sharpest risk is not returns but authorization: what a key is allowed to do. The Safety Vault is the set of guardrails required before the agent handles anyone’s capital:

• Session keys: time-boxed, delegated authority via smart accounts, not a standing hot key.
• Spend caps: a daily spend limit, enforced independently of the strategy.
• Destination whitelist: funds can only move to approved addresses.
• Circuit breaker: auto-flattens open positions and pauses on anomaly.
• Daily-loss kill-switch: auto-pauses on a loss threshold breach.
• Reconcile-from-exchange: the exchange is treated as the source of truth; positions are reconciled at startup so the agent never trades on a stale internal view.

These limits, and the block history when a guardrail fires, are designed to be shown and proven in the console, not merely asserted. Anchoring wallets and trading keys are operator-managed and separated from code.

Financial responsibility rests with the user. These guardrails reduce authorization risk; they do not guarantee outcomes, and nothing here is a promise of returns.

Next: see how the whole system fits together in the architecture overview, or check any sealed decision directly at Verify.