Why MagicBlock is part of our Solana architecture
MagicBlock Ephemeral Rollups extend Solana with a specialized Solana Virtual Machine (SVM) runtime. SDICE Perps delegates selected Solana state accounts to an ER validator, executes its Solana program against that state, and commits the resulting state back to Solana. Users keep their Solana wallets and deposited tokens remain in Solana program-controlled vaults.
This is onchain program execution in an auxiliary Solana execution environment. An ER confirmation is not the same as a finalized Solana mainnet transaction: commitments and base-layer settlement are separate steps. Delegation and the ER validator add their own security and availability assumptions.
- Delegate Solana state
- Execute in MagicBlock
- Commit to Solana
What “fully onchain” means here
The authoritative financial state is held in program accounts across the ER and Solana base layer. The program records positions and their opening and closing prices, applies PnL and liquidation rules, and enforces the settlement accounting. Mainnet programs control token transfers, settlement swaps, the FIFO payout queue, ownership balances and staking rewards.
The browser displays that state. The backend relays prices, prepares transactions, submits keeper actions and caches history. Those services run offchain, but a database edit alone cannot transfer vault tokens or create an onchain claim. They submit transactions and inputs that must pass the program’s checks.
Price updates in milliseconds
MagicBlock documents Pyth Lazer oracle-account updates every 50–200 milliseconds, depending on the asset. SDICE Perps price sampler targets 250-millisecond intervals, and the shared browser price relay sends up to four updates per second. These are feed specifications and scheduling targets, not a guarantee of end-to-end trade latency or a measurement of every live update.
The trading program reads supported market oracle accounts in the ER. Existing account notifications also drive the live chart and price display. Each displayed tick does not require its own Solana mainnet transaction. Commits and settlement still have costs, and a displayed tick is not a guaranteed execution price.
From a position to spendable tokens
Opening and closing update delegated position state in the ER. Required state is then committed or released to Solana, where settlement transactions return unused collateral, execute any required swaps and record the final pool and ownership amounts. Winning profit enters the onchain FIFO queue and is paid in USDC as liquidity permits.
A closed position, a completed settlement and a paid FIFO claim are different events. Fast price updates do not promise an instant withdrawal or payout.
Onchain execution still has trust assumptions
SDICE Perps relies on MagicBlock’s validator and oracle accounts, authorized publisher inputs for collateral valuation and settlement, keepers, and the program’s upgrade authority. Freshness, permissions and replay checks constrain accepted inputs; they do not make an authorized publisher’s quote independently trustless.
The current market-price path consumes MagicBlock-attested oracle account data; SDICE Perps does not independently verify every underlying Pyth Lazer signature. Onchain describes where financial rules execute and state is recorded. It does not mean every service runs onchain, every input is independently verified, or every ER update has already finalized on mainnet.