Skip to main content
Quick reference for every protocol-specific term used across the Railnet documentation. For a guided introduction to the key concepts, start with How it works.
A lightweight contract clone deployed on-the-fly to handle protocols with per-address limitations. Each clone acts as an isolated execution context for a single Query, inheriting the Interceptor pattern so additional rewards are automatically routed to the Vehicle owner. This enables hundreds of concurrent asynchronous operations without address conflicts.
A module that maintains an allowlist or blocklist of addresses for a Conduit or Vehicle. When attached, it restricts who can deposit, redeem, or receive share transfers based on the configured list mode. Used alongside TransferMode to enforce access control and compliance policies.
An Advanced Strategy enables asset managers to execute on protocols or functions not available as standard Railnet Vehicles — such as swaps, borrows, bridges, perps, or complex RWA operations. Implemented on-chain as a Specialized Vehicle that standardizes non-custodial custody (multi-chain treasury wallet), on-chain policy enforcement (contract/function/calldata whitelists), and NAV computation. Composable with the full Railnet stack: distributable via Conduits or usable as a sub-vehicle within a MultiVehicle (fund-of-funds model). See also: Specialized Vehicle, Strategy.
The operator action of deploying capital from a Multi-Vehicle’s DEPOSIT Sector into one or more sub-vehicles. Distinct from a user deposit — allocations are performed by the asset manager (or keeper) to put idle capital to work across yield sources.
The persona responsible for deploying and operating a Multi-Vehicle. Asset managers select yield sources, configure sub-vehicles, set allocation strategies, and rebalance capital. They can operate both standard Strategies (MultiVehicle) and Advanced Strategies (Specialized Vehicle). They interact with Railnet through the build interface and earn fees for their management services.
A Vehicle that requires multiple transactions to complete an operation due to protocol-level constraints such as cooldown periods (Ethena) or withdrawal queues (Syrup). Queries enter the PROCESSING state and settle over time. See also: Sync Vehicle.
The primary asset (e.g., USDC) that a Vehicle or Multi-Vehicle denominates in. All deposits and redemptions are expressed in the base asset, and the share price is calculated relative to it. Returned by the STEAM asset() method.
A distribution channel that wraps any Vehicle or Multi-Vehicle with its own ERC20 share token, custom fees, and access control. Platforms deploy Conduits to distribute yield strategies to their users with custom fee structures, compliance, and branded shares — without building protocol-specific integrations. Keepers automate async operations so users never need to manually claim.
A protocol-imposed delay between initiating and completing a withdrawal. During the cooldown, assets are locked and the Query remains in the PROCESSING state. Common in protocols like Ethena, where unstaking sUSDe requires a multi-day waiting period before assets can be claimed.
A small number of shares minted to a burn address during Vehicle or Conduit deployment as an anti-inflation attack mechanism. Dead shares ensure totalSupply is never zero, preventing the first-depositor share price manipulation that affects naive vault implementations.
A STEAM operation where a user commits base assets (such as USDC) to a Vehicle or Multi-Vehicle in exchange for shares. The Query mode is set to DEPOSIT.
A specialized contract inside a Multi-Vehicle that handles one operational concern. Each Engine has a single responsibility and is deployed as a separate contract:
  • SectorAccountingEngine — double-entry bookkeeping across all Sectors
  • SubQueryEngine — manages the sub-vehicle Query lifecycle and ephemeral accounting
  • QueueStrategyEngine — configurable priority queues for deposit and redeem allocation
  • QueryRedeemQueue — FIFO queue for processing async redemptions fairly
Together the four Engines power all Multi-Vehicle operations while keeping each concern isolated and upgradeable.
A mechanism used by the SubQueryEngine to track the estimated value of in-flight Queries. Prevents share price distortion by including expected outputs from PROCESSING queries in the totalAssets() calculation.
Railnet’s central role-based access control system built on OpenZeppelin’s AccessControlDefaultAdminRules. EAC manages three types of roles:
  • Global roles apply protocol-wide across all contracts (e.g. FACTORY_SPAWN to deploy new Vehicles)
  • Scoped roles are restricted to a specific contract address (e.g. VEHICLE_STEAM granted only on one Vehicle)
  • Public roles are granted to everyone by default, enabling permissionless access where appropriate
