Deposit Router Contracts

​

What Changed in V3.2.0

• depositForAvailable(...) — new entry point that pulls min(allowance, balance) from msg.sender instead of an explicit amount argument. Eliminates the calldata-amount-mismatch revert that bridge-fee underflows would otherwise cause: any 1-wei underdelivery from Across/Stargate would previously revert the whole composer call. Now the router sweeps whatever actually arrived.
• ERC-4626 void-return fallback — vaults whose deposit() returns no value (some forks of OpenZeppelin’s older 4626 reference) are detected via vrd.length and fall back to a balanceOf delta to compute shares. Removes a class of “Adapter: shares not delivered” reverts on niche forks.
• All V3.1.1 changes (open caller model, no whitelist) carried forward.

​

What Changed in V3.1.1

• Removed the authorizedCallers gate on depositFor / depositRequestFor. Any address can now call with an arbitrary user argument, which is used purely for the Routed event and as the share recipient. This removes ops friction of whitelisting every new LiFi bridge-receiver contract (ReceiverAcrossV3/V4, ReceiverStargateV2, ReceiverChainflip, per-chain Executors, etc.) and keeps the composer flow working across bridge updates without a router upgrade.
• Security note: funds are pulled from msg.sender (the caller must own the tokens or have been approved), so no one can spend a third party’s balance. The remaining risk is attribution spoofing — anyone can emit a Routed event with an unrelated user/partnerId. Attribution consumers (revenue share, referrer tiering) should treat Routed events as advisory and cross-check against on-chain share balances where strict correctness matters.
• authorizedCallers storage slot and the admin functions (setAuthorizedCaller, setAuthorizedCallerBatch) are preserved for forward compatibility but are not consulted by the current implementation.

​

What Changed in V3.1.0

• 8-arg depositFor with minSharesOut — on-chain slippage floor. The 7-arg form is kept as a compatibility shim (forwards with minSharesOut=0).
• Shares returned explicitly — _executeVaultCall now returns the exact shares minted, cross-checked against balanceOf(recipient) to detect silent failures in downstream adapters.
• Routed event now includes shares — previously indexers had to read vault share balances to compute this.
• Introduced authorizedCallers whitelist (removed again in V3.1.1 — see above).

​

Contract Addresses

​

How Deposits Work

​

Same-Chain Deposit

User approves tokens to router → User calls depositFor() → Router pulls tokens
  → Router dispatches to vault protocol → Shares sent to user → Routed event emitted

​

Cross-Chain Deposit (Two-Step)

Step 1 (source):  User sends LiFi bridge tx
                  → tokens arrive at user's wallet on destination chain
Step 2 (dest):    User approves → User calls depositFor() → Shares sent to user

​

Cross-Chain Deposit (Single-Step, Composer)

User sends LiFi tx on source chain → LiFi Executor on destination receives tokens
  → Executor calls router.depositFor(..., user=<user>) → Shares sent to user

​

depositForAvailable (V3.2.0+)

function depositForAvailable(
    address vault,
    address asset,
    address user,
    bytes32 partnerId,
    uint8 partnerType,
    bool isERC4626,
    uint256 minAmount,        // floor — revert if pulled amount < this
    uint256 minSharesOut      // slippage floor on shares minted
) external;

uint256 allowed = IERC20(asset).allowance(msg.sender, address(this));
uint256 bal     = IERC20(asset).balanceOf(msg.sender);
uint256 amount  = allowed < bal ? allowed : bal;
require(amount >= minAmount && amount > 0, "Insufficient");
IERC20(asset).safeTransferFrom(msg.sender, address(this), amount);
// dispatch via _executeVaultCall, emit Routed.

​

depositFor

// 8-arg (preferred) — includes slippage floor
function depositFor(
    address vault,
    address asset,
    uint256 amount,
    address user,
    bytes32 partnerId,
    uint8 partnerType,
    bool isERC4626,
    uint256 minSharesOut
) public;

// 7-arg (compat) — forwards to the 8-arg form with minSharesOut = 0
function depositFor(
    address vault,
    address asset,
    uint256 amount,
    address user,
    bytes32 partnerId,
    uint8 partnerType,
    bool isERC4626
) external;

require(user != address(0) && vault != address(0) && asset != address(0) && amount > 0, "Bad params");
// No caller gate — any msg.sender may call with any `user`.

​

depositRequestFor

function depositRequestFor(
    address vault,
    address asset,
    uint256 amount,
    address user,
    bytes32 partnerId,
    uint8 partnerType
) external;

​

Events

event Routed(
    bytes32 indexed partnerId,
    uint8 partnerType,
    address indexed user,
    address indexed vault,
    address asset,
    uint256 amount,
    uint256 shares     // NEW in V3.1.0
);

event DepositRequestRouted(
    bytes32 indexed partnerId,
    uint8 partnerType,
    address indexed user,
    address indexed vault,
    address asset,
    uint256 amount,
    uint256 requestId
);

event VaultAdapterUpdated(address indexed vault, address indexed adapter);
event AuthorizedCallerUpdated(address indexed caller, bool authorized); // emitted by admin setter; no longer affects caller access in V3.1.1

​

Vault Dispatch Priority

​

Vault Adapter Pattern

interface IVaultAdapter {
    function deposit(
        address vault,
        address asset,
        uint256 amount,
        address recipient
    ) external returns (uint256 shares);
}

router.setVaultAdapter(vaultAddress, adapterAddress);      // single
router.setVaultAdapterBatch(vaults[], adapters[]);          // batch

​

Caller Model (V3.1.1)

​

Admin Functions

​

Security Properties

• No custody — contract never holds a positive balance between transactions. Any stuck balance is rescuable by owner.
• No fees — 100% of the deposited amount is forwarded to the vault. Attribution is event-only.
• Access-controlled user spoofing — non-authorized callers can only pass user == msg.sender.
• Reentrancy protected — all state-mutating deposit paths use the OpenZeppelin ReentrancyGuard.
• Optional vault allowlist — vaultWhitelistEnabled can gate which vaults can be deposited into. Off by default.
• Two-step ownership — prevents accidental transfer to dead addresses.
• UUPS upgradeable — owner-controlled, storage layout preserved across all upgrades via _deprecated_ padding.

​

API Integration Notes