Rovum Protocol, Whitepaper

The settlement layer for on-chain markets

Version 1.0 · 2026

Status & scope. Rovum is live on public testnet, with mainnet targeted for Q3 2026. This document describes the protocol as designed and as implemented on testnet. Forward-looking figures (settlement times, routing improvements, venue and chain counts, fee parameters) are design targets and testnet observations, not guarantees of mainnet performance. Token mechanics described here are the intended design and remain subject to audit, governance, and regulatory review. Nothing in this paper is financial, legal, or investment advice, or an offer or solicitation to buy any security. See §13, Risk Factors and Disclaimers.

1. Abstract

Capital markets are split in two. On one side sits the on-chain economy: crypto assets, stablecoins, and the composable rails of decentralized finance. On the other sits the real economy: equities, indices, and commodities, locked inside custodial venues, brokers, and a settlement system that still clears in days. Moving value between the two means off-ramping, waiting, re-onboarding, and trusting an intermediary with custody at every step.

Rovum is a settlement layer that erases that divide. It lets a holder trade any asset for any other (ETH for tokenized gold, BTC for Apple, USDC for the S&P 500) in a single, non-custodial, on-chain transaction, routed automatically to the best available execution across dozens of venues and multiple chains, and settled atomically in seconds.

Rovum is not an exchange that takes custody, nor a single liquidity pool. It is an intent-based settlement protocol: users sign an intent describing the trade they want; a competitive network of solvers discovers the optimal route across the entire market; and a minimal settlement contract executes the result atomically against the user's own wallet. Assets never leave the user's control until the moment of settlement, and settlement either completes in full or not at all.

This paper specifies the protocol: the settlement engine and why it achieves roughly 1.4-second finality; the routing engine that consistently beats a naive swap by 1–3%; the model by which real-world assets become tradable on-chain through regulated issuers; the non-custodial security architecture; and the ROV token that coordinates, secures, and accrues value from the network.

2. Introduction: the three walls

Every cross-asset trade today runs into at least one of three walls.

Wall 1: Walled-off markets. Crypto and real-world assets live in separate, incompatible systems. A crypto holder who wants exposure to gold or an index must leave the on-chain economy entirely: sell to stablecoins or fiat, withdraw to a bank or broker, buy the asset in a different venue under a different account, and accept that the two halves of their portfolio can never settle against each other directly. There is no native path from a token to a share.

Wall 2: Borrowed custody. The venues that do offer real-world assets are custodial. To trade, you deposit, handing assets to an intermediary that settles on its own terms, can halt withdrawals, can rehypothecate or lend out your balance, and concentrates counterparty risk. "Not your keys, not your coins" is not a slogan here; it is the operating model of nearly every venue that touches equities or commodities.

Wall 3: Fragmented liquidity. Even within crypto, liquidity is scattered across chains and venues. The same asset trades in dozens of pools on six or more networks, none deep enough alone to absorb size without moving the price. A trader either accepts slippage, or manually hunts for routes across bridges and interfaces, paying in time, gas, and execution quality.

These walls compound. The result is an investor experience that is slow (settlement measured in days), risky (custody surrendered at every step), and expensive (liquidity left on the table on every trade).

Rovum's answer is a single settlement layer for every market. Any asset routes to any asset; trades settle on-chain in seconds; and the user's keys never leave their wallet. No walls, no intermediaries, no wait.

3. Protocol overview

At a high level, Rovum has four cooperating parts.

        ┌──────────────────────────────────────────────────────────┐
        │                         USER                             │
        │   signs an intent  ("2.5 ETH → Gold, min 2.10 oz")       │
        └───────────────┬──────────────────────────────────────────┘
                        │ EIP-712 signature + Permit2 allowance
                        ▼
        ┌──────────────────────────────────────────────────────────┐
        │                   ROUTING ENGINE                         │
        │  builds the liquidity graph across 47 venues · 6 chains  │
        │  finds best execution, splits the order, broadcasts it   │
        └───────────────┬──────────────────────────────────────────┘
                        │ intent + best-known route
                        ▼
        ┌──────────────────────────────────────────────────────────┐
        │                   SOLVER NETWORK                         │
        │  bonded solvers compete to fill the intent at or above   │
        │  the user's limit, sourcing liquidity & RWA mint/redeem  │
        └───────────────┬──────────────────────────────────────────┘
                        │ winning fill
                        ▼
        ┌──────────────────────────────────────────────────────────┐
        │                 SETTLEMENT ENGINE                        │
        │  one atomic on-chain transaction:                        │
        │  pull input → execute route → deliver output → done      │
        │  (completes fully, or reverts, never partial)           │
        └──────────────────────────────────────────────────────────┘