A single EAC contract governs access for the entire Railnet deployment, keeping permissions centralized and auditable.
A contract that deploys Vehicles and Conduits with consistent configuration and anti-inflation protection. The CoreFactory serves as the central registry and deployment engine.
A composition pattern where a Strategy (MultiVehicle) includes other Strategies or Advanced Strategies (Specialized Vehicles) as sub-vehicles, creating a nested allocation structure. The outer MultiVehicle’s sector-based accounting tracks the inner strategies’ NAV like any other sub-vehicle. This works because MultiVehicle extends SingleAssetBaseVehicle, making it a valid sub-vehicle in another MultiVehicle’s VehicleRegistry.
An optional contract attached to a Vehicle or Multi-Vehicle that handles fee collection and distribution. Supports four fee types: performance, management, deposit, and redeem. Fees are configured in basis points with an immutable maximum ceiling.
The highest share price previously recorded for a Vehicle or Multi-Vehicle with performance fees enabled. Performance fees are only charged on gains above the high water mark, ensuring the asset manager does not earn fees on recovering from a loss — only on generating net new value.
A pattern for managing additional reward distribution. Vehicles declare interception rules via the interceptions() view function, which off-chain indexers read to route protocol incentives, airdrops, and yield-bearing tokens to the correct destinations.
An off-chain automation system that monitors active Queries and executes state transitions when conditions are met. Keepers trigger jobs such as advancing async queries past cooldown periods or settling withdrawal queue positions.
An extension that adds auxiliary functionality to a Vehicle through the ModulesManager. Modules can perform tasks such as claiming and distributing external rewards. New modules go through a timelock before they can interact with user assets.
A meta-strategy vault that orchestrates positions across multiple underlying Vehicles. It distributes capital across sync and async yield sources through a single entry point, and enables rebalancing without users needing to interact with individual protocols.Powered by four Engines:
  • SectorAccountingEngine — tracks every asset movement with double-entry bookkeeping
  • SubQueryEngine — manages per-Vehicle Queries and ephemeral accounting
  • QueueStrategyEngine — determines allocation priority across Vehicles
  • QueryRedeemQueue — processes redemptions in FIFO order
The Multi-Vehicle computes a real-time on-chain NAV across all positions via totalAssets(), ensuring accurate share pricing at all times. Multi-Vehicles can also include Specialized Vehicles as sub-vehicles, enabling a fund-of-funds model where Advanced Strategies sit alongside standard yield sources.
The persona responsible for distributing yield strategies to end users. Platforms deploy Conduits to wrap existing Vehicles or Multi-Vehicles with branded shares, custom fee structures, and access control — without building direct protocol integrations. Examples include wallets, neobanks, and DeFi aggregators.
An on-chain governance layer within a Specialized Vehicle that enforces what operations the asset manager can execute. Capabilities include: contract whitelists (which contracts can be called), function-level permissions (which functions), calldata-level checks (which parameters are accepted), and guardian governance with timelock enforcement. Replaces opaque web2 policy systems (Fireblocks, ForDeFi) with fully transparent, auditable, on-chain rules.
A structured request representing a deposit or redemption operation in the STEAM standard. Each Query carries an owner, receiver, input/output assets, mode (DEPOSIT or REDEEM), a unique salt, and optional protocol-specific data.Queries move through three phases:
  1. Creation — assets are committed and the Query enters the state machine
  2. Execution — the underlying protocol processes the operation (instant for sync, multi-step for async)
  3. Settlement — output assets or shares are distributed to the receiver
Each Query is independent — one failure never blocks others, and multiple Queries can be in-flight concurrently.
The operator action of shifting capital between sub-vehicles within a Multi-Vehicle. Rebalancing lets the asset manager respond to changing market conditions, optimize yield, or reduce risk by moving allocations from one yield source to another — without requiring users to withdraw and re-deposit.
A STEAM operation where a user returns shares to a Vehicle or Multi-Vehicle in exchange for base assets. The Query mode is set to REDEEM.
A STEAM view method that returns the supported input and output asset combinations for a Vehicle. Integrators call route() to discover which assets a Vehicle accepts for deposits and which assets it returns on redemption, enabling programmatic discovery of Vehicle capabilities.
A logical partition in the Multi-Vehicle accounting system that represents the operational state of assets. Every asset movement has a source Sector and a destination Sector — assets can never be “lost” because the double-entry bookkeeping always balances.Five core Sectors track the main flow:
  • ENTRY — assets just deposited by users
  • DEPOSIT — assets queued for allocation
  • ALLOCATION — assets actively deployed in Vehicles
  • REDEEM — assets returning from Vehicles
  • EXIT — assets ready for user withdrawal
