Sudont’s Cage is a dual-engine physics simulator. Every transaction is dropped into a local
revm (EVM) or LiteSVM (SVM) memory sandbox before it hits the chain. Both engines are
first-class citizens.
A single CanonicalIntent carries a vm_type field that routes it to the correct Cage
implementation. The architecture is unified at the type level — the Judge and the rest of the
pipeline are completely VM-agnostic.
Defined in sudont-types, SimulationEngine is the contract both Cage implementations fulfill:
SimulationEngine — VM-Agnostic Interface
/// Both EVM and SVM cages implement this trait.pub trait SimulationEngine: Send + Sync { fn simulate(&self, intent: &CanonicalIntent) -> Result<SimOutcome, String>;}
The CanonicalIntent input carries the vm_type discriminant:
VmType Enum
pub enum VmType { Evm, Svm,}
The RPC layer reads vm_type and dispatches to the correct SimulationEngine implementation
at runtime — no conditional logic needed in the Judge or policy layers.
EVM engine is on the roadmap — Wave 14+. The shipped private alpha is
Solana-only via LiteSVM. The integration points described below (revm,
reth-backed state, Uniswap V3, Aerodrome adapters) are the planned design and
are not yet wired into the demo. Treat this section as forward-looking
architecture documentation.
Rust crate (planned):sudont-cageDependency (planned):revm = "14.0"The EVM Cage will use revm — a pure-Rust, production-grade
Ethereum Virtual Machine implementation.
Exact Semantics
Byte-for-byte compatible with geth/reth execution
Full State Access
Storage slots, emitted logs, and state diffs
Gas Accounting
Precise gas computation and revert reason extraction
EIP Support
EIP-3607 and active EIPs via feature flags
State source (planned): Local Base reth node with Flashblocks support. The simulation will
reflect the pending world, not a stale cache.Planned protocol adapters: Uniswap V3 (planned) (exactInputSingle, exactInput), Aerodrome (planned) router swap flows.
The Judge uses asset_changes to compute effective slippage and price impact against the
CanonicalIntent’s amount_out_min and slippage_bps fields.
Rust crate:sudont-cage-svmDependency:litesvmThe SVM Cage implements the same SimulationEngine trait for Solana transactions:
SVM SimulationEngine
pub struct SvmSimulator;impl SimulationEngine for SvmSimulator { fn simulate(&self, intent: &CanonicalIntent) -> Result<SimOutcome, String> { // intent.data holds the serialized Solana transaction bytes // The simulator deserializes into VersionedTransaction, // executes inside LiteSVM, and returns native logs + state diffs. }}
LiteSVM is a fast in-process Solana runtime that executes transactions without a validator:
State Hydration
Account state from RPC snapshots
Full Execution
Instruction-level Solana program execution
Log Capture
Compute unit accounting and log output
Mainnet Compatible
Supports loading real SBF binaries when needed
Standard Web3 clients submit native Transaction / VersionedTransaction payloads through the
Sudont RPC proxy; the proxy routes the decoded bytes into sudont-cage-svm with vm_type: Svm —
no client-side wrapping required.
The Sudont RPC proxy reads the VM discriminant directly from the incoming request and dispatches
to the correct engine:
Endpoint family
Engine
Crate
eth_*, sudont_* (EVM)
revm
sudont-cage
solana_*, sudont_* (SVM)
LiteSVM
sudont-cage-svm
The Judge, Constitution, and diagnostic machinery are shared — only the simulation backend
differs. Point a standard Ethers or Solana Web3 client at the proxy and the correct engine is
selected automatically.