1. The user expresses what they want, not how to get it: a signed intent ("swap 2.5 ETH for gold, receive at least 2.10 oz, before this deadline"). No deposit, no custody transfer, just a signature and a scoped allowance.

2. The routing engine quotes the intent against the whole market in real time, building a graph of every viable path across 47 venues and 6 chains, splitting the order where splitting helps, and identifying the cheapest execution. This is the "best execution, automatically" layer.

3. The solver network is a set of bonded, competing fillers. Each solver tries to satisfy the intent at or above the user's limit price using its own inventory and the routes the engine surfaced, including minting or redeeming tokenized real-world assets through issuer adapters. Competition between solvers is what drives execution quality and compresses spread.

4. The settlement engine is the on-chain endpoint: a minimal, audited contract that executes the winning fill atomically. In a single transaction it pulls the user's input asset (via their signed allowance), runs the route, and delivers the output asset back to the user's wallet. If any leg fails, the whole transaction reverts and the user keeps their original asset. Settlement is all-or-nothing.

Everything else in the protocol, cross-asset swaps, the routing engine, instant settlement, real-world assets, non-custodial guarantees, multi-chain liquidity, fiat ramps, and the developer SDK, is a property or surface of these four parts. Rovum is not eight products; it is one settlement primitive, exposed eight ways.

4. Architecture

4.1 Design principles

Four principles constrain every design decision:

1. The user never gives up custody. Assets move exactly once, in the settlement transaction the user authorized, and only if the user receives what they signed for. There is no deposit step and no protocol-held balance.
2. Settlement is atomic. A trade completes in full or reverts. Users are never left holding a half-finished cross-asset position.
3. Execution quality is competitive, not administered. Rovum does not set prices. A market of solvers competes to fill each intent, and the best fill wins. The protocol's job is to make that competition fair, fast, and verifiable.
4. The protocol is minimal and verifiable. The on-chain settlement contract is small, audited, and does as little as possible. Complexity (routing, inventory, cross-chain rebalancing) lives off-chain in actors who post bonds and can be slashed, never in custody of user funds.

4.2 Intents, not orders

Traditional exchanges take orders: precise instructions to buy or sell a specific amount at a specific venue, which the exchange then custodies and matches. Rovum takes intents: a declarative statement of the desired outcome, signed but not yet executed.

An intent is an EIP-712 typed message containing, at minimum:

Crucially, signing an intent does not move funds. It authorizes a future settlement contract to pull at most sellAmount of sellAsset, and only in a transaction that simultaneously delivers at least minBuyAmount of buyAsset to the user. Token access is granted through Permit2-style scoped, expiring allowances rather than blanket approvals, so a signed intent that is never filled simply expires and grants nothing.

This inversion, outcome instead of instruction, is what makes everything downstream possible. The user does not need to know which of 47 venues across 6 chains has the best gold liquidity right now; they need only state that they want gold. Discovering the how is the engine's job.

4.3 The settlement engine

The settlement engine is the heart of the protocol: a compact, immutable smart contract deployed on each supported settlement chain. It has exactly one job, execute a matched intent atomically, and it does it in one transaction with the following structure:

settle(intent, signature, route):
  1. verify, recover the signer, check nonce/deadline/chainId, confirm
               the intent has not been settled before
  2. pull, transfer exactly intent.sellAmount of intent.sellAsset
               from the user via their Permit2 allowance into the engine
  3. execute, run `route`: a sequence of calls to whitelisted venue
               adapters (DEX pools, RWA issuer mint/redeem, stable hops)
  4. check, require the engine now holds ≥ intent.minBuyAmount of buyAsset
  5. deliver, transfer the output to intent.receiver; refund any surplus
  6. settle, mark the nonce used; emit a Settlement event
  ── if any step fails, the entire transaction reverts ──

Several properties follow directly from this design:

