Over the past few weeks there have been numerous discussions about the upcoming dynamic fees in Core v2, so we wanted to take some time to go over how the system will work in a less technical and easier to understand way based on some simple examples. We hope this helps clarify some of the questions and brings a better understanding of the new Dynamic Fees system in ARK Core V2.

We’ll be preparing another blog post soon which will go even deeper into technical breakdowns, along with a guide for phase 1 of testing Dynamic Fees on DevNet in preparation of MainNet.

ARK Core V2 will be the first implementation of a dynamic fees system within a DPoS network model. We envision that creating a “fee marketplace” between users and delegates will move ARK even closer to creating a dynamic, responsive and resilient network. Both delegates and end-users stand to benefit from dynamic fees: end-users benefit from delegate competition in the form of lower transaction fees, while delegates gain another tool in their arsenal to contend with potential attack vectors such as spam attacks.

Dynamic Fees ELI5

Dynamic fees is a protocol-level change. On the one hand, delegates (block producers) set their own minimum acceptable fee for each transaction type. Meanwhile, ARK users define how much they are prepared to pay for a transaction to get included in the block and blockchain. The bigger the set fee from the user, the quicker the inclusion of the transaction in the block. A maximum allowed fee is set (which will be the same as current static fee), making it impossible to “fat finger” the transaction fee and pay some enormous amount on fees alone.

End Users

ARK users will have an option to customize how much they are prepared to pay when sending transactions, voting, registering a delegate, etc. Our goal is to implement dynamic fees to be maximally intuitive, allowing users the full benefit of customization without detracting from or confusing the seamless user experience you expect from ARK. Over the coming months we’ll be making improvements as we get feedback from the community and users to make this as easy to use as possible.

In the desktop and mobile apps the default preset value for a TX fee will be based on current network average. This will be displayed on the sending screen in ARKtoshis (1 ARKtoshi = 0.00000001 ARK) and current FIAT value of your selected currency so you will know exactly how much you are paying for your transaction. You will also have an advanced option which will present you with 3 calculated values based on the period of last 30 days:

minimum: the lowest forged transaction fee paid over the last 30 days.

maximum: the upper cap on forged transactions fees (hard-capped at 0.1 ARK) over the last 30 days.

average: the average forged transaction fee paid over the last 30 days, obtained from forged transactions spanning over that period.

All delegates can set their minimum acceptance fee. If the received transaction fee is below the delegate minimum fee, it will not be included in that delegate’s block. Clients won’t be allowed to send less than current network (not delegate) minimum fee (calculated by the spanning period over the last 30 days), which in the vast majority of cases will ensure that your transaction is included in a block.

Maximum fee is limited to current static fees. In addition, delegates have the option of disabling dynamic fees, meaning that they will just continue including blocks with the current fee model (0.1 ARK transfers, 1 ARK voting, 5 ARK 2nd signature, 25 ARK delegate registration). Maximum fee cannot exceed current static fees so you will never pay more than what you pay in version 1 of ARK.

You can check the values by calling the node configuration endpoint here: https://docs.ark.io/api/public/v2/node.html#retrieve-the-configuration

A response is received for each transaction type, showing their min, max and average fee values.

Practical Examples

To drive home the mechanics of dynamic fees, let’s consider two fictional ARK users: Stacy and David.

Stacy has earned lots of ARK from GitHub contribution bounties, and she needs her transaction processed as soon as possible. So, when she opens her wallet to send the transaction, she selects the option for maximum fees.

Once Stacy confirms her transaction details, the transaction is sent from the ARK wallet to an ARK node, where it is verified and added to the “pool” of transactions that have yet to be attached to a block.

After a few seconds, a new block is forged by Delegate A. To begin this process, Delegate A’s node looks through the “transaction pool” to find all transactions with fees that exceed the delegate’s minimum forging fee. Because Delegate A has chosen a minimum forging fee of 0.05 ARK and Stacy has chosen the maximum fee of 0.1 ARK, her transaction meets the criteria and is forged in Delegate A’s block.

Now, let’s talk about David. After a long year of buying high and selling low, David is in a tough spot, and is looking to save as much as possible on his ARK transaction fees.

When David sends a transaction, he chooses the option for minimum fees. As an example, let us assume the minimum fee is 0.001 ARK at the time David sends his transaction.

Just like Stacy’s transaction, David’s is sent to an ARK node, verified, and added to the transaction pool in anticipation of being forged. Again, just like in Stacy’s transaction, it is now Delegate A’s turn to forge a block.

However, unlike with Stacy, David’s selected fee of 0.001 ARK is below the minimum forging fee of 0.05 ARK that Delegate A has set in their node configuration. Because of that, Delegate A’s node chooses not to include David’s transaction in its forged block. Delegate A forges a block, and David’s transaction remains in the transaction pool awaiting the next block.

Fortunately for David, Delegate B has been chosen by the network to forge the next block. Delegate B has set his fee for processing transactions at 0.0001 ARK which is just below the network minimum average. David’s transaction fee was 0.001 which is above Delegate B’s minimum fee threshold, so Delegate B accepts the fee offered by the client (actual transaction fee) and includes the transaction in the next forged block.

Notice that, in our example, David’s transaction is forged only one block later than Stacy’s. However, when selecting fees for your transactions, keep in mind that this will not always be the case. As delegate forging order is selected randomly at the beginning of each “round”, and 8 second block times across 51 candidates leads to approximately 6 minute 48 second round times, you can expect that minimum-fee transactions will be forged anywhere from 0 to 14 minutes after they’re added to the network.

Currently default expiration time for a transaction is 6 hours (subject to change as we go to MainNet). This can already be configured at the node level in the config file. In the future we will probably make a separate configuration option for the dynamic-fees, or the lite clients will be able to set their own preferred expiration time.

We have to keep in mind that offered fee (fee set by the client while sending the actual transaction) is not the same as the calculated fee by the delegate. The calculated fee represents a delegate’s costs for the processing (forging) of the transaction. The whole point of dynamic fees is to find a market match between client’s offered fees and delegates costs (calculated by a dynamic formula). When a clients offered fee is above or equal to the delegates calculated fee, the transactions are included in the block. Regardless, you pay the fee you have set while signing the transaction. Nobody can override or change your offered fee. In the worst case scenario your transaction stays in the pool and expires, returning to the originating address (if fee is below any delegates set minimum).

See Room For Improvements?

If you think there could be improvements made to the current mechanics of the Dynamic Fees or would like to share your overall opinion please make a comment in this Reddit thread: https://old.reddit.com/r/ArkEcosystem/comments/9ktfr0/ark_core_v2_dynamic_fees_explanation_and_more/

Dynamic Fee Testing On Devnet

In the next few days we are going to release another blog post that will go a bit more into the core of Dynamic Fees (more technical), accompanied by a guide on how to enable and test Dynamic Fees. With this we’ll begin phase 1 of specific testings on Devnet, starting with Dynamic Fees.

If you’d like to help test please join our Slack and #devnet channel.