> For the complete documentation index, see [llms.txt](https://docs.buoy.finance/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.buoy.finance/for-vault-leaders/deposit-limits.md). # Deposit Limits Vaults created since **vault v3 (September 2026)** let the Leader shape *who* may deposit and *how much*. Three optional rules exist, all off by default and all enforced by the contracts rather than by the app: | Rule | What it does | Set | Changeable later | Who can change it | | ------------------------------------------- | ------------------------------------------------------------------------------ | --------------------------------------------------- | ---------------- | -------------------------- | | **Minimum leader share** (skin in the game) | Other people can only deposit while you hold at least X% of the vault's shares | At creation only | **Never** | — | | **TVL cap** | Deposits that would push the vault's net value above the cap are refused | At creation or later | Yes | You, or the protocol admin | | **Depositor whitelist** | Only addresses you list can deposit, each up to a **position cap** in USDC | Switch at creation or later; addresses after launch | Yes | You, or the protocol admin | One property is shared by all three and worth stating up front: **they gate deposits only.** No limit ever applies to a withdrawal. A depositor you remove from the whitelist, or a vault that is over its cap, can always exit — see [Security & Trust](/protocol-deep-dive/security-and-trust.md). Vaults created before v3 have none of these rules and cannot gain them; the rules live in a policy contract that a vault is bound to at creation. ## Minimum leader share Your **skin in the game**: the share of the vault's total Buoys you commit to keep holding, from 0 to **50%**. It is set in the creation wizard and can **never** be changed afterwards — that permanence is exactly what makes it a credible promise to depositors, who see it in the vault header as **MIN. LEADER SHARE**. How it is checked: whenever someone *other than you* deposits, the vault projects your share **after** their Buoys are minted; if it would fall below the bar, the deposit is refused. Your own deposits are never gated by it, so you can always top up. What that means in practice: * **You must deposit first.** On an empty vault nobody else can enter until you hold shares. The wizard reminds you of this. * **Your stake sets the vault's capacity.** With a 10% minimum and 1,000 Buoys in your wallet, the vault can have at most 10,000 Buoys in total — other depositors can add up to 9,000. Deposit more and the room grows; withdraw and it shrinks. * **Falling below the bar closes the vault to new money, nothing else.** If you withdraw and drop under the minimum, existing depositors keep their shares and can withdraw as usual; only new non-leader deposits wait until you top up. Trading gains or losses do not change share counts, so they never move you across the bar. * **Performance fees help.** Fee shares are minted to you, so a profitable vault slowly raises your share. A note on the fee: the referral slice of every performance fee is minted to the protocol's RewardsDistributor, not to you, and that slice counts as "someone else's" shares when your share is measured — a marginal effect, but a real one on a vault sitting exactly at the bar. ## TVL cap A ceiling on the vault's **net value** in USDC. A deposit — yours included — that would push the value above the cap is refused. Pending deposits already count toward it, so two people cannot both squeeze into the last slot. Depositors see it under **TVL** on the vault page as *cap X USDC*, and the deposit panel tells them how much room is left (**Max deposit is …**) or that the vault is full. To change it, open **Manage → Deposit limits → TVL CAP**, enter the new value and **Save** (blank or 0 = no cap). Some things to know: * **Lowering the cap below the current value forces nobody out.** It just closes the vault to new deposits until the value falls below the cap again. * **Trading can carry the vault above the cap.** That is fine — the cap only decides whether a *deposit* may enter. * Changing the cap takes one transaction and applies immediately; a deposit already waiting for settlement is re-checked against the new cap when it settles. ## Depositor whitelist Turn on **Whitelist-only deposits** — in the wizard, or later from **Manage → Deposit limits** — and only addresses you have listed can deposit. Each entry carries a **position cap**: the most net capital, in USDC, that address may have in the vault. While the whitelist is on: * An address with no entry (or a cap of 0) cannot deposit at all. The app shows them **Not whitelisted for this vault**. * A listed address can deposit until its *used* amount reaches its cap. Deposits must land in the depositor's **own wallet** — depositing on behalf of another address is refused, so a listed address cannot be used as a door for others. * **You are always exempt**, with or without an entry. * Withdrawals are never affected. ### The position cap is net capital, not lifetime volume *Used* is the USDC an address has put in **minus what it has taken out**, measured in capital, not in market value — so a position that doubled in price does not use up more of its cap. Concretely: * a deposit request counts the moment it is submitted (a cancelled one is credited back); * a withdrawal frees room as soon as it is **Locked**, in proportion to the share of the position redeemed — redeem half your Buoys, free half your used cap; * cancelling a Locked withdrawal counts the released USDC as capital again. Because usage is tracked from day one on every v3 vault — whitelist on or off — switching the whitelist on later starts from an accurate picture of who holds what, and switching it off and on again does not reset anything. ### Managing the list **Manage → Deposit limits** shows the editor whenever the whitelist is on. Each row is an address plus its cap and, for saved rows, **USED / CAP** read live from the contract. Add rows, edit caps, or strike a row out to remove it, then **Save** — a single transaction that writes only the rows you changed. Removing an address is the same as setting its cap to 0. Lowering a cap below what an address has already deposited only blocks its *further* deposits; it never touches existing Buoys. If you launched the vault whitelist-only, nobody but you can deposit until you add the first entries — the confirmation screen says so. ## What a rejected deposit looks like The app checks all three rules before a depositor signs, and the contract checks them again when the request is submitted, so almost every refusal is instant: the transaction reverts, no request fee is paid, nothing is queued. The rules that depend on the vault's value — the leader share and the TVL cap — are checked once more when the deposit **settles**, against the live NAV. If the vault's value moved in between and the deposit no longer fits, settlement refuses it and the request simply **stays Pending**: the settlement service re-checks it whenever the vault's state changes (you top up, the cap is raised, other requests settle), and the depositor can cancel it after the usual timeout and reclaim the full USDC. See [Request Lifecycle](/protocol-deep-dive/request-lifecycle.md). ## Under the hood The rules are not in the vault contract itself but in a separate **VaultPolicy** contract shared by all v3 vaults, which each vault consults through a fixed pointer set at creation. The policy can only *refuse* a deposit request — it holds no funds, cannot mint or burn, and is never consulted on the withdrawal path — so the most a rule can do is close a vault to new money. Developers: [Smart Contract Integration](/developers/smart-contract-integration.md) lists the calls, events and errors. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.buoy.finance/for-vault-leaders/deposit-limits.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.