Documentation

Operate on Railnet

Railnet was designed to provide a future-proof infrastructure that addresses the needs of regulated asset managers, solving for the operational complexity, trustworthiness, and auditability of onchain asset management. In this guide, we will present why you should build your strategies on Railnet, and how to get started.

Where Existing Solutions Fall Short

Operational Complexity

  • Onchain yields are maturing, and protocols are becoming more complex. Designing rebalancing strategies, adapting to evolving mechanics, and maintaining safety at scale is extremely difficult.
  • This complexity forces asset managers to build custom infrastructure outside existing vault solutions diverting resources from delivering superior risk-adjusted returns.

Accounting

  • Regulatory compliance requires precise and timely valuation of on-chain positions. However, fragmented data, inconsistent fee structures, and reliance on oracle or third-party assumptions introduce uncertainty.
  • These factors make it challenging to achieve the "exact" accounting standards institutions expect, increasing operational and compliance risk.

Safeguards and Auditability

  • Running strategies onchain demands strict role separation, permission controls, and transparent execution paths.
  • Without these safeguards, operational actions become hard to audit, potentially unsafe, and misaligned with regulatory expectations slowing institutional adoption.

Benefits of Railnet

Railnet eliminates manual transaction crafting, idle-liquidity management, and offchain NAV systems. All allocations, flows, and in-flight assets are tracked and valued in real time by the contracts themselves.

Capability
Without Railnet
With Railnet
Allocation Guardrails
Define and enforce where capital can be deployed using explicit policies that constrain execution paths and prevent unauthorized allocations.
Before
Asset managers manually craft contract calls (on-chain or via MPC) and must deeply understand each protocol to operate safely. This is error-prone and difficult for third parties to verify as a strict, auditable permission set.
After
The multi-vehicle owner authorizes an asset manager to deposit/redeem to a specific yield source in a single operation, without protocol-specific knowledge, with explicit and verifiable execution constraints.
Unified Execution
A single execution layer where asset managers express intent and the contracts automatically handles all protocol logic, transactions, and asynchronous flows.
Before
Managers need deep protocol knowledge and maintain their own offchain backend for transaction crafting, sequencing, and timing to execute operations safely.
After
Managers express intent to route funds (A → B) and Railnet handles protocol logic and asynchronous flows, letting managers focus on risk-adjusted yields rather than infrastructure.
Automated Liquidity Management
Automatically route user deposits and redemptions based on predefined policies, with deterministic ordering and state-aware handling of asynchronous liquidity.
Before
Managers constantly monitor idle liquidity and rebalance manually (gas + ops overhead). Withdrawals often require maintaining idle liquidity or manually coordinating complex unwinds.
After
Entry/exit queues allocate deposits deterministically (e.g., first 20M to Morpho then Aave). Withdrawals follow configured exits (e.g., withdraw from Aave by default), reducing idle reserves and manual operations while handling async complexity.
Integrated NAV Calculation
Maintain a real-time, verifiable view of positions, flows, and yield across asynchronous protocols, serving as a single source of truth.
Before
Async flows make it difficult to track in-flight assets and compute NAV. Managers build custom accounting/oracles and push NAV on-chain to price shares correctly.
After
NAV is computed by the contracts in real time. In-flight assets are tracked using double-entry bookkeeping and ephemeral accounting, so asynchronous movements remain accounted for without additional engineering.

The STEAM Standard

Railnet vehicles implement the STEAM (State Transition Engine for Asset Management) standard — a protocol designed to overcome the limitations of traditional vault interfaces like ERC-4626.

Beyond ERC-4626

Traditional vaults assume synchronous operations: deposit assets, receive shares instantly. But many DeFi operations are inherently asynchronous:

  • Cooldown periods — Ethena requires waiting before unstaking sUSDe
  • Withdrawal queues — Syrup processes withdrawals in a FIFO queue
  • Multi-step strategies — MultiVehicle coordinates across multiple protocols

ERC-4626 has no mechanism for tracking in-flight operations or recovering from errors — failed transactions simply revert, losing all context.

From Balances to State Transitions

STEAM introduces Queries — structured requests with persistent identity and a clear state machine. Every operation moves through defined states:

  1. Creation → Assets are pulled, operation is initiated
  2. Execution → Vehicle interacts with the underlying protocol
  3. Settlement → Output assets are distributed to the receiver

This model provides auditability (every query has a traceable lifecycle), error recovery (dedicated RECOVERING state instead of silent reverts), and query independence (one failure doesn’t block other operations).

For the full technical specification, see the Vehicle & STEAM Standard reference.

Section overview

Architecture

Understand the MultiVehicle system architecture and how components work together.

Accounting & Flow

Learn how sectors track assets and control flows between vehicles.

Fee Management

Configure and collect fees from your MultiVehicle strategies.

Additional Rewards

Distribute protocol rewards and incentives to your users.
New

Conduits

Wrap Vehicles with ERC20 shares, fees, and access control for end users.

Ready to Get Started?

Now that you understand what MultiVehicle can do, dive into the key concepts to master operational patterns, or jump straight into deployment.
Learn Key Concepts Start Deploying