# Fee Models in the Qredo Network

#### CryptoEconLab, May 2023

In a service-based platform like Qredo, fees are a key mechanism to tie the value being generated by the network with the value of the native currency or token.

In this report, we discuss different fee models and how they can be applied to Qredo. Particularly, Qredo will implement two types of fees:

- **Protocol fees** - fees that need to be paid when submitting requests to the Qredo network. The goal is to avoid spamming attacks on the network and to support Validator operations.
- **Service fees** - fees computed in a pay-as-you-go model based on the total volume transacted in billable operations. The goal is to have a fairer distribution of network costs by requiring clients moving a higher volumes through Qredo to pay more.

For each type of fee, in the following sections, we will aim to answer the following two questions:
1. How are fees collected?
2. How are fees computed?

We will discuss the mechanisms in general terms and highlight which parameters will need to be tuned afterwards during the simulation analysis.

But before discussing the models of each type of fee, we will describe a set of commonly used fee models and explore how they allow value to flow from network usage to the token.

## Fees Models

The following table provides an overview of 4 fee models. For each, we describe how fees are paid, how the model enables value to flow from clients to the other network participants, and the model's impact on token buy pressure (from clients) and token sell pressure (from other network participants).

| Model | Payment mechanism | Value-flow mechanism | Buy pressure impact | Sell pressure impact |
|---|---|---|---|---|
| Native currency | Fees are denominated in the native token and paid to network participants | Token demand & fees | High | High |
| Burn | Fees are denominated in the native token and burned | Token demand | High | Medium |
| Foreign currency | Fees are denominated in another token (usually USD) and paid to network participants | Fees | Low | Low |
| Discount | Fees can be denominated in the native token or another token. Using the native token provides a discount. Fees are paid to network participants | Token demand (lower) & fees | Medium | Medium |
| Buy and distribute | Fees are denominated in another token (usually USD) and paid to the protocol. The protocol sells the tokens to purchase the native token. Fees in the native token are paid to network participants | Token demand & fees | High | High |
| Buy and burn | Fees are denominated in another token (usually USD) and paid to the protocol. The protocol sells the tokens to purchase the native token. Fees in the native token are burned | Token demand | High | Medium |

We should note that the models are not exclusive. For instance, Ethereum uses a mix of the native currency models and the burn model in its gas fees mechanism.

## Qredo protocol fees

### How are fees collected?

As explained before, protocol fees serve two main roles, namely increasing the cost of spam attacks and subsidizing part of the costs of running the Qredo protocol. Thus, for this use-case, we propose to use the **Burn Model for Qredo's protocol fees**.

Firstly, burning is the most effective mechanism for preventing spam attacks. If validators received the protocol fees, they wouldn't have costs for adding network requests. Instead, burning introduces a level-playing field for all users wanting to use Qredo's L2 as the net costs of submitting a request are the same, independently of whether the user is also a Validator.

Secondly, burning QRDO creates a token supply pressure that benefits all network participants that hold QRDO. In other words, the entire economy profits directly from the tokens being burned. In addition, as protocol usage increases, more tokens will be burned, thus tieing adoption with token demand.

To collect protocol fees, Qredo has three main classes of transactions:

- Self-funded transactions - Transactions initiated by protocol users with a Qredo Layer 2 (QL2) wallet (i.e., the protocol is capable of charging the protocol fees). Examples include withdrawals, transfers between Qredo Layer 2 (QL2) wallets, etc.
- Protocol-funded transactions - Transactions initiated by protocol users without a QL2 wallet (i.e., the protocol is not capable of charging the protocol fees). Examples are wallet creation transactions or MPC-sign transactions for clients without a QL2 wallet.
- Control transactions - Internal transactions that the Qredo network must execute to maintain operations. These transactions are not generated by protocol users. Instead, they are initiated by the protocol itself or by the development team when deploying protocol changes. Examples include fee collection, messaging, network upgrades, etc.

The fee collection mechanism for self-funded transactions is very simple - protocol users must have QRDO in their QL2 wallet before making a transaction request. When the transaction is executed, the protocol takes the protocol fees from the user's wallet and burns them.

