ProtocolFeeReserveProxy). This occurs anytime that a fund:
ComptrollerProxy(see "Fund Lifecycle" page)
ProtocolFeeReserveProxycontinuously 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).
setAutoProtocolFeeSharesBuyback()is toggled on in the fund's
ComptrollerProxy, then it will attempt to use the $MLN available in the the
VaultProxyto atomically buyback the full amount of protocol fee shares collected (during deposit and shares redemption actions).
ProtocolFeeTrackeris 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
ProtocolFeeReserveProxyis an upgradable, persistent contract that serves as the repository to which protocol fee shares are minted, and its current
ProtocolFeeReserveLibhandles logic for how those shares can be acted upon, i.e., bought back at a discount by the fund in exchange for $MLN
VaultProxy$MLN holdings (i.e., burn) and shares (i.e., mint and burn) are executed by the
VaultProxyrather than via these external contracts:
ProtocolFeeTrackerdoes not have permission to call a minting function on the
ProtocolFeeReservedoes not have permission to call a burning function on the
ProtocolFeeReservedoes not actually receive and burn its own $MLN, this is handled inside of the
ProtocolFeeReservesimply provide the
VaultProxywith the data it needs handle minting and burning.
ProtocolFeeReserveoperate in complete trust of the
VaultProxy, and this pattern keeps logic simple and clean, does not expose
VaultProxyfunctions to additional state-changing callers, and is gas efficient.