# Summary: Exploit Reversal via Firewall DPoS

## Overview

Firewall uses a delegated proof-of-stake design to ensure all exploits that occur are promptly reversed.

There are three defined actors involved in the exploit reversal system: Delegates, UMA DVM, and the Firewall DAO. These actors play within the five main roles of our exploit reversal system:

| Role | Who Plays It |
| -------- | -------- |
| Exploit Identification | Anyone |
| ***Exploit Report Submission*** | ***Delegates*** |
| Exploit Report Disputer | Anyone |
| Exploit Report Arbitrator | UMA DVM |
| Reparations Distributor | Firewall DAO |

This document focuses specifically on the role of Delegates. We've designed a DPoS-based network to achieve our goals because it ensures strong economic and social incentives for Firewall's integrators.

Here is a quick overview of the Firewall network. Most of the system factors algorithmically adjust based on the AUM of the network.

- Delegates stake are in Liquid Staking Token's of ETH, such as stETH
- To be considered a Delegate, one must have a minimum number of total $ staked
- Delegates must have a minimum number of assets staked themselves to become eligible as a Delegate
- Capital is locked in the system for 28-day rolling terms
- Delegates commit their liquidity for 28 days
- Withdrawal requests take minimally 7 days, maximally 34 days, depending on when requested within a term
- Delegates stake earns a benchmark yield for staking into the Network Insurance Layer[^1] (NIL) on 28-day terms
- Delegates can also earn alpha over this yield by accurately reversing exploits
- If an exploit goes un-reversed, all Delegates stakes are slashed from the NIL, to compensate the exploited application
- If an exploit is reversed incorrectly, the submitting Delegate(s) are penalized for damaging network UX and censorship costs

[^1]: NIL is the Network Insurance Layer, which provides the insurance backstop to network users in the case an exploit is not reversed. To become a Delegate the minimum stake must be committed to Firewall's NIL, on rolling 28-day terms.

## Goals

1. An exploit cannot occur on the network without being reversed quickly and accurately
2. Do this through a robust, open, and trustless system
3. Application teams and users feel safe that (1) is true, and in the case it becomes untrue, will be compensated

## DPoS Responsibilities

- Accurately identify exploits and submit state recalculations when exploits do occur, within the `output finalization period`
- Provide a backstop of insurance to network users in the case exploits are missed

### Exploit Identification

Quickly identifying exploits when they occur falls under the core competencies of the optimal Delegate. However, only the submission of a state recalculation needs to be [economically/socially] gated, exploit identification can be done by anyone.

Anyone with the skillset to quickly identify an exploit on the network can get paid for being fastest. To start, exploit identifiers, which can be thought of a flavor of "searchers" will post a small bond and register the exploit details onchain, from which Delegates can choose to validate and act on.

Longer-term, to keep this relationship between top "searchers" and "Delegates" in the open and equal-access, a system similar to the Flashbots auction between "searchers" and "block builders" will be used.

It's in Delegates best interest to attract and incentivize these specialized "searchers" who can detect exploits fast, so they earn more of the associated rewards. Some Delegates will have this skillset in-house (e.g. Peckshield), some will outsource it to the general market. Generally, this relationship and incentive-structure is very similar to a MEV strategy.

### State Recalculations

State recalculations are submitted by Delegates to reverse exploits when they occur. This simple process only requires the Delegate provide two pieces of information:

1. The ID of the application that was exploited
2. The block number to recalculate state from, which is the block with the first transaction of the exploit

The fastest to accurately submit this information earns the [bulk of the] rewards.

## Incentives

Our DPoS network relies on both positive and negative incentives to align actions with the network's goals.

### Positive

**Staking Yield**

- All Delegates earn a benchmark yield for committing assets into the NIL system
- The staking yield is a fixed amount of rewards per term, based on a target staking yield
- The target staking yield is based on the network AUM

**Exploit Reversal Yield**
- Delegates earn rewards for successfully reversing exploits
- on non-incentivized exploits, they may receive either a:
- fixed fee e.g. $1,000
- a share of inflationary rewards proportional to their "ER" points
- inflationary rewards incentivize Delegates to perform their duty in order to out-perform the "benchmark" or treasury yield of the network, to avoid being out-inflated, and attract more delegators to their business
- inflationary rewards further align skilled actors with the network's goals
- inflationary rewards may cost more than a fixed fee model