On the other hand, protocol-funded transactions and control transactions cannot be directly charged to a user's wallet. Instead, the protocol fees for these transactions need to be covered by an Ecosystem Fund that is fully controlled by the protocol. The fund will be financed by a token allocation from the unvested QRDO pool and a cut of the service fees collected by the protocol. **The exact QRDO allocation and service fees cut will be defined in the second phase of this project**.

### How are fees computed?

At the moment, all transaction types have similar computation costs for the network. Here are some differences, but they are not significant (can we link here the analysis made by the Qredo team?).

Therefore, for simplicity, we propose a **fixed fee for all transaction types**. The total protocol fees collected will thus scale linearly with the number of transactions executed by the network.

The **final fee value will be also computed in the second phase of this project**. However, the final value will be a balance between two goals:

1. Have a sufficiently high fee to avoid protect against spamming attacks
2. Have a sufficiently low fee to avoid over-burning and make transactions unaffordable for most users.

### Issues to consider with this design

**Over-burning**

Qredo currently has a fixed supply of 2 billion tokens. A design where protocol fees are burnt will eventually lead to a token supply too small to support all the other token features, such as paying for service fees or staking. In other words, burning is good in the short term as it aligns token supply with protocol usage. However, in the long term, the network is expected to eventually reach a level of over-burning that will limit the growth of the network.

This issue is not a major concern in the short to medium term since the fees will be set to limit the risk of over-burning and because QRDO still has a large enough supply to accomodate a reasonable amount of burning. Nevertheless, this is an issue that needs to be closely monitored and may need to be readdressed down the line.

**Attacks via Protocol-funded transactions**

Another problem that needs more thought is the risk of attacks via protocol-funded transactions. An attacker can hurt the network in two ways by submitting too many of these transactions:

They can spam the network and block all other users that want to submit transactions
They can drain the Ecosystem fund, thus blocking all other users to submit protocol-funded transactions until service fees are collected and paid into the fund.
Note that none of these attacks lead to financial gain for the attacker, but they can cause real harm to the network.

There are some ways to mitigate this issue. First, we need to differentiate which transactions can be submitted by protocol users and which transactions can only be generated by the protocol. The protocol-only transactions are not an issue since attackers cannot submit them.

Second, we can limit as much as possible the protocol-funded transactions. For instance, Qredo could start requiring the creation of a QL2 wallet for submitting MPC-sign transactions. From a technical perspective, this mitigation strategy will not be feasible for wallet creation transactions and deposits. Thus, these two types of transactions will require a deeper analysis.

Thirdly, the protocol can limit how many protocol-funded transactions can be executed at any given time. This mitigation strategy also needs a deeper analysis as it can also hurt usability.

:::warning
:warning: **Discuss with the team**

- What can we do to mitigate the attacks via Protocol-funded transactions?
- Does transaction bandwidth increase with the number of validators?
:::

## Qredo service fees

### How are fees collected?

Since Qredo's productive value is not necessarily proportional to the number of requests executed by the network, protocol fees are not enough to fully capture it. In fact, as a custody service, Qredo uses a pay-as-you-go model based on the volume traded from *billable transactions*.

Qredo considers all transactions that lead to assets exiting the Qredo network as *billable transactions* (trading activity or withdrawals). The following table provides an overview:

| Product | Transaction | Type |
|---|---|---|
| Web3 Wallets (MPC-based) | Transfers between Web3 Wallets | Non-billable |
| | Transfers from a Web3 Wallet to a wallet address (non MPC-controlled) | Billable |
| | Deploying from a Web3 Wallet into Web3 (smart-contract calls) | Billable |
| Vaults (QL2) | Deposits into a Vault address | Non-billable |
| | Transfers between Vault addresses | Non-billable |
| | Withdrawals from a Vault address to a Web3 address | Non-billable |
| | Withdrawals from a Vault address to a wallet address (non MPC-controlled) | Billable |

Currently, Qredo does an estimation of the volume in USD a certain client traded in the past 30 days and uses that volume to compute the fee that should be applied to the current request of that client.

As Qredo's L2 network can be used to interact with different tokens and blockchains, the volume estimation involves using a pricing feed from an Oracle.

Since the traded volume is denominated in USD, the fees are also denominated in USD. In addition, having the possibility to pay service fees in USD is an important product feature since it increases the platform's usability. This is especially important for institutional clients as it simplifies their internal accounting and paperwork.

