;
};
## What is an Advanced Strategy
This is where most asset managers start. An Advanced Strategy is a standalone strategy container that gives full protocol execution flexibility — lend, borrow, swaps, bridges, perpetual futures, RWA operations — while standardizing the four things that are otherwise left to bespoke, risky setups: investor lifecycle, non-custodial execution, on-chain guardrails, and accounting.
Each Advanced Strategy is composed of:
* A **7540 Vault** — the capital entry point that handles deposits, redemptions, share pricing, settlement, fees, and access control
* A **Strategy** where the strategy funds are held and the operations are executed — no third party can recover your keys
* An **on-chain policy engine** governing exactly which contracts, functions, and parameters the asset manager can use, defined by the quorum of the strategy smart contract
* **Standardized NAV reporting** so share pricing is accurate and auditable
You interact with any supported DeFi protocol directly. There are no adapters to build, no Railnet adapter to wait for. If the protocol has a smart contract, Railnet will whitelist required operations in the strategy's policy engine.
## Why Specialized Vehicles exist
Today, traditional asset managers who need to operate beyond simple allocation strategy currently use their existing wallet infrastructure like Fireblocks or ForDeFi for custody & execution with web2 co-signer services for policy enforcement, and ad-hoc setups for NAV computation. This approach has fundamental problems:
* **Strategy is not truly non-custodial** — owners of the wallet infrastructure providers can recover private keys, creating a trust dependency that undermines the premise of on-chain asset management
* **Policy engines are black boxes** — web2 co-signer and policy services are partial not publicly auditable, not verifiable on-chain, and not standardized accross asset managers
* **NAV computation is ad-hoc and error-prone** — incorrect NAV means incorrect share pricing, which means loss of funds for depositors. In fund-of-funds structures, NAV errors chain across layers — a bad Advanced Strategy NAV cascades into every Allocation Strategy that holds it
* **Every strategy is bespoke** — each deployment requires custom integration work for custody, policy, and reporting, with no standardized framework
Specialized Vehicles solve these problems by standardizing four pillars that every advanced strategy needs.
## The four pillars
### Vault
The 7540 Vault is the capital entry point for every Advanced Strategy. It implements the ERC-7540 standard handling deposits, redemptions, share pricing, fee collection, and access control through a single contract.
The vault supports both synchronous and asynchronous flows. When the NAV is valid, deposits settle instantly; when it has expired, they are kept pending and settled together at the next valuation cycle. Redemptions follow the same dual model — pending by default, with an optional instant liquidity buffer for immediate withdrawals. Pending funds are isolated in a dedicated escrow (Silo) until settlement.
The vault collects management, performance, entry, exit, and haircut fees — all configurable per strategy. Access can be gated via allowlist, blocklist, or external sanctions lists.
NAV guardrails protect against erroneous valuations by enforcing on-chain bounds on share price changes.
For a deep dive, see [Vault 7540 mechanics](/strategies/advanced/vault).
### Strategy
A multi-EVM-chain programmable set of smart contract (Safe + Guards + Policy Engine) deployed per strategy. The smart contract is fully non-custodial and can't execute asset management operations on its own or via the admin quorum — no workspace owner, no infrastructure provider, and no third party can recover the private keys. The strategy owners define the policy engine, changes in the policy can only be done with a delay timelock. The asset manager operates the strategy with its own logic, quorum and signing process on the attached policy engine, and the smart contract architecture ensures that all operations follow the on-chain guardrails or reject the operation.
### Policy
A custom on-chain policy engine is deployed matching your strategy requirements relying on **Zodiac Roles Modifier v2** that governs what the asset manager can do:
* **Contract whitelists** — which contracts can be called
* **Function-level permissions** — which functions on those contracts are allowed
* **Granular and on-chain parameter checks** — which parameter values are accepted (recipient addresses, spending limits, slippage bounds)
* **Guardian governance** — oversight roles with timelock enforcement for policy changes
Every rule is transparent, auditable, and verifiable on-chain. No dependency on a third-party back-end or co-signer. What gets executed on the strategy is only what was agreed in the strategy definition. Platforms and depositors can inspect the exact constraints governing a strategy before allocating capital. There are no off-chain co-signers, no black boxes, and no trust assumptions beyond the smart contracts themselves.
For a deep dive, see [Policy engine](/strategies/advanced/policy-engine).
### Accounting
Accurate NAV is critical — it determines share pricing for every depositor and, when a Specialized Vehicle is held inside an Allocation Strategy (MultiVehicle), incorrect NAV cascades through the fund-of-funds accounting.
The valuation process and format is standardized across all Advanced Strategies, making it possible for platforms and risk managers to compare strategies on equal terms.
## Supported protocols
The policy engine can whitelist any smart contract, but these protocols ship with pre-built permission sets — ready to use in your strategy with prebuilt constraints, spending limits, and risk classifications.
| Category | Protocol | Chains | Description |
| ------------------- | ----------- | ------------------- | ----------------------------------------------------------------------- |
| **Lending** | Aave V3 | ETH, ARB, OPT, BASE | Supply, borrow, and manage collateral across the largest lending market |
| **Lending** | Compound V3 | ETH, ARB, BASE | Single-asset lending markets with isolated risk |
| **Lending** | Morpho Blue | ETH, ARB, BASE | Isolated lending markets with permissionless market creation |
| **Lending** | Spark | ETH | Lending and savings products in the Sky (Maker) ecosystem |
| **DEX / Swaps** | Uniswap V3 | ETH, ARB, OPT, BASE | Concentrated liquidity swaps and LP positions |
| **DEX / Swaps** | CoW Swap | ETH, ARB, BASE | MEV-protected batch auction swaps via pre-signing |
| **DEX / Swaps** | Balancer V2 | ETH, ARB, OPT, BASE | Weighted pool swaps and liquidity provisioning |
| **Staking / Yield** | Lido | ETH | Liquid staking (stETH/wstETH) with withdrawal queue support |
| **Staking / Yield** | Pendle | ETH, ARB | Yield tokenization — trade fixed and variable yield separately |
| **Savings** | Sky DSR | ETH | DAI Savings Rate — earn yield on idle DAI |
This list is growing. If a protocol you need is not listed, you can whitelist its contracts manually through the policy engine. Any EVM smart contract can be scoped with custom permissions.
## Use cases
* **Custom RWA looping strategy with instant redeem liquidity** — recursive deposit/borrow against tokenized real-world assets, with a liquid reserve to serve immediate redemptions
* **Multi-perps yield strategy** — allocate across perpetual futures protocols to capture funding rate yield, with on-chain policy constraints on position sizing and protocol exposure
* **Cross-chain yield farming** — deploy treasury wallets on multiple EVM chains and allocate capital to yield sources across networks, with unified accounting and NAV reporting
* **Custom protocol interactions** — any strategy requiring contract calls not yet available as standard Railnet Vehicles. The policy engine lets you whitelist exactly the contracts and functions you need
## Custom Vehicle patterns
Looping (recursive deposit/borrow to amplify yield), leverage, and cross-chain bridging are patterns you build using the Specialized Vehicle's on-chain policy engine. For each pattern, you whitelist the specific contracts and functions your strategy needs:
* A **looping strategy** whitelists a lending protocol's deposit and borrow functions, allowing recursive calls within the policy engine's constraints
* A **leverage strategy** whitelists borrowing and swap contracts, with calldata-level checks constraining leverage ratios
* A **bridging strategy** whitelists bridge contracts and destination-chain treasury wallets, enabling cross-chain capital movement under on-chain governance
These are not built-in protocol features — they are custom patterns enabled by the policy engine's flexibility. The on-chain nature of the policy means every constraint is visible to depositors and auditors.
## How it connects to Railnet
While Railnet is not fully live, the **distribution of Advanced Strategies is done directly from the Vault 7540**, as well as the fees management.
A yield source wraps the 7540 vault interface of this Advanced Strategy with Railnet's standard Vehicle adapter. This makes it fully composable with the Railnet stack:
* **Distributed directly via a Conduit** — wrap the Specialized Vehicle with a [Conduit](/conduits) to offer it to end users, with your own fees, compliance rules, and branded shares
* **Used as a sub-vehicle in an Allocation Strategy** — a [MultiVehicle](/developers/contracts/multi-vehicle) can hold a Specialized Vehicle alongside standard Vehicles, creating a fund-of-funds model where managed allocation and custom execution coexist
* **Fees managed at the Railnet Vehicle level** — the standard [fee framework](/developers/contracts/fee-manager) applies, including detailed per-fee-type accounting, multi-recipient support, and flexible revenue distribution
From the perspective of a Conduit or an Allocation Strategy, a Specialized Vehicle behaves like any other Vehicle — deposits, redemptions, and NAV reporting follow the same STEAM interface.
## Fund of funds
An Allocation Strategy (MultiVehicle) can include Specialized Vehicles as sub-vehicles alongside standard Vehicles. The MultiVehicle's [sector-based accounting](/developers/contracts/accounting) tracks the Specialized Vehicle's NAV just like any other sub-vehicle — each sub-vehicle occupies a sector, and the Allocation Strategy computes its aggregate NAV from all sectors.
This enables portfolio construction where some allocation goes to established yield sources (via standard Vehicles) and some goes to custom strategies (via Specialized Vehicles), all managed through a single Allocation Strategy with unified accounting, fee collection, and distribution.
## What to read next
How the Policy Engine enforces on-chain permissions, spending limits, and guardian governance.
Day-to-day operations — execute transactions, manage spending limits, update permissions.
Compose multiple yield sources and Advanced Strategies into a managed portfolio with automated queues.
Guardrails, allocation caps, and risk frameworks for strategy operations.