Deposit Flow

The deposit flow is the primary way users enter a leveraged position. It takes user capital (e.g., USDC), transforms it into a leveraged RWA position through a series of coordinated steps, and returns Position Manager shares to the depositors.

Lifecycle

sequenceDiagram
    participant U as Users
    participant F as Facility (Intent)
    participant Req as Request
    participant Fund as Fund
    participant PM as Position Manager

    U->>F: 1. Deposit USDC
    F-->>U: ERC-6909 LP tokens

    Note over F: 2. Facilitator locks intent

    F->>Req: 3. Pull bridge loan
    Req-->>F: Bridge capital

    F->>Fund: 4. Subscribe (deposits + bridge loan)
    Note over Fund: 5. Settlement wait (days/weeks)
    Fund-->>F: 6. Wrapped receipt tokens (e.g. wUSCC)

    F->>PM: 7. Deposit collateral & borrow
    PM-->>F: Mint PM shares (collateral − debt)

    F->>Req: 8. Repay bridge loan

    Note over F: 9. Intent resolved
    U->>F: Claim PM shares

End-to-End Flow

1. Deposit phase — Users deposit capital (e.g., USDC) into a Facility intent and receive ERC-6909 LP tokens minted 1:1
2. Lock — The facilitator closes the deposit window and begins resolution
3. Bridge loan — The Facility pulls bridge capital from a Request contract that has been pre-funded by a bridge facilitator
4. Fund subscription — The Facility commits the combined capital (user deposits + bridge loan) to a Fund wrapper, which forwards it to the external protocol (e.g., Bitwise)
5. Settlement wait — The external protocol processes the subscription. This can take days or weeks depending on the protocol
6. Unlock — Once settled, the Fund wrapper mints wrapped receipt tokens (e.g., wUSCC)
7. Position creation — The Facility deposits the wrapped tokens as collateral into the Position Manager and borrows against them. PM shares are minted reflecting the net equity (collateral minus debt)
8. Repayment — The borrowed funds are used to repay the bridge loan via the Request
9. Resolution — The intent is resolved. LP token holders can now claim their pro-rata share of Position Manager shares

Bridge Loan Sizing

The amount borrowed through the Request contract is not simply a fixed multiple of the user deposit. It depends on several factors:

• Current Position Manager LTV — if the existing PM is above its target LTV (due to interest accrual or price drift), less bridge capital is needed. The deposit itself will bring the LTV back down, so the protocol borrows less rather than overshooting
• Average asset yield — the expected return on the underlying RWA collateral
• Expected yield on the Request — the return demanded by the bridge facilitator for providing the loan
• Expected borrow rate — the interest rate on the Position Manager’s existing borrow positions
• Subscription duration — how long the bridge loan will be outstanding while waiting for the RWA to settle

The goal is to minimize the cost of the bridge loan for depositors while getting as close to the target leverage as possible.

Resulting LTV

The actual LTV reached after the deposit flow will fluctuate from the target. The protocol does not overshoot to compensate — if the LTV ends up below the target, it stays there. Specifically, the bridge loan is sized so that the borrowed amount is at most (n − 1) × deposit where n is the target leverage. The LTV can then only be brought to the exact target through a subsequent retarget leverage flow.

In effect, the deposit flow nets two intents together:

• The depositor wants to go from 1x to nx leverage
• The existing PM holders are currently at n × (1 + ε) leverage and want to return to nx

The deposit brings the existing holders closer to target while onboarding the new depositor at or below the target leverage.