Another important feature of Qredo's business is that some institutional clients do not pay directly with the decentralized protocol. Instead, They sign a traditional B2B agreement with Qredo's LLC and the Qredo team is responsible for billing and collecting the fees. In this situation, fees are not collected algorithmically by the protocol and thus Qredo LLC must do an extra step to transfer the value being generated there into the Qredo network. Thus, the fee model must consider these two types of clients (clients *billed* by the protocol vs. clients *billed* by the LLC) and adjust the value transfer mechanism.

The need to have fees denominated and paid in fiat already excludes some of the fee models discussed in the first section of this report, namely, the *native currency model* and the *burn model*. But, even though we want to give users the option to pay in fiat, we still need to transfer the value generated from these fees into Qredo's economy. Thus, given these limitations, we are left with the *discount model*, the *buy and distribute model* or the *buy and burn model*.

The *buy and burn model* is not the best fit for service fees. In the long term, as minting rewards decline, the value generated by service fees will be an important source of income for Validators and Developers.

On the other hand, users should have the option to pay in QRDO if they want. There is no reason to make fiat payment a requirement. Therefore, the **ideal model for Qredo service fees is a mix between the discount model and the buy and distribute model**.

In this design, clients have two options - they either pay service fees in QRDO or fiat. If they pay in QRDO, these fees are directly pooled into the Ecosystem Fund, which will be later distributed among network participants (i.e. Validators, Stakers, Developers, etc.). If they pay in fiat, these fees will be used to buy QRDO, and only then will they be deposited in the Ecosystem Fund.

Since QRDO payments involve less work to the protocol, fees paid in QRDO are entitled to a discount. The discount will depend on the estimated costs of fiat-to-QRDO conversion and will be a key parameter of the service fee model.

Another important mechanism is the fiat-to-QRDO conversion strategy. Which service will be used to buy QRDO? Is it internal to the economy or external? How frequently will the conversion be? And what stakeholder is responsible for the conversion operations?

Finally, for the clients billed by the LLC, we need to consider another key model parameter - the tipping rate. The tipping rate is the percentage of fees paid by these clients to the LCC that will be "tipped" to the network. As Qredo's LLC is responsible for business development, client relations, and payment collection for these clients, they cannot pay the entirety of the fees back to the network. On the other hand, the clients are using the decentralized protocol and thus some value must be transferred. This split is encoded by the tipping rate.

**The tipping rate and the QRDO discount rate will be defined in the second phase of this project**.

:::warning
:warning: **Discuss with the team:** fiat-to-QRDO conversion strategy (question are above)
:::

### How are fees computed?

Currently, fees are computed as a rate applied to the total volume in USD traded by the user in billable transactions.

The fee rate applied to the traded volume follows a curve based on the traded volume of the previous 30 days:

$$\min\{0.3131\cdot \mathsf{aggregatedUSD}^{−0.4743}, 1\}$$

where $\mathsf{aggregatedUSD}$ is the sum of all billable transaction volume for the user in the previous 30 days (including the current trade). In addition, the fees must be higher than 1 USD or 0.005% of the traded volume.

At the moment, we don't propose any change to the fee calculation formula. However, the fee model is flexible to accomodate different payment models (e.g. subcription models).

Note that for the clients wishing to pay in QRDO, the protocol must employ an Oracle to incorporate the exchnage rate between USD and QRDO.

<!--
*From an old report:*

The put into context how much value fees may generate, we plot below the cumulative USD amount collected by Qredo and three hypothetical scenarios where a fixed percentage (ranging between 1-10 BPS) of the total USD amount of transactions within Qredo's L2 network would be collected. The differences come in part due to the fact that some transactions in Qredo are not billable and, thus, do not generate fees. An alternative could be to charge a fixed, nominal amount for each transaction (notice that, in this setting, the fees do not need to be equal across different transactions).


Other potential avenues to capture revenue and utility is to generate demand for "Qredo-native" transactions by e.g., incentivising L2-native transactions (over L1), as well as capturing revenue from them. In addition, ecosystem growth and interaction with other protocols (e.g., DEXs) could also be an avenue to generate and capture future value.
-->