We break down how a DecimalChain fee is calculated, how the price oracle converts it into DEL, and why the USD cost of operations stays the same.

How fees are calculated in DecimalChain and why their size in DEL changes

After the July update, users noticed that transfers, delegation and other operations started to cost a different amount of DEL. For some it felt like using the blockchain had become more expensive.

What changed is not the cost of operations, but how the fee is converted into DEL. The price oracle now tracks the real market value of DEL more accurately, so the number of coins needed to pay the fee changed. The cost of an operation is still set in USD and stays at the level defined by network parameters.

Two transaction paths — two fee models

Decimal is a two-module blockchain: it has a native Cosmos layer and an EVM layer for smart contracts. That is why the fee is calculated by one of two models, depending on how the transaction is sent.

If you use Decimal Console or the mobile app — as most users do — operations run through EVM smart contracts, and the fee is calculated in gas.

If a transaction is sent to a node directly, via CLI or custom scripts, the native model applies: a charge for transaction size plus a fixed operation tariff.

The two models never combine: each transaction uses exactly one of them. What matters is that both are pegged to USD through the price oracle, so everything below about stable USD costs applies to both cases.

Let’s start with the native model — it is simpler and shows the principle clearly.

What a fee consists of in the native model

A fee in DecimalChain has two independent parts.

The first is a fixed tariff for a specific operation, set in USD. Transfers, delegation, token creation and validator creation all have different tariffs.

The second depends only on transaction size: the network charges 0.00008 USD per byte of data.

The total is then converted from USD into DEL at the current rate from the price oracle. The oracle works like an automatic exchange board: it reads the DEL market price and passes it to the network. The fee is then calculated as:

Fee (DEL) = (Byte charge + Sum of operation tariffs) ÷ DEL price

where Byte charge = Transaction size × 0.00008 USD, and the tariff sum is the cost of all operations inside the transaction.

Example tariffs:

  • coin transfer — 0.0004 USD;
  • delegation — 0.08 USD;
  • token creation — 0.004 USD;
  • validator creation — 0.40 USD.

If a transaction contains several operations, their tariffs add up. For a multi-send, the tariff is charged for the first transfer (0.0004 USD) and additionally 0.0002 USD for each further recipient.

A worked example (native model)

A regular transfer sent directly to a node, 200 bytes in size.

Byte charge: 200 × 0.00008 USD = 0.016 USD.

Transfer tariff: 0.0004 USD.

Total: 0.016 + 0.0004 = 0.0164 USD.

At a DEL price of 0.90 USD the fee is 0.0164 ÷ 0.90 = 0.0182 DEL. At 0.45 USD it is 0.0164 ÷ 0.45 = 0.0364 DEL.

The DEL amount nearly doubled, but the real cost stayed the same — about 1.64 cents. What changed is how many coins are needed to pay the same USD amount, not the cost of the operation.

Why operations cost differently

Each operation type has its own fixed USD tariff. This is a protocol parameter, not a measure of computational complexity or current load. Transaction size is charged on top: more data means a higher byte part. Creating a token is a good example — the base tariff is fixed, but the price depends on the ticker: a short three-letter ticker costs noticeably more than a long one, while the network load is the same.

Why a USD peg

A fee fixed in DEL would be inconvenient. If the network always charged 0.1 DEL, a rising DEL price would make a simple transfer unexpectedly expensive, and a falling price would make the fee too cheap to protect the network from mass automated transactions. A USD anchor keeps the cost of an operation stable, while the DEL amount is recalculated at the current rate.

Does network load matter

No — in either model. Unlike some blockchains, DecimalChain users do not compete on fee size for a place in the next block. The cost is set by network parameters and converted to DEL by the oracle. Higher load alone does not raise the fee.

How fees work in Console and the mobile app

The formula above applies to transactions sent directly to a node. Decimal Console and the mobile app work differently: operations run through EVM smart contracts, so the fee uses a Gas model:

Fee (DEL) = Gas used × Gas price

Gas usage depends on what the smart contract actually does when executing the operation, so it cannot be taken from a price list in advance — you see the exact number in the fee preview before sending.

The difference from Ethereum still holds. Gas price is not set by a market auction between users: it is defined by network parameters in USD and converted to DEL at the oracle rate, just like in the native model.

Because the models differ, the same operation can cost a different amount. For example, at a DEL price of 0.90 USD a delegation via Console recently cost about 0.29 DEL, while the same delegation sent directly to a node comes to about 0.11 DEL. This is not a glitch or a double fee: these are two different software paths with different fee models, and the result of the operation is identical.

Where the fee goes

A fee has two roles. Technical — protecting the network from mass useless operations. Economic — a constant use case for DEL across transfers, delegation, token issuance and smart contracts. After payment the fee is split: 50% of DEL is burned and permanently removed from circulation; 50% goes to the validator that produced the block and is then shared between the validator and its delegators according to the validator’s rules. This way every operation both supports the network and gradually reduces the amount of DEL in circulation, which makes the fee not only a payment for operations but also an important part of the whole blockchain economy.