docs: fee based tokens

[raul-oliveira]

Rendered

[raul-oliveira]

I'm still validating which version (tx version or token_info_version) to change with a POC

[msbrogli]

You have to cover this implementation detail in the guide level explanation. You can leave it to the low level design.

[obiyankenobi]

Why are we going for this model? The original proposal suggests a flat fee.

[raul-oliveira]

The reasons I ultimately moved away from a flat fee model and instead adopted a fee calculation based on the transaction size are:

• Flat fees could disproportionately penalize small, simple transactions while inadvertently subsidizing larger ones. A fee model based on transaction size fairly charges users according to their actual network usage.
• A flat fee, while initially predictable, doesn’t adapt to network usage or congestion. Introducing a size-based fee model offers adaptability, better managing network capacity and preventing potential bottlenecks during high traffic periods.
• Enabling a custom token fee, will allow users to melt tokens without authority.
• Users are already familiar with fee models based on transaction size (e.g., Bitcoin and Ethereum). Adopting a similar approach reduces friction in user onboarding, simplifies adoption, and aligns Hathor with established blockchain industry standards.

[obiyankenobi]

A flat fee, while initially predictable, doesn’t adapt to network usage or congestion.

Nor does a tx size based fee. What can help in this case are priority fees, but this can be added in both fee models (flat or tx size).

Users are already familiar with fee models based on transaction size (e.g., Bitcoin and Ethereum).

It doesn't mean they are happy with it. I guess 99% of users in Ethereum complain about unpredictable fees.

Flat fees could disproportionately penalize small, simple transactions while inadvertently subsidizing larger ones.

I agree, but this is something we did not prioritize in our existing token standard and hasn't been an issue. Currently, you pay the same deposit regardless of the "type" of transaction you will make. There might be tokens that have a majority of small txs (few inputs and outputs) and other that have larger txs. Both pay the same deposit (1%). I don't see the benefit of doing this differently now.

In the end, this variable fee introduces more complexity and reduces the UX for users. He may send a 5 HTR tx and pay 0.1 HTR one time and later, while transferring the same amount, pay double if he has to use more inputs.

Enabling a custom token fee, will allow users to melt tokens without authority.

It depends how we will handle the fees. If the fees are melted, then yes. However, if the fees are sent to an address that is inaccessible, the supply remains the same. In practice, it's the same, though. In any case, I can always send the tokens I have to an inaccessible address today.

My recommendation

We should have a flat fee per fee-based token.

We should also allow custom tokens as fee payment (as well as HTR), but only the same token that is on the transaction. For instance, when sending hUSDC, I can only use hUSDC for fee payment.

I don't have an opinion yet if payment of fees with custom tokens should be decided at token creation - i.e. when someone is creating the token, he should choose to allow it to be used for fee payment. So when creating YanCoin, I can choose whether fee payment is only in HTR or users can also use YanCoin itself.

@trondbjoroy suggested that all tokens should support fee payment in the token itself as "fees should work in a consistent way for all tokens". That's a fair point.

[raul-oliveira]

How do you see tokens which value nothing being used to pay the fee in a transaction?

Example:

• Token A is minted without a deposit, and I can choose the amount.It means token A values nothing.

Does make sense to enable the charge of custom tokens?

[obiyankenobi]

You are 100% correct, I mixed things up. For fee payment, it must happen with a token that has been created with the deposit model. So if we choose to enable fee payment in custom tokens, a deposit-based token will be needed to pay for fee-based token tx fees.

This removes our argument that users would not need to hold other tokens (eg: when sending USDC, they'd need another token as well).

I still believe we should have a flat fee (probably 0.01 HTR). However, we'd need to decide if we enable other deposit-based tokens to be used for fee payment or just HTR.

On Dozer's proposal, the token creator selects the token used for fee payment when creating the token. I'm thinking it might be more confusing for users, unless there's a clear benefit of allowing it.

[hBulldozer]

I don't have an example of a Protocol using this approach, but I can elaborate on a hypothetical scenario.
Let's say I want to operate stablecoins on the Hathor Network. However, I want to charge fees when users transact with my coins within the network. If I create a gas coin using the 1% HTR lock method (let's call it SGC—StableGasCoin), I can mint and sell it to users who will need it to pay transaction fees for all my stablecoins that are programmed to use SGC instead of HTR for gas.

