# Protocol Access

This release implements a "protocol fee," which essentially:

* is a tax on AUM
* is levied continuously relative to an annualized target percentage (initially 25 bps)
* results in burning a corresponding amount of $MLN

## Approach

The protocol fee is charged to a fund by minting new shares to an Enzyme Council-administered contract (`ProtocolFeeReserveProxy`). This occurs anytime that a fund:

* receives a new deposit
* have shares redeemed
* migrates to a new release or reconfigures to a new `ComptrollerProxy` (see "Fund Lifecycle" page)

This approach of minting shares rather than directly collecting $MLN or other assets was thoroughly vetted and resulted in the least user friction, leanest architecture, and highest reliability.

It does, however, come with the drawback that the Council-administered `ProtocolFeeReserveProxy` continuously receives shares from *n* funds, which then need to somehow be converted to $MLN to be burned. Doing this manually via shares redemptions would be work-intensive, cost-inefficient (i.e., gas for redemptions and swaps), and in some cases not even possible (e.g., funds with all value locked in external positions).

To optimise the ease of protocol access and of passively collecting $MLN, this release uses an **Auto-Access** mechanism: 

Protocol shares are minted at an inflated rate (e.g., 50 bps) above the effective target access rate (e.g., 25 bps). Funds can access the protocol with $MLN to pay the target rate and avoid being penalised.

## Contracts

In order to implement this mechanism, two decoupled contracts with different lifespans and separate concerns are used in tandem:

* `ProtocolFeeTracker` is a non-upgradable, release-level contract that handles state and logic related to tracking the amount of shares that each fund owes at any moment in time
* `ProtocolFeeReserveProxy` is an upgradable, persistent contract that serves as the repository to which protocol fee shares are minted, and its current `ProtocolFeeReserveLib` handles logic for how those shares can be acted upon, i.e., bought back at a discount by the fund in exchange for $MLN

Importantly, all state-changing actions upon `VaultProxy` $MLN holdings (i.e., burn) and shares (i.e., mint and burn) are executed by the `VaultProxy` rather than via these external contracts:

* the `ProtocolFeeTracker` does not have permission to call a minting function on the `VaultProxy` 
* the `ProtocolFeeReserve` does not have permission to call a burning function on the `VaultProxy` 
* the `ProtocolFeeReserve` does not actually receive and burn its own $MLN, this is handled inside of the `VaultProxy`

The `ProtocolFeeTracker` and `ProtocolFeeReserve` simply provide the `VaultProxy` with the data it needs handle minting and burning.

This works because the `ProtocolFeeTrakcer` and `ProtocolFeeReserve` operate in complete trust of the `VaultProxy`, and this pattern keeps logic simple and clean, does not expose `VaultProxy` functions to additional state-changing callers, and is gas efficient.


---

# 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://specs.enzyme.finance/topics/protocol-fee.md?ask=<question>
```

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.