# Fund Lifecycle Globally, new funds can be created on the latest release according to the `Dispatcher`. Once created, funds can be migrated to the newest release. The global logic for these actions is located in the `Dispatcher` and additional release-level logic is located in the `FundDeployer`. The `FundDeployer` operates as the top-level release contract, governing: * **creation**: how new funds are created on this release * **migration**: how funds on previous releases are upgraded to this release * **reconfiguration**: how funds on this release can change all release-level configuration (core settings, policies, and fees) A new `ComptrollerProxy` is deployed and attached to the `VaultProxy` as its `accessor` via each of these actions. It stores core config options, and the config relative to extensions and their plugins are stored in those particular contracts by reference to the `ComptrollerProxy`. The `ComptrollerProxy` thus serves as the primary configuration object of a fund. See "Architecture: Release" for more detail on these contracts. ## Creation In order to create a new fund, CallerA (any account) can call `FundDeployer.createNewFund()` and all components and configuration of the fund are created atomically. The steps taken by this function are: 1. The `FundDeployer` deploys a new `ComptrollerProxy` instance, which sets the caller-provided core and extension config. 2. `FundDeployer` calls to the `Dispatcher` to deploy a new `VaultProxy` with the CallerA-provided `fundOwner` and `fundName` (note that `fundOwner` does not need to be CallerA), along with the release's `VaultLib` and the newly-created `ComptrollerProxy` that will become the `VaultProxy` 's `accessor`. 3. The `FundDeployer` sets the newly-deployed `VaultProxy` on the `ComptrollerProxy` and calls`ComptrollerProxy.activate()` to perform the final setup logic and give extensions a final chance to validate and update state. 4. The fund is now live on this release. ## Migration ### **Migration to this release from a previous release** 1. MigratorA calls `FundDeployer.createMigrationRequest()` , which deploys a new `ComptrollerProxy` instance, setting the caller-provided core and extension config, and the `VaultProxy` that will be migrated. 2. MigratorA waits for the `migrationTimelock` defined on the `Dispatcher` to pass. \[NOTE: This is no longer used and is set to \`0\`] 3. MigratorA calls `FundDeployer.executeMigration()` , which calls up to `Dispatcher.executeMigration()` 4. The `Dispatcher` updates the `VaultProxy` 's `VaultLib` and assigns the newly-created `ComptrollerProxy` as its `accessor` . 5. The `FundDeployer` calls `ComptrollerProxy.activate()` to give extensions a final chance to validate and update state. 6. The fund is now live on this release. ### Migration from this release to a new release The `Dispatcher` invokes hooks at each stage of the migration that call down to the outbound `FundDeployer` , giving this release the chance to execute arbitrary code, reacting to the migration. This release implements only the `invokeMigrationOutHook` that runs immediately prior to executing the migration. It: * pays the due protocol fee * pays out any fee shares outstanding * calls `selfdestruct()` on the `ComptrollerProxy` ## Reconfiguration A reconfiguration is very similar to a migration (on both a high and low level) in that a new `ComptrollerProxy` is created to replace the old `ComptrollerProxy` , within the same release. It can even be called an "intra-release migration." The difference is mostly that rather than passing calls up to an authoritative `Dispatcher`, the `FundDeployer` itself stores a `reconfigurationRequest` and defines a local`reconfigurationTimelock` \[NOTE: This is no longer used and is set to \`0\`]. 1. MigratorA calls `FundDeployer.createReconfigurationRequest()` , which deploys a new `ComptrollerProxy` instance, setting the caller-provided core and extension config, and the `VaultProxy` that will be moved. 2. MigratorA waits for the `reconfigurationTimelock` to pass. \[NOTE: This is no longer used and is set to \`0\`] 3. MigratorA calls `FundDeployer.executeReconfiguration()` , which assigns the newly-created `ComptrollerProxy` as its `accessor` . 4. The `FundDeployer` deactivates the old `ComptrollerProxy` as described in "Migration from this release to a new release". 5. The `FundDeployer` calls `ComptrollerProxy.activate()` to give extensions a final chance to validate and update state. 6. The fund now has a new `ComptrollerProxy` with new configuration live on this release. --- # Agent Instructions: 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: ``` GET https://docs.enzyme.finance/enzyme-blue-protocol/topics/creation-migration-reconfiguration.md?ask= ``` The question should be specific, self-contained, and written in natural language. 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.