Exploit Reversal "ER" points are accrued by Delegates individually throughout a term, and reset at the end of it. The share any one Delegate earns from the inflationary rewards for a term is proporational to their ER points relative to all accumulated ER points in that term.

Per individual exploit, ER points are heavily front-loaded to fastest responder. See the below proposed breakdown:

| Responder Position | ER Points Scored |
| -------- | -------- |
| 1 | 15 |
| 2 | 4 |
| 3 - 5 | 2 |
| 6 - 10 | 1 |

This incentivizes Delegates to actively participate in an exploit reversal's process positively beyond the first responder, while heavily incentivizing being the fastest.

Each Delegate that stakes their collateral against a state recalculation submission adds utility by providing further confidence in the path of the network, and providing more financial compensation for reparations in the case the path chosen by the network is incorrect.

**Disputing Incorrect Exploit Reversal Submissions**

Note, incentives for disputing incorrect ER submissions by other Delegates, are the same as the "Exploit Reversal Yield". To dispute an incorrect submission a Delegate submits their own ER submission, first one to do so wins maximal ER points, etc.

Note, if a threshold for economic backing is reached, the network will follow a disputers exploit reversal submission over the initial response, before UMA's resolution which takes up to 96 hours.

- The threshold to do this is variably impacted if the Delegate who submitted the first "incorrect" submission switches their backing to the disputer's
- They're incentivized to correct their answer ASAP to reduce their censorship penalties, further explained below

### Negative

The cost of every Delegate acting maliciously or having poor performance is variable to the size of the exploit missed or un-reversed.

The cost of an individual malicious or poor-performing Delegate is the application they claimed was exploited gets censored and has no liveliness for a period up to UMA's DVM settlement time (48-96 hours).

Below are the details for how the network handles these downsides.

**Incorrect Exploit Reversal Slashing**
When reversing an exploit, a Delegate's stake becomes the UMA bond. If reversal details are incorrect, their stake is slashed.
- The slashed funds get distributed to the UMA DVM, disputer(s), and the Pilot DAO
- the Pilot DAO is responsible for distributing financial reparations for the incorrectly handled exploit
- There are two associated penalties:
- one is a fixed penalty, for damaging the UX of the network
- one is a variable penalty, for censoring an app
- variable depending on how long their wrong submission affects the network
- this is similar to ETH's PoS "inactivity leak"

An exploit can be incorrectly reversed in three distinct cases:
1. No exploit occurred on the submitted application. This effectively censored the app from usage for a period of up to 96 hours
2. An exploit occurred on the application, but the submitted block for the state recalculation didn't go back far enough. This effectively censored the app and didn't handle the exploit, which equates to an extra censored period of up to 96 hours
3. An exploit occured on the application, but the submitted block for the state recalculation went back too far. This effectively censored the app for some extra period of time less than the network's `output finalization period`

The % of stake slashed depends on how "far off" their answer is from being optimally correct
- "far off" penalties are defined by a bonding curve, relative to the optimal block to have recalculated state from
- If no exploit occurred on the submitted app, the maximal penalty is applied for the censorship of up to 96 hours
- If an exploit occurred but block submitted didn't go back far enough, the maximal penalty is applied for the censorship of up to 96 hours

**Missed Exploit Slashing**
If an exploit goes undetected past the `output finalization period`, all Delegates get slashed by the DPoS mechanism, and their funds are used to compensate for the exploit.
- ***this is the meaning of the phrase "insured by the network itself", or the concept of a NIL (network insurance layer)***

## Staking Model

*Below is an example model for the DPoS network, the true bonding curve and formula for the rewards schedule will be added to this doc in the future.*

The key to the core business model of Firewall's network is to reasonably expect streams of revenue to be greater than the "Annual Security Cost" column.

Network base streams of revenue would be:

1. MEV-generation from privileged sequencer order-flow, based on network activity. Can model these numbers from existing MEV-generation based on AUM of a network and specific applications (e.g. a DEX will generate more MEV than a lending app)
2. A skim fee on all or specific user transactions on the network, similar to Optimism's fee for public goods funding. This is a surplus fee charged on-top the required fees to pay for L1 data posting.

The Firewall network and platform will have other streams of revenue as well, but they're out of scope for the DPoS topic.

