Replies: 2 comments 2 replies
-
One consideration with deposits is that it probably requires more refactoring of From an end user standpoint, we definitely want to enable monitors & farmers to be able to send 0-fee transactions, and implementing spam prevention that still allows use of our existing fee-delegation logic seems preferable imo. After reading into the Cosmos SDK discussions, it seems like there is rough alignment on the following approach from Bez in cosmos/cosmos-sdk#4527 (comment):
I would say since there's active discussion of this across a few different SDK threads, and since there seems to be general interest in prioritizing this on the SDK side, we should try to see if the above proposed SDK solution meets our needs. If so, let's prioritize for SDK v0.43 and block implementing the new regen modules on mainnet until this is resolved. That is atleast my preferred approach. Thoughts from others? |
Beta Was this translation helpful? Give feedback.
-
I strongly support deposit for data heavy transactions. We could creat interface for that:
Storage has inherently differe cost structure than CPU, so i think it make sense to price it differently. Fee grant can have a structure: (max deposit, max fee) |
Beta Was this translation helpful? Give feedback.
-
What mechanisms should we use?
Relevant discussions in the SDK: cosmos/cosmos-sdk#8224 and cosmos/cosmos-sdk#4527
Beta Was this translation helpful? Give feedback.
All reactions