Conversation
WalkthroughA new Solana-based fee adapter for Anoncoin is introduced that fetches protocol revenue from Meteora bonding curve and DAMM V2 pools using the Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~8 minutes Suggested labels
🚥 Pre-merge checks | ✅ 3 | ❌ 3❌ Failed checks (2 warnings, 1 inconclusive)
✅ Passed checks (3 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 anoncoin 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/anoncoin/index.ts`:
- Around line 12-24: The adapter currently returns aggregated
dailyFees/dailyRevenue/dailyProtocolRevenue without labeled breakdowns and lacks
a breakdownMethodology; update the fetch flow (the return object constructed in
the fetch function and the adapter export named adapter) to use explicit labeled
breakdown entries (e.g., labels such as "partner_trading_fees" or a
source-specific name) when calling .add() / building the output so each
revenue/fee dimension includes a label, and add a matching breakdownMethodology
object inside the adapter (next to methodology) that documents each exact label
string you used; ensure the labels in breakdownMethodology exactly match the
label keys emitted by fetch and that you update ProtocolRevenue/Revenue fields
to reference the labeled breakdown structure.
- Around line 8-11: Change the Solana fee query to only include native SOL by
passing mints: ['So11111111111111111111111111111111111111112'] into the
getSolanaReceived call (the call that currently passes options and target:
PARTNER_FEE_CLAIMER). Update the .add() calls that record the metric to include
explicit labels (e.g., label: "partner_trading_fees" and currency or token
label) and add a breakdownMethodology object for this file documenting all
revenue sources (e.g., partner trading fees: SOL transfers to
PARTNER_FEE_CLAIMER, any other sources if present) so the metric follows the
fees/**/*.ts guidelines.
🪄 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: f71f7c58-8694-4034-8de4-cdea1c601b64
📒 Files selected for processing (1)
fees/anoncoin/index.ts
| const dailyFees = await getSolanaReceived({ | ||
| options, | ||
| target: PARTNER_FEE_CLAIMER, | ||
| }); |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
For Allium's solana.assets.transfersdataset, how is native SOL represented in themint column, and what is the recommended way to filter only Meteora partner-fee transfer senders for a recipient wallet?
💡 Result:
Native SOL is represented in the mint column of Allium's solana.assets.transfers dataset as the Wrapped SOL mint address 'So11111111111111111111111111111111111111112'. No specific information was found on filtering for "Meteora partner-fee transfer senders" in the Allium documentation. The table includes columns like program_name, transfer_type, from_address, and in the _w_tx_cols variant, tx_account_keys which may allow filtering by Meteora program accounts (e.g., DLMM: LBUZKhRxPF3XUpBCjp4YzTKgLccjZhTSDM9YuVaPwxo, DAMM v2: cpamdpZCGKUy5JxQXB4dcpGPiikHawvSWAd6mEn1sGG, Dynamic Fee Sharing: dfsdo2UqvwfN8DuUVrMRNfQe11VaiNoKcMqLHVvDPzh). Partner-fee transfers likely originate from Meteora fee vaults or pools, so recommended filter could be to_address = '<recipient_wallet>' AND program_name LIKE '%meteora%' or parsing tx_account_keys for Meteora PDAs, but exact method not documented.
Citations:
- 1: https://docs.allium.so/historical-data/supported-blockchains/solana/solana/assets/transfers
- 2: https://allium-e770e2b7.mintlify.app/historical-data/supported-blockchains/solana/solana/assets/transfers
- 3: https://docs.meteora.ag/developer-guide/guides/dynamic-fee-sharing/overview
- 4: https://docs.meteora.ag/developer-guide/home
- 5: https://meteora.mintlify.app/developer-guide/home
🏁 Script executed:
# First, locate and examine the anoncoin adapter file
find . -path "*/fees/anoncoin/index.ts" -type fRepository: DefiLlama/dimension-adapters
Length of output: 96
🏁 Script executed:
# Check the complete fees/anoncoin/index.ts file
cat -n fees/anoncoin/index.tsRepository: DefiLlama/dimension-adapters
Length of output: 1091
🏁 Script executed:
# Locate the getSolanaReceived helper function
find . -path "*/helpers/token.ts" -type f | head -1 | xargs cat -n | head -100Repository: DefiLlama/dimension-adapters
Length of output: 4165
🏁 Script executed:
# Search for getSolanaReceived function definition in helpers/token.ts
grep -n "getSolanaReceived" helpers/token.ts | head -5Repository: DefiLlama/dimension-adapters
Length of output: 350
🏁 Script executed:
# Get the getSolanaReceived function implementation
sed -n '200,400p' helpers/token.tsRepository: DefiLlama/dimension-adapters
Length of output: 6714
🏁 Script executed:
# Get the full getSolanaReceived function implementation
sed -n '428,527p' helpers/token.tsRepository: DefiLlama/dimension-adapters
Length of output: 3879
Filter to SOL mint and add explicit labels with breakdownMethodology
getSolanaReceived accepts optional mints parameter to filter token types. The current code collects ALL tokens transferred to PARTNER_FEE_CLAIMER, but the methodology specifies "Partner trading fees (SOL)". Add mints: ['So11111111111111111111111111111111111111112'] to filter only native SOL. Additionally, per fees/**/*.ts guidelines, add explicit labels in .add() calls and a breakdownMethodology object documenting all revenue sources.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@fees/anoncoin/index.ts` around lines 8 - 11, Change the Solana fee query to
only include native SOL by passing mints:
['So11111111111111111111111111111111111111112'] into the getSolanaReceived call
(the call that currently passes options and target: PARTNER_FEE_CLAIMER). Update
the .add() calls that record the metric to include explicit labels (e.g., label:
"partner_trading_fees" and currency or token label) and add a
breakdownMethodology object for this file documenting all revenue sources (e.g.,
partner trading fees: SOL transfers to PARTNER_FEE_CLAIMER, any other sources if
present) so the metric follows the fees/**/*.ts guidelines.
| return { dailyFees, dailyRevenue: dailyFees, dailyProtocolRevenue: dailyFees }; | ||
| }; | ||
|
|
||
| const adapter: SimpleAdapter = { | ||
| version: 2, | ||
| adapter: { | ||
| [CHAIN.SOLANA]: { fetch }, | ||
| }, | ||
| dependencies: [Dependencies.ALLIUM], | ||
| isExpensiveAdapter: true, | ||
| methodology: { | ||
| ProtocolRevenue: "Partner trading fees (SOL) claimed by Anoncoin from Meteora bonding curve and DAMM V2 pools.", | ||
| }, |
There was a problem hiding this comment.
Add required labeled breakdowns and breakdownMethodology for this fees adapter
This adapter emits fee/revenue dimensions but does not provide explicit labeled breakdown entries plus matching breakdownMethodology. Please add source-specific labels and document them under breakdownMethodology with exact label matches.
Suggested structure
const adapter: SimpleAdapter = {
version: 2,
adapter: {
[CHAIN.SOLANA]: { fetch },
},
dependencies: [Dependencies.ALLIUM],
isExpensiveAdapter: true,
+ breakdownMethodology: {
+ Fees: {
+ "Meteora Partner Trading Fees": "SOL partner fees claimed by Anoncoin partner fee claimer wallet."
+ },
+ Revenue: {
+ "Meteora Partner Trading Fees To Protocol": "Partner fees retained by Anoncoin protocol."
+ },
+ ProtocolRevenue: {
+ "Meteora Partner Trading Fees To Treasury": "Protocol revenue from claimed Meteora partner fees."
+ }
+ },
methodology: {
ProtocolRevenue: "Partner trading fees (SOL) claimed by Anoncoin from Meteora bonding curve and DAMM V2 pools.",
},
};As per coding guidelines: “Include a required breakdownMethodology object in TypeScript adapter files documenting all labels used in .add() calls” and “Always provide labels in .add() calls even when there is only one source of fees.”
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@fees/anoncoin/index.ts` around lines 12 - 24, The adapter currently returns
aggregated dailyFees/dailyRevenue/dailyProtocolRevenue without labeled
breakdowns and lacks a breakdownMethodology; update the fetch flow (the return
object constructed in the fetch function and the adapter export named adapter)
to use explicit labeled breakdown entries (e.g., labels such as
"partner_trading_fees" or a source-specific name) when calling .add() / building
the output so each revenue/fee dimension includes a label, and add a matching
breakdownMethodology object inside the adapter (next to methodology) that
documents each exact label string you used; ensure the labels in
breakdownMethodology exactly match the label keys emitted by fetch and that you
update ProtocolRevenue/Revenue fields to reference the labeled breakdown
structure.
|
@akhil-onjuno thanks for the PR |
https://anoncoin.it/
Adds a fees/revenue adapter for Anoncoin (anoncoin.fun).
What it tracks: Partner trading fees (SOL) claimed by Anoncoin from Meteora DBC and DAMM V2 pools.
Approach: Uses
getSolanaReceivedto sum SOL transfers to the Anoncoin partner fee claimer wallet.BKPxAdgwPHXE3ZPZt5XsAovDgUaUufHgZnSAZ3eRWQNW