> 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/protocol-deep-dive/security-and-trust.md). # Security & Trust This page lays out who can do what in Buoy, which guarantees are enforced by code, and which parts of the system you are trusting. It's written to be checked against the contracts — not to reassure. ## The powers matrix | | Deposit / withdraw | Trade vault capital | Move funds out of a vault | Value the vault (NAV) | Pause a vault | Change vault params / upgrade | | ------------------ | :----------------: | :-----------------: | :-----------------------: | :-------------------: | :-----------: | :---------------------------: | | **User** | ✅ own funds | ❌ | ✅ own withdrawals only | ❌ | ❌ | ❌ | | **Leader / agent** | ✅ like any user | ✅ | ❌ | ❌ | ❌ | deposit limits only⁴ | | **Fulfiller** | ❌ | limited¹ | ❌² | ✅ | ❌ | ❌ | | **Protocol admin** | ❌ | ❌ | ❌² | ❌ | ✅ | ✅³ | ¹ The fulfiller can close/liquidate positions and move capital between the vault's own venues — only to fund withdrawals. It cannot open new exposure. ² All fund movements are restricted to the vault's own accounts or to depositors owed a withdrawal. No role has a code path to an arbitrary address. ³ The admin can set a vault's Leader, fee, and paused state, and upgrade the shared Router/Factory contracts — but **not** the code of already-deployed vaults, which are immutable. ⁴ On v3 vaults the Leader (and the admin) can change the vault's TVL cap and depositor whitelist — rules that decide who may *deposit*. The minimum leader share is fixed at creation and nobody can change it. None of these rules touches withdrawals. See [Deposit Limits](/for-vault-leaders/deposit-limits.md). Vaults operated by Buoy's own strategy engine sit in the **Leader / agent** row: the engine holds an agent key and has exactly those powers — trade, and nothing else. Being protocol-operated grants it no additional authority over its vaults. ## Enforced by code These hold regardless of who is honest: * **No custodial extraction.** Neither the Leader, the trading agent, the fulfiller, nor the admin can transfer vault funds to an outside address. Bridge and transfer destinations are hard-coded to the vault's own accounts. * **Immutable vaults.** Each vault's contract cannot be changed after deployment. Its pointer to the deposit-rules policy is set at creation and has no setter. * **Entry rules can only refuse.** A vault's deposit limits live in a separate policy contract whose hooks can reject a deposit request but hold no funds, cannot mint or burn, and are never consulted on a withdrawal — a Leader can close a vault to new money, never lock existing money in. * **Slippage floors.** Settlement below a user's quoted minimum reverts. * **Stale-valuation rejection.** Settlements carry the vault-state nonce they priced against; any intervening change reverts them ([details](/protocol-deep-dive/nav-and-share-price.md)). * **Replay protection.** Each settlement executes at most once. * **Guaranteed exit.** Any unsettled request is cancellable by its owner after the timeout — user funds cannot be permanently locked by an absent or malicious operator. * **Reentrancy guards** on all state-changing entry points; **no genesis shares** (first deposit sets a 1:1 basis, closing the inflation-attack vector); **minimum deposit** guard against dust-griefing. * **Bounded builder fees.** A Leader can only approve builders on the protocol whitelist, and only up to the vault's fee ceiling (0.1% by default) — a Leader cannot authorize an unlimited fee to a venue they control. * **No zero-value release.** A locked withdrawal's shares are already burned, so its obligation can never be written down to zero — that would release the request having paid nothing, with no cancel escape. * **Validated implementation swaps.** The factory rejects a vault implementation that isn't a contract or whose declared version doesn't match what the factory expects, so an incompatible implementation cannot be pointed at silently. * **Validated factory swaps.** The Router probes a candidate factory before accepting it, and retains the outgoing one, so repointing cannot orphan existing vaults or cut depositors off from cancellation. ## Pre-deployment hardening The production contracts were deployed after a security review and hardening pass. What changed as a result: * The unused Chainlink CRE `onReport` fulfillment path was removed entirely — contracts, storage and tests — leaving a single, direct settlement path instead of two, one of them dead. * The **builder-fee ceiling** and the **no-zero-value-release** guard above were added. * Factory and vault-implementation swaps were made **validating** rather than blind, and the legacy-factory retention was introduced so a factory change cannot orphan existing vaults. * Unused L1 action encoders and orphan contracts were deleted, shrinking the surface to only what the vault actually uses. Review narrows the space of bugs; it does not prove their absence, and it says nothing about the trust assumptions listed below — those are design choices, not defects. ## External security review The contracts were reviewed by [Shieldify](https://www.shieldify.org/), who reported 7 Medium and 5 Low severity findings. Nine were fixed and three were deliberately dispositioned with public rationale — see the finding-by-finding [Security Review Remediation](/protocol-deep-dive/security-review-remediation.md), or read the [full report (PDF)](https://github.com/buoyloan/buoy-docs/tree/main/.gitbook/assets/Buoy-Security-Review.pdf). ## What you are trusting Honesty compels a clear list. Today, Buoy has three real trust assumptions: ### 1. The fulfiller's valuations The NAV that settlements execute at is computed off-chain by a protocol-operated service, and **the contracts accept it without an independent check**. A malicious or compromised fulfiller could settle requests at wrong valuations — enriching some participants at others' expense (though still never withdrawing funds itself). Mitigations: the valuation method is deterministic and publicly reproducible from Hyperliquid data, every settlement is on-chain and auditable after the fact, and the blast radius of a *stalled* fulfiller is bounded by the cancellation mechanism. ### 2. The protocol admin The admin can pause vaults, replace a vault's Leader, change fees, and upgrade the Router and Factory. An upgrade to the Router is powerful — it's the contract users approve USDC to, and the official app requests an **unlimited** approval so repeat deposits stay one transaction. The allowance only ever covers USDC you still hold in your wallet, and you can revoke it at any time; but it does mean admin key security is a genuine part of the security model, and users who prefer to bound the exposure can set a finite allowance themselves. ### 3. The underlying platform Vault capital lives on Hyperliquid infrastructure: HyperCore accounts, the HyperEVM chain, and the USDC bridge between them. Buoy inherits their risks. ## The Leader is *not* on the trust list Worth stating explicitly, because it's the protocol's core design goal: **you don't trust the Leader with custody.** A Leader can lose your money by trading badly — that's the risk you knowingly price when choosing a vault — but cannot run away with it, and cannot block your exit. ## Incident levers If something goes wrong, the protocol can **pause** affected vaults (freezing deposits and withdrawals while positions stay managed), and users retain timeout-cancellation on anything pending at pause time once unpaused. Pausing is a safety brake, not a confiscation tool — a paused vault's funds remain in the vault, governed by the same destination restrictions as always. ## Key handling The fulfiller's settlement key and the per-vault HyperCore agent keys it manages are the protocol's most sensitive off-chain material. Agent keys are stored **encrypted at rest** (AES-256-GCM) so the database and its backups never hold plaintext, and process secrets are loaded from a managed secret store rather than checked-in configuration. None of these keys can move funds out of a vault — that restriction is in the contracts, not in the key handling — but they can trade and settle, so they're treated accordingly. --- # 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/protocol-deep-dive/security-and-trust.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.