Coreal.
Book a working session →
← PLATFORM·P3 · Trading OS · Terminal

Multi-Chain Trading Terminal

A trading terminal for the chain-fragmented reality. Wallets, watchlists, copy trades and limit orders work the same way across Solana and four EVM chains, with anti-MEV runtime guards on every quote.

TPS
10k
Chains
4
Guards
Anti-MEV
EVMSOLANACOPYRWA
01Capabilities

What ships in the box.

C-01

Wallet import

Read-only or signing wallets across SOL + EVM

C-02

Limit orders

Off-chain orderbook with on-chain settlement

C-03

Copy trading

Mirror selected wallets with risk limits

C-04

Anti-MEV guards

Sandwich/front-run detection on every quote

C-05

Watchlists

Real-time price + on-chain flow monitoring

C-06

Embedded payment cards

Spend balances directly via Coreal-issued cards

02Technical deep dive

How it works under the hood.

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.

03Data model

Core entities & key fields.

The handful of entities you would design first if you were building this from scratch. Naming and field shape match what an audit firm or counterparty would expect.

ENTITYPURPOSEKEY FIELDS
wallet_linkImported wallet (read-only or signing) per userid · user_id · chain · address · permission · signing_strategy
orderUser-submitted limit/market orderid · user_id · chain · pair · side · price · size · status · created_at
matchOrderbook match eventid · ts · taker_order · maker_order · price · size · settlement_id
settlement_bundleOn-chain settlement recordid · match_id · chain · tx_hash · gas · slippage · final_price
copy_linkCopy-trading relationshipid · follower_id · leader_address · envelope (json) · status · started_at
mev_simulationAnti-MEV pre-submission simulationid · order_id · expected_slippage · adversary_model · decision · relay_used
04Request lifecycle

From input to settled state.

The path a single operation takes through the system. Every step is journaled and replayable.

1. Order entryUser submits order in terminal UI; mobile/desktop client → BFF
2. Risk + envelopePosition size, leverage, copy envelope, KYT on counterparty checked
3. Orderbook matchDeterministic matcher pairs against resting orders or routes to AMM
4. MEV simulationPre-submission runtime decides direct / protected / refuse
5. Chain submissionSettlement bundle published via direct RPC or protected relay
6. Journal writeMatch + bundle + chain receipt stored in immutable trade journal
05Operational characteristics

What this looks like in production.

SLO-01
Execution kernel
10,000 TPS

Rust matcher sustained throughput

SLO-02
Order placement p95
< 60ms

UI submit → orderbook accept

SLO-03
Chain submission p95
< 800ms (SOL) / < 4s (ETH)

Order → confirmed on chain

SLO-04
MEV protection rate
> 95%

Of attackable orders routed through protected relay

SLO-05
RPC pool size
12+ providers

With circuit breakers and per-chain failover

SLO-06
Journal retention
7 years

Immutable trade and decision journal

06Architecture

Behind the surface.

Rust execution kernel (10k TPS) → multi-chain RPC pool with circuit breakers → off-chain orderbook with deterministic matching → settlement layer per chain. Anti-MEV runtime samples bundles before submission.

07Integrations

Vendors & rails.

Solana mainnetEthereumBaseArbitrumPolygonJitoFlashbotsCoreal Card
08Regulatory posture

CASP-ready under MiCA when activated · KYT pre-flight on every wallet · travel-rule compliant · audit-grade trade journal.

09Adjacent products

The rest of the platform.