Update fee methodology for earlier weeks#6303
Update fee methodology for earlier weeks#6303brihu23 wants to merge 7 commits intoDefiLlama:masterfrom
Conversation
…fetches
- fees: wrap getETHReceived and getSolanaReceived in try/catch so Allium
timeouts/errors dont
…ra-collector transfers - should sort earlier fee days during 1 bip / no fee promo during January, data should remain consistent for post feb 1st
Summary by CodeRabbit
WalkthroughModified Genius Protocol fee tracking to iterate over multiple fee collector wallets instead of a single multisig target. For EVM and Solana separately, the adapter now loops through respective fee collector lists, fetches inflows per collector with cross-collector exclusion filters, and includes per-collector error handling with logging. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Suggested labels
🚥 Pre-merge checks | ✅ 2 | ❌ 4❌ Failed checks (3 warnings, 1 inconclusive)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches✨ Simplify code
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
The genius-protocol adapter exports: |
|
We had 2-3 transitions with fee collection wallets/addresses during the first couple weeks during the 0 fee promo period (where 1 bip was taken) and between weeks 1-4 before stabalizing, updated on-chain methodology to reflect this to show fees to back up api volume results for weeks 1-3 with a few of those crazy volume days |
|
The genius-protocol adapter exports: |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@fees/genius-protocol/index.ts`:
- Around line 45-65: The call to addTokensReceived inside the EVM_FEE_COLLECTORS
loop is unprotected and can throw, aborting the whole EVM processing; wrap the
addTokensReceived invocation in a try/catch like getETHReceived, logging a
contextual warning/error that includes options.chain and the addr and then
continue the loop (or return 0 for chain-specific helper functions) so a
recoverable failure (e.g., indexer timeout) degrades gracefully instead of
failing the entire fetch; keep the same log style used for getETHReceived.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: e8a1009b-2b80-4606-b055-a2baadeba8b4
📒 Files selected for processing (2)
dexs/genius-protocol/index.tsfees/genius-protocol/index.ts
collector - address coderabbit fixes
|
The genius-protocol adapter exports: |
There was a problem hiding this comment.
Actionable comments posted: 1
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: 1ad4971f-e802-4363-8ae9-b92b2f1d231a
📒 Files selected for processing (1)
fees/genius-protocol/index.ts
|
The genius-protocol adapter exports: |
|
The genius-protocol adapter exports: |
|
The genius-protocol adapter exports: |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@fees/genius-protocol/index.ts`:
- Around line 45-55: The current logFilter passed to addTokensReceived relies on
log.from (which only exists on the getLogs path) and therefore doesn't filter
indexer responses; update the call to exclude intra-collector transfers by
either (1) removing logFilter and supplying a fromAddressFilter built from
EVM_COLLECTORS_SET so the indexer can do the exclusion, or (2) force the getLogs
path by adding skipIndexer: true to the options passed to addTokensReceived, or
(3) if you must keep indexer, implement decoding of from in the indexer path
(less recommended). Modify the loop invoking addTokensReceived (for
EVM_FEE_COLLECTORS) to use one of these approaches and reference
addTokensReceived, logFilter, fromAddressFilter, skipIndexer, and
EVM_COLLECTORS_SET when making the change.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: 9b4ce758-e980-4598-b50e-87e1fc93dac7
📒 Files selected for processing (1)
fees/genius-protocol/index.ts
logFilter applies
|
The genius-protocol adapter exports: |
|
The genius-protocol adapter exports: |
dexs/genius-protocol/index.ts
Outdated
| try { | ||
| return await fetchURL(`${DAILY_VOLUME_URL}?date=${options.dateString}`); | ||
| } catch (e) { | ||
| console.warn(`[genius-protocol] volume API unavailable for ${options.dateString}: ${(e as Error).message}`); |
There was a problem hiding this comment.
@brihu23 you need not worry about handling this, even if it throws error we handle externally and show as 0.
is your dune query onchain? if yes can you switch to that instead , so we would exactly know sources of your volume.
also is genius protocol an interface? like is it a platform which provides trading on external liquidity like pancakeswap/ hyperliquid etc?
There was a problem hiding this comment.
Hi @bheluga! Got it - yes we will be switching to a router so that all volume will be on chain in the next month or so. We are a trading terminal - https://www.tradegenius.com/home similar to Axiom, Fomo, GMGN. I can see if we can create a way to recreate volume based off of txns to our fee collection wallets in an upcoming sprint for dex volume
There was a problem hiding this comment.
Our Dune query is not on-chain it is the same API - our fee collection is on chain - working to get the banner removed as we have 5-10k active traders / wallets who have contributed > 100 dollars in fees. This PR should show that - assuming that that banner came up because our multisig only receives funds from our fee collection wallet.
|
The genius-protocol adapter exports: |
|
The genius-protocol adapter exports: |
There was a problem hiding this comment.
♻️ Duplicate comments (1)
fees/genius-protocol/index.ts (1)
127-134: 🧹 Nitpick | 🔵 Trivial
breakdownMethodologypresent but no labeled.add()calls tie into it.The
breakdownMethodologydocuments "Terminal Trading Fees" but the helper functions (addTokensReceived,getETHReceived,getSolanaReceived) add to balances without labels. Per guidelines, labels should be provided even for a single source to avoid backfills when additional sources are added.When Aster Builder / Hyperliquid fees are integrated, consider wrapping the balance additions with labeled tracking. For now, this serves as documentation but won't produce labeled breakdowns in the output.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@fees/genius-protocol/index.ts` around lines 127 - 134, The breakdownMethodology defines "Terminal Trading Fees" but the balance updates use unlabeled helpers, so add labeled balance entries to match the documentation: where addTokensReceived, getETHReceived, and getSolanaReceived currently push amounts into balances, wrap those calls with balances.add(...) (or replace the unlabeled adds) supplying the label "Terminal Trading Fees" (and the appropriate chain/token) so the reported breakdown matches breakdownMethodology and future sources (e.g., Aster Builder/Hyperliquid) can be added without backfilling.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Duplicate comments:
In `@fees/genius-protocol/index.ts`:
- Around line 127-134: The breakdownMethodology defines "Terminal Trading Fees"
but the balance updates use unlabeled helpers, so add labeled balance entries to
match the documentation: where addTokensReceived, getETHReceived, and
getSolanaReceived currently push amounts into balances, wrap those calls with
balances.add(...) (or replace the unlabeled adds) supplying the label "Terminal
Trading Fees" (and the appropriate chain/token) so the reported breakdown
matches breakdownMethodology and future sources (e.g., Aster
Builder/Hyperliquid) can be added without backfilling.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: b5db3f95-8488-4e35-a564-3c7beca16954
📒 Files selected for processing (1)
fees/genius-protocol/index.ts
|
The genius-protocol adapter exports: |
NOTE
Please enable "Allow edits by maintainers" while putting up the PR.
package.json/package-lock.jsonfile as part of your changesName (to be shown on DefiLlama):
Twitter Link:
List of audit links if any:
Website Link:
Logo (High resolution, will be shown with rounded borders):
Current TVL:
Treasury Addresses (if the protocol has treasury)
Chain:
Coingecko ID (so your TVL can appear on Coingecko, leave empty if not listed): (https://api.coingecko.com/api/v3/coins/list)
Coinmarketcap ID (so your TVL can appear on Coinmarketcap, leave empty if not listed): (https://api.coinmarketcap.com/data-api/v3/map/all?listing_status=active,inactive,untracked&start=1&limit=10000)
Short Description (to be shown on DefiLlama):
Token address and ticker if any:
Category (full list at https://defillama.com/categories) *Please choose only one:
Oracle Provider(s): Specify the oracle(s) used (e.g., Chainlink, Band, API3, TWAP, etc.):
Implementation Details: Briefly describe how the oracle is integrated into your project:
Documentation/Proof: Provide links to documentation or any other resources that verify the oracle's usage:
forkedFrom (Does your project originate from another project):
methodology (what is being counted as tvl, how is tvl being calculated):
Github org/user (Optional, if your code is open source, we can track activity):
Does this project have a referral program?