The CREDITS platform charges a transaction fee. It means a certain number of CS — the system’s in-house tokens applicable to financial transactions — charged from the sender whenever a transaction is initiated. The amount of fees depends on the number of transactions in a round, the sender’s transaction activity, the number of trusted nodes in a round, and the physical transaction size. The fees for every component are limited to the minimum and maximum values. In other words, even if the sender’s transaction activity is extremely high/low, the fee payable by the sender will never be higher/lower than the maximum/minimum limit. Let us take a closer look at the dependence between these components.

### Dependence of the transaction fee on a round

The fee amount is affected by both the number of transactions in a round and the number of trusted nodes. Both values are variable but limited to the minimum and maximum values. For example, every round has at least one transaction. The maximum number of transactions in any given round is 65,535. The nominal average number of transactions is set equal to 10,000. The number of nodes varies, too. Every round is required to have no less than 3 and no more than 101 nodes.

### Dependence of fees on the number of transactions in a round

**The greater the number of transactions in a round, the lower the fee.**

The pricing component is represented by a piecewise-linear function where the number of transactions is the abscissa and the price of transaction in a round is the ordinate. Connecting the abscissas and ordinates of points gives us the graph of pricing component. Below is an example of four fixed points: 1. (1, P1), 2. (n2, P2), 3. (n3, P3), 4. (65,536, P4).

Assuming that we have preset Q values of the number of transactions with the known price of transaction in this segment, which is calculated using the formula {n*i*, n*i*}q*i*=1, the segment of the piecewise-linear function P = *ki* . n + *bi *in the interval [*ni, ni+1*], where is the number of transactions, is defined by the system of equations

Solving this system defines the relevant component for all q-1 segments.

### Number of trusted nodes in a round and their effects on the fee amount

**The greater the number of trusted nodes in a round, the higher the fee.**

Price grows linearly pro rata to the number of trusted nodes in a round with a certain calibration constant of proportionality, it also grows quadratically with respect to the number of trusted nodes with the calibration constant. This dependence derives from the fact that all nodes have equal rights and the consensus algorithm entails sending messages with a quadratic dependence. The resulting relationship for the full round price Pм at M trusted nodes is calculated using the formula Pм=α⋅М+β⋅М2.

### Dependence of fees on the sender’s transaction activity

**The greater the number of transactions generated by the sender, the higher the fee.**

In this case, the minimum and maximum values are applicable, too. The lower limit is set equal to 0 TPS, the upper limit is set equal to 1,310,720 transactions per second. Transaction pricing builds on the same principle as in the case of round dependence. The pair of parameters that has an important role to play here is the total number of transactions per second for one sender and transaction markup for the sender’s given transaction activity. If the number of outbound transactions goes up, so does the price, as shown in the piecewise-linear function graph below.

### Procedure for extracting a subset of valid transactions from a set of given transactions

A subset of valid transactions is identified in accordance with the D. Serdyuk algorithm.

Let us assume that sender А has balance 10. In the next round sender А participates in four transactions in its capacity as sender and in two transactions in its capacity as recipient. All of these transactions are part of the same round.

As a result of transaction recording, the balance of participant А is as follows:

(Current balance) — (sum of the prices of “sent” transactions) + (sum of the prices of “received” transactions): 10–(9+10+11+15)+(7+8+12)=10–45+27=-8

Sender А, for some unknown reason, releases one transaction more — if we delete from the table the transaction shown in the figure below in dark blue, then balance A will become positive. However, this will necessitate a recalculation of the balance of participant В and all other participants whose balance could have been affected by the removal of this transaction.