> ## Documentation Index > Fetch the complete documentation index at: https://docs.atlasyield.club/llms.txt > Use this file to discover all available pages before exploring further. # Deposits > Direct and routed paths, and the two hard safety rules on every leg. 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. 1. **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. 2. **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.