Skip to content

Collateralization Oracle (v2)#146

Merged
eswak merged 25 commits intofei-protocol:feat/v2from
eswak:feature-collateralization-oracle
Sep 5, 2021
Merged

Collateralization Oracle (v2)#146
eswak merged 25 commits intofei-protocol:feat/v2from
eswak:feature-collateralization-oracle

Conversation

@eswak
Copy link
Contributor

@eswak eswak commented Aug 31, 2021

This PR adds the Collateralization Oracle required for the V2.

In short, this new oracle...

  • Is configured by the DAO to follow a list of PCVDeposits (add, remove, swap are onlyGovernor)
  • Has its own list of oracles (need to call setOracle(token, address))
  • Relies on an updated PCVDeposit interface, we will need to deploy wrappers for existing deposits

The new PCVDeposit interface has the following methods :

  • balanceReportedIn() the token address used for accounting in this deposit
  • balanceAndFei() the resistant token balance & the protocol-owned FEI in this deposit

The CR Oracle has a function pcvStats() that returns :

  • the Protocol Controlled Value
  • the User Circulating FEI
  • the Protocol Equity
  • a validity status


/// @title a PCV Deposit interface for Fei V2
/// @author eswak
interface IPCVDepositV2 is IPCVDeposit {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ultimately we should just add these methods to the original interface (but I know that would lead to many compilation errors so we should wait until ready to add all of these methods to existing contracts)

@eswak eswak force-pushed the feature-collateralization-oracle branch from 45284eb to 2ddc62b Compare September 4, 2021 16:52
@eswak eswak changed the base branch from master to feat/v2 September 4, 2021 16:52
@eswak
Copy link
Contributor Author

eswak commented Sep 4, 2021

I rebased the branch & updated target to feat/v2, and implemented the first batch of changes. I'll work on memoization next.

/// of a deposit (holding the same token) is deployed.
/// @param _oldDeposit : the PCVDeposit to remove from the list.
/// @param _newDeposit : the PCVDeposit to add to the list.
function swapDeposit(address _oldDeposit, address _newDeposit) external onlyGovernor {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thoughts on just calling add then remove? It takes a bit more gas but may reduce complexity. This function is pretty simple so I don't feel strongly about it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

best code is no code 👍

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now that the logic is remove + add I don't think we need to enforce the tokens are the same as they are effectively distinct operations

Copy link
Contributor

@Joeysantoro Joeysantoro left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added one last nit. Contract looks fantastic

@eswak eswak merged commit ff99edb into fei-protocol:feat/v2 Sep 5, 2021
@eswak eswak deleted the feature-collateralization-oracle branch September 5, 2021 19:41

/// @notice returns true if a token is held in the pcv
function isTokenInPcv(address token) external view returns(bool) {
return tokensInPcv.contains(token);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Aren't we better off looking up a token in the tokenToOracle mapping and ensuring that the resulting address is not address 0 instead of enumerating over a list of addresses?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants

Comments