Margin Rescue built on dreamDEX

Live · Hideki

Reading BTC-PERP and ETH-PERP from the testnet…

Know the call
before the market
sends it.

Cross-margin stress, priced rescues, guarded fills.

Margin Rescue shocks BTC and ETH together on a dreamDEX cross-margin account, compares concrete reductions, executes one through a reduce-only guard, and recomputes the same scenario from the real fills.

Read-only; nothing is signed. Try a real 6‑market account

built on dreamDEXPerps testnet · Somnia Hideki · chain 50383

A replay of the recorded fork run on the real 6-market account 0x2E36…B745. At block 33,472,616 the account reconciles exactly with a buffer of 527.10 USDso. Under BTC −8% and ETH −12% the buffer falls to (262.05): a margin call. Of the eight reductions evaluated, ETH −50% is the smallest that meets the target. The guard sold 0.8165 ETH in two fills inside the 2,305.06 limit, and the buffer recomputed from the fills is 6.48 USDso: goal met.

Rescue lifecycle

How a rescue reads

Four records, each checked against the next.

The figures are the fork run in the console above, unedited: a real 6-market account, forked from block 33,472,615 and read at 33,472,616.

01

The scenario is fixed

Absolute prices, hashed. After execution the account is valued at these same prices again, not shocked anew from wherever the market went.

scenario.json
scenario   2d73979b848ff9b5…
reference  block 33,472,616 · 0x10d2a7b4…
model      mr-model/1 · static · funding frozen
BTC        79,976.86 to 73,578.71   −8%
ETH         2,316.66 to  2,038.66  −12%
SOL XRP BNB SUI held at reference
target     buffer at least 0.00 USDso

Hashed with SHA-256; the recompute values the account at these same prices.

02

Every reduction is priced on the book

Each candidate is filled now against the order book read at the reference block, then the remainder is valued at the scenario prices. The smallest cut that meets the target is preferred.

candidates.json
Candidates evaluated for the fork account. Buffer at the scenario prices in USDso; negatives in parentheses.
CandidateCut nowBuffer at scenarioGoal
No action0.00(262.05)Fails
BTC −25%1,110.08(145.39)Fails
BTC −50%2,220.96(28.66)Fails
BTC −75%3,331.8488.05Meets
BTC −100%4,442.71204.76Meets
ETH −25%945.66(127.78)Fails
ETH −50%Preferred1,891.556.48Meets
ETH −75%2,837.21140.70Meets
ETH −100%3,783.10274.95Meets

ETH −50% removes 1,891.55 of notional; the cheapest BTC fix, −75%, would remove 3,331.84.

03

One guarded order

The guard executes only if the live position still equals the one confirmed, and reverts the whole transaction if the position flips or grows.

ReduceOnlyGuard

Sell 0.8165 ETH · IOC · limit 2,305.06 · deadline 120 s

  • Live position equals the confirmed 1.633 ETH long
  • Sell 0.8165, IOC, limit 2,305.06, deadline 120 s
  • After the fills: same side, smaller, reduced by at most 0.8165
  • Replaying the same confirmation afterwards reverts PositionMismatch(1.633, 0.8165)

Fork: 38 / 38 Solidity tests against the real venue, with traces.

04

Recomputed from what filled

The receipt is bound to the confirmation first: sender, guard, calldata, nonce, the guard's event and the taker's fills. Then 17 ledger checks explain every change to the account before anything is credited.

recompute.json
Account figures before and after the reduction, at the scenario prices, in USDso; negatives in parentheses.
At the scenario pricesHealth equityMaintenanceBuffer
Before209.81471.87(262.05)
Forecast436.73430.256.48
Actual, from the fills436.73430.256.48
Now, at current marks1,019.13444.81574.32

17 of 17 ledger checks hold · no outside change · reconciles exactly · goal met

Built on dreamDEX.

Not around it: every read and every order goes through the venue's own contracts and tools.

dreamDEX is a fully onchain central limit order book on Somnia, open to apps built on top of it. Margin Rescue reads accounts through the venue's own bank, pools and SDK, and acts only through the operator grant dreamDEX already offers to bots. Nothing of the venue is forked, wrapped or re-hosted.

Every component, address and version
  1. OursSnapshot, scenario, candidates, run ledgerThe TypeScript client and ReduceOnlyGuard.sol, the only parts that are Margin Rescue's.
  2. SDK@somnia-chain/markets-sdk 0.32.1The venue's TypeScript SDK: the chain, the deployment's addresses, and the contract errors and events every receipt is decoded with.
  3. PermissionsOperatorPermissionsRegistryThe owner's per-pool grant of placeOrderFor, the same grant dreamDEX's “Link a bot” writes. It admits the guard, and is revoked afterwards.0x6B2F…8D3a
  4. Order booksPerps pools · placeOrderForAll 21 pools from the factory: positions, resting orders and books. Every candidate is priced on its book; the guard sends one IOC order.
  5. CollateralMarginBankCross-margin USDso collateral. Its own health getters are what the independent rebuild has to match, to the raw unit.0x4787…1394
  6. StopsStop registry · markets indexerTP/SL stops, listed from the indexer and checked on chain at the pinned block.
  7. ChainSomnia Hideki testnet · 50383The chain under all of it. Any other chain is refused.

