System layers
BLEEEP is built as five stacked layers, L0 through L4. Each layer has one job, and the boundary between them is deliberate: a user’s private strategy logic lives at the bottom and never moves up. Only verdicts, proofs, revealed records, and authorized signals flow upward to where humans and other agents can consume them. This page gives the layer map, traces how a single signal passes through the stack, and orients the reader on the data model that records it.
The five layers
| Layer | Name | Responsibility |
|---|---|---|
| L0 | Validation Engine (neutral judge) | Judges every user strategy GO / NO-GO using a capture-first backtester and an adversarial validation gate: the same fixed, public bar for everyone. The engine never runs its own book. |
| L1 | Execution | Runs live trading through an Executor abstraction with paper/live parity, on-chain-first across venues like Polymarket and perpetual DEXes (Lighter first), behind a Safety Vault. |
| L2 | Proof of Provenance | Seals every decision into an append-only hash-chain, batches commits into a Merkle root, and anchors that root on Robinhood Chain (a second resilience chain is planned for later). |
| L3 | BLEEEPY agent | The autonomous verifier on Virtuals Protocol: discover, capture, adversarially verify, publish a verdict, then stop at a human deploy gate. |
| L4 | Public surface / agent economy | The verification console, validated signals, and paid Verification API (x402 / ACP) where the proofs are consumed. |
The boundary rule is simple: a user strategy’s private logic is never exposed. Only the verdicts, proofs, and signals produced at L2 flow upward. What leaves the system is results, never logic: a user can keep their own logic private while proving results, and this private-alpha / public-proof separation is what the whole design turns on. The engine does not keep a proprietary strategy book or trade against users; it only judges the ones users submit.
Every strategy is user-built, and the engine is a neutral judge, not a competitor: it never runs its own book against the users it validates. Trust does not come from any BLEEEP track record; it comes from the accumulating collective GO / NO-GO record, the NO-GO archive (rejected strategies expose no alpha), and an engine whose passing bar is fixed, versioned, and public. See User strategies for the full picture.
How a signal flows through the stack
A single decision moves through the layers in a fixed order: decide → seal → anchor → reveal → verify:
- Decide (L0 → L3). The engine evaluates a frozen user strategy spec against future-only data and emits a verdict:
GO,NO_GO, orINSUFFICIENT. Most candidates land on NO-GO, and that rejection is recorded too, so the NO-GO archive becomes shared, verifiable evidence of what does not work. - Execute (L1). On a GO, the Executor opens or closes a position. Live execution is off by default and is promoted by a human only after paper out-of-sample results hold.
- Seal (L2). The decision, including NO-GO records, is committed as a hash and linked into an append-only chain, so nothing can be inserted, deleted, or reordered after the fact.
- Anchor (L2). A batch of sealed commits is reduced to one Merkle root and anchored on Robinhood Chain. Whether the batch holds one record or a thousand, it is a single transaction. A second anchor chain for resilience is planned to be added later, so no single chain becomes a point of failure.
- Reveal & verify. After the outcome is known, the underlying record and its salt are disclosed. Anyone can then recompute the commit, check the Merkle proof against an anchored root, and confirm the seal predated the outcome.
Because the commit is sealed before the outcome and the root is anchored publicly, verification only needs the on-chain root and the revealed record. Verification does not require trusting BLEEEP’s dashboard or self-reported numbers.
The data model, briefly
The record layer mirrors this flow without exposing strategy internals. A few tables carry the weight:
- Gate logs capture every evaluation cycle: its inputs (as a hash), its verdict, and its rejection reason. These are the source feed for the proof layer.
- Sealed records store the commitment for each decision, its position in the ordered batch, the previous-hash link, the running chain hash, any encrypted payload, and its reveal status. The salt remains private until reveal.
- Anchor rows record, per batch, the Merkle root and the anchoring transaction, so a proof can be checked on-chain. The schema is per-chain, ready for the planned second chain.
Rationale is stored only as a hash, so the reasoning stays private while its existence and timing remain provable. See /architecture/validation for how the gate metrics feed those records.
Related reading: /architecture/engine for the neutral L0 validation engine, /architecture/execution for the L1 executor and Safety Vault, /proof-of-provenance for the L2 sealing mechanism, and /ecosystem for the L4 agent economy.
Next: read /architecture/engine to see how L0 turns raw market data into a GO / NO-GO verdict.