Fix GameClub fees adapter - track all USDT received by FeeCollector#6341
Fix GameClub fees adapter - track all USDT received by FeeCollector#6341ruddhks552 wants to merge 1 commit intoDefiLlama:masterfrom
Conversation
…track all USDT to FeeCollector
Summary by CodeRabbit
WalkthroughRemoved the Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Suggested labels
🚥 Pre-merge checks | ✅ 4 | ❌ 2❌ Failed checks (1 warning, 1 inconclusive)
✅ Passed checks (4 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 gameclub.ts adapter exports: |
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 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/gameclub.ts`:
- Around line 18-22: The adapter currently returns dailyFees, dailyRevenue, and
dailyProtocolRevenue all as the same value and lacks a breakdownMethodology;
update the fees adapter to (1) add a breakdownMethodology object that documents
every label used (e.g., "protocol", "supply-side", etc.) consistent with the
existing methodology object, and (2) verify whether any supply-side revenue
exists and if so compute and return dailySupplySideRevenue separately instead of
equating it to dailyProtocolRevenue; reference the return values dailyFees,
dailyRevenue, dailyProtocolRevenue, dailySupplySideRevenue and any .add() labels
so the breakdownMethodology accurately describes the labels used.
- Around line 25-29: The methodology object uses generic keys ("Fees",
"Revenue", "ProtocolRevenue") which violate the adapter guideline to use
source-specific labels; update the methodology constant named methodology to use
descriptive keys that reflect the actual fee source (e.g., TradingFees,
ProtocolFees, ProtocolRevenueFromTradingFees or similar consistent labels) and
update any downstream code that reads those keys to the new names so consumers
still get the same values.
🪄 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: e7326bd9-5b06-4e06-8af4-b6cfebdcf1fe
📒 Files selected for processing (1)
fees/gameclub.ts
| return { | ||
| dailyFees, | ||
| dailyRevenue: dailyFees, | ||
| dailyProtocolRevenue: dailyFees, | ||
| }; |
There was a problem hiding this comment.
🧹 Nitpick | 🔵 Trivial
Add breakdownMethodology and consider using labels.
Per coding guidelines, fees adapters should include a breakdownMethodology object documenting all labels used. While the current methodology object describes the fee structure, consider adding explicit breakdown documentation.
Also, the adapter assumes dailyFees = dailyRevenue = dailyProtocolRevenue (100% to protocol). Verify there is no supply-side revenue (e.g., liquidity providers, market makers) that should be tracked separately in dailySupplySideRevenue.
📝 Suggested enhancement with breakdownMethodology
const methodology = {
Fees: "Users pay fees when they trade on GameClub prediction markets",
Revenue: "All fees go to the protocol",
ProtocolRevenue: "All fees go to the protocol",
};
+const breakdownMethodology = {
+ "Trading Fees": "USDT fees collected from prediction market trades",
+};Then use the label in the return if the helper supports it, or document it for future reference.
As per coding guidelines: "Include breakdownMethodology object in fees adapters that documents all labels used in .add() calls with clear descriptions."
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@fees/gameclub.ts` around lines 18 - 22, The adapter currently returns
dailyFees, dailyRevenue, and dailyProtocolRevenue all as the same value and
lacks a breakdownMethodology; update the fees adapter to (1) add a
breakdownMethodology object that documents every label used (e.g., "protocol",
"supply-side", etc.) consistent with the existing methodology object, and (2)
verify whether any supply-side revenue exists and if so compute and return
dailySupplySideRevenue separately instead of equating it to
dailyProtocolRevenue; reference the return values dailyFees, dailyRevenue,
dailyProtocolRevenue, dailySupplySideRevenue and any .add() labels so the
breakdownMethodology accurately describes the labels used.
| const methodology = { | ||
| Fees: "Users pay fees when they trade on GameClub prediction markets", | ||
| Revenue: "All fees go to the protocol", | ||
| ProtocolRevenue: "All fees go to the protocol", | ||
| Fees: "Users pay fees when they trade on GameClub prediction markets", | ||
| Revenue: "All fees go to the protocol", | ||
| ProtocolRevenue: "All fees go to the protocol", | ||
| }; |
There was a problem hiding this comment.
🧹 Nitpick | 🔵 Trivial
Use more specific fee source labels in methodology.
The methodology uses generic terms. Per guidelines, use specific source-based labels.
📝 Suggested methodology refinement
const methodology = {
- Fees: "Users pay fees when they trade on GameClub prediction markets",
- Revenue: "All fees go to the protocol",
- ProtocolRevenue: "All fees go to the protocol",
+ Fees: "Trading fees collected from GameClub prediction market positions",
+ Revenue: "Trading Fees To Protocol - all collected fees retained by GameClub",
+ ProtocolRevenue: "Trading Fees To Protocol - allocated to protocol treasury",
};As per coding guidelines: "Use specific, descriptive labels in fees adapters - avoid generic labels."
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@fees/gameclub.ts` around lines 25 - 29, The methodology object uses generic
keys ("Fees", "Revenue", "ProtocolRevenue") which violate the adapter guideline
to use source-specific labels; update the methodology constant named methodology
to use descriptive keys that reflect the actual fee source (e.g., TradingFees,
ProtocolFees, ProtocolRevenueFromTradingFees or similar consistent labels) and
update any downstream code that reads those keys to the new names so consumers
still get the same values.
bheluga
left a comment
There was a problem hiding this comment.
@ruddhks552 thanks for the PR.
Any reason for this change? Its not a good practice to USDT track received from everyone , since some txns like this may not be fees https://intel.arkm.com/explorer/tx/0x8153dce6decacc976d0ab9e316a8846210c933b58b6ba73c425f4d2fdc3e07b2 .
…track all USDT to FeeCollector
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?