FIP-87: PCV Sentinel

Status: Sent to DAO

Authors: @klob


Often there are times in crypto where quick action is needed, and needed faster than the typical 15minutes-1hour that a multisig team can be expected to respond. One such recent example is the CREAM hack; a few others were the recent Rari oracle-liquidity attacks.

The PCV Sentinel aims to solve this need for “quick, permissioned action”, and also provides as a secondary effect a way to automate key levers in the Fei system - but only those that the GUARDIAN role already has access to (such as pausing or unpausing certain psms).

As a reminder, the GUARDIAN role is held currently only by the Multisig Guardian, and has the power to pause and unpause many contracts in the system, perform low impact adjustments on protocol parameters, and veto dao votes.

The Guardian works as follows: On its own, it can do nothing. However, the guardian multisig can elect to add “guard” at their perogative. Each “guard” can be envisioned as a protector of one thing. Internally, each guard is a smart contract that knows how to check for a particular failure condition - such as “low liquidity fuse pool oracle”, and knows what to do when that check fails - such as “pause the fuse pool”.

Other potential guards:

  • simple automation of the psms: enable ETH psm when dai & lusd psms have low liquidity, or pause it if they have sufficient liquidity
  • oracle issues: pause psm if univ2 & oracle price have diverged widely enough
  • exploit protection: pause & withdraw all assets from pcv deposit to safe location (via PCVGuardian) if underlying pcv deposit assets mismatch pcv deposit balance record

The existing PCVGuardian + this PCVSentinel should add a good degree of potential automated protection actions (triggered by keepers or protocol bots) and should provide a good degree of additional firewalling from protocol-health threatening issues.


The PCV Sentinel will be deployed and granted the role of “GUARDIAN” (the same role as the multisig guardian. The Tribe DAO authorizes the multisig guardian to add automated policies to the PCV Sentinel to protect the PCV, automate key protocol features such as the PSM, the collateralization oracle, and other system-critical components.

The (near-finalized) code for the PCV Sentinel can be viewed here:


The proposal will use simple-choice yes/no voting.


Note that there is one special case to consider with this proposal, namely, it’d be granting a second address (the pcv sentinel) the role of “GUARDIAN”. One could argue that then the PCV Sentinel could be used to counteract the multisig guardian in some kind of attack; however, the multisig guardian is the only one that has the ability to add guards to the pcv sentinel, and should absolutely avoid adding guards that implement arbitrary logic or call out to other contracts to figure out what calldata to provide.

(This is additionally why we’ve chosen to use .call on calldata retrieved from each guard, instead of .delegatecall; thanks @Joey for convincing me that this was the right move, eventually.)


Moving to last call.

1 Like

Snapshot posted here: Snapshot

1 Like

Proposal is now up for vote on the DAO: Tally | Fei Proposal

PCV Sentinel deployed @ 0xC297705Acf50134d256187c754B92FA37826C019