**Network AUM:** The total assets on the network, marked in USD
**Delegate Threshold:** The minimum $ value staked to be an active Delegate
**Target Delegates:** The total number of Delegates in the system
**Target Insurance:** The target insurance to be provided as a backstop for the network, from Delegates stakes, in case of un-reversed exploits
**Target Staking Yield:** The target staking yield (in APR) Delegates earn for committing capital into the NIL
**Annual Security Cost[^2]:** The total annualized cost to the network to ensure all exploits are reversed, and provide an insurance backstop.
**Exploit Reversal (ER) Yield + Cost[^3]:** The yield (in APR) and associated cost it'd add to the security budget, from inflationary rewards that Delegates can earn by accurately reversing exploits that occur.

[^2]: Note, this does not model-in the potential fixed-fee cost rewarded per exploit reversed, though should be a miniscule number relative to the base yield.

[^3]: This is an experimental column. While inflationary rewards provides strong incentive for active Delegate participation and further aligns good actors with more network ownership, it seems the network can reduce costs and pay less [via a fixed fee per exploit] since Delegates already have strong incentive via the insurance backstop mechanism to ensure no exploits don't get reversed.
It's also easier and fairer for Delegates to bid on exploit details in the eventual blind searcher auction from a fixed reward.

| Network AUM | Delegate Threshold | Target Delegates | Target Insurance | Target Staking Yield (APR) | ***Annual Security Cost*** | ER Yield (APR) + Cost
| -------- | -------- | -------- | -------- | -------- | -------- | --------
| $0-10M | $25k | 4 | $100k | 20% | $20k | 10% / $10k |
| $10-25M | $50k | 10 | $500k | 10% | $50k | -- |
| $25-50M | $100k | 10 | $1M | 5% | $50k | -- |
| ... | ... | ... | ... | ... | ... | -- |
| $1B-5B+ | $2M | 30 - 100 | $60M - $200M | 3% | $1.8M - $6M | -- |
| $5-10B+ | $5M | 40 - 100 | $200M - $500M | 3% | $6M - $15M | -- |

Note, "target" refers to these being the numbers the DPoS network's rewards model will offer for its optimal cost acquisition for liquidity to the NIL.

*Example*
If we target paying a 5% yield to acquire our target of $100M in capital commitments to the NIL:

- if we have > $100M staked to the NIL, the network staking yield will be < 5%
- if we have < $100M staked to the NIL, the network staking yield will be > 5%

Where it adjusts algorithmically based around our optimal NIL liquidity per our pre-defined schedule, similar to how Aave's variable rates lending market operates to target a specific liquidity available.

## Other Notes

**Approach to the Principal-Agent problem**

Our DPoS network is subject to the P-A problem. Our approach to solving it is inspired by [this paper](https://eprint.iacr.org/2023/605), and detailed in a write-up we'll be sharing soon.

**Does not matter if one entity controls many Delegates**
- Only one honest Delegate is required to reverse exploits
- All Delegates are incentivized to act honestly via the insurance backstop
- the more Delegates an entity has, the higher the cost of attack (not reversing exploits) on the network is
- Anyone can force a review of an exploit being missed, arbitrated by the UMA DVM
- We target a specific number of Delegates via our algorithmic rewards schedule, which adjusts by network AUM
- this works in a similar manner to lending app's borrow/lend rate models, which target specific liquidity availabilty

**Censorship Penalties**

96 hours is the max period of censorship an app may endure. This is the upper bound on the time UMA'S DVM settlement period takes.

Note, a Delegate falsely censoring an app is incentivized to correct their submission ASAP to short-circuit their censorship penalties, so that the app can stop being censored before UMA's official response occurs.

**Non-Incentivized Exploits**

This is mentioned above, where a fixed reward (or a share of inflationary rewards) is given to Delegates to accurately submit exploit reversals.

- "non-incentivized" is the default classification of an exploit on the network
- As long as exploiters believe they can't successfully exit the network with stolen funds, there is no incentive for them to execute these exploits
- We predict "non-incentizing" apps on Pilot trend to experiencing zero exploits, reducing the downside of selective finality on the network UX
- Teams who are focused on bootstrapping a community/users, iterating to product-market fit, etc. will likely fall in the "non-incentivizing" category, where there is no incentive to exploit their product

### Reach Out and Follow Along!

We're excited to hear feedback, thoughts, and criticism as we continue to build and iterate on our vision. Please reach out to us in our Discord or on Twitter, and join the community discussion!

- [@itsDSPawer](https://twitter.com/itsDSPawer) & [@sam___iamm](https://twitter.com/sam___iamm)
- Join our Discord: https://discord.gg/Rs3T7CXDq9
- Follow our Twitter: https://twitter.com/Pilot_HQ