# Miden fee model

This note contains the current sketch of the fee model for the Miden protocol. Not all aspects of the model have been finalized and there are open questions which may affect the design in significant ways. The full discussion about the fee model can be found [here](https://github.com/0xMiden/miden-base/discussions/1217).

## Preliminaries

There are 3 conceptual entities that participate in the Miden protocol which are relevant for the fee model:

- **Users** execute, prove, and submit transactions to the network. Each transaction updates the state of a single account, but can consume and produce zero or more notes.
- **Batch builders** aggregate transactions into batches.
- **Block builders** aggregate batches into blocks.

Currently, batch and block building is done by a single centralized node operator. In the future, both batch and block production can be decentralized (e.g., some entities may be involved in batch production while others would be involved in block production).

Transactions can also be executed/proven by the network (e.g., when notes interact with network accounts) - we call these *network transactions* to distinguish them from *local transaction* which are executed by the users. However, for the purposes of this discussion, there is no significant difference between local and network transactions.

## Goals

The fee model tries to achieve the following goals:

- Provide a mechanism for prioritizing transactions if/when the network is congested (i.e., there is more transaction demand than network capacity).
- Ensure that batch and block producers are incentivized to include transactions into batches and batches into blocks (i.e., to avoid, empty batches and blocks).
- To make fee payment for the users as easy as possible. This includes:
- Allow fee payment in multiple currencies to avoid the situation when a user's account has some assets but the user is not able to engage in transactions because they don't have the native asset in the account.
- Make fee estimation as simple as possible to ensure that users don't end up underpaying or overpaying fees in most situations.

Another auxiliary goal of the fee model is to encourage "note cut-through" when a transaction which consumes some note is included into the same batch/bock as the transaction which generated this note. When this happens, the note is effectively "erased" (i.e., it is not recorded on-chain) .

## Design

The design of the fee model is loosely based on the multi-dimensional EIP-1559, and works roughly as follows:

- Every transaction includes a fee set by the user.
- When a transaction is included in a batch, part of this fee is used to satisfy the protocol-defined base fee for the resources the transaction consumes. The base fee is burned. The remaining portion of the fee is treated as a "tip" for the batch builder. If a transaction fee is insufficient to cover the base fees, it cannot be included in a batch.
- When a batch is included in a block, it can pay a "tip" to the block builder.
- If a given block consumes more of some resource than its target utilization, the base fee for this resources goes up in the next block. If the block consumes less than the target, the base fee goes down until it reaches some protocol-defined minimum level.


### Resources

The resources for which the fees are charged are yet to be finalized, but they will likely include some combination or aggregation of the following:

- Number of cycles it takes to execute the transaction.
- Number of notes consumed by the transaction.
- Number of notes created by the transaction.
- Total size of produced on-chain notes (in bytes).
- Total size of state deltas of on-chain accounts (in bytes).

As mentioned above, for each resources the protocol defines three parameters:

- Target utilization.
- Maximum utilization.
- Minimum fee.

For example, for consumed notes it could be something like:

- Target utilization: 1000 notes per block.
- Maximum utilization: 4000 notes per block.
- Minimum fee: 1 unit per consumed note.

Then, if the current base fee is 2 units per consumed note and a block includes transactions which consume 2000 notes, the base fee will increase in the next block. If however, the block consumes 500 notes, the base fee will decrease.

### Multi-currency fees

The base fee must be paid in the native token of the protocol, however, users should be able to pay transaction fees in any token. To bridge this gap, batch builders can convert user-provided fees into the native token at the rates they deem acceptable during batch construction process.

For example, let's say a transaction consumes resources requiring 200 native units in base fees. The user may decide to pay fees in USDC instead and include $0.02 USDC with their transaction. If the current exchange rate is greater than 10000 native units for 1 USDC, then it would be profitable for a batch builder to take the $0.02 USDC and cover the base fee for the user. If, however, the exchange rate is less than 10000 native units for 1 USDC, no batch builder would pick this transaction for batching as it would be unprofitable for them to cover the base fee in exchange for the fee provided by the user.

### Batch anchoring

When building a batch, a batch builder must pick an *anchor block* in the chain against which the batch is built (this is needed because the batch builder may not know the the most recent block in the chain). This block will define the base fees for the transactions included in the batch. To make sure that the batch builder does not pick a stale block, the anchor block must be close to the chain tip (e.g., within $n$ blocks of the chain tip where $n$ could be small value - something like 10).

If the anchor block is further away from the chain tip than $n$, then the batch cannot be included in a block. Thus, batch builders are incentivized to pick the most recent block as their anchors.

## Action modeling

### Estimating transaction fees

When constructing a transaction, the user needs to estimate a transaction fee. This requires:

- Calculating resources consumed by the transaction.
- Determining base fees needed to be paid for each resource.
- Determining the amount of tip to pay for the transaction.

Computing consumed resources shouldn't be too difficult and we can provide a kernel procedure to help with this.

Determining base fees can be done either by looking at the anchor block of the transaction or getting the information from an external source (e.g., wallet).

Determining the tip amount would need to be done with a help of an external source (e.g., the wallet), though, there may be some automated strategies (e.g., set tip to 10% of the base fee).

To increase the likelihood of having the transaction included in the chain, the user can pay a bigger tip. This will serve two purposes:

- It will incentivize batch builders to prioritize the transaction.
- It will protect the user against potential fluctuations of the base fee.

If the user wants to pay the fee in non-native currency, they would need to obtain the current exchange rate from an external source (e.g., wallet) and apply it to the estimated fee in the native units.

### Batch constructions

When constructing a batch, a batch builder needs to:

- Pick transactions to include into the batch.
- Pick the anchor block against which to construct the batch.
- Decide how much tip to pay to the block producer for this batch.

As mentioned above, the batch builder is incentivized to pick the most recent block as the anchor. They are also incentivized to include transactions into the batch because this is the only way for them to get compensated for batch production (i.e., there is no incentive to build empty batches). Batch builder compensation comes from the following sources:

- Tips remaining after transactions pay their base fees, minus the tip that the batch builder pays to the block builder.
- Extra fees remaining after "note cut-through". These fees remain because users need to allocate base fees for produced/consumed notes, but if the notes are erased, the base fees can be pocketed by the batch builder.
- Extra fees remaining from transactions executed against the same account. These fees remain because users would need to allocate base fees for every account update, but if the same account was updated twice in the same batch, the base fee would need to be burned only once. And thus, the batch builder would be able to pocket the difference.

The exact strategy for picking transactions for a specific batch may get pretty complex and may require sophisticated "solver" logic. However, it is also possible to use simple "greedy" heuristics which could be sufficient in the vast majority of cases (the only time greedy heuristic would not be optimal is when blocks are at the maximum capacity).

### Block construction

When constructing a block, a block builder needs to pick a set of batches which don't violate maximum resource allocations (e.g., all batches in a block should not consume more than 4000 notes) and pay attractive enough tip. This incentivizes the block producer to include batches into blocks (i.e., not to build empty blocks).

## Open questions

- Currently, the tip portion of the transaction fee is used to compensate both batch and block builders for their work. Would this result in a situation where the tip portion becomes the dominant part of the fee?
- If so, then we may need to introduce block rewards so that block builders are compensated primarily via block rewards. However, this would decrease the incentive for block builders to include batches into blocks (and this may result in some blocks being empty). Is there a way to compensate block builders differently and still retain an incentive for them to build non-empty blocks? For example:
- Could block builders receive some portion (e.g., 50% or 75%) of the base fee?
- Could there be other incentives for block builders to include batches into blocks? (e.g., using batches in consensus logic).
- Even if we introduce block rewards, would tips be sufficient to incentivize batch builders? Or would we need to introduce separate batch rewards? And if so, how can we ensure that batch builders are not incentivized to build empty batches?