Users will find Namada easier to use if they can pay for fees in whatever tokens they have available (which may not always be NAM). Supporting different fee tokens is not difficult from a technical perspective – Namada already supports this – and gas costs can be adjusted periodically. However, we face the question of what to do with the collected fees. At the moment, collected fees are simply paid to the block proposer. This was simple to implement, but I would argue that it has three key downsides:
Validators now have to deal with small amounts of various non-native tokens (which seems annoying).
The mechanism for translating non-native fee demand into support for the network as a whole is a bit murky (theoretically if everyone does the calculations it should translate into more demand for NAM such as to receive more non-native token fees, but the flow is complex to reason about).
I propose that instead we use non-native fee payments to buy-and-burn NAM with cross-chain swaps.
This would work roughly as following:
We create a “non-native fee treasury” account. Non-native transaction fees are paid directly into this account.
Periodically (perhaps every epoch), Namada itself executes a cross-chain swap (same mechanism as shielded swaps, but this one would be fully public), which:
a. Selects all non-native fee tokens in the treasury account (perhaps above some minimum threshold).
b. Executes a cross-chain swap (e.g. using Osmosis) to swap those tokens for NAM.
c. Sends the NAM back to Namada and burns it.
I think this has several advantages compared to our current mechanism:
Validators no longer have to reason about non-native fee tokens at all.
Demand in the form of non-native transaction fees is clearly translated to demand for NAM. We can even use the swap price from the periodic swaps to automatically reset the relative gas prices for different fee tokens.
Namada itself controls where these cross-chain swaps go, which can perhaps be used as part of a broader shielded swaps partnership agreement with another chain (or other chains).
One might ask why burn the resulting NAM instead of sending it to the PGF account or somewhere else. That would also be possible, but I think it’s cleanest to decouple the two mechanisms – governance should be able to make decisions e.g. about how much PGF funding to commit and to what independently of the current transaction fee demand (which may often vary for unrelated short-term reasons).
They don’t receive them individually directly, but they receive the benefits of NAM being bought-and-burned (assuming that they hold + stake NAM). It should even out the economics from a validator’s perspective (since the benefits don’t vary widely depending on what transactions an individual validator receives + includes in their block proposal).
i imagine that we’ll have plenty of time before the non-native token fees accumulate to a meaningful amount (likely many epochs), which gives folks time to consider how to implement the swap functions
While I can agree with you both that it most likely won’t be any big amounts, from a principled pov I think there are some issues here:
there is no way the general inflation from a burn will in any meaningful way offset losing nam directly for validators. if you are any validator, would you rather have 10 nam in hand or have 10 nam be burnt? For any ordinary holder obviously getting the tokens would be magnitudes of magnitudes better.
the forementioned being the case, I’m not sure I like creating an assymetric incentive structure where it’s worse for validators if people use non-native gas payments
I realize it may not be big amounts so maybe not that important m, but I am having trouble following the reasoning a slight deflation can in any meaningful way offset losing direct rewards.
As I suggested in the past, I will be in favor of making a treasury using the external IBC assets used as a non-native gas fee tokens in Namada.
In regard to the usage of these funds, I see a buy-and–burn mechanism as a great idea. I’m also thinking of and seeing with good eyes using them to fund initiatives in ongoing developments related to Namada and their native chains - I think it would be a great one too.
All good points. An underlying assumption of mine here – which might be wrong – is that validators would find it annoying to deal with unpredictable, small amounts of many different non-native tokens (as fee payments), and that this annoyance would be substantial enough that they’d be happy to sacrifice somewhat-better rewards for a simpler system.
Maybe we can hybridize these systems a bit and have our cake and eat it too. What do you think of the following:
Periodically, Namada sets a min gas price, denominated in all supported fee tokens.
When users send a transaction, they pay at least the min gas price, and may add a tip (similar to EIP1559).
All non-native fee tokens, and the minimum payment (min gas price * gas) for any NAM transaction fees, go to the temporary Namada account. Any NAM tips (for NAM transaction fees) go directly to the block proposer. Non-native fee token tips are tracked in storage.
Periodically, Namada executes a cross-chain swap (as described above), swapping all non-native fee tokens to NAM.
Based on the swap prices and tracked tips, validators receive their non-native fee token tips, but now in NAM. The rest of the NAM received from swaps is burned.
This is a little bit more complex, and we’d need to think about the implementation effort required here, but it seems to give us the best of both worlds: base fee demand translates into overall network demand, validators receive tips (which should be common, e.g. a little tip can be the default in most interfaces), and validators only have to deal with NAM. It’s probably also more efficient to swap all the non-native fee tokens at once (periodically) – lower transaction fees (on the other chains) than if all the validators did this individually.
Maybe we can hybridize these systems a bit and have our cake and eat it too. What do you think of the following:
@cwgoes i like this! tho it does seem a little complex, especially having the protocol tracking all of these fragments owed to different proposers
Toss IBC fees into PGF for now, imo
i agree w @cwgoes, block proposers accruing fragments of many kinds of potential IBC tokens seems much more annoying (and maybe problematic for accounting?) than valuable
tbh, i think it’s better to just accrue the little IBC token fragments in the PGF account for now–i agree w @Daniel. if these numbers start to become even close to meaningful, maybe then we can revisit how validators / stakers earn these
My only concern here would be that if this is a regular operation, then some IBC relayer could easily front-run the swaps if transferring from transparent address to osmosis, which would lead to buying back NAM at a higher price, especially if there is no deep liquidity in the NAM-XYZ AMMs.
That said this is the most utilitarian approach. It benefits NAM holders and validators alike, aligning incentives.
While I see the ideal merits of this approach and it aligns with my personal values we should consider that PGF governance will be messy and has yet to really form at all. Introducing more layers for potential bureaucratic decision-making will lead to more governance bike-shedding and fighting down the line. I think a governance minimized approach here makes more sense. Besides, NAM holders can arbitrarily vote to create more NAM for PGF arbitrarily, which is plenty powerful.
tl;dr
this is a noble pursuit but introduces more governance, which at this stage we should try to minimize.
Sorry, I’ve been forum-awol for a few days. I think the degree to which validators would be annoyed with the non-native fees relates to whether it’s in fact just dust, or has real economic value. If non-native gas payment is substantial, I doubt validators would prefer them being burnt. The idea of having it converted to NAM beforehand is good, I still don’t understand why we are keen on burning the base part of the fee instead of sending it to validators on a pro-rata basis periodically. (this would not be exactly the same as non-conversion, but at least it would go to the validator cluster).
I think it makes more overall economic sense to return (part of) the value generated by demand for transactions to the network stakeholders as a whole, not just validators, because many network stakeholders besides validators are involved in actually sourcing that demand – e.g. full nodes, indexers, wallet developers, educators, etc. etc. – and they benefit much more directly (assuming that they hold some NAM) if the base fee is simply converted to NAM and burned.
I propose that we start here with a simple update, which would:
Add a protocol treasury account which can hold non-native tokens.
Send non-native token base fees to that account.
Burn native token base fees.
This will help establish the basic economic substrate for the protocol to do something with non-native fees, but we don’t have to commit to exactly what that mechanism looks like immediately. Validators will still receive tips (in both native and non-native fees). For now we can continue setting base gas prices manually, but this change would also allow an easy update to an EIP1559-like automatic mechanism in the future.
More and more chains are implementing gasless transactions to reduce end-user friction. The upcoming Ethereum upgrade Pectra will make gasless transacting possible on mainnet. Namada risks falling behind the curve if gasless transacting becomes the new trend.
Perhaps instead of burning, the collected fees can be put in a gas station pool to subsidize the first x amount of transactions per account.
not sure how related the topic of gasless txs is related to this topic
Rather than jumping through the hoops proposed in the first post (sorry, @cwgoes!) I started to wonder why Namada has any transaction fees at all. Looks like an XY problem to me: “what are we going to do with the collected fees” versus “why are there fees?”.
The current gas costs were picked rather arbitrarily, neither out of concrete and urgent necessity to stop and prevent spam, nor to cover infrastructure and downstream costs.
To make IBC’ing into Namada attractive, we agreed to initially delay making gas fees in non-NAM tokens more expensive, again supporting the argument that fees are arbitrary.
Transaction fees are not expected to cover the cost of infrastructure. Providing infrastructure is considered an altruistic act.
Paying transaction fees for Shielded Transactions can be a risk of leaking information and the correct way to do it through a disposable gas payer is a rather coarse workaround that may bloat the chain.
So, what was the rationale behind transactions fees in Namada? Is it just inherited from Cosmos, and further back from Ethereum (why does Ethereum PoS have gas?) and Bitcoin?
There are completely gasless blockchains out there and apparently they are successfully able to prevent spam attacks. Ethereum Gas Station is not truly gasless, someone else is footing the bill, but clearly it addresses a need, so even Ethereum is rethinking gas now.
Hmm, at least in the discussions I recall, we picked gas costs rather conservatively (they’re probably unnecessarily high right now), precisely to make spam unlikely. Personally, I think it’s important to proactively prevent spam, as the costs to user experience and node operators can be much higher if you only react to it once it starts happening.
Hmm, this may be the view of that poster, but I’m not sure I’d be so definitive. Namada is very early in the product lifecycle and doesn’t have too many users yet (although the volume of MASP deposits already is impressive!) – I think it will take time to understand what the demand (and willingness to pay transaction fees) really is. I also don’t expect all operators to be altruistic, I expect them to have a range of motivations, goals, and constraints.
There’s a more fundamental reason than that: spam prevention, or anti-DoS, in a permissionless system (or at least a system without other permissions beyond gas). Without payment for transaction processing which is proportional to compute and storage resources used (which is just what “gas” is), some adversary could submit many transactions and spam the network, making it at minimum unusable for real users, and often imposing long-term costs on operators (historical examples include the DoS attacks around the Ethereum “Shanghai” upgrade and the Zcash “sandblasting” attacks, both of which involved gas mispricing).
Do you have examples in mind here? I have a hard time imagining how it would be possible to support free transactions without reintroducing this possibility of DoS, at least without some other permissioning mechanism.
How do you prevent an adversary from simply creating many new accounts and using the subsidized transactions to spam the system?
Do you have examples in mind here? I have a hard time imagining how it would be possible to support free transactions without reintroducing this possibility of DoS, at least without some other permissioning mechanism.
There are some feeless blockchains and some with negligible fees. Those with negligible fees (such as Stellar, Algorand, Hedera Hashgraph, Ripple) still have the aforementioned drawbacks, of course.
Nano Transactions are feeless because validators are not paid via fees but instead are incentivized to maintain the network’s efficiency and security. Transactions from accounts with larger Nano balances are prioritized by nodes. Each transaction (send/receive block) requires the sender to compute a small, energy-efficient PoW puzzle.
Hive A fork of Steem. Transactions consume Resource Credits, which are earned automatically based on the user’s staked Hive Power and account activity. Casual users rarely deplete their Resource Credits.
Koinos Instead of fees, users consume Mana, a resource generated by holding $KOIN tokens. Mana regenerates over time. Creating new accounts costs Mana, deterring spam via fake accounts.
EOS could be considered feeless, but I think having to buy and allocate RAM, NET and CPU makes it less user friendly than just having fees.
Hmm, validators may have other incentives, but I’d be concerned about potential DoS with just a PoW puzzle (if it’s easy to compute on consumer devices, it’s easy to compute a lot of them on dedicated hardware). Prioritizing transactions based on account history could indeed be helpful, but it’s not really compatible with shielded transactions, at least not without a lot of additional cryptography engineering.
To me, staking one token to get another token which you spend to send transactions is a fee, just a fee in a different token. At the moment, staked NAM generates NAM, which can be used to pay fees – if instead it generated “FEE”, which could only be used to pay fees, would it really be that different? Perhaps the fee tokens not being tradeable is desirable?
