> For the complete documentation index, see [llms.txt](https://docs.enzyme.finance/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.enzyme.finance/enzyme-blue-protocol/users/end-users.md). # End users There are two categories of end users of the Enzyme Protocol: fund managers and investors. ### Fund managers There are three primary fund management roles in this release, all of which are stored on the `VaultProxy` and thus will persist to subsequent releases (if those releases decide to use them): * Owner * Migrator * Asset Manager {% hint style="warning" %} **All three fund management roles are fully trusted.** Since November 1, 2026, Asset Managers are treated as fully trusted actors, at the same level as the fund owner. This matches the trust model used in Enzyme Onyx. Only assign a role to an address you would trust with the same level of control as the owner. {% endhint %} #### Owner Each fund has one owner, who can perform any administrative action on the fund. Ownership can be changed via a pair of nominate-claim transactions. Owners are considered fully-trusted. #### **Migrator** Each fund can have a single migrator, who can call any migration or reconfiguration action on the `FundDeployer`. Only the owner can set or unset a migrator. Migrators are considered fully-trusted, since they can arbitrarily change all fund configuration. #### **Asset Manager** Each fund can have many asset managers, who can call any action on the `IntegrationManager` or `ExternalPositionManager` , and also buyback protocol fee shares. Allowed calls to the `IntegrationManager` and `ExternalPositionManager` can be further narrowed per-asset manager via policies. Only the owner can add or remove asset managers. Asset managers are considered fully-trusted. Policies that restrict asset managers remain available and are enforced on-chain, but they are operational guardrails (e.g., to keep a manager within the fund's mandate or to limit the impact of mistakes), not a security boundary against a malicious or compromised asset manager. ### Investors A fund can theoretically have unlimited investors, who get exposure to a fund's performance by buying, redeeming, or receiving a transfer of fund shares. ### Relationship between owners, asset managers, and investors Different funds have different needs and operational requirements. The core contracts are left as unrestrictive as possible by default, with configuration options, policies, and peripheral tooling available to help craft bespoke setups. Fund owners, migrators, and asset managers are considered fully-trusted by all contracts created and configured by the Enzyme team. Any trust limitations must be done externally via peripheral contracts (e.g., timelocked owner contracts). Fund owners delegate portfolio management actions to asset managers. Because asset managers are fully trusted, it is the responsibility of the fund owner to only appoint asset managers they would trust with the same level of control as themselves, and to remove any asset manager they no longer fully trust. Asset manager actions and action results can additionally be restricted via policies, but these restrictions should be treated as operational guardrails rather than protection against a malicious asset manager. Similarly, roles in peripheral contracts (e.g., executors of deposit and redemption queues) are assigned by the fund owner, who must assess whether the role is safe to assign to a given account. It is assumed that investors will continuously assess their own trust of the fund owner, the fund's asset managers, and the fund setup, as-needed. Issues that require a malicious or compromised fund owner, migrator, or asset manager (including an asset manager bypassing a policy intended to restrict asset managers) are out of scope of the bug bounty program. --- # 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 by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.enzyme.finance/enzyme-blue-protocol/users/end-users.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. 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.