# Application example \[A neobank ships a USDC earn product on Railnet, then grows it]

A neobank wants an "Earn" tab paying yield on USDC. Its users are retail, KYC'd at signup, and expect to withdraw on demand.

## Step 1: one source, one Conduit

The neobank picks a USDC lending market, an Aave V3 reserve or a Morpho Blue market. Railnet connects it through a Vehicle, an adapter implementing [STEAM](/developers/contracts/steam-standard) that absorbs its entry points, share math and capacity limits and exposes one lifecycle instead: create, process, settle. Every deposit or redemption is a Query with its own state, so one failure never blocks another and a slower source uses the same interface.

It deploys a [Conduit](/conduits) on that Vehicle, and the Conduit is the product:

| Setting | This neobank |
|---|---|
| Receipt token | `nbUSDC`, minted on deposit, burned on withdrawal |
| Fees | 0.5% management, under the immutable cap set at deployment |
| Access | KYC allow-list, plus sanctions screening |
| Transfers | Disabled; switching them on later is permanent |

A user taps **Earn**, deposits 1,000 USDC and receives `nbUSDC`. The balance grows as the market accrues interest, and withdrawing burns the shares and returns USDC in the same transaction. Nobody in the app sees a Vehicle, a Query or a Conduit.

The management fee accrues against `block.timestamp` as Vehicle shares minted to the Conduit's [Fee Manager](/conduits/configure-fees); a dispatch call splits that balance across recipients by basis-point share. The backend reads positions, prices, fees and flows from the [Railnet API](/developers/api).

## Step 2: a second audience (optional)

Six months in, the neobank offers the same yield to business accounts at a lower fee: a second Conduit on the same Vehicle, with a different receipt token, a 0.15% management fee, a different allow-list and transfers enabled. No liquidity is split, because both Conduits deposit into the same market. Products multiply per audience or price point, not per protocol.

## Step 3: compose several sources (optional)

<NetworkArch />

Later the neobank wants the rate smoothed across venues and a slice in a tokenized fund. Three Vehicles (the Aave V3 reserve, the Morpho Blue market and an ERC-7540 vault settling on the operator's epoch) compose into an [Allocation Strategy](/strategies/allocation), a MultiVehicle in the contracts. A deposit queue fills the first source up to its cap, then the next; the redeem queue runs in reverse, each source keeping a minimum floor. Liquid markets in front mean withdrawals settle instantly even while part of the book sits in a delayed source. [Sector accounting](/developers/contracts/accounting) tracks idle, reserved, allocated and in-flight capital, so NAV is current every block.

The neobank can operate the Strategy itself or issue a Mandate to an asset manager working inside [guardrails](/strategies/allocation/guardrails) enforced on-chain: only authorized Vehicles, a cap per source and on total assets, and only the roles their operations need. For swaps, borrows, bridges and anything no adapter exposes, a manager runs an [Advanced Strategy](/strategies/advanced).

Pointing a Conduit at the Strategy works exactly as pointing it at a single Vehicle, so the app integration does not change. Another distributor can wrap the same Strategy in its own Conduit.

## Next steps

<Cards>
  <Card title="Quick start" description="Deploy a Conduit on the source you picked." icon="rocket" to="/conduits/quick-start" />

  <Card title="Yield sources" description="The catalog of connected protocols." icon="layers" to="/yield-sources" />

  <Card title="Sync vs async" description="How keepers settle cooldowns and queues." icon="timer" to="/developers/contracts/sync-vs-async" />
</Cards>
