# Min Fee Discussion

March 16, 2021

## Attendees
- Sam Hart
- Cory Levinson
- Aleks Bezobchuck
- Robert Zaremba
- Zaki Manian
- Ethan Buchman

## Agenda
- Actionables from last time:
- building sane default into the binary
- Disallowing zero fee (except for specific operations like delegator withdraw)
- Is this sufficient to address problems regen outlined?
- Alternatives
- fixed base fee that can be changed via governance
- could this be used in conjunction with elasticity based on non-emty blocks?
- Split between single denom / multi-denom
- EIP-1559 solution space
- Cornell solution (https://arxiv.org/pdf/1901.06830.pdf)
- what kind of fees should be accepted
- any?
- whitelist by gov?
- authz can blow up state
- considering small bond amount for authz operations
- zaki: ship single currency with sdk
- creates ux issues for users

---

March 9, 2021

## Attendees
- Sam Hart, Cory Levinson, Aleks Bezobchuck, Aditya Sripal, Jack Zampolin, Aaron C, Robert Zaremba, Marko Baricevic, John Adler, Zaki Manian

## Agenda
- Framing: Min-fee (spam prevention) vs base-fee (price predictability + MEV harm reduction)
- Upcoming changes to mempool + block execution - required before some fee models are possible
- What risks do we face in the next 6-12m before this happens? (Hub + other zones)
- What intermediate solutions are required in this timeframe?

## Notes

- Sam: Context is there was a conversation in #economics channel in cosmos hub discord, but also this came up through an earlier issue raised by Regen Net
- Regen Network is launching their chain and has specific concerns around spam prevention (mainly aimed at new chains without a significant amt of transaction demand)
- There are fee models proposed in Eth ecosystem (https://eips.ethereum.org/EIPS/eip-1559)
- We need to be aware of changes coming to tendermint & SDK so we know where we're going w/ fee models
- Aaron: From our end, the requirement is that there's a way to ensure that there aren't high impact operations that can be performed with zero cost
- e.g. state storage (0-fee transactions with msg's that bloat state)
- Few weeks ago we had an architecture call to discuss one proposal:
- There could be a block fulfilment threshold, and the fee would dynamically adjust based on wether threshold is reached
- The issue is that if you're working w/ a low-volume chain, fees will drop to 0 as block fulfilment threshold would not get met
- The other proposal was to have validators signal with a desired min-fee, and you take some median of that
- A few of the newer modules (authz module) allows for you to create dummy accounts and give them all permissions (to do nothing)
- On the Regen side, we allow for the creation of new denoms, or store arbitrary amounts of data on-chain.
- Sam: Can someone speak to IBC concerns?
- Aditya: IBC introduces a lot of state to the hub. Clients are going to be a big part of IBC (you're submitting headers and keeping track of consensus states...)
- The concern that Aaron repeated is the same in IBC. IBC doesn't really care about fees but does want prevention of spamming / DOS vectors
- Sam Hart: I've been thinking about long term changes to the fee model, and there's a bunch of things that we need to put in place before we can make more readical cahnges to how we're doing fees
- Sunny: With more advanced fee models (EIP-1559) are designed for cases where there is full demand for block space
- If there's no consistent demand for blockchain, fees go to 0
- From an economic standpoint, we still want to make sure there's some minimal fee
- Sunny: We need a way to convert fees into the single base asset.
- Marko: One question from my side - Are we talking about making a decision for everyone using the SDK? Or is this about allowing chain developers to provide their own fee models
- Sunny: I think it has to be pluggable. But the default in the base repo is really bad.
- Sam Hart: The validator signaling strategy -- can you fill in some more gaps here, Sunny?
- Sunny: You'd have a medianizer where every validator can signal what they think the min-fee should be. How ever occasionally they want, a validator can update the min-fee.
- Validators then would need to have something to update the min-fee at some regular interval (say every day it may update the min-fee based on atom price)
- This script would require validators to have a hot key. So it may be valuable to utilize msg auth here.
- You could also delegate that to a 3rd party.
- Aaron: The one thing that isn't quite answered by this proposal, is how do you set quorum, and what do you do if you don't have a quorum? Lastly, do some votes become stale?
- Sunny: Every validator should submit an initial min-fee with GenTx.
- Maybe we can have something to determine min-fees as stale?
- On the next upgrade, we can propose a reasonable min-fee
- Sam: The thing that I dislike about this is multi-denom. It seems like a lot of mental overhead to be setting min fees for every
- Aaron: I think the administrative overhead would be taken care of by some price feed API
- Sam: And now you have a system where everyone is dependent on these price feeds
- Sunny: This is what oracles are though.
- Aaron: Do you have a sense of how may validators are setting min-fees?
- Sunny: Some validators set to zero, for Sikka we rarely upgrade. Some users have complained that our fees are too high. I disagree and think fees should be raised right now.
- Sam: Both of these proposals seem unreasonable to tackle within the scope of 6-12 months
- Aaron: One option is, building into the binary, a sane default minimum.
- Sunny: That sounds totally reasonable.
- Sam: We could also disallow zero fees. So that they cannot be absolutely zero.
- Aaron: One weird point that we've encountered, we realized that if we don't have 0 fees at genesis. So there's this weird thing that when you launch, you actually need 0 fees for a while at the beginning.
- Sunny: You could also say that Delegate & Withdraw don't actually need fees.
- Sunny: Two issues for per-node min fee configurations:
- you can't actually query what the min-fee is
- Full nodes filter based on their min-fee to determine how to propogate transactions in the network
- Aaron: This points to how on the social level. We need to decide if we decidedly want to rely on social coordination for this.
- Sunny: I'm 100% EIP-1559. If its something that takes a few months to implement, we should probably go for it.
- John: With LazyLedger we are planning on using essentially the same thing as EIP-1559, as it gives a flexible blocksize cap. With a completely in-protocol adjustement of base fee. We are also doing single denom for the fee.
- Zaki: There seem to be two camps here:
- Multi denom fee maximalist for UX
- Probably requires AMM / Oracle
- Single denom fee maximalist for mechanism design
- Can use EIP-1559 model
- Sunny: This preference comes down to a chain preference. Cosmos Hub may prefer multi-denom, whereas Regen likely leans towards a single denom model.
- Aaron: What if we explore a little more what sunny was brinigng up, in the current mem-pool design
- Sam: what about client-side proof of work
- Zaki: not great for mobile users

Wrap-up
- Two immediate actionables:
- Builiding something into the node
- Adding a sane default
- Beyond that, we've identified this single denom v multi-denom paradigm
- Aaron: Let's have a follow-up meeting and try to keep at having this conversation until there's more consensus about which approach we take

## Follow-up