Execution (L1)

The execution layer (L1) is where BLEEEP’s validated decisions may enter paper simulation or, when enabled, live execution. Paper and live trading share the same decision interface and risk path where practicable so their behavior can be compared without treating their fill mechanics as identical. Eligible signals and Trade Abstentions use the pre-outcome decision proof class. Forward-stream and execution-mandate lifecycle events, routing blocks, fills, and other execution results use event-evidence records. Routed instructions and resulting events link to the originating decision and the mandate valid at submission where applicable.

Decision recording may continue while routing authority is absent, expired, suspended, or revoked. Such action signals remain explicitly unexecuted. When a live integration is released, it remains disabled by default and requires a current live-mode execution mandate together with the applicable paper, validation, eligibility, venue, and risk gates.

Every registered Trade Abstention, strategy-validation result, routing disposition, and fill carries its actual proof and anchor status. A Trade Abstention carries a valid pre-outcome proof only when its anchor finalized within the registered deadline. A strategy-validation NO_GO uses a computation-provenance record. A registered order identifies the execution-mandate identifier and version current at submission. A later fill traces through that order and carries its own event-evidence record and evidence-source label; only a successfully anchored fill record links to a finalized Robinhood Chain batch that makes subsequent alteration detectable.

Validation, Prop qualification, stream activation, a funded arrangement, and execution authority are distinct. Personal manual trading and bounded personal automation do not require a Prop PASS. Execution on behalf of another principal under a released funded arrangement may require a current strategy record, scoped Prop qualification, a registered AI agent version where applicable, explicit principal authorization, sufficient capacity, current risk approval, and venue availability. Every routed instruction is checked against the effective authority defined under the Safety Vault. A GO, PASS, capital offer, or funded mandate never creates order-routing authority automatically.

Paper and live execution parity

L1 uses one execution abstraction so the strategy’s decision logic does not change merely because an order is simulated or live. PaperExecutor is the default execution-mandate mode; selecting LiveExecutor requires the additional live gates. The shared decision interface supports two execution modes:

• PaperExecutor provides conservative, queue-aware simulation against authoritative order-book and trade evidence without submitting real orders. Marketable instructions consume evidenced opposite-side depth. Resting limits use order-level reconstruction when authoritative sequence data supports it; otherwise, they use the conservative synthetic queue in the frozen paper-execution model. Unsupported fills receive no credit. The shared decision interface and risk path support comparison without turning a paper fill into a live fill.
• LiveExecutor submits real orders subject to the controls below and reconciliation against the venue.

The strategy logic and decision interface remain the same across modes, while execution, liquidity, latency, market impact, and evidence differ. This logic parity makes paper behavior comparable without implying that paper and live outcomes will match. See the validation engine for how a strategy becomes eligible for execution.

Venues

L1 routes to different venues without changing the high-level decision interface. Lighter, an onchain perpetual DEX, is the first BLEEEP Prop paper reference venue; any Agent live integration is evaluated and released separately. Polymarket provides onchain binary prediction markets whose registered-account transactions may support ON_CHAIN_TRANSACTION_RECORDS within the declared verification scope. BLEEEP may extend the same registered-wallet and contract-scope verification model to additional perpetual and spot DEX integrations.

Execution is onchain-first for supported integrations. A transaction receives the ON_CHAIN_TRANSACTION_RECORDS label only when it can be independently checked within the registered account, network, contract, chain-finality, and decoding scope; this does not prove offchain intent, beneficial ownership, or activity outside that scope. A broker or centralized-exchange fill retains its actual lower-assurance evidence-source label unless supported by VENUE_AUTHENTICATED evidence. Venue availability, proof class, and evidence-source label must therefore be disclosed per integration.

The Safety Vault (least privilege)

BLEEEP treats authorization, meaning what a key or account permission is allowed to do, as a critical risk alongside market loss. An execution mandate supplies human order-routing authority; the Safety Vault constrains that authority but never creates or broadens it. Implementation varies by venue and account type.

The current mandate identifies the authorized trader or registered AI agent, any applicable frozen strategy or agent version, and any applicable Validation Standard version. It also identifies the execution mode, account, venue, markets, exposure and order limits, daily-loss limit, expiry, and termination conditions. Any scope change or material strategy- or agent-version change creates a new mandate version; an expansion of authority also requires a fresh human authorization decision. At routing time, L1 applies the narrowest limit among the mandate, current eligibility, Safety Vault, venue or account permissions, and integration controls.

The minimum controls are:

• Bounded authority: time-boxed session keys where smart accounts support them, or equivalent broker- or venue-native permissions.
• Exposure or spend caps: limits enforced independently of the strategy.
• Withdrawal and destination control: whitelists where supported, or equivalent dedicated-account and withdrawal restrictions.
• Circuit breaker: blocks new risk and attempts to close positions in an orderly manner or takes another protective action when an anomaly occurs; successful flattening still depends on venue and market conditions.
• Daily-loss kill-switch: automatically pauses on a loss-threshold breach.
• Reconcile-from-venue: the authoritative venue or chain state is reconciled at startup and continuously under the registered controls; a mismatch blocks or pauses new risk rather than assuming an internal view is current.

Smart-account controls apply only where the integration supports them. Broker and centralized-venue integrations must provide equivalent native permission, withdrawal, account-separation, and reconciliation controls before live use. BLEEEP-operated anchoring keys and any integration credentials are separated from application code and managed under their applicable authorization controls.

Mandate creation, scope change, suspension, resumption, detected expiry, automatic termination, and revocation are append-only event evidence. Suspension, revocation, or expiry blocks new risk prospectively; it does not retroactively invalidate an accepted order or later fill and cannot guarantee cancellation or flattening at a venue. Treatment of working orders, open positions, cancellations, and protective close instructions follows the released controls. The console shows the current mandate identifier, version, scope, expiry, status, and related routing blocks.

Users remain responsible for their decisions and account activity. These guardrails reduce authorization risk; they do not guarantee outcomes, and nothing here is a promise of returns.

Next: Trading via Robinhood describes the optional broker-execution integration.