# Mathematical Model Specification
###### tags: `cadlabs-ethereum-economic-model`
[](https://hackmd.io/wHM-t557Tp2BH1gItdRvFA)

Mathematical Model Specification for the [CADLabs Ethereum Economic Model](https://github.com/CADLabs/ethereum-economic-model/releases/tag/v1.1.0) version v1.1.0.

:::info
If you are not viewing this document in HackMD, it was formatted using Markdown and LaTeX to be rendered in HackMD. For the best viewing experience see https://hackmd.io/@CADLabs/ryLrPm2T_
:::

## Overview

This Mathematical Model Specification articulates the relevant Ethereum validator economics system dynamics as a [state-space representation](https://en.wikipedia.org/wiki/State-space_representation). Given the iterative nature of dynamical systems modelling workflows, we expect to make adjustments to this Mathematical Model Specification as we build and validate the cadCAD model.

### Assumptions

The model implements the official [Ethereum Specification](https://github.com/ethereum/eth2.0-specs) wherever possible, but rests on a few default system-level and validator-level assumptions detailed in the model [ASSUMPTIONS.md](https://github.com/CADLabs/ethereum-economic-model/blob/main/ASSUMPTIONS.md) document.

### Level of Aggregation

Although cadCAD technically supports several computational modelling paradigms (e.g. agent-based modelling, population-level modelling, system dynamics modelling, hybrid modelling, etc.) we adopt an aggregate system dynamics lens. Rather than modelling the behaviour of individual agents, we consider what is often called a "representative agent" in economics literature. This allows us to apply aggregation and approximation for groups of agents, or in our case - validators aggregated as validator environments.

### Epoch-level Granularity

Unless specified otherwise in the Mathematical Model Specification, all State Variables, System Metrics, and System Parameters are time-dependent and calculated at per-epoch granularity. For ease of notation, units of time will be assumed implicitly. In the model implementation, calculations can be aggregated across epochs where necessary - for example for performance reasons.

## Notation

The Mathematical Model Specification uses the following notation:
* A list / vector of units or in calculations is represented using the matrix symbol: $\begin{bmatrix} x \end{bmatrix}$
* A list or vector variable is represented using the vector symbol: $\vec{x}$
* A $\Rightarrow$ symbol represents a function that returns a value, ignoring the arguments. For example a Python lambda function `lambda x: 1` would be represented as: $\Rightarrow 1$
* The superscript $S^+$ is used to define a state transition from state $S$ at the current epoch $e$, to the state at the next epoch $e + 1$
* The superscript $S'$ is used to define an individual element to be aggregated in order to get the final state $S$

The following domain notation is used in the Mathematical Model Specification:
* $\mathbb{Z}$ - positive and negative integers
* $\mathbb{R}$ - positive and negative real numbers
* $\mathbb{Z}^+$ - positive integers
* $\mathbb{R}^-$ - negative real numbers
* etc.

## System States

To create a [state-space representation](https://en.wikipedia.org/wiki/State-space_representation), we first describe the system's [state-space](https://www.google.com/search?q=state+space+state+variables&oq=state+space+state+variables) in the form of a set of State Variables. A state-space is a data structure that consists of all possible values of State Variables. The state of the system can be represented as a state vector within the state-space.

For reasons of clarity and comprehensibility we categorize State Variables as follows: ETH State Variables, Validator State Variables, Reward and Penalty State Variables, EIP-1559 State Variables, and System Metric State Variables.

We define the State Variables' domain, range, and units. The "variable" column values are direct referrences to the cadCAD model code.

## Network Parameters
| Variable |Symbol| Default Value | Unit | Description |
| -------- | -------- | -------- | -------- | -------- |
| `PUBLIC_CHAINS_CNT` | $N_u$| 1 | $\mathbb{Z}$ | Number of public chains|
| `PRIVATE_CHAINS_CNT` |$N_r$ |1 | $\mathbb{Z}$ | Number of private chains|
| `CHAINS_CNT` |$N_0$ |1 | $\mathbb{Z}$ | Number of total chains|

### POLYGN State Variables

| Name | Symbol | Domain | Unit | Variable | Description |
| -------- | -------- | -------- | -------- | -------- | --------|
| POLYGN Price | $P$ | $\mathbb{R}^+$ | $$/\text{ETH}$ | `polygn_price` | POLYGN spot price sample (from exogenous process, but constant in step 1) |
| POLYGN Supply | $S$ | $\mathbb{R}^+$ | $\text{ETH}$ | `polygn_supply` | POLYGN supply with inflation/deflation |
| POLYGN Staked | $X$ | $\mathbb{R}^+$ | $\text{ETH}$ |`polygn_staked` | Total POLYGN staked ("active balance") by all active validators |

### Validator State Variables

| Name | Symbol | Domain | Unit | Variable |
| -------- | -------- | -------- | -------- | --------|
| # Validators in Activation Queue | $V_{queue}$ | $\mathbb{R}^+$ | None | `number_of_validators_in_activation_queue` |
| # Validators | $V$ | $\mathbb{R}^+$ | None | `number_of_validators` |
| # Validators Online | $V_{online}$ | $\mathbb{R}^+$ | None | `number_of_validators_online` |
| # Validators Offline | $V_{offline}$ | $\mathbb{R}^+$ | None | `number_of_validators_offline` |
| Average Effective Balance | $\bar{B}$ | $\mathbb{R}^+$ | $\text{Gwei}$ | `average_effective_balance` |
| Validator POLYGN Staked | $\vec{\sigma}$ | $\mathbb{R}^+$ | $[\text{ETH}]$ | `validator_polygn_staked` |

### Reward and Penalty State Variables

| Name | Symbol | Domain | Unit | Variable |
| ------------------------------ | ------- | -------------- | ------------- | -------------------------------- |
| Base Reward | $\beta$ | $\mathbb{R}^+$ | $\text{Gwei}$ | `base_reward` |
| Amount Slashed | $\psi$ | $\mathbb{R}^+$ | $\text{Gwei}$ | `amount_slashed` |
| Validating Rewards | $R_v$ | $\mathbb{R}^+$ | $\text{Gwei}$ | `validating_rewards` |
| Total Online Validator Rewards | $R_o$ | $\mathbb{R}^+$ | $\text{Gwei}$ | `total_online_validator_rewards` |

### EIP1559 State Variables

| Name | Symbol | Domain | Unit | Variable |
| -------- | -------- | -------- | -------- | --------|
| Total Base Fee of Public Chains | $F$ | $\mathbb{R}^{+{N_u}}$ | $\text{Gwei}$ | `total_public_base_fee` |
| Total Base Fee of Private Chains | $F$ | $\mathbb{R}^{+{N_r}}$ | $\text{Gwei}$ | `total_private_base_fee` |
| Base Fee per Gas | $t$ | $\mathbb{R}^+$ | $\text{Gwei/gas}$ | `base_fee_per_gas` |
| Total Priority Fee to Validators | $T_v$ | $\mathbb{R}^{+{N_0}}$ | $\text{Gwei}$ | `total_priority_fee_to_validators` |

### Treasury State Variables

| Name | Symbol | Domain | Unit | Variable |
| -------- | -------- | -------- | -------- | --------|
| Total Base Fee of Public Chains Donating to Domain Treasury | $D_u$ | $\mathbb{R}^{+}$ | $\text{Gwei}$ | `public_base_fee_to_domain_treasury` |
| Total Base Fee of Private Chains Donating to Domain Treasury | $D_r$ | $\mathbb{R}^{+}$ | $\text{Gwei}$ | `private_base_fee_to_domain_treasury` |

### System Metric State Variables

We first define System Metrics on the level of the following 7 validator environments, using Numpy array matrix algebra:

1. DIY Hardware
2. DIY Cloud
3. Pool StaaS
4. Pool Hardware
5. Pool Cloud
6. StaaS Full
7. StaaS Self-Custodied

We then define network-level System Metrics through aggregation.

#### Validator Environment Level

The State Variables in this category have the following vector form:

\begin{bmatrix}
\text{DIY Hardware}\\
...\\
\text{StaaS Self-Custodied}
\end{bmatrix}

| Name | Symbol | Domain | Unit | Variable |
| -------- | -------- | -------- | -------- | --------|
| Validator Revenue | $\vec{K_r}$ | $\mathbb{R}$ | [$] | `validator_revenue` |
| Validator Profit | $\vec{K_p}$ | $\mathbb{R}$ | [$] | `validator_profit` |
| Validator Revenue Yields | $\vec{Y_r}$ | $\mathbb{R}$ | $[\%]$ | `validator_revenue_yields` |
| Validator Profit Yields | $\vec{Y_p}$ | $\mathbb{R}$ | $[\%]$ | `validator_profit_yields` |
| Validator Count Distribution | $\vec{V}$ | $\mathbb{R}^+$ | $[\%]$ | `validator_count_distribution` |
| Validator Hardware Costs | $\vec{C}_{hardware}$ | $\mathbb{R}^+$ | [$] | `validator_hardware_costs` |
| Validator Cloud Costs | $\vec{C}_{cloud}$ | $\mathbb{R}^+$ | [$] | `validator_cloud_costs` |
| Validator Third-Party Costs | $\vec{C}_{third-party}$ | $\mathbb{R}^+$ | $[\%]$ | `validator_third_party_costs` |
| Validator Costs | $\vec{C}$ | $\mathbb{R}^+$ | [$] | `validator_costs` |

#### Treasury State Variables
| Name | Symbol | Domain | Unit | Variable |
| -------- | -------- | -------- | -------- | --------|
| Domain Treasury Unlocked Balance| $M_u$ | $\mathbb{R}^+$ | $\text{Gwei}$ | `domain_treasury_balance_unlocked` |
| Domain Treasury Locked Balance | $M_l$ | $\mathbb{R}^+$ | $\text{Gwei/gas}$ | `domain_treasury_balance_locked` |
| Private Treasury Balance | $M_p$ | $\mathbb{R}^{+N_r}$ | $\text{Gwei/gas}$ | `private_treasury_balance` |

#### Aggregate Network Level

The above validator-environment-level System Metrics are then aggregated into scalar values to define aggregate network-level system metrics. For example, the validator costs $\vec{C}$ becomes the total network costs $C$ when summed over all 7 validator types.

| Name | Symbol | Domain | Unit | Variable |
| -------- | -------- | -------- | -------- | --------|
| POLYGN Supply Inflation | $I$ | $\mathbb{R}$ | $\%$ | `supply_inflation` |
|POLYGN Inflation to Validators||$\mathbb{R}$|Gwei|`total_inflation_to_validators`|
| Total Revenue | $K_r$ | $\mathbb{R}$ | $ | `total_revenue` |
| Total Profit | $K_p$ | $\mathbb{R}$ | $ | `total_profit` |
| Total Network Costs | $C$ | $\mathbb{R}^+$ | $ | `total_network_costs` |
| Total Revenue Yields | $Y_r$ | $\mathbb{R}$ | $\%$ | `total_revenue_yields` |
| Total Profit Yields | $Y_p$ | $\mathbb{R}$ | $\%$ | `total_profit_yields` |

## System Inputs

By defining State Variables we have defined the system's state-space and with it, system boundaries. System inputs are not dependent on the system's State Variables. Their logic is defined by Policy Functions in our cadCAD model, and they update the model's State Variables via State Update Functions.

We describe three environmental processes as System Inputs, updating the ETH Price and ETH Staked State Variables.

### Validator Adoption Process & ETH Staked Process

For the purpose of the model, we define environmental processes for both Validator Adoption and ETH Staked. A certain level of Validator Adoption has an implied ETH Staked value. We use the ETH Staked process to drive the model when performing phase-space analyses of a range of ETH staked values, and the Validator Adoption process when performing time-domain analyses where the validator activation mechanism also comes into play.

The ETH Staked environmental process, represented in the model as a Python lambda function, is called at each epoch with the current run and timestep, and returns the change in ETH staked to update the ETH Staked State Variable during runtime. On the other hand, the Validator Adoption environmental process returns the number of validators being added to the activation queue at each epoch.

For the MVP implementation of our model we assume a representative agent that remains within the system once entered, and we use a monotonically increasing function as a standard adoption model. We also plan the option for the user to manually define validator adoption levels to emulate custom scenarios.

In future model implementations, we could imagine adding feedback loops from State Variables - for instance, capital efficient validators will likely stake and unstake ETH based on the development of validator returns.

### ETH Price Process

For the MVP implementation of our model we use tiered ETH price levels to represent the relevant spectrum of market conditions, similar to [Hoban/Borgers' Economic Model](https://drive.google.com/file/d/1pwt-EdnjhDLc_Mi2ydHus0_Cm14rs1Aq/view). We also plan the option for the user to manually select ETH price ranges to emulate custom scenarios.

This environmental process, represented in the model as a Python lambda function, is called at each epoch with the current run and timestep, and returns an ETH price sample to update the ETH Price state variable during runtime.

## System Parameters

System Parameters are used as configurable variables in the model's System Input (Policy Function) and State Update (State Update Function) logic. An example of a parameter would be the `BASE_REWARD_FACTOR`, used to calculate and update the base reward State Variable.

In a cadCAD model, parameters are lists of Python types that can be swept, or in the case of a stochastic process used to perform a Monte Carlo simulation. For the purpose of experimentation we've set defaults, and will sweep parameters within reasonable ranges around these defaults.

Any parameter with the suffix `_process` can be assumed to be a Python lambda function used to generate a series of values for said parameter, indexed by the run and/or timestep. An illustrative example:

import random

TIMESTEPS = 100
samples = random.sample(range(95, 99), TIMESTEPS + 1)
validator_uptime_process = lambda _run, timestep: samples[timestep] / 100

For reasons of clarity and comprehensibility we categorize parameters as either Ethereum Official Specification, Validator Environment, Validator Performance, or Transaction Pricing System Parameters.

### Treasury Parameters

| Variable | Default Value | Unit | Description |
| -------- | -------- | -------- | -------- |
|`BASE_FEE_PUBLIC_QUOTIENT`|55|$\begin{bmatrix} \% \end{bmatrix}$| The portion of public chain base fee distributed to domain treasury |
|`BASE_FEE_PRIVATE_QUOTIENT`|10|$\begin{bmatrix} \% \end{bmatrix}$|The portion of private chain base fee distributed to domain treasury|
| `domain_treasury_monthly_unlock_process` | 0.01 |$\%$ |A process that returns the monthly unlock percentage of the total treasury balance.|

### POLYGN System Parameters

| Variable | Default Value | Unit |
| -------- | -------- | -------- |
| `MIN_PER_EPOCH_CHURN_LIMIT` | `4` | None |
|`MAX_VALIDATOR_COUNT` | `100` | None |
| `MIN_SLASHING_PENALTY_QUOTIENT` | `1e7` | None |
| `inflationary_rate_per_year` | `0.01` | None |

### Validator Environment System Parameters

| Variable | Unit | Description |
| -------- | -------- | -------- |
| `validator_percentage_distribution` | $\begin{bmatrix} \% \end{bmatrix}$ | The distribution of the total number of validators per validator type. Vector sum is a total of 100%. |
| `validator_hardware_costs_per_epoch` | $$\begin{bmatrix} USD \end{bmatrix}$$ | The per-epoch costs for DIY hardware infrastructure per validator type |
| `validator_cloud_costs_per_epoch` | $$\begin{bmatrix} USD \end{bmatrix}$$ | The per-epoch costs for cloud computing resources per validator type |
| `validator_third_party_costs_per_epoch` | $\begin{bmatrix} \% \end{bmatrix}$ | A percentage value of the total validator rewards that goes to third-party service providers as a fee per validator type |

### Validator Performance System Parameters

| Variable | Default Value | Unit | Description |
| -------- | -------- | -------- | -------- |
| `validator_uptime_process` | `max(0.98, 2 / 3)` | $\%$ | The expected average validator uptime. A combination of validator internet, power, and technical uptime: 99.9 * 99.9 * 98.2. Minimum uptime is inactivity leak threshold of `2/3`, as this model doesn't model the inactivity leak mechanism. |
| `slashing_events_per_1000_epochs` | `1` | $\frac{1}{1000}\text{epochs}$ | The expected number of validator actions that result in slashing per 1000 epochs |

### Transaction Pricing System Parameters

| Variable | Default Value | Unit | Description |
| -------- | -------- | -------- | -------- |
| `base_fee_process` | `30` | $\text{Gwei/gas}$ | EIP-1559 transaction pricing base fee burned for each transaction. Default value approximated using average historical gas price - see [assumptions doc](https://github.com/CADLabs/ethereum-economic-model/blob/main/ASSUMPTIONS.md). |
| `priority_fee_process` | `2` | $\text{Gwei/gas}$ | EIP-1559 transaction pricing priority fee. Default value approximated using average gas price - see [assumptions doc](https://github.com/CADLabs/ethereum-economic-model/blob/main/ASSUMPTIONS.md). |
| `gas_target_process` | `15e6` | $\text{Gas}$ | The long-term average gas target per block. Simplifying assumption that gas used per block will equal gas target on average over long-term. |

## State Update Logic

After defining the model's state-space in the form of System States, we describe the State Update Logic, represented as cadCAD Policy and State Update Functions (sometimes also called "mechanisms").

To visualize the State Update Logic, we use a differential specification diagram (also known as a "cadCAD Canvas" at cadCAD Edu). This diagram will accompany the derivation of the Mathematical Model Specification of the model mechanisms.

The [model's cadCAD Canvas / Differential Model Specification](https://lucid.app/lucidchart/c7656072-e601-4ec4-a44b-0a15c9a5700d/view) is accessible via LucidChart. Below is an illustrative screenshot.


We describe the State Update Logic along the columns of the model's cadCAD Canvas, also known as "Partial State Update Blocks" (PSUB). One round of execution of these Partial State Update Blocks would represent the state transition from one epoch to the next.

#### cadCAD Canvas Legend

Extracts from the cadCAD Canvas have been included for each PSUB below when deriving the Policy and State Update Logic, and the following is the legend included with the cadCAD Canvas:

<img src="https://i.imgur.com/lbqjbbU.png" alt="psub" height="500rem"/>

#### Constants

The following constants are used in the derivation of the State Update Logic.

| Name | Symbol | Domain | Unit | Variable | Value |
| -------- | -------- | -------- | -------- | --------| --------|
| Epochs per year | $E_{year}$ | $\mathbb{Z}^+$ | $\text{epochs}$ | `epochs_per_year` | 82180 |
| Epochs per day | $E_{day}$ | $\mathbb{Z}^+$ | $\text{epochs}$ | `epochs_per_day` | 225 |

### PSUB 1&2: EIP1559 Transaction Pricing

<img src="https://i.imgur.com/4oO0dkL.png" alt="psub" height="500rem"/>

EIP-1559 replaces the current transaction gas price (in Gwei per gas), with two values: a dynamic base fee that is burned and applied to all transactions, and a priority fee per transaction that is paid to miners/validators.

The current gas limit is replaced by two values:
* a “long-term average target” equal to the current gas limit
* a “hard per-block cap” which is twice the current gas limit

The long-term average gas target per block is set to 15m gas; by default we assume the gas used per block will on average be equal to the gas target.

Pre-merge, while Proof-of-Work is still active, miners receive the priority fee, and the gas used is calculated according to block-time:
\begin{equation}
\begin{aligned}
\text{gas used} &= \text{blocks per epoch} \times \text{gas target}\\
F &= \text{gas used} \times f\\
T = T_m &= \text{gas used} \times t\\
\end{aligned}
\end{equation}

Post-merge, when Proof-of-Work is deprecated and Proof-of-Stake validators start including transactions, validators receive the priority fee, and the gas used is calculated according to slot-time:
\begin{equation}
\begin{aligned}
\text{gas used} &= \text{slots per epoch} \times \text{gas target}\\
F &= \text{gas used} \times f\\
T = T_v &= \text{gas used} \times t\\
\end{aligned}
\end{equation}

### PSUB 3: Validator Process

<img src="https://i.imgur.com/GeixAb3.png" alt="psub" height="500rem"/>

Validators that deposit their initial stake first enter into an activation queue before being considered active validators and having their stake as part of the effective balance used when calculating validator rewards and penalties.

\begin{equation}
\begin{aligned}
\text{churn limit } &= \text{MIN_PER_EPOCH_CHURN_LIMIT}\\
\text{new validators } &= \text{validator_process(run, timestep)} \\
v &= \text{min($V_{queue} +$ new validators, churn limit)}\\
V^+ &= V + v\\
V_{queue}^+ &= V_{queue} - v\\
\end{aligned}
\end{equation}

The number of validators is equal to the sum of the number of validators online and offline:

\begin{equation}
\begin{aligned}
V_{online} &= V^+ \times \text{validator uptime} \\
V_{offline} &= V^+ - V_{online}
\end{aligned}
\end{equation}

### PSUB 4: POLYGN Processes

<img src="https://i.imgur.com/nTrNTL5.png" alt="psub" height="500rem"/>

The ETH price is driven by an environmental process, defined earlier in the Model Specification, that updates the ETH price at each timestep.

The total ETH staked is the number of activate validators multiplied by the average effective balance in ETH:
$$
X = V \times \frac{\bar{B}}{10^9}
$$

### PSUB 5: Base Reward

<img src="https://i.imgur.com/vqxkttL.png" alt="psub" height="500rem"/>

The following mathematical pseudo-code is used to calculate the aggregate average effective balance of the system:

\begin{equation}
\begin{aligned}
\bar{B} &= \frac{\text{total_effective_balance}}{V} \\
\end{aligned}
\end{equation}

<img src="https://i.imgur.com/1Zz3MaI.png" alt="psub" height="500rem"/>

\begin{equation}
\begin{aligned}
\text{total_inflation_to_validators} &= \frac{S\times\text{inflationary_rate_per_year}}{\text{epochs_per_year}} \\
\end{aligned}
\end{equation}

### PSUB 6: Slashing Rewards & Penalties

<img src="https://i.imgur.com/wlWM6yY.png" alt="psub" height="500rem"/>

First, we calculate the slashing reward for a single slashing event, indicated by $'$:

\begin{equation}
\begin{aligned}
\psi' &= \frac{\bar{B}}{\text{MIN_SLASHING_PENALTY_QUOTIENT}}\\
\end{aligned}
\end{equation}

To calculate the **total amount slashed** for the epoch, we scale by the number of slashing events per epoch:

\begin{equation}
\begin{aligned}
\psi &= \psi' \times N\\
\end{aligned}
\end{equation}

### PSUB 7: Treasury

<img src="https://i.imgur.com/5qlZuo4.png" alt="psub" height="500rem"/>

$$\text{domain_treasury_balance} += D_u + D_r $$

## System Metrics

System Metrics are computed from State Variables in order to assess the performance of the system. The calculation of our System Metrics is also represented in the [model's cadCAD Canvas / Differential Model Specification](https://lucid.app/lucidchart/c7656072-e601-4ec4-a44b-0a15c9a5700d/view) and accessible via LucidChart. Below is an illustrative screenshot.


The following state-update logic for system metric State Variables could also be performed in post-processing, assuming there are no feedback loops that influence the metrics, to improve run-time performance.

#### Validator Reward Aggregation

The **total online validator rewards** is the *net* rewards and penalties awarded to online validators accounting for validating, whistleblowing, and priority fees post-merge:

$$
R_o = \text{total_inflation_to_validators} + T
$$

#### POLYGN Issuance

The **POLYGN supply** at the next epoch is equal to the sum of the ETH supply at the current epoch and the net network issuance:
$$
S^+ = S + (\text{total_inflation_to_validators}- \psi)
$$

#### Validator Costs

The **validator costs** is the sum of hardware, cloud, and third-party costs per validator type:
$$
\vec{C} = \vec{C}_{hardware} + \vec{C}_{cloud} + \vec{C}_{third-party} \qquad ([$])
$$

The **total network costs** is the sum of validator costs over all validator types (row index $i$):
$$
C = \sum_{i}{\vec{C}_{ij}} \qquad ($)
$$

#### Validator Revenue and Profit

The **validator revenue** is the rewards for online validators in ETH, $R_o / 10^9$, distributed according to the validator percentage distribution multiplied by the current ETH price $P$:
$$
\vec{K}_r = \text{validator_percentage_distribution} \times R_o / 10^9 \times P \qquad ([$])
$$

The **validator profit** is the validator revenue less the validator costs:
$$
\vec{K}_p = \vec{K}_r - \vec{C} \qquad ([$])
$$

The **total revenue** is the sum of validator revenue over all validator types:
$$
K_r = \sum_{i}{\vec{K}_{r,ij}} \qquad ($)
$$

The **total profit** is the total revenue less the total network costs:
$$
K_p = K_r - C \qquad ($)
$$

#### Validator Revenue and Profit Yields

The per-validator **revenue and profit yields** are calculated and annualized as the validator profit and revenue multiplied by the number of epochs in a year divided by the validator ETH staked, $\sigma$, in dollars:
$$\vec{Y}_r = \frac{\vec{K}_r \times E_{year}}{\sigma \times P} \qquad ([\%])$$
$$\vec{Y}_p = \frac{\vec{K}_p \times E_{year}}{\sigma \times P} \qquad ([\%])$$

The total **revenue and profit yields** are calculated and annualized as the total profit and revenue multiplied by the number of epochs in a year divided by the total ETH staked, $X$, in dollars:
$$Y_r = \frac{K_r \times E_{year}}{X \times P} \qquad (\%)$$
$$Y_p = \frac{K_p \times E_{year}}{X \times P} \qquad (\%)$$