• Atomicity. Steps 2–5 occur in one transaction. The user's ETH is only pulled if, in the same transaction, they receive their gold. A failure anywhere, a venue reverts, slippage exceeds the limit, an adapter is paused, reverts everything. The user's original asset is untouched.
• Non-custody. The engine holds assets for the duration of a single transaction and nothing longer. There is no balance to freeze, lend, or lose. Between transactions, the protocol holds nothing.
• Limit enforcement on-chain. minBuyAmount is checked by the contract, not trusted to the solver. A solver cannot deliver less than the user signed for; the math is enforced in step 4.
• Surplus belongs to the user. If the solver's route returns more than minBuyAmount (positive slippage), the surplus is delivered to the user in step 5, not kept by the solver. This aligns solvers with users: they win by finding better routes, and the user captures the upside.
• Minimal trusted surface. The engine itself contains no pricing, no routing, and no order book, only verification, transfers, adapter calls, and a final inequality. This is what makes it small enough to audit exhaustively (a full CertiK audit is underway) and safe to make immutable.

Venue adapters are thin, individually-audited modules that translate the engine's generic "swap X for Y here" into a specific venue's interface, a Curve pool, a Uniswap v4 hook, a Balancer vault, or an RWA issuer's mint/redeem endpoint. Adapters are added by governance and can be paused independently, so a problem at one venue never compromises the engine or other venues.

4.4 How settlement reaches ~1.4 seconds

"Settled in seconds, not days" is a claim about two different clocks, and it is worth separating them.

The traditional clock: T+2. When you buy a share through a broker, the trade executes immediately but settles two business days later (T+2). In that window, a clearing house stands between buyer and seller, custodians update their books, and counterparty risk is live. Settlement is slow because it is a multi-party reconciliation across institutions that don't share a ledger.

The Rovum clock: block finality. On Rovum, execution and settlement are the same event: the atomic transaction in §4.3. There is no clearing house and no separate settlement window, because buyer, seller, and the assets all share one ledger, the chain. "Settlement time" is therefore simply the time from the user signing to the settlement transaction reaching finality on the settlement chain.

That time is dominated by the chain, not by Rovum. Rovum settles on fast-finality chains (Base, Arbitrum, Optimism, Polygon, and Solana) where block times and economic finality land in the sub-second to ~2-second range. Measured end-to-end on testnet (sign → broadcast → solver fill → on-chain finality), typical settlements land around 1.2–1.5 seconds, which is why the protocol advertises ~1.4s typical. Ethereum mainnet, with ~12-second blocks, is supported as a liquidity source (see §4.6) but is not a primary settlement chain precisely because its finality is too slow for the target experience.

In short: Rovum is not "fast" because it invented a new consensus. It is fast because it collapses execution and settlement into a single on-chain event and runs that event where blocks are quick, turning a two-day, multi-institution process into one transaction.

4.5 The routing engine (best execution)

For any pair the user might want, ETH→Gold, BTC→Apple, USDC→S&P 500, there is rarely a single direct market, and even where one exists, it is rarely the best price. The routing engine's job is to quote the intent against the entire market and find the optimal way to fill it.

