Skip to main content
Railnet’s STEAM standard was designed to address specific limitations in existing vault standards and approaches. This page provides a structured, fact-based comparison to help you evaluate where Railnet fits.

​
Standards comparison

​
ERC-4626 — synchronous vaults

ERC-4626 established a widely adopted vault interface for DeFi. It handles atomic deposit-and-share operations in a single transaction. Limitations:
  • Synchronous only — no mechanism for cooldown periods, withdrawal queues, or multi-step flows
  • No operation tracking — once a transaction completes, there is no lifecycle to observe
  • Works well for simple DeFi protocols (Aave, Compound) but cannot represent assets with settlement delays

​
ERC-7540 — asynchronous extension

ERC-7540 extended ERC-4626 with asynchronous deposit and redeem requests. The specification itself acknowledges several limitations:
  1. No cancellation flow — users cannot revoke a pending request once initiated
  2. No native timestamping — ambiguity around how long a request can remain pending and when it should expire
  3. No defined state transition model — no clear, enforceable path from “pending” to “claimable”
  4. Single logical action — abstracts a two-step process into one, which breaks down for complex strategies
  5. All-or-nothing — vaults must be either fully synchronous or fully asynchronous, with no support for partial fills, staggered liquidity, or mixed execution paths

​
STEAM — stateful lifecycle

STEAM provides a 7-state lifecycle with explicit, enforceable transitions:
  • Every operation (Query) has a unique ID with full lifecycle tracking
  • Supports both sync and async in the same architecture — a Strategy can hold sync and async yield sources (Aave and Ethena) simultaneously
  • Built-in error recovery (RECOVERING state) — assets can be reclaimed without impacting other operations
  • Explicit rejection — operations can be denied with assets returned via the REJECTED state
  • Per-operation isolation — a failure in one Query does not affect others

​
Capability comparison

CapabilityERC-4626ERC-7540STEAM (Railnet)
Sync operationsYesYesYes
Async operationsNoYesYes
Mixed sync + asyncN/ANo (vault-level choice)Yes (per-Vehicle)
Operation lifecycleNonePending / Claimable7-state machine
Concurrent operationsN/ALimitedYes (unique Query IDs)
Cancellation / rejectionNoNoYes (REJECTED state)
Error recoveryNoNoYes (RECOVERING state)
Multi-source compositionNoNoYes (Multi-Vehicle)
Distribution layerNoNoYes (Conduits)
Real-time NAVExternalExternalContract-native
Access controlExternalExternalBuilt-in (EAC)
Fee managementExternalExternalBuilt-in (Fee Manager)

​
Approach comparison

​
Single-protocol vault approaches

Some vault platforms are designed around a single protocol or ecosystem.
Morpho Vaults are ERC-4626 based and built primarily for Morpho Markets. Asset managers (“curators”) construct strategies within the Morpho ecosystem.Morpho explicitly does not build adapters for competing protocols (Aave, Euler, etc.). This is a deliberate design choice rooted in avoiding dependency on upgradeable external protocols. Their focus is on native tokenized products built directly on the Morpho stack.Railnet takes a different approach: it wraps any yield source — including Morpho — through a common standard. Dependency risk is distributed across many protocols rather than concentrated in one, and asset managers can rebalance liquidity across Vehicles if an underlying protocol changes.
Lagoon implements ERC-7540 without a native request queuing system. Key constraints:
  • A vault is configured as either fully synchronous or fully asynchronous — no hybrid model
  • Users must redeem their entire position — partial withdrawals are not supported
  • Users cannot maintain multiple pending redemption requests concurrently
  • Management logic is handled off-chain rather than through on-chain state transitions
Railnet supports mixed sync/async operations within the same Strategy, partial operations through the Query model, multiple concurrent requests per user, and on-chain state management through STEAM.
Veda’s BoringVault is a minimalist vault core that delegates strategy execution, pricing, and access control to specialized modules. Curators submit Merkle-tree-verified rebalance messages to deploy capital across DeFi protocols. Key constraints from an asset manager’s perspective:
  • One vault per partner — distributing the same strategy to multiple platforms requires deploying a separate BoringVault for each, with its own fee configuration, access control, and accounting
  • Operational overhead scales linearly — rebalancing, rate updates, and Merkle tree management must be repeated across every vault instance
  • No native distribution layer — there is no built-in mechanism to share a single strategy across multiple channels with per-partner customization
Railnet separates strategy management from distribution. An asset manager creates one Strategy, then wraps it into multiple Conduits — each with custom fees, compliance rules, and access control — without duplicating capital allocation. Rebalancing happens once at the Strategy level, and operational complexity stays flat as partners scale.Railnet also composes well with Veda. Asset managers already operating on Veda infrastructure can wrap existing BoringVaults as yield sources within a Railnet Strategy, enabling a fund-of-funds model — building diversified, multi-strategy products on top of the infrastructure they already know and trust.

​
Railnet’s approach

Railnet is not competing with individual protocols or single-asset vaults. It operates at a different layer of the stack:
  • Protocol-agnostic — wraps any yield source (DeFi or real-world asset) through the STEAM standard
  • Multi-source by design — a single Strategy composes multiple yield sources across different protocols and asset types
  • On-chain operations — deposit, redemption, rebalancing, fee collection, and queue management all happen on-chain through standardized interfaces
  • Connective infrastructure — connects protocols, asset managers, and platforms into a unified network rather than competing with any one of them

​
When to use what

ERC-4626

Simple, single-protocol synchronous vaults. Wrapping an Aave market or Compound pool where deposits and withdrawals complete atomically.

ERC-7540

Single async vault when you need basic async deposit/redeem without multi-source composition or mixed execution modes.

STEAM (Railnet)

Multi-protocol strategies, mixed sync/async operations, real-world assets with off-chain timing, or institutional requirements (compliance, risk analytics, auditable accounting).