The process would work like this:

1. Protocol mints SGC (StableGasCoin);
2. Protocol issues stablecoins with this rule - for example, mints sBRL with gas set to SGC instead of HTR;
3. Protocol sells SGC at arbitrary or fixed price (could be via a smart contract);
4. Users pay fees using the protocol's gas coin, initially minted using HTR.

This creates utility for the SGC coin and potential revenue for the protocol while also contributing to Hathor, as the 1% lock is burned.

[obiyankenobi]

Got it, it's clearer now. It seems the use case would be to monetize a product/protocol that has usage.

I'm wondering if it makes sense to add this or just keep it simple and only accept HTR. Just to be clear, I think we should keep it simple for business reasons, not because development would be (slightly) harder. It would end up being a friction point for users, who may have to hold multiple tokens for fee payment.

[obiyankenobi]

@msbrogli replying to your comment about fees.

require us to determine a single flat fee that works for both simple and complex transactions.

I don’t yet have a strong opinion on the best approach, but another alternative would be to charge fees based on the number of outputs with fee-based tokens.

I don't see a problem charging the same fee for small or large txs. This is something we already don't handle in the deposit-based txs and it hasn't been a problem. While I appreciate it drives more demand for HTR tokens, I believe the gains in simplicity are greater.

Almost all txs that a user sends have 2 outputs, as it needs to include a change output. So if we say it's 0.01 HTR per fee-based token output, it will cost 0.02. However, he may send a tx and the output match the input, so it will only cost 0.01 HTR. This discrepancy is not easy to explain to the average user.

This would remove the incentive for bundling multiple transactions to save on fees.

I guess only a few players would have the ability to do that, as exchanges and marketplaces. Most commonly, people will not do that.

[msbrogli]

Almost all txs that a user sends have 2 outputs, as it needs to include a change output. So if we say it's 0.01 HTR per fee-based token output, it will cost 0.02. However, he may send a tx and the output match the input, so it will only cost 0.01 HTR. This discrepancy is not easy to explain to the average user.

It is very complicated to explain to EVM users how fees are calculated. But they all understand how much it costs. I guess it is the same here. One transaction would pay 0.01 HTR while the other would pay 0.02 HTR in fees. It seems simple enough for users.

I guess only a few players would have the ability to do that, as exchanges and marketplaces. Most commonly, people will not do that.

Everything is hard to reach masses without tools. All we need is a popular wallet to implement it and then lots of people would use it unconsciously. For instance, mixers were theory before Tornado Cash made it simple for people to use.

[obiyankenobi]

Everything is hard to reach masses without tools. All we need is a popular wallet to implement it and then lots of people would use it unconsciously.

I agree, but to reach this point there must be use on the network, and simplifying fees, which is a barrier to adoption, is a way to be able to get there.

All we need is a popular wallet to implement it and then lots of people would use it unconsciously.

It will be a good problem when we reach the point when we have these kind of services in the network.

It is very complicated to explain to EVM users how fees are calculated. But they all understand how much it costs. I guess it is the same here.

I don't think they understand how it works, they just pay what's displayed on the wallet. To quote @trondbjoroy "Bitcoin and Ethereum shouldn't be viewed as success stories when it comes to fees IMO". They do it because they want to send transactions, because there's demand for it. As a smaller network having to attract users and products, we need to look for enhancements to the current models.

[trondbjoroy]

Bitcoin and Ethereum shouldn't be viewed as success stories when it comes to fees IMO. Their first mover advantage is huge and I haven't met anyone who's happy with how their fee systems work. I think we should instead look to the success of Solana with their low, flat fees.

It makes everything more predictable for both users and developers integrating with the network, as they don't have to bother with fee calculation. This doc from Yan offers more context and details about the pros and cons of the different models.