One account, every market

1,203 of 7,677 accounts held two or more.

On dreamDEX, every position in an account draws on the same USDso collateral. A move in BTC changes how much margin is left for ETH, SOL and the rest, and a short can be the leg that keeps a long alive.

So the question is not which position is losing the most, but which concrete reduction restores the buffer for the whole account under the move you fear. In the fork example the instinctive fix, cutting the larger BTC leg, needs three quarters of it; halving ETH does the job with less exposure removed.

Margin Rescue checks every leg, every resting order and every stop, and says when its answer cannot be trusted.

Accounts by markets held

Live, read-only · indexer scan 26 Oct 2026
Show as a table
Accounts with open positions, by number of markets held
Markets heldAccounts
16,474
2322
3329
4230
5193
664
725
811
98
107
111
121
132
143
151
161
171
180
191
201
212
Accounts holding 2 to 21 markets. A paged scan of the Hideki markets indexer, 10,999 non-zero positions across 7,677 accounts; not an atomic on-chain snapshot, and accounts are not people.

What is proven, and where

Fixture, fork or live: every entry says which.

Fixture means synthetic data in unit tests. Fork means a local fork of the real venue at a recorded block. Live means Somnia Hideki itself.

  1. Fixture

    260 / 260

    Scenario arithmetic, rounding, the plan's two worked fixtures, exit codes after faults, the publication boundary

    Verified

  2. Fixture

    9 / 9

    The guard against mocks

    Verified

  3. Fork

    38 / 38

    IOC limits, guard invariants, rollback after venue fills, per-fill ledger

    Verified

  4. Fork

    12 / 12

    The live executor under faults: tampering, book change, partial fill, owner change, timeout, RPC outage, refused preflight, cleanup retries and failure, a result that cannot be written, funding drift

    Verified

  5. Fork

    Goal met

    The full loop on a real 6-market account

    Verified

  6. Live, read-only

    Exact ×4

    Independent reconciliation of real accounts with 3, 6, 9 and 21 markets

    Verified

  7. Live, read-only

    7,700 / 7,700

    The bank's rounding, every holder of every pool

    Verified

  8. Live write

    Goal met

    One guarded reduction on the project's test account, with verified cleanup

    Verified

Open the dashboardHow each entry was checked

Questions

Short answers. The guide has the long ones.

Does Margin Rescue hold a key or sign anything?

No. The site and the app read public chain data only. A reduction is signed in your own terminal, with your own wallet, from a plan you review; the browser never sees a key.

Is it part of dreamDEX?

No. It is an independent tool built on dreamDEX's perps testnet: it uses the venue's contracts, SDK and operator grant as they are, and is not affiliated with or endorsed by dreamDEX or Somnia.

Which network does it run on?

dreamDEX perps on the Somnia Hideki testnet, chain 50383. Any other chain is refused, and nothing touches mainnet or real funds.

What does an analysis read?

The whole account at one pinned block: the bank's collateral and health, every position in all 21 pools, resting orders, the stop list and the BTC and ETH books. Then the block hash is checked again, so the snapshot cannot mix two blocks. That is why it takes 15 to 25 seconds.

What if the answer cannot be trusted?

Then there is no recommendation. A stale mark, an inexact reconciliation, a stop list the indexer has not caught up on, or a linked child account blocks it, and the reason is shown.

Has it run on the live network?

Yes. The live write, one guarded reduction on the project's own test account: goal met and cleanup verified, independently read back from the chain. The read-only parts have run as well: four real accounts reconcile exactly, and 7,700 of 7,700 holders match the bank's rounding. The app shows the run's transactions, its recomputation and its cleanup.

Health equity 209.81 436.73 Maintenance 471.87 430.25 Buffer (262.05) 6.48 Fork run, at the scenario prices, before the guarded sell and recomputed from its fills

One account. Every market. One rescue.

Paste any dreamDEX account, choose the move, and read what is left of its buffer, which reduction would restore it, and what a real execution looked like.

Open appRead the guide

  1. FeaturesWhat each part of the loop does.
  2. DashboardLive BTC and ETH markets and every proof.
  3. GuideThe app, the command line, and your own account.
  4. TechnologyAccounting, scenario, guard, and the dreamDEX components it uses.

This is a static what-if at stated prices on the Somnia Hideki testnet. It does not predict prices, the path to them, liquidation, or fills of resting orders and stops along the way; an expected fill is not a guaranteed fill. The preferred reduction is the best of the candidates evaluated, not a global optimum. Nothing here is financial advice or concerns real funds.