Five sections covering the structural decisions, the data model under them, and the operational characteristics you can show to an architecture review or a regulator.
§ 01
Why one terminal across five chains is hard
The temptation when building multi-chain is to write five client adapters and call it done. The reality is that each chain has different finality semantics (Solana 400ms slot, Ethereum 12s, Arbitrum sub-second-to-eventual), different fee dynamics (Ethereum gas markets, Solana priority fees, Base sequencer), different MEV exposure (Ethereum builder ecosystem, Solana Jito bundles), and different RPC reliability profiles. A user-facing terminal that simply abstracts these into a uniform UI either lies about latency or breaks when a chain misbehaves. Coreal's terminal makes the differences visible where they matter (latency expectations, MEV risk, fee level) and uniform where they don't (order entry, position tracking, history).
§ 02
Anti-MEV runtime: how it actually works
Anti-MEV protection is not a single check — it's a runtime that runs on every order submission. Before a transaction goes to the chain, the runtime simulates it against the current mempool/bundle state, computes the expected slippage assuming an adversary inserts ahead, and decides between three paths: (1) submit normally if the order is unattackable (small enough or in a non-MEV-active block); (2) submit through a protected relay (Flashbots Protect on Ethereum, Jito bundles on Solana) if the order is attackable but value-transferring; (3) refuse to submit and surface a warning if simulation shows unavoidable loss. The user sees a colour-coded indicator on every order; the system records the simulation hash for replay.
§ 03
Off-chain orderbook with on-chain settlement
Limit orders that wait for hours or days are wasteful and risky to keep on-chain — they create rebalancing storms when prices move and they expose intentions to MEV. Coreal's terminal maintains an off-chain orderbook with deterministic matching: every match generates a settlement bundle that is posted on-chain only at execution. The orderbook itself is journaled — every place, modify, cancel and match is an event with cryptographic continuity. If a user disputes "you didn't fill my order at price X", the journal answers definitively: at time T the orderbook state was Y, the best available price was Z, and the match decision was deterministic.
§ 04
Copy trading risk envelope
Copy trading lets a user mirror selected wallets with a configured allocation. The naive implementation copies every transaction; the result is a copier with no risk controls who follows the leader into liquidation. Coreal's copy trading wraps every mirrored action in a per-copier risk envelope: position size cap (% of leader's position), maximum drawdown trigger (auto-pause if leader is down N%), excluded assets, max leverage. When the leader executes, the copier's position is adjusted by the envelope-clipped amount, not the raw size. The leader doesn't know who follows; the follower has explicit, configurable, replayable risk parameters.
§ 05
Settlement bundles and replay
Every executed trade produces a settlement bundle: a typed record of the order, the match, the chain, the on-chain transaction hash, the price paid, the slippage, and the gas/fee paid. Bundles are immutable and replayable — given a bundle, the system can deterministically reconstruct the order book state, the matching decision, and the chain state at the time of execution. This matters for two reasons: (1) it produces a regulator-grade audit trail that meets MiCA/MiFID conduct requirements; (2) it enables backtesting and retrospective analysis without re-running the matcher. Trade journals are the single source of truth.