Dynamic Sectors are created per-operation: a Vehicle Sector stages assets before protocol interaction, and a Pending Sector isolates in-flight async operations.
The ratio of totalAssets() / totalSupply() for a Vehicle, Multi-Vehicle, or Conduit. Share price reflects the current value of one share in terms of the base asset. It rises as the underlying yield sources generate returns, and is used to calculate deposit and redemption amounts.
The on-chain implementation of an Advanced Strategy. A Specialized Vehicle wraps a Lagoon vault interface with a standard Railnet Vehicle adapter, making it composable with MultiVehicles and Conduits. Unlike standard Vehicles that adapt a specific DeFi protocol, Specialized Vehicles give asset managers full execution flexibility — they can call any whitelisted contract and function. The three pillars standardized by Specialized Vehicles are: (1) custody via non-custodial multi-chain treasury wallets, (2) policy via on-chain engines with contract, function, and calldata whitelists, (3) accounting via standardized NAV computation and reporting. See also: Advanced Strategy, Vehicle.
State Transition Engine for Asset Management. The standardized interface that all Vehicles implement. STEAM defines a state machine with seven states (EMPTY, PROCESSING, WAITING, UNLOCKING, SETTLED, RECOVERING, REJECTED) for managing the full lifecycle of deposit and redemption operations.
A Vehicle that is managed by a Multi-Vehicle rather than receiving direct user deposits. The Multi-Vehicle allocates capital into its sub-vehicles, manages their Query lifecycles, and aggregates their returns into a single share price. Each sub-vehicle has its own Sector for accounting purposes.
A Vehicle that completes operations in a single transaction. Queries transition directly from EMPTY to UNLOCKING during create(). Examples include Aave V3, Compound V3, and ERC-4626 wrapper vehicles. See also: Async Vehicle.
A configurable policy on a Conduit that governs whether and how ERC20 share tokens can be transferred between addresses. TransferMode works alongside AccountList to enforce compliance rules — for example, restricting transfers to allowlisted addresses only or disabling transfers entirely.
A multi-EVM-chain programmable wallet deployed as part of a Specialized Vehicle. Fully non-custodial — no third party can recover private keys. Each Advanced Strategy gets its own Treasury Wallet instance per chain, controlled by the on-chain policy engine.
The STEAM lifecycle method that finalizes a successful operation. Called when a Query is in the UNLOCKING state, it distributes output assets or shares to the receiver and transitions the Query to SETTLED. A partial unlock distributes only a portion of the expected output and transitions the Query back to PROCESSING for the remainder.
A smart contract that implements the STEAM interface for a specific DeFi protocol. Each Vehicle wraps protocol-specific logic behind four standardized lifecycle methods:
  • create() — initiates a deposit or redemption operation
  • resume() — advances an async operation past a waiting state
  • unlock() — finalizes a successful operation and distributes output
  • recover() — handles failures by returning assets to the sender
Vehicles come in two flavors:
  • Sync Vehicles (Aave, Compound, ERC-4626) settle in a single transaction
  • Async Vehicles (Ethena, Syrup) require multiple transactions with cooldown periods or withdrawal queues
A protocol-imposed mechanism where redemption requests are placed in a queue and processed in order as liquidity becomes available. Common in protocols like Syrup (Maple), where lenders must wait for borrowers to repay before funds can be withdrawn. The Vehicle’s Query remains in the PROCESSING state until the queue position is filled.
A Vehicle that wraps an existing ERC20 token for STEAM compatibility without adding yield. Used for access control overlays, fee application, integration testing, or making tokens composable with Railnet infrastructure. Always synchronous — deposits and withdrawals complete in a single transaction.
The underlying DeFi protocol that a Vehicle wraps and standardizes behind the STEAM interface. Examples include lending protocols (Aave, Morpho), staking protocols (Ethena), and liquidity pools (Syrup). Each yield source has its own mechanics, but the Vehicle abstraction presents a uniform interface to depositors and Multi-Vehicles.

Understand the building blocks

See how these terms fit together in a guided walkthrough of Railnet’s core concepts.