Bring-up
Genesis → first block production → first orderbook submission → first fill. Verifies the engine boots into a known-good state before any stress is applied.
openhl is up; the first deposit lands. Zero PDAs allocated — the bridge state IS the market.
What happens
Stand up an openhl perp market from zero. On the EVM side this is *implicit*: the `LiveRethEvmBridge<()>` is constructed with the market struct already in its initial state, and the first deposit is just an entry in the bridge's `accounts` map. There is no per-market PDA to allocate, no Market header to initialize separately, no vault PDA to derive — the bridge IS the market. Contrast this with `openhl-solana/bring-up` (same `compare_key`), where reaching the same state requires 5 on-chain instructions and ~4 distinct accounts (raw Market alloc, Initialize, market PDA via invoke_signed, per-(market,mint) vault PDA, CPI deposit). The diff is the account model.
Declared outcomes
Each declared outcome is scored ✓ pass / ✗ fail against the run’s actual state.
- Single deposit lands a single trading account — no per-account PDA allocation along the way.
- Bring-up emits no fills (no orders submitted).
- Quiet bring-up — the scanner finds nothing to flag.
- Account 10's post-bring-up collateral equals the deposited amount; nothing has moved it.
4 of 4 outcome(s) verified.
Verbatim report
The exact 5-section report the run emits — identical every run.
─── scenario: bring-up ────────────────────────────────────
HEADLINE ✓: openhl is up; the first deposit lands. Zero PDAs allocated — the bridge state IS the market.
DESCRIPTION:
Stand up an openhl perp market from zero. On the EVM side this is *implicit*: the `LiveRethEvmBridge<()>` is constructed with the market struct already in its initial state, and the first deposit is just an entry in the bridge's `accounts` map. There is no per-market PDA to allocate, no Market header to initialize separately, no vault PDA to derive — the bridge IS the market. Contrast this with `openhl-solana/bring-up` (same `compare_key`), where reaching the same state requires 5 on-chain instructions and ~4 distinct accounts (raw Market alloc, Initialize, market PDA via invoke_signed, per-(market,mint) vault PDA, CPI deposit). The diff is the account model.
TIMELINE (per-block):
height mark src trades fills deposits liqs adl fund
------ ------ --------------- ------ ----- -------- ---- --- ----
1 100 stub-empty-book 0 0 1 0 — —
2 100 stub-empty-book 0 0 0 0 — —
3 100 stub-empty-book 0 0 0 0 — —
ACCOUNT DELTA (final − initial):
account collateral position avg_entry
------- ---------- -------- ---------
10 100 0 0
(initial account count: 0, final account count: 1)
OUTCOMES:
✓ Single deposit lands a single trading account — no per-account PDA allocation along the way.
✓ Bring-up emits no fills (no orders submitted).
✓ Quiet bring-up — the scanner finds nothing to flag.
✓ Account 10's post-bring-up collateral equals the deposited amount; nothing has moved it.
4 of 4 outcome(s) verified.
NOTE: v1 runs the scenario in-process against a unit-provider
`LiveRethEvmBridge<()>` (no Reth boot). For the production-shape
run (real Reth + Malachite + JSON-RPC), use:
openhl reth-devnet --chain-history scenarios/bring-up.json --rounds 3
NEXT:
• Adopt this engine : https://github.com/psyto/rdk
• Custom build : https://fabrknt.com/waitlist.html?product=evm-perp&intent=build
• Hosted access : https://fabrknt.com/waitlist.html?product=evm-perp&intent=hosted