I agree with Yan's recommendation above. To add, I believe we need to enforce the same fee structure for all transactions involving a fee-based token. Meaning, it shouldn't be up to the token creator to decide whether fees can be paid in HTR and/or the custom token. Both options should always be available. Otherwise it would be confusing if in one transaction you can pay with the custom token and in the next you have to pay with HTR.

Allowing both tokens to pay for fees adds utility to HTR and improves the UX as users don't need to hold HTR. This is a major hassle on EVM networks (although wallets are addressing it with account abstraction now).

We'd need to agree what the default payment method would be in case the user wallet has both HTR and the custom token. IMO it should default to HTR in the Hathor wallets.

[hBulldozer]

It's always wonderful to see our suggestions being put into action. Thank you for listening to us!

We're posting this to provide context on our thinking behind a possible feature allowing projects to charge fees using custom tokens created with a 1% HTR lock requirement.

We thought of a way to give utility to a specific token, just like HTR is used for the overall network. A project could create tokenA that they control the supply and distribution of and can sell for a fixed price for example. And another tokenB that would be the transaction token for their service, so for users to use the service related to tokenB, they would need to have tokenA.

This tokenA would be like a credit/gas token for this protocol. Since it would have been created with HTR, 100x more of it would have been burned, effectively giving utility to the locked HTR while also benefiting the ecosystem of the project that distributes their project's tokenA, credit/gas token.

Thinking about it more now, I see that it seems complex and is a use case that may have little adoption, but when we wrote the RFC, we thought it wouldn't be complex to implement and could be interesting.

In some projects, people modify the ERC20 to include a transaction fee in the token itself that can be burned or sent to the treasury. However, we understood that this wouldn't add utility to HTR, which is why we suggested using this "gas” token.

We agree with Yan and Trond that following Solana's low flat fee approach is a better strategy for the ecosystem. While it may not drive significant demand for HTR in individual transactions, it will become meaningful with the expected volume of small transactions from users/agents/services currently excluded from Ethereum and Bitcoin due to their high, unpredictable fees.​​​​​​​​​​​​​​​​

[msbrogli]

It's not clear to me how the priority tip would work in our case since we have a DAG of transactions and miners cannot freely choose which transactions will be confirmed by them.

[raul-oliveira]

Removed, lets close this only with fee. I wasn't aware of this point. Tks

[msbrogli]

What's the proposed value for the fee_rate_per_byte? It might be useful to get a histogram of tx size of transactions with custom tokens in mainnet so we can understand how much fee would be charged.

[raul-oliveira]

I'll grab it. For now I've added an example using the tx anamoty as reference. Pls, check if it's clear this way.

[raul-oliveira]

Done

[msbrogli]

This example is focused on calculating the tx size. But that's something we already have. I guess it would be more useful to have examples of the expected fee charged for small, medium and big transactions.

[raul-oliveira]

Edited

[msbrogli]

Finally, its structure promotes sustainability, ensuring controlled blockchain growth.

Can you elaborate, please?

[raul-oliveira]

Edited

[msbrogli]

I feel we should keep the mining requirement for now. If I got it right, the fees will not be enough to prevent spam so we might need to keep this other mechanism in place.

[raul-oliveira]

Edited

[glevco]

I was discussing this with @obiyankenobi. This breaks an existing premise in the protocol, that deposit-based tokens can only have their total supply decreased by using a melt authority. With this new feature, anyone can burn deposit-based tokens, and this is a breaking change (it's possible some existing application depends on this premise). This is different than sending tokens to a burn address because it decreases the total supply. What do you think @msbrogli?

[obiyankenobi]

I agree this is somewhat expected in the protocol (only melt authority can decrease supply). However, I'm not sure there's a better alternative.

Also, this already happens for the HTR token. If I melt 0.50 YanCoin in 2 separate txs, I won't get any HTR back, while I should get 0.01 HTR back if I melt 1.00 YanCoin. So this "law" is already broken with HTR.

Maybe the best course of action is to just acknowledge that this may happen and make it clear to builders. The main difference is that those with the melt authority will be able to get HTR back when they do this kind of melt.