Hi @keating and everyone!
Thanks for the post and the presentation, it’s nice to see prior proposals coming together into the Fee Flow System. Sharing some thoughts in order to keep the conversation going:
-
The price auction is indeed a reasonable model since it heavily reduces the complexity associated of converting fees into ZK for burning or distributing. The fixed-price is also fair in terms of simplicity regarding this first iteration.
-
Baseline burn parameters seem aligned with the ZK Flywheel while leaving open the possibility of including other distribution recipients or changing the parameter itself which is of course desirable.
-
As mentioned on the call, and given the inherent relationship with V31, a set path for ZK should be probably incorporated as it wouldn’t make sense to have it directed to the auction contract.
On roles and governance
First of all, the existance of an emergency admin is a necessary safeguard given the sensitive nature of the contract. The listed actions very well reflect the expected faculties that his role should have in order to perform precisely an emergency action, to which some seem more pressing than others. On who should hold the question remains open although it reasonably falls into the Security Council given that 1) Its an already existing structure 2) Emergency actions fall within their scope (as long as the emergency corresponds to precisely a security breach).
On the admin role, Foundation and ML play a key role within the Fee Flow System given that new ZK Chains deployments are stewarded and implemented by them. This naturally gives high context on the fee designs and mechanisms that eventually end up in the Fee Flow System. In order to streamline this role further, an internal Committee or structure could be set in place to monitor and execute the required actions, something that Lido has done vastly i.e.
Moreso, the possibility of engaging with service providers such as risk managers could also be contemplated within the responsabilities of this Committee. The DSC experience during Ignite can be leveraged when thinking of this approach.
On the admin role and it’s functions:
- Add and remove tokens from an approved list of claimable assets.
If we are thinking on these based off ZK Chains fees, it would make sense to provide some sort of fast track in order to execute presumably operational decisions. Several protocols have experimented on this with different applications such as UNIfication (simplified process for fee parameters), AAVE (Direct-to-AIP framework) or Lido (Easy Tracks - stVaults example).
- Assign the fixed ZK claim threshold, i.e., the amount of ZK a claimant must transfer to sweep the token inventory
Again, this would be closely related to the burn parameter and the distribution contracts if any, making it dependent to the outcome of another ZIP or TPP as well as the available listed tokens. In the same spirit, destination adresses management follow the same principle.
Final thoughts
The Fee Flow system gives the chance to decouple governance from operations and think of governance surfaces areas. As per V31, fixed-fees can only be modified by protocol upgrades, therefore giving the ZK Association direct ownership, something that the burn parameter modification and creation of new distribution contracts likely should follow. For the derived operations, having a MVS to monitor and execute should be optimal alongside a separate process for standar procedures.
Again, this are some early thoughts to keep the conversation going, feel free to call out any misinterpretation.
Thanks!