Conversation
|
The pagcrypto adapter exports: |
📝 WalkthroughWalkthroughAdds a new PagCrypto SimpleAdapter implementing multi-chain revenue fetching (Solana, Base, Polygon, Tron, XRPL), with per-chain inflow strategies, wallet configuration validation, a prefetch that aggregates USD volumes, and a fetch that returns dailyFees/dailyRevenue/dailyProtocolRevenue. Changes
Sequence DiagramsequenceDiagram
participant App as Application
participant Adapter as PagCrypto SimpleAdapter
participant Prefetch as Prefetch
participant SQL as SQL Builders
participant Dune as Dune (query executor)
participant Fetch as Fetch Handler
participant Bal as Daily Balances
App->>Adapter: request data
Adapter->>Prefetch: run prefetch
Prefetch->>SQL: build per-chain queries (Solana, Base, Polygon, Tron, XRPL)
SQL-->>Prefetch: SQL statements
Prefetch->>Dune: execute UNION ALL aggregated query
Dune-->>Prefetch: USD volume results
Prefetch-->>Adapter: aggregated volumes
Adapter->>Fetch: invoke fetch (select chain strategy)
Fetch->>Bal: inject USD volume into daily balances
Bal-->>Fetch: confirm balances
Fetch-->>Adapter: return dailyFees/dailyRevenue/dailyProtocolRevenue
Adapter-->>App: deliver results
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Poem
🚥 Pre-merge checks | ✅ 1 | ❌ 2❌ Failed checks (1 warning, 1 inconclusive)
✅ Passed checks (1 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches
🧪 Generate unit tests (beta)
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 pagcrypto adapter exports: |
|
The pagcrypto adapter exports: |
There was a problem hiding this comment.
Actionable comments posted: 5
🤖 Fix all issues with AI agents
In `@fees/pagcrypto/index.ts`:
- Around line 192-199: The current buildXrplSql function returns a stubbed SQL
that always reports 0 volume; replace this with a fail-fast behavior so XRPL
cannot silently produce wrong data: change buildXrplSql to throw a clear Error
(or otherwise abort) with a message like "XRPL SQL not implemented" whenever
called, or ensure the caller excludes/enables XRPL only if a real implementation
exists; reference buildXrplSql to locate and update the stubbed implementation
so the system fails fast instead of returning zeroed results.
- Around line 98-114: WALLETS is declared as Record<ChainKey, string[]> but
populated with string values, causing .map failures in sqlList/buildEvmSql;
update WALLETS so each chain value is an array (e.g., wrap existing string
literals in arrays) or modify initialization to parse the
PAGCRYPTO_<CHAIN>_WALLETS env var into arrays, and keep assertWalletsConfigured
(and its use of WALLETS[k].length) intact; ensure callers like sqlList and
buildEvmSql receive arrays so .map works correctly and no runtime crash occurs.
- Around line 131-152: buildSolanaSql only queries SPL token transfers and
therefore omits native SOL volume; update buildSolanaSql (referencing the
function name, wallets, splMints, and enabledAssets usage) to include native SOL
transfers: add a query branch that selects native transfers (e.g., where
token_mint_address = 'native' or from the native transfer table used in your
Dune schema), convert lamports to USD using the appropriate price/amount_usd
column or join to a price table, and UNION (or SUM together) the native SOL
usd_in with SPL usd_in so volume_usd includes both; alternatively, if your
dataset can't support native SOL yet, detect enabledAssets('solana') includes
"native" and throw/return an error to fail fast and disable SOL until
implemented.
- Around line 156-173: buildEvmSql currently only sums ERC20 transfers
(erc20s/token_address) so any enabled native assets (address === "native" from
enabledAssets) are ignored; update buildEvmSql to handle natives by either
removing "native" from erc20s and adding a second SELECT (or UNION) that sums
native transfers (use the same time/window/blockchain/wallet filters but target
native transfer rows — e.g. token_address = 'native' or the DB’s native-transfer
indicator) or, if you prefer to disallow natives, filter them out earlier (in
enabledAssets or before building erc20s) so native assets are not considered
enabled. Ensure you reference buildEvmSql, enabledAssets, erc20s, token_address,
and the wallet filter (lower("to") IN ...) when making the change.
- Around line 179-188: The buildTronSql function currently returns a stub that
reports 0 while CONFIG.tron.status is true, causing misleading reports; either
implement the real Tron SQL using Tron transfer tables and pricing joins or fail
fast. Update buildTronSql (and any caller that relies on it) to detect
unimplemented state when CONFIG.tron.status === true and either throw a clear
error or return a non-enabled signal (e.g., disable reporting) instead of
returning zero; if you choose to implement, replace the stub with a proper Dune
SQL that joins Tron transfer tables to pricing data and apply the same contract
filtering pattern used for EVM wallets (reference WALLETS.tron for token list).
Ensure callers handle the thrown error or disabled flag so the adapter does not
publish a zero value.
🧹 Nitpick comments (2)
fees/pagcrypto/index.ts (2)
120-122: GuardsqlListagainst empty allowlists.
IN ()will produce invalid SQL if wallets/assets are empty. Consider a defensive fallback so the query returns no rows instead of failing.♻️ Suggested fix
function sqlList(items: string[]) { + if (!items.length) return "NULL"; return items.map((x) => `'${x}'`).join(", "); }
205-224: Handle the case where no chains are enabled.If all
CONFIG.*.statusare false, the CTE is invalid. Add a guard to return empty results.♻️ Suggested fix
const prefetch = async (options: FetchOptions) => { assertWalletsConfigured(); const queries: string[] = []; @@ - // union results from all enabled chains + if (!queries.length) return []; + // union results from all enabled chains const sql = `
|
The pagcrypto adapter exports: |
|
The pagcrypto adapter exports: |
|
The pagcrypto adapter exports: |
|
The pagcrypto adapter exports: |
|
The pagcrypto adapter exports: |
fees/pagcrypto/index.ts
Outdated
|
|
||
| const queries: string[] = []; | ||
|
|
||
| if (CONFIG.solana.status) queries.push(buildSolanaSql(options)); |
There was a problem hiding this comment.
can you use this token inflows helper where chain is supported?
dimension-adapters/helpers/token.ts
Lines 90 to 91 in f535176
you can use dune if chain is not supported, and please remove unnecessary comments and keep adapter file lean.
There was a problem hiding this comment.
Updated to use addTokensReceived for supported EVM chains (Base, Polygon) and removed Dune/SQL.
Solana/Tron/XRPL are excluded for now since the helper doesn’t reliably support them.
|
The pagcrypto adapter exports: |
|
The pagcrypto adapter exports: |
|
The pagcrypto 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):
PagCrypto
Twitter Link:
https://x.com/PagCryptoFi
List of audit links if any:
N/A
Website Link:
https://pagcrypto.finance
Logo (High resolution, will be shown with rounded borders):
https://media.pagcrypto.finance/shared/logos/logo.svg
Current TVL:
N/A (this PR adds a fees/revenue adapter, not a TVL adapter)
Treasury Addresses (if the protocol has treasury):
Treasury and fee-collector wallet addresses are configured in the adapter and tracked per chain (Solana, Base, Polygon, Tron, XRPL).
Chain:
Solana, Base, Polygon, Tron, XRPL
Coingecko ID (so your TVL can appear on Coingecko, leave empty if not listed):
pagcrypto
Coinmarketcap ID (so your TVL can appear on Coinmarketcap, leave empty if not listed):
N/A
Short Description (to be shown on DefiLlama):
PagCrypto is a crypto-to-fiat payments infrastructure that enables on-chain assets to be used for real-world payments through local payment rails such as PIX, with multi-chain support.
Token address and ticker if any:
N/A (protocol does not have a publicly traded governance token)
Category (full list at https://defillama.com/categories) *Please choose only one:
Payments
Oracle Provider(s): Specify the oracle(s) used (e.g., Chainlink, Band, API3, TWAP, etc.):
Pyth Network, Chainlink (asset pricing)
Implementation Details: Briefly describe how the oracle is integrated into your project:
Asset prices are obtained via on-chain and off-chain oracle feeds to determine fiat-equivalent values for crypto payments and settlement flows. Oracle prices are used for conversion, validation, and fee calculation, while final fee/revenue accounting is derived from on-chain settlement transfers.
Documentation/Proof: Provide links to documentation or any other resources that verify the oracle's usage:
https://docs.pagcrypto.finance
https://pyth.network
https://coingecko.com
forkedFrom (Does your project originate from another project):
No
methodology (what is being counted as tvl, how is tvl being calculated):
This PR does not track TVL.
The adapter tracks fees/revenue by summing the USD value of on-chain token transfers received by PagCrypto-controlled fee-collector and treasury wallets across supported chains, filtered by an allowlist of supported assets.
Data is sourced from Dune Analytics curated transfer tables.
Github org/user (Optional, if your code is open source, we can track activity):
https://github.com/pagcrypto
Does this project have a referral program?
Yes
Summary by CodeRabbit
✏️ Tip: You can customize this high-level summary in your review settings.