The liquidity graph. The engine models all available liquidity as a directed graph. Nodes are assets (ETH, USDC, XAU, AAPL, …); edges are venues that can convert one into another (a Curve pool, a Uniswap pool, an RWA issuer's mint or redeem, a stable-to-stable hop). Each edge carries a live cost model: spot price, fee, gas, and, critically, a price-impact curve describing how the marginal rate worsens as size grows. Across 47 venues and 6 chains, this graph has thousands of edges.

Finding the route. Filling an intent optimally is a min-cost / max-output problem on this graph:

1. Pathfinding. A modified Bellman-Ford/Dijkstra search enumerates candidate paths from sellAsset to buyAsset, including multi-hop paths through stable intermediaries (USDC, DAI, USDT), for example ETH → USDC → XAU when the direct ETH→gold market is thin. The example route the testnet surfaces for ETH→Gold, ETH → USDC → Gold via Curve · Ondo, is exactly this kind of two-hop path.
2. Order splitting. Because each edge's price impact rises with size, the cheapest fill for a large order is usually split across several paths. The engine solves for the split that equalizes marginal price across all chosen paths, the convex-optimization condition for optimal execution. Splitting an order so that the last dollar through each route costs the same is provably optimal for convex impact curves.
3. Net-of-everything comparison. Candidate solutions are ranked by output net of fees, gas, price impact, and cross-chain cost, not headline spot price. The winner is the route that puts the most buyAsset in the user's wallet.

Where the "AI" is. Two components go beyond static graph search:

• Liquidity forecasting. Depth and price impact are not static; they move with order flow and market conditions. Rovum runs predictive models over historical and live venue data to anticipate where depth will be in the seconds ahead, which venues are about to be cheap. This is the same machinery behind the "settlement opportunity" signals the product surfaces (e.g., "ETH → Gold is routing 1.9% better than direct right now, liquidity on Curve · Ondo is unusually deep"): the engine continuously scores pairs for transient routing advantages.
• Solver competition. The engine's route is a strong baseline, not a mandate. It is broadcast to the solver network (§4.6), and any solver that can do better, using private inventory, just-in-time liquidity, or a route the engine didn't see, wins by delivering more to the user. The combination of a high-quality baseline and an open competition to beat it is what reliably produces the 1–3% improvement over a naive direct swap that Rovum targets.

Best execution is enforced where it matters: on-chain. However good or bad the route, the settlement contract still requires the user receive at least their signed minBuyAmount, and pays them any surplus.

4.6 Liquidity: aggregation and the solver inventory model

Rovum holds no liquidity of its own and runs no pool. It aggregates liquidity that already exists and adds a layer of professional market-makers, solvers, on top.

Aggregation. Through venue adapters, the engine can source from automated market makers (Curve, Uniswap, Balancer), RWA issuers (Ondo, Backed, Matrixdock; see §5), and other on-chain venues across all six chains. By treating them as one graph, Rovum presents deeper effective liquidity than any single venue, so size that would "walk the book" in one pool is spread across many and fills at a fairer average price. Testnet liquidity by chain illustrates the spread, for example, Ethereum, Base, and Arbitrum each contributing tens of millions in routable depth, alongside Solana, Optimism, and Polygon.

Solvers and inventory. A solver is a bonded actor (an individual, fund, or market-maker) that competes to fill intents. Solvers add three things on top of raw venue liquidity:

1. Inventory. A solver can fill a user instantly from its own balance and rebalance against venues afterward, removing even venue latency from the user's path.
2. Just-in-time sourcing. Solvers can assemble liquidity the public graph doesn't expose (OTC, private pools, their own RWA positions).
3. Risk absorption. Most importantly, solvers absorb the timing and cross-chain risk that would otherwise fall on the user (see §4.7).

Solvers are kept honest by economics, not trust. To participate, a solver posts a bond in ROV. When a solver commits to fill an intent and fails to settle it within the deadline, its bond is slashed and the intent is re-broadcast. Solvers profit from the spread between the price they source and the price they deliver, but the settlement contract caps that profit at the user's surplus (positive slippage flows to the user, not the solver), so solvers compete on efficiency, not on extracting from users.

4.7 Cross-chain settlement

Cross-chain is where most "trade anything" systems quietly become custodial or non-atomic. Rovum's design keeps the user's settlement single-chain and atomic, and pushes cross-chain complexity onto solvers who are paid and bonded to carry it.

The key insight: the user does not need a cross-chain transaction; they need the best price, which may live on another chain. Consider a user on Base who wants an asset whose deepest liquidity is on Arbitrum:

1. The user signs a single intent on Base and never touches another chain.
2. The routing engine sees the best execution involves Arbitrum liquidity and surfaces it.
3. A solver fills the user on Base, atomically, from its own inventory. The user's settlement is the ordinary single-chain transaction of §4.3, with all the same atomicity and non-custody guarantees.
4. The solver then rebalances its inventory across chains on its own time, sourcing the asset on Arbitrum and using cross-chain messaging, Rovum uses Chainlink CCIP and canonical bridges for solver rebalancing, to move value where it needs to be.

From the user's perspective, settlement is atomic and confined to one fast chain. The asynchronous, slower, riskier cross-chain leg is borne entirely by the solver, who is compensated by spread and disciplined by its bond. This is the only model that delivers "cross-chain" execution without asking the user to trust a bridge with custody mid-trade or to accept a non-atomic, multi-transaction settlement that can strand them halfway.

For assets that must genuinely move across chains for the user (not just for the solver's books), Rovum uses canonical bridges and CCIP under the same atomic wrapper where the destination chain's finality allows, and otherwise presents the operation honestly as a bridge-plus-settle with its own confirmation, never disguised as instant.

5. Real-world assets

The most differentiated thing Rovum does is let on-chain capital trade real-world assets, Apple, Tesla, the S&P 500, gold, as easily as it trades tokens. This section explains what those assets actually are, who backs them, and how a swap into "Apple" is really executed.

5.1 Rovum does not issue securities

Rovum is a settlement and routing layer, not a tokenization issuer. It does not custody equities, mint claims on gold, or take the regulatory position of a securities issuer. Instead, it integrates established, regulated tokenization providers and routes trades into and out of their tokens. The RWA issuers referenced across the protocol are real infrastructure:

• Ondo Finance: tokenized treasuries and yield products, and tokenized equity exposure.
• Backed Finance: bToken tokenized equities and ETFs, issued under a regulated European framework with 1:1 backing held by a custodian.
• Matrixdock: tokenized gold (XAUm) and short-term treasuries, with audited vault/reserve backing.

These issuers hold the real underlying, shares at a broker/custodian, gold in a vault, treasuries with a regulated agent, and provide the two operations that matter: mint (deposit the underlying or its cash equivalent, receive the token) and redeem (return the token, receive the underlying or cash). The token is a transferable, on-chain claim that the issuer guarantees to back and redeem. "Backed and redeemable" is a property the issuers provide; Rovum's contribution is to make that token reachable in a single swap.

5.2 What a swap into "Apple" actually does

When a user signs an intent to swap BTC for Apple, the engine and a solver may execute it one of two ways, whichever is cheaper net of cost:

• Secondary route. Buy the issuer's already-circulating equity token (e.g., a Backed bAAPL) on a DEX venue, fast, and best when secondary liquidity is deep.
• Primary route. Convert BTC to the issuer's accepted stable, mint fresh tokens directly from the issuer through its adapter, and deliver them, best for size, since primary mint has no secondary slippage.

The routing engine chooses between these the same way it chooses any route: by net output. Either way, the user signs once, settles atomically on-chain, and ends up holding a backed, redeemable claim on Apple sitting in the same wallet as their crypto, with the option, at any time, to swap it back or (where the issuer permits) redeem it for the underlying.

5.3 Pricing, oracles, and eligibility

• Pricing. Real-world asset prices are sourced from Chainlink oracles and the issuers' own reference rates. The settlement contract still enforces the user's signed minBuyAmount, so an oracle is an input to routing and risk checks, never the sole determinant of what the user receives.
• Market hours. Equities trade on exchange schedules; their tokenized forms can trade 24/7 but with thinner, wider markets when the underlying market is closed. The engine prices this into routing (wider spreads off-hours) and surfaces it to the user.
• Eligibility. Some tokenized securities are permissioned under the issuer's regulatory framework and are not available to all users or all jurisdictions. Eligibility is enforced at the issuer/adapter boundary, Rovum routes only what a given user is permitted to hold, and the protocol itself takes no custody and makes no securities offering. This boundary is a core part of the compliance design and a real constraint on which RWAs are available where (see §13).

6. Security and the non-custodial model

Security at Rovum is not a feature bolted onto a custodial core; it is a consequence of the architecture. Because the protocol never holds user funds, the entire category of "exchange loses/freezes/rehypothecates customer assets" does not apply.

6.1 What "non-custodial" precisely means here

• No deposits. There is no step where a user sends assets to Rovum and waits. Users hold their assets in their own wallets at all times.
• Sign, don't surrender. A user authorizes a trade with an EIP-712 signature and a scoped Permit2 allowance, permission for the settlement contract to pull at most the sell amount, only in a transaction that delivers the buy amount. An unfilled intent grants nothing and expires.
• One-transaction custody. The settlement contract touches assets for the duration of a single atomic transaction and never between transactions. There is no protocol balance to freeze, lend, or lose. There is no withdrawal queue because there is nothing to withdraw from.
• Your keys throughout. At settlement, the user receives the output directly to their own wallet. Custody is never transferred to Rovum, a solver, or a venue.

6.2 Smart-contract security

• Minimal surface. The settlement engine is small by design (verify, pull, execute, check, deliver) and immutable once deployed, which is what makes exhaustive audit feasible.
• Audit. The contracts are undergoing a full audit with CertiK; the report will be published on-chain once it is complete. The ROV token contract will be verified and viewable on the block explorer at launch.
• Adapter isolation. Each venue/issuer adapter is independently audited and can be paused by governance without touching the engine, so a fault at one venue is contained.
• Allowance hygiene. Permit2 scoping means users never hand out unbounded approvals; allowances are bounded in amount and time.

6.3 Solver and economic security

• Bonds and slashing. Solvers post ROV bonds and are slashed for committing to an intent and failing to settle it. Misbehavior is expensive; honest filling is profitable.
• User-protective settlement math. The contract enforces minBuyAmount and routes positive slippage to the user, so even a malicious solver cannot deliver less than promised or skim the upside.
• MEV resistance. Because users sign limit-protected intents (not public market orders) and solvers compete to fill them, often via private order flow, the usual sandwich/front-run vectors are structurally reduced. The worst a hostile actor can do is fail to fill an intent, which simply re-broadcasts it.

6.4 Treasury and transparency

Presale and protocol funds are held in a verifiable, on-chain multisig treasury, with institutional-grade key management and transaction security provided by Fireblocks MPC infrastructure, the same rails Rovum exposes to institutional solvers and partners (see §8). Note this secures the protocol's own treasury and institutional participants' operations; it is never custody of user funds, which remain non-custodial by design throughout. Allocations, vesting, and treasury movements are visible on-chain. The official presale runs only at app.rovum.net; Rovum will never DM users first or ask for a seed phrase.

7. Fiat on- and off-ramps

A settlement layer for every market has to connect to the one most people start and end in: their bank account. Rovum integrates regulated fiat rails so users can move between cash and on-chain assets without leaving the protocol.

• On-ramp. A card or bank deposit is converted to USDC (via Circle and licensed payment partners) and delivered to the user's wallet, from where it can be swapped into any asset on the protocol. Card on-ramps settle effectively instantly, with a transparent processing fee (testnet preview: ~1% for card deposits).
• Off-ramp. The reverse: any asset is settled to USDC on-chain, then converted to fiat and paid out to the user's card or bank through the same partners. The product preview shows the target experience, a withdrawal of $2,000 arriving on a Visa ···· 4242 instantly.
• The point. Ramps are deliberately boundary infrastructure. Inside Rovum everything is non-custodial and on-chain; the ramp is the thin, regulated edge where fiat meets the protocol. Getting in and out is never the hard part, and it never compromises the non-custodial core.

Fiat-rail availability, limits, and fees vary by jurisdiction and partner and are subject to the partners' own KYC/AML requirements.

8. Build on Rovum: settlement as a primitive

Everything described so far is exposed to developers through a single SDK, so any application can offer cross-asset, best-executed, atomic settlement without building any of it.

import { rovum } from '@rovum/sdk'

// One call: quote, route, and settle a cross-asset swap, non-custodially.
await rovum.swap({ from: 'ETH', to: 'XAU', amount: 1.2 })
// → settled · 1.9% better than direct

Under that one line sits the full engine: intent construction and signing, the routing engine's best-execution quote, solver competition, and atomic on-chain settlement. The SDK also exposes lower-level primitives, quote() to preview routing, intent() to construct and sign without settling, and subscriptions to settlement events, so builders can compose Rovum into their own flows.

Who builds on it. Rovum is designed to be the rail underneath other products: wallets adding in-app cross-asset swaps, fintech apps offering tokenized equities and gold, DeFi protocols needing best-execution settlement, treasuries rotating between crypto and real-world assets, and neobanks bridging fiat and on-chain markets. Every integration deepens shared liquidity and routes more volume through the protocol, the network grows with each app that builds on it, and that flywheel is a core part of the value thesis for the ROV token.

9. The ROV token

ROV is the coordination and value-capture asset of the protocol. It is a utility token: it secures the solver network, prices priority and discounts, governs the protocol, and accrues a share of the economics the network produces. It is not an equity, a debt, a deposit, or a claim on Rovum's revenue as a company (see §13).

ROV is woven through the protocol in four ways, the same four the product surfaces as the "value flows back to the token" hub.

9.1 Pay fees in ROV → up to 25% rebate

Rovum charges a small protocol fee on settlement (a few basis points of trade notional, layered on top of solver execution; the exact parameter is governed, see §10.4). Users may pay that fee in any asset, but paying in ROV earns a rebate of up to 25% versus paying in another asset. This does two things: it creates continuous, utility-driven demand for ROV from the protocol's own users, and it rewards the people most active in the network.

9.2 Stake ROV → routing priority + fee share

Staking ROV serves the network and the staker:

• Solver bonding. Solvers must stake ROV as the bond that backs their commitments (§6.3). Staked ROV is the economic security of the fill network.
• Routing priority. Staked participants receive priority in intent routing and solver selection, a faster, preferential lane that scales with stake.
• Fee share. A portion of every protocol fee is distributed to stakers, pro-rata. Stakers are paid by real network activity, in proportion to how much security they provide. This turns ROV into a productive, cash-flow-bearing position tied directly to protocol volume, not to emissions.

9.3 Governance → vote on listings and parameters

Staked ROV is voting power (§11). Holders govern which RWA issuers and venues are listed, fee levels and the rebate, solver bonding and slashing parameters, treasury allocation, and protocol upgrades. The people who use and secure the network steer it.

9.4 Buybacks → protocol fees buy back ROV

A share of protocol fees is used to buy ROV on the open market, with the bought tokens directed by governance toward stakers, the treasury's strategic reserves, or removal from supply. Buybacks tie token value directly to usage: as settlement volume grows, fee revenue grows, and a portion of that revenue becomes persistent buy-side pressure on ROV. Combined with the fixed supply (§10), buybacks make ROV deflationary in spirit even though no new tokens are ever minted. Value accrues by reducing effective float and returning economics to holders, not by inflating supply.

9.5 The value loop

   more apps & users  ─►  more settlement volume  ─►  more protocol fees
          ▲                                                  │
          │                                                  ├─► fee rebate (demand for ROV)
          │                                                  ├─► staker fee share (yield on ROV)
          │                                                  ├─► buybacks (buy-side pressure)
          │                                                  └─► treasury (funds growth, grants)
          │
   deeper liquidity & better execution  ◄──────────────  staking secures solvers

Each mechanic reinforces the others: usage produces fees; fees create ROV demand (rebates), yield (staking), and scarcity (buybacks); staking secures the solver network that produces the execution quality that attracts more usage. ROV is the asset through which the network's growth and its security are the same thing.

10. Tokenomics

10.1 Supply

ROV has a fixed total supply of 1,000,000,000 (one billion) tokens. There is no inflation and no ongoing emission schedule: every token that will ever exist is allocated at genesis. All network rewards (staking yield, ecosystem incentives) are paid from pre-allocated buckets and from real protocol fees, never from minting new supply.

10.2 Distribution

The distribution is deliberately community-weighted: 60% of supply (presale + community/ecosystem) is directed to users and the network rather than insiders. Team and advisors together hold 16%, fully on transparent vesting.

10.3 Vesting and unlocks

Vesting is designed to align long-term contributors with the network and to avoid supply shocks:

Indicative figures; the canonical schedule and on-chain vesting contracts are published at TGE and are governed thereafter.

10.4 Fee model and value capture

• Protocol fee. A small, governed fee (basis points of notional) is taken at settlement, on top of competitive solver execution. Because solvers compete and positive slippage flows to users, the all-in cost to a user remains low, and net of routing improvement, frequently better than a direct swap even after the fee.
• Fee routing. Protocol fees are split, by governed parameters, among: stakers (fee share), buybacks (open-market ROV purchases), and the treasury (growth, grants, security). Paying fees in ROV earns the up-to-25% rebate.
• No inflation funding. Crucially, none of this is funded by minting ROV. Yield and incentives come from genuine activity and pre-allocated buckets, so ROV's value capture scales with usage, not with dilution.

10.5 Presale

The presale distributes the 30% public allocation and funds mainnet delivery.

At the launch price of $0.1, ROV's fully-diluted valuation is $100M. The rising-stage structure rewards earlier participants with a lower entry, and the entire public allocation is distributed at TGE, with team/treasury/advisor allocations following the vesting schedules above. (Figures reflect the presale as configured; always verify the official URL.)

11. Governance

Rovum is designed to progressively decentralize control to ROV stakers.

What governance controls.

• Listings. Which RWA issuers, venues, and assets are integrated (and which are paused/removed).
• Economic parameters. The protocol fee, the ROV fee rebate, the split of fees between stakers/buybacks/treasury, and solver bonding/slashing parameters.
• Treasury. Allocation of the treasury and the disposition of bought-back ROV.
• Upgrades. Adapter additions, new settlement chains, and protocol parameter changes (the core settlement engine is immutable; governance acts at the adapter/parameter layer and via new deployments, not by mutating audited settlement logic).

How it works. Voting power derives from staked ROV, aligning governance with the people who both use the protocol and post the security that backs it. Proposals follow a standard lifecycle (temperature-check discussion, formal on-chain proposal, time-locked execution), with a timelock between a passed vote and its execution so users always have advance notice of change. The path moves from a foundation-stewarded launch toward full community control as the network and its governance mature.

12. Roadmap

The sequencing is deliberate: crypto-to-crypto best-execution settlement proves the engine at mainnet, then real-world-asset pairs and the institutional surface expand the market the engine settles. The token's value mechanics (fees, staking, buybacks) activate with mainnet volume.

13. Risk factors and disclaimers

This section is not boilerplate. The architecture in this paper has real dependencies and real risks, and a serious reader should weigh them.

Protocol and technology risk. Smart contracts, however audited, can contain undiscovered vulnerabilities. Adapters integrate external venues and issuers whose own contracts carry independent risk. Atomic settlement protects users within a transaction but cannot protect against a flawed adapter or a compromised dependency.

Real-world-asset / counterparty risk. Rovum does not issue or custody real-world assets; it routes to third-party tokenization issuers (e.g., Ondo, Backed, Matrixdock). The backing and redeemability of those tokens depend entirely on those issuers, their custodians, and their regulatory standing, not on Rovum. Issuer insolvency, custody failure, redemption suspension, or de-pegging of a tokenized asset are risks borne by the holder of that asset.

Regulatory risk. Tokenized securities and commodities are subject to evolving and jurisdiction-specific regulation. Some assets are permissioned and unavailable to certain users or regions; availability may change; and regulatory action could affect issuers, ramps, or the protocol's reach. Fiat ramps depend on licensed partners and their KYC/AML obligations.

Cross-chain and solver risk. Cross-chain liquidity sourcing relies on solvers, bridges, and messaging (e.g., Chainlink CCIP), which carry latency and security assumptions. Solver bonds mitigate but do not eliminate the risk of failed or delayed fills; a thin solver market could widen spreads or slow settlement.

Liquidity and market risk. Execution quality depends on available liquidity, which varies by asset, chain, and time (notably for equities outside market hours). "1–3% better than direct" and "~1.4s" are targets and testnet observations, not guarantees. Asset prices can move sharply; tokenized RWAs can trade away from their underlying.

Token and presale risk. ROV is a utility token whose value, if any, depends on protocol adoption and is subject to extreme volatility and potential total loss. Forward-looking statements (roadmap, mainnet timing, value mechanics) may not materialize. Presale participation involves risk of loss.

No advice; no offer. Nothing in this document is financial, investment, legal, or tax advice, or a recommendation to buy, sell, or hold any asset. ROV is described as a utility token and this paper is not an offer or solicitation to buy a security in any jurisdiction. Forward-looking statements are subject to change without notice. Participants are responsible for their own due diligence and for complying with the laws of their jurisdiction. Only use the official URL, app.rovum.net; Rovum will never contact you first or request your seed phrase.

14. Conclusion

Markets fragmented into two systems, the on-chain economy and the real economy, connected only by slow, custodial, lossy bridges. Rovum's bet is that the connection should be a settlement primitive, not a venue: a way to turn any asset into any other in one atomic, non-custodial, best-executed transaction, and to expose that capability to every user and every developer through a single rail.

The design follows from that bet. Intents instead of orders, so users state outcomes and keep custody. A competitive solver network instead of an order book, so execution quality is earned, not administered. A minimal atomic settlement engine on fast chains, so a two-day clearing process becomes one transaction. Third-party regulated issuers behind adapters, so real-world assets are reachable without Rovum becoming a securities custodian. And a token, ROV, through which using the network, securing it, and owning a share of its economics are the same act.

The walls between crypto and the real economy were never laws of nature; they were missing infrastructure. Rovum is building the rail through them.

Glossary

• Adapter: a thin, audited module that lets the settlement engine interact with a specific venue or RWA issuer; pausable and isolated.
• Atomic settlement: a trade that completes entirely or reverts entirely, never partially.
• Best execution: filling a trade at the optimal achievable price net of fees, gas, slippage, and cross-chain cost.
• EIP-712: the Ethereum standard for signing structured, human-readable data; how Rovum intents are signed.
• Intent: a signed, declarative statement of a desired trade outcome (sell X, receive at least Y) that authorizes, but does not execute, a future atomic settlement.
• Permit2: a token-approval standard enabling scoped, expiring allowances, used so a signed intent grants access only within bounds and only if filled.
• RWA (real-world asset): an off-chain asset (equity, index, commodity) represented on-chain as a backed, redeemable token issued by a regulated provider.
• ROV: the protocol's utility token: solver bond, fee rebate and discount, staking/fee-share asset, governance vote, and buyback target.
• Routing engine: the system that models all liquidity as a graph and computes the best-execution route (and order split) for an intent.
• Solver: a bonded, competing actor that fills user intents, sources liquidity and RWA mint/redeem, and absorbs timing and cross-chain risk.
• Settlement engine: the minimal, immutable on-chain contract that executes a matched intent atomically and enforces the user's limit.
• TGE (Token Generation Event): the event at which ROV is generated and distributed to presale participants and allocations.

Rovum Protocol · Whitepaper v1.0 (draft) · The settlement layer for on-chain markets · rovum.net