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 that bind an operation to the address that initiated it. The Vehicle clones an Account per Query — the query ID is the salt — transfers the position to it, and drives the protocol through the clone’s performCall, so each Query gets its own identity on the underlying protocol. The clone inherits the Interceptor pattern, routing any reward that lands on it back to the Vehicle that owns it. This enables hundreds of concurrent asynchronous operations without address conflicts.
A compliance module attached to a Conduit that maintains an allowlist and a blocklist of addresses, plus optional sanctions-oracle screening. It answers intent-specific predicates — canDeposit, canRedeem, canTransfer, canReceive, and canForceRedeem — with precedence sanctions > blocklist > allowlist. Its AllowlistMode decides how strictly the allowlist applies: OPEN ignores it, REGULAR gates deposits only, and STRICT gates deposits and transfers. See also: Transfer Policy.
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 AVAILABLE Sector into one or more sub-vehicles. It runs through dispatch() on the SectorAccountingEngine, which opens a deposit Query on the target sub-vehicle, and requires MULTI_VEHICLE_DISPATCH. 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’s sUSDe) or request queues (ERC-7540 vaults, including Lagoon). 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.
Shares permanently locked at the burn address (0x…dEaD) when a Vehicle or Conduit is deployed. The factory makes an initial deposit — its size is configured per asset in the AssetRegistry — then transfers the resulting shares to the burn address. This keeps totalSupply from ever being 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 independently upgradeable behind its own beacon. The VehicleManager sits alongside them as the Multi-Vehicle’s management contract — it is not an Engine.
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_DEPOSIT granted only on one Vehicle)
  • Public roles are opened up by the admin with setRolePublic or setScopedRolePublic, after which every account passes the check without an explicit grant — 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. Each type has its own factory — AaveV3VehicleFactory, ERC4626VehicleFactory, MultiVehicleFactory, ConduitFactory, and so on — gated by FACTORY_SPAWN (CONDUIT_SPAWN for Conduits) and fed by the AssetRegistry, which holds per-asset authorization and initial deposit amounts. They all route the deployment itself through the shared CoreFactory, which wraps CreateX for deterministic CREATE2 addresses and EIP-1167 minimal proxy clones.
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 BaseVehicle, making it a valid sub-vehicle once authorized on another MultiVehicle’s VehicleManager.
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 totalAssets() value previously checkpointed for a Vehicle, Multi-Vehicle, or Conduit with performance fees enabled. The FeeManager charges the performance fee only on earnings above that checkpoint, 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 watches on-chain conditions and submits the transactions that advance operations. Jobs are published on-chain — for example by the MultiVehicleJobListing — each with a status target the keeper polls for POLL, EXEC, or STOP and an exec target it calls once the job is ready; the shipped Multi-Vehicle jobs feed the redemption queue and retrieve assets back from it. Keepers also progress Queries on a user’s behalf, such as processing Conduit queries under CONDUIT_PROCESS.
An extension that adds auxiliary functionality to a Vehicle through the ModulesManager. Modules can perform tasks such as claiming and distributing external rewards. Enabling one takes two steps: an account holding MODULE_MANAGER registers the module with addModule, then the Vehicle itself opts in with allowModule before that module can execute on it.
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
A VehicleManager sits alongside the Engines, holding sub-vehicle authorization and configuration.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. There is no single rebalance call: the asset manager chains dispatch() calls on the SectorAccountingEngine — a REDEEM dispatch out of the source sub-vehicle, then a DEPOSIT dispatch into the destination — reusing one operationId so both legs stitch back into a single intent, with move() shifting balances between Sectors along the way. When every sub-vehicle involved settles synchronously the whole sequence fits in one multicall; an async redeem splits it across transactions. Rebalancing lets the asset manager respond to changing market conditions, optimize yield, or reduce risk 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 supported input/output asset combination for a Vehicle. The STEAM view method routes() returns two arrays — the deposit routes and the redeem routes — letting integrators discover programmatically which assets a Vehicle accepts for deposits and which it returns on redemption.
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 static Sectors track the main flow:
  • ENTRY — virtual source for assets entering the accounting system
  • AVAILABLE — idle base assets usable for both allocation and redemption fulfillment
  • ALLOCATION — sub-vehicle shares held from settled deposits
  • RESERVED — base assets the operator has earmarked; counted in totalAssets() but excluded from withdrawable()
  • EXIT — virtual destination for assets leaving the accounting system
Dynamic Sectors are derived rather than declared: a vehicle Sector (SectorLib.toSector(vehicle)) stages assets and shares per sub-vehicle, and a query Sector isolates a single in-flight sub-query.
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, PAUSED, 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 the Aave V3, Morpho Blue, and ERC-4626 vehicles. See also: Async Vehicle.
The two gates a Conduit applies to a user-initiated share transfer; isTransferable(from, to) returns their combined result. The first is transferEnabled, a one-way latch flipped on by enableTransfers() under CONDUIT_SET_TRANSFER_ENABLED — it can never be turned back off, so ERC20 integrations cannot be bricked. The second is the attached AccountList’s canTransfer(from, to), which screens both parties against sanctions, the blocklist, and — in STRICT mode — the allowlist. Conduit-internal moves such as minting, burning, fee accrual, and forceRedeem bypass both gates by construction.
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 paused 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 V3, Morpho Blue, ERC-4626) settle in a single transaction
  • Async Vehicles (Ethena, ERC-7540 vaults such as Lagoon) require multiple transactions with cooldown periods or request queues
The management contract of a Multi-Vehicle. It authorizes and unauthorizes sub-vehicles (authorize, authorizeAndConfigure, unauthorize), stores each one’s configuration with configure, sets operational thresholds and maxTotalAssets, and exposes feedQueryRedeemQueue and retrieveQueryRedeemQueueAssets for the redemption queue. MultiVehicle.manager() returns it, and it is also the accessor for the four Engines.
A protocol-imposed mechanism where redemption requests are queued and filled as vault settlement or liquidity allows. Railnet’s ERC-7540 vehicles — including the Lagoon vehicle — batch user demand in an ERC7540VehicleQueue that submits one vault request per batch: the permissionless processRequest() drains the full live backlog, while the bounded processRequest(maxSubmission) overload is gated by VEHICLE_PROCESS_QUEUE for keepers chunking a backlog the vault will not accept in one request. The Vehicle’s Query remains in the PROCESSING state until its share of the request settles.
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 V3, Morpho Blue), staking protocols (Ethena), and tokenized vaults (ERC-4626, and ERC-7540 vaults such as Lagoon). 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.