When the user accepts an allocation, each position becomes one deposit leg. A leg is
executed one of two ways:
- Direct path — the user is already on the vault’s chain holding its underlying
token. The app builds the protocol’s own deposit call and the user’s account executes
it directly.
- Routed path — the user’s funds are on another chain or in another token. Execution
goes through an intent-based relayer: a solver delivers the required token on the
destination chain and executes the deposit calldata there, typically settling in
seconds for cents.
Two hard safety rules
Both checks run before any funds move, and both fail closed.
- The user must be the encoded recipient. Deposit calldata always names the user as
receiver / onBehalfOf. For the minority of protocols whose vaults credit shares
to whatever address calls deposit() (rather than to a named recipient), the routed
path is refused outright — those vaults can only be entered on the direct path, where
the user’s own account is the caller.
- Route targets are validated. Where a deposit routes through a protocol’s own
router (e.g. Pendle), the transaction target returned by the protocol’s API is
checked against the known canonical router address before anything is signed. An
unexpected target aborts the deposit.
Where the user’s wallet supports batched execution (EIP-5792), multiple legs are bundled
into a single approval flow; otherwise legs execute sequentially, each individually
signed.
The result of a deposit is vault shares (or the protocol’s equivalent position token)
held in the user’s account. Positions remain visible and withdrawable even if
AtlasYield disappears — they live in the underlying protocols, not in Atlas. 
