Conversation
|
We also need to add a test here that tries to call |
Joeysantoro
changed the base branch from
feat/v2-phase1-fixes
to
feat/v2/base
xklob
left a comment
xklob
left a comment
There was a problem hiding this comment.
This looks great. I'm glad we hardcoded in the Treasury, Dripper, etc.
I think we need to make very sure that the Tribe balance in the Treasury & the Dripper aren't manipulable if we're going to use tribe.balanceOf (as opposed to having them report their own locked balances).
Otherwise, no concerns.
The only way to get tokens out of them is drip() or having a governor or PCV Controller role. |
3 participants
Separates all Tribe Minting logic out from TribeReserveStabilizer into a TribeMinter contract
@title implementation for a TRIBE Minter Contract
@author Fei Protocol
This contract will be the unique TRIBE minting contract.
All minting is subject to an annual inflation rate limit.
For example if circulating supply is 1m and inflation is capped at 10%, then no more than 100k TRIBE can enter circulation in the following year.
The contract will increase (decrease) the rate limit proportionally as supply increases (decreases)
Governance and admins can only lower the max inflation %.
They can also exclude (unexclude) addresses' TRIBE balances from the circulating supply.
The minter's balance is excluded by default.
ACCESS_CONTROL:
This contract follows a somewhat unique access control pattern.
It has a contract admin which is NOT intended for optimistic approval, but rather for contracts such as the TribeReserveStabilizer.
An additional potential contract admin is one which automates the inclusion and removal of excluded deposits from on-chain timelocks.
Additionally, the ability to transfer the tribe minter role is held by the contract owner rather than governor or admin.
The owner will intially be the DAO timelock.
This keeps the power to transfer or burn TRIBE minting rights isolated.
Also makes some light changes to RateLimited contract