Monero provides private digital money, but its consensus does not execute general-purpose smart contracts. XMRVM provides a separate execution environment where users can fund programmable applications with XMR, interact with internal balances, and request native Monero withdrawals.
V1 is a private SVM-based runtime operated as a service, with TEE protection as a planned deployment goal. Deposits are held under a platform custody model, and internal balances represent claims governed by the service’s reserve, execution, and withdrawal rules.
01 / THE MODEL
Monero for settlement. Runtime for applications.
A user sends native XMR to a deposit address associated with an XMRVM account. After deposit checks and the stated confirmation policy, the service credits an internal balance. Application calls update the runtime’s state; they do not create individual Monero transactions.
When a user requests an exit, the runtime reserves the relevant balance and the service processes a native XMR payout.
02 / VERSION ONE
A private SVM-based execution environment.
The current codebase uses LiteSVM inside the XMRVM service and exposes a custom Solana-style RPC interface. V1 keeps application state within that service rather than publishing it to Solana Mainnet.
“SVM-based” describes the execution technology that runs XMRVM applications: Solana-style programs executed inside the private runtime.
03 / APPLICATIONS
Agreements first. Broader finance later.
Initial use cases include escrow, conditional payments, subscriptions, and rule-bound agent payments. Exchanges, lending, token issuance, and treasury systems are longer-term application goals.
Private execution keeps application state inside the runtime, so users interact through the service’s own operation and custody model.
04 / PRIVACY & TRUST
Privacy by default. Trust made explicit.
Monero protects transaction details on its own network, and the private runtime keeps account association, service activity, and application state out of public view.
TEE attestation verifies the measured workload running the service. Reserve reconciliation, recovery, upgrades, and key control are part of the same design.
02 / ROADMAP
Build the trust model before scaling the promise.
Each phase depends on engineering, testing, and security evidence from the previous work.
01
V1 IMPLEMENTATION IN PROGRESSPRIVATE EXECUTION
Establish the private SVM foundation
Build the internal ledger, account interactions, deposit attribution, withdrawal state tracking, and a usable dApp flow.
SVM runtimeLedger accountingdApp interface
02
NEXT: VALIDATETEST-NET OPERATIONS
Prove the deposit-to-withdrawal lifecycle
Exercise deposits, confirmations, reorganization handling, payout signing, uncertain submissions, recovery, and reserve reconciliation end to end on a test network. Define account key backup and user support procedures.
Stagenet testingRecoveryReserve controls
03
PLANNEDTEE & VERIFIABILITY
Protect and verify the operating service
Select a TEE platform, package the runtime, bind remote attestation to reproducible releases, restrict key use, and design anti-rollback and recovery controls. Publish the threat model and obtain independent review before handling real value.
TEE deploymentAttestationIndependent review
04
FUTURE TRACKPUBLIC SOLANA
Evaluate public Solana programs
Design and deploy on-chain programs as a separate architecture track. Public Solana execution would expose on-chain activity and would not inherit Monero privacy automatically. Define bridging, custody, upgrade authority, and user disclosures before connecting any assets.
Program designPublic composabilityNew trust assumptions
03 / DAPP
A first look at the user experience.
An interactive look at the account dashboard and the escrow workflow.