Skip to content

Conversation

@ducksquaddd
Copy link
Member

The old system which existed to allow fee-less price feeder TXs simply didnt work, due to it comparing lowercase msg type URLs to mixed case msg type URLs.

This new system replaces that logic, and allows certain addresses to ability to define 0uelys fees and have it get into the block. It also forces highest execution priority to TXs of such nature, so Price-Feeder TXs should always execute before anything else for example.

@codecov
Copy link

codecov bot commented Jul 22, 2025

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 57.47%. Comparing base (90cdb75) to head (e940bc0).

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #1389      +/-   ##
==========================================
+ Coverage   57.43%   57.47%   +0.04%     
==========================================
  Files        1002     1002              
  Lines       42408    42417       +9     
==========================================
+ Hits        24355    24380      +25     
+ Misses      16364    16350      -14     
+ Partials     1689     1687       -2     
Components Coverage Δ
leveragelp_transactions 75.00% <ø> (ø)
leveragelp_lifecycle 87.11% <ø> (ø)
leveragelp_keeper 85.26% <ø> (ø)
leveragelp_queries 20.39% <ø> (ø)
accountedpool_transactions 100.00% <ø> (ø)
accountedpool_lifecycle 100.00% <ø> (ø)
accountedpool_queries 81.25% <ø> (ø)
amm_transactions 72.86% <ø> (ø)
amm_lifecycle 86.66% <ø> (ø)
amm_keeper 72.64% <ø> (ø)
amm_queries 57.43% <ø> (ø)
assetprofile_transactions 76.85% <ø> (ø)
assetprofile_lifecycle ∅ <ø> (∅)
assetprofile_keeper 80.00% <ø> (ø)
assetprofile_queries 60.00% <ø> (ø)
burner_transactions 13.33% <ø> (ø)
burner_lifecycle ∅ <ø> (∅)
burner_keeper 100.00% <ø> (ø)
burner_queries 78.57% <ø> (ø)
commitment_transactions 74.49% <ø> (ø)
commitment_lifecycle ∅ <ø> (∅)
commitment_keeper 80.97% <ø> (ø)
commitment_queries 43.97% <ø> (ø)
epochs_transactions ∅ <ø> (∅)
epochs_lifecycle 92.00% <ø> (ø)
epochs_keeper 84.61% <ø> (ø)
epochs_queries 83.33% <ø> (ø)
estaking_transactions 56.33% <ø> (ø)
estaking_lifecycle 87.93% <ø> (ø)
estaking_keeper 67.79% <ø> (ø)
estaking_queries 66.90% <ø> (ø)
incentive_transactions ∅ <ø> (∅)
incentive_lifecycle ∅ <ø> (∅)
incentive_keeper ∅ <ø> (∅)
incentive_queries ∅ <ø> (∅)
masterchef_transactions 85.40% <ø> (ø)
masterchef_lifecycle 72.32% <ø> (ø)
masterchef_keeper 100.00% <ø> (ø)
masterchef_queries 42.74% <ø> (ø)
oracle_transactions 27.27% <ø> (ø)
oracle_lifecycle 100.00% <ø> (ø)
oracle_keeper 77.77% <ø> (ø)
oracle_queries 37.50% <ø> (ø)
parameter_transactions 15.38% <ø> (ø)
parameter_lifecycle ∅ <ø> (∅)
parameter_keeper 75.00% <ø> (ø)
parameter_queries 57.14% <ø> (ø)
stablestake_transactions 80.18% <ø> (ø)
stablestake_lifecycle 100.00% <ø> (ø)
stablestake_keeper 92.00% <ø> (ø)
stablestake_queries 90.90% <ø> (ø)
perpetual_transactions 75.37% <ø> (ø)
perpetual_lifecycle 75.29% <ø> (ø)
perpetual_keeper 63.02% <ø> (ø)
perpetual_queries 58.60% <ø> (ø)
tier_transactions 100.00% <ø> (ø)
tier_lifecycle 100.00% <ø> (ø)
tier_keeper 90.90% <ø> (ø)
tier_queries 74.48% <ø> (ø)
tokenomics_transactions 71.87% <ø> (ø)
tokenomics_lifecycle ∅ <ø> (∅)
tokenomics_keeper 80.00% <ø> (ø)
tokenomics_queries 79.06% <ø> (ø)
tradeshield_transactions 80.80% <ø> (ø)
tradeshield_lifecycle ∅ <ø> (∅)
tradeshield_keeper 75.00% <ø> (ø)
tradeshield_queries 67.56% <ø> (ø)
🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

"elys16qgewtplahkqwqa0aqv4pxnxa58ulu48k6crhj", // Price Feeder 1 mainnet
"elys1zwexzk6ns5ermvag5fc0gtyvrnxyaz9kzaflqf", // Price Feeder 2 mainnet
"elys1nelawytdfdk4af3z0sy2p8vkrllk8zw9g32jmf", // Execution bot 1 mainnet
"elys1gszp63euzm0ecs3qwu0j6mexjr97hjs7x5gvzk", // Execution bot 2 mainnet
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we should not hardcode these addresses, should be stored or removed via gov

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Building that logic out is definitely outside my scope of Cosmos SDK. But I also never saw a project do it like that, in everyone else's implementation things were hard coded.

But maybe can implement some logic so that if its testnet only testnet addresses are in the array, etc.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ref this: #1389 (comment)

In pre-blocker, you can call params and use a setter function.

}
minGasPrices = sdk.NewDecCoins(minGasPrice)
"elys1gy503ty29ydute5rksnkwgmtatelret9d455lt", // Execution bot devnet
"elys1dae9z45ccetfwr208ghya6npntg75qvxgmg4p9", // Price Feeder devnet
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same here

priority = getTxPriority(feeCoins, int64(gas))
}

return feeCoins, priority, nil
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

in this we are making all txs gases for hardcoded addresses, is that correct ?

I guess we should only allow price txs as gasless otherwise someone can spam the chain with other txs if compromised.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The priority changes the priority of the TX, allowing our gasless TXs to execute before everyone else otherwise our gasless TXs always execute last.

This logic also does not remove gas from the tx it simply makes it so the minimum fee is 0, so if you upload a TX with a fee 0 it can pass. But you can still pass in a fee.

Also because this uses the feepayer address to identify who can send 0 uelys fees, we can actually make it one address then do a feegrant, from say governance. So we could control who has access.

// GaslessAddrs contains only the governance module address.
// Governance can grant feegrants to operational addresses (price feeders, liquidation bots, etc.)
// When those addresses use feegrants, the fee payer becomes governance, enabling gasless transactions.
var GaslessAddrs = []string{
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hard coding sender of tx makes tit difficult to change on the fly. Why not set it when chain starts by fetching params of respective module?
Only con is it might have to be done every block or we can do periodically or some other design

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I mean this makes it so governance can change it on the fly. If a wallet gets compromised then the governance module simply revokes the fee grant.

feePayer := sdk.AccAddress(feePayerBytes).String()

for _, ga := range GaslessAddrs {
if feePayer == ga {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this allow address to do all txs gasless

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah I mean this was just a design choice for flexibility. Allows governance to pick and choose what they want to allow as fee-less too. Then if it's abused the abuser can get removed it's not really a huge risk IMHO.

But I mean I don't mind either way we can limit it to specific TXs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants