fix(kasu): correct fees magnitude, multi-deployment per chain, add XDC USDC pool#6399
Merged
bheluga merged 14 commits intoDefiLlama:masterfrom Apr 16, 2026
Merged
Conversation
Track performance fees from Kasu lending pools via FeeManager FeesEmitted events. Reports daily fees, protocol revenue, and holder revenue (ecosystem fees to KSU lockers). Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
…mVariables on-chain Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
- dailyFees now reports the actual performance fee collected (totalFee),
not the back-calculated gross interest. Previous calc inflated Base
fees ~10x (e.g. $42k/day vs the real ~$4k).
- Refactor per-chain config to an array of {feeManager, systemVariables,
paymentToken} so a single chain can host multiple deployments.
- Add second XDC deployment (USDC pool) alongside the AUDD one.
- Fix XDC AUDD pool token: was incorrectly USDC.e, now real AUDD address.
…apter # Conflicts: # fees/kasu.ts
Contributor
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
WalkthroughReplaced per-chain single fee/source configuration with per-chain Changes
Sequence Diagram(s)sequenceDiagram
participant Adapter as Adapter
participant RPC as Blockchain RPC
participant Factory as LendingPoolFactory
participant Pool as LendingPool
participant SysVars as SystemVariables
participant Token as PaymentToken
Adapter->>RPC: load DEPLOYMENTS for chain
loop per deployment
Adapter->>Factory: query past `PoolCreated` logs (from factoryStartBlock)
Factory-->>Adapter: list of Pool addresses
loop per pool
Adapter->>Pool: query `FeesOwedIncreased` logs (lookback window)
Pool-->>Adapter: FeesOwedIncreased events
Adapter->>SysVars: resolve `PerformanceFeeUpdated` / `FeeRatesUpdated` at event blocks
SysVars-->>Adapter: per-epoch fee params
Adapter->>Adapter: prorate fees by time overlap, compute splits (protocol/holders/token-locker/supply-side)
Adapter->>Token: attribute token balances per split
end
end
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Possibly related PRs
Suggested labels
🚥 Pre-merge checks | ✅ 5 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (5 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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
fees/kasu.ts (1)
94-99:⚠️ Potential issue | 🔴 CriticalReturn the dedicated
dailyProtocolRevenueaccumulator.Line 88 correctly records only
protocolFeeintodailyProtocolRevenue, but the return object aliasesdailyRevenueinstead. That overstates protocol revenue by the rKSU-holder distribution.One-line fix
- dailyProtocolRevenue: dailyRevenue, + dailyProtocolRevenue,🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@fees/kasu.ts` around lines 94 - 99, The return object in the function (in fees/kasu.ts) incorrectly aliases dailyProtocolRevenue to dailyRevenue; update the returned object so the dailyProtocolRevenue property returns the accumulator variable dailyProtocolRevenue (not dailyRevenue), leaving dailyFees, dailyUserFees, dailyRevenue and dailyHoldersRevenue unchanged so the protocol-only fee is reported correctly.
🤖 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/kasu.ts`:
- Around line 86-90: The revenue split labels are too generic—update all
invocations of dailyRevenue.add, dailyProtocolRevenue.add,
dailyHoldersRevenue.add and dailySupplySideRevenue.add to use explicit
source→destination labels (e.g. "Performance Fees To Protocol", "Performance
Fees To rKSU Holders"), use distribution-type labels for holder buckets (e.g.
"Token Locker Distributions"), and source→destination for supply-side (e.g.
"Borrow Interest To Lenders"); then update the corresponding entries in
breakdownMethodology so the exact same labels are used for each bucket (ensure
the protocol-only accumulator still returns the dedicated protocol label).
Ensure every occurrence mentioned in the diff blocks (the revenue,
protocolRevenue, holdersRevenue and supplySideRevenue adds and their matching
breakdownMethodology entries) is renamed accordingly and no generic labels like
"Ecosystem fees" or "Fees" remain.
- Around line 81-90: The code currently records only the captured performance
fee into dailyFees (and dailyUserFees), omitting the lender share (supplySide)
so gross protocol revenue is understated; update the calls that add to dailyFees
and dailyUserFees to use the gross borrower-interest amount (totalFee +
supplySide) instead of totalFee alone, keeping dailySupplySideRevenue as
supplySide and leaving dailyRevenue calculations unchanged so the invariant
dailyRevenue = dailyFees - dailySupplySideRevenue holds; apply the same change
to the similar block around the dailyFees/dailyUserFees updates referenced in
lines 96-106.
---
Outside diff comments:
In `@fees/kasu.ts`:
- Around line 94-99: The return object in the function (in fees/kasu.ts)
incorrectly aliases dailyProtocolRevenue to dailyRevenue; update the returned
object so the dailyProtocolRevenue property returns the accumulator variable
dailyProtocolRevenue (not dailyRevenue), leaving dailyFees, dailyUserFees,
dailyRevenue and dailyHoldersRevenue unchanged so the protocol-only fee is
reported correctly.
🪄 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: 86b4530a-c315-4d5a-be05-16a916685adc
📒 Files selected for processing (1)
fees/kasu.ts
Comment on lines
+86
to
+90
| dailyRevenue.add(paymentToken, protocolFee, METRIC.PERFORMANCE_FEES); | ||
| dailyRevenue.add(paymentToken, ecosystemFee, "Ecosystem fees"); | ||
| dailyProtocolRevenue.add(paymentToken, protocolFee, METRIC.PERFORMANCE_FEES); | ||
| dailyHoldersRevenue.add(paymentToken, ecosystemFee, "Ecosystem fees"); | ||
| dailySupplySideRevenue.add(paymentToken, supplySide, METRIC.BORROW_INTEREST); |
Contributor
There was a problem hiding this comment.
🛠️ Refactor suggestion | 🟠 Major
Make the split labels and methodology destination-specific.
dailyRevenue includes both the protocol-receiver leg and the rKSU-holder leg, but methodology.Revenue still describes protocol-only revenue and "Ecosystem fees" is too generic. Once Line 98 returns the dedicated protocol accumulator, ProtocolRevenue: Same as Revenue will also stop being true. Please rename the split buckets explicitly—e.g. Performance Fees To Protocol / Performance Fees To rKSU Holders for revenue, Borrow Interest To Lenders for supply side, and Token Locker Distributions for holders—and mirror those exact labels in breakdownMethodology.
As per coding guidelines, use source and destination labels for dailyRevenue/dailySupplySideRevenue, use distribution type labels for dailyHoldersRevenue, and avoid generic labels like Fees or Other.
Also applies to: 107-110, 131-147
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@fees/kasu.ts` around lines 86 - 90, The revenue split labels are too
generic—update all invocations of dailyRevenue.add, dailyProtocolRevenue.add,
dailyHoldersRevenue.add and dailySupplySideRevenue.add to use explicit
source→destination labels (e.g. "Performance Fees To Protocol", "Performance
Fees To rKSU Holders"), use distribution-type labels for holder buckets (e.g.
"Token Locker Distributions"), and source→destination for supply-side (e.g.
"Borrow Interest To Lenders"); then update the corresponding entries in
breakdownMethodology so the exact same labels are used for each bucket (ensure
the protocol-only accumulator still returns the dedicated protocol label).
Ensure every occurrence mentioned in the diff blocks (the revenue,
protocolRevenue, holdersRevenue and supplySideRevenue adds and their matching
breakdownMethodology entries) is renamed accordingly and no generic labels like
"Ecosystem fees" or "Fees" remain.
|
The kasu.ts adapter exports: |
…plit labels - dailyFees = gross borrower interest (totalFee + supplySide) per DefiLlama convention, so dailyRevenue = dailyFees - dailySupplySideRevenue. - Return dedicated dailyProtocolRevenue accumulator instead of aliasing to dailyRevenue; methodology entries now truly distinct. - Rename generic bucket labels to explicit source→destination labels: "Performance Fees To Protocol", "Performance Fees To rKSU Holders", "Borrow Interest To Lenders", "Token Locker Distributions". - Mirror the new labels in breakdownMethodology and methodology docstrings.
Contributor
There was a problem hiding this comment.
♻️ Duplicate comments (1)
fees/kasu.ts (1)
86-95:⚠️ Potential issue | 🟠 MajorRecord gross borrower interest in
dailyFees/dailyUserFees.Line 90 only books the captured performance fee, while Lines 91-95 also book the lender leg separately. That leaves
dailyFees/dailyUserFeessmaller thandailyRevenue + dailySupplySideRevenue, so this adapter no longer follows the repo’s required income-statement mapping. UsegrossInterest = totalFee + supplySidefor the fee buckets, and update theFeesmethodology/breakdown to a borrow-interest label.Suggested fix
- dailyFees.add(paymentToken, totalFee, METRIC.PERFORMANCE_FEES); + const grossInterest = totalFee + supplySide; + dailyFees.add(paymentToken, grossInterest, METRIC.BORROW_INTEREST);- Fees: "Performance fees collected by the protocol from lending pool interest accruals (a percentage of gross borrower interest).", + Fees: "Gross borrower interest accrued by the lending pools before the lender/protocol split.", UserFees: "Same as Fees.",Fees: { - [METRIC.PERFORMANCE_FEES]: "Performance fees collected by the protocol from borrower interest", + [METRIC.BORROW_INTEREST]: "Gross borrower interest accrued before the lender/protocol split", },As per coding guidelines, "
dailyFeesdimension in fees adapters - maps to Gross Protocol Revenue and should include all fees from all sources" and "dailyRevenuedimension in fees adapters - maps to Gross Profit and should equaldailyFees - dailySupplySideRevenue(what protocol keeps)".Also applies to: 99-102, 109-115, 136-139
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@fees/kasu.ts` around lines 86 - 95, The fee recording currently adds only the captured performance fee to dailyFees/dailyUserFees, causing dailyFees to be smaller than dailyRevenue + dailySupplySideRevenue; compute grossInterest = totalFee + supplySide (where supplySide is computed from performanceFee, totalFee) and use grossInterest when calling dailyFees.add (and dailyUserFees.add if present) so that dailyFees maps to Gross Protocol Revenue, while keeping dailyRevenue.add(paymentToken, protocolFee, ...) and dailySupplySideRevenue.add(paymentToken, supplySide, ...) unchanged; also update the Fees methodology/breakdown label to "borrow-interest" to reflect the gross borrower interest mapping.
🤖 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/kasu.ts`:
- Around line 86-95: The fee recording currently adds only the captured
performance fee to dailyFees/dailyUserFees, causing dailyFees to be smaller than
dailyRevenue + dailySupplySideRevenue; compute grossInterest = totalFee +
supplySide (where supplySide is computed from performanceFee, totalFee) and use
grossInterest when calling dailyFees.add (and dailyUserFees.add if present) so
that dailyFees maps to Gross Protocol Revenue, while keeping
dailyRevenue.add(paymentToken, protocolFee, ...) and
dailySupplySideRevenue.add(paymentToken, supplySide, ...) unchanged; also update
the Fees methodology/breakdown label to "borrow-interest" to reflect the gross
borrower interest mapping.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: 7ccb9bef-25dd-48c0-9d22-0f54c32f0709
📒 Files selected for processing (1)
fees/kasu.ts
|
The kasu.ts adapter exports: |
1 similar comment
|
The kasu.ts adapter exports: |
Contributor
Author
|
Quick note on the CI bot output showing all-zero slices:
Running the adapter locally against a window that includes a real event (e.g. which matches on-chain reality. Happy to remove |
bheluga
reviewed
Apr 15, 2026
Member
bheluga
left a comment
bheluga
left a comment
There was a problem hiding this comment.
@kivanov82 thanks for the PR.
We do consider interests under fees.
so fees = revenue + supplySideRevenue.
You can refer https://docs.llama.fi/list-your-project/other-dashboards and https://docs.llama.fi/analysts/data-definitions for more information
Per maintainer feedback: "We do consider interests under fees, so fees = revenue + supplySideRevenue." Restores invariant dailyFees == dailyRevenue + dailySupplySideRevenue and switches the Fees breakdown label to METRIC.BORROW_INTEREST.
Contributor
Author
|
Thanks @bheluga — updated. |
Contributor
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/kasu.ts`:
- Around line 68-88: The code currently reads a single current performanceFee
into the variable performanceFee and reuses it for all FeesEmittedEvent logs;
update the logic in the logs processing loop (the for (const log of logs) block
that computes supplySide/grossInterest) to fetch the performance fee at each
log's block instead of the one-time lookup: for each log, call options.api.call
(or query fee-change events) with the log.blockNumber/blockTag to retrieve the
historical performanceFee (the same ABI 'uint256:performanceFee' used
originally) and use that per-log value when computing supplySide and
grossInterest; alternatively, prefetch and apply fee-change events to map block
ranges to fees and pick the correct fee for each log.
🪄 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: d1e67865-4c28-4c4f-b4dc-05061cc27d06
📒 Files selected for processing (1)
fees/kasu.ts
|
The kasu.ts adapter exports: |
…h spread Switches the fee source from FeeManager.FeesEmitted (borrower-repayment-driven, irregular) to LendingPool.FeesOwedIncreased (emitted per epoch at clearing). Pools are discovered via PoolCreated on the LendingPoolFactory with cacheInCloud; events are fetched from block(fromTimestamp - 3 epochs) to handle clearing delays. Each event's feesAmount is spread evenly across its epoch (1 week) and only the overlap with the adapter's fetch window is attributed. Resolves the DefiLlama annualization issue where a single weekly settlement spike inflated the 365x extrapolation. Daily values are now smooth and the annualized number reflects actual protocol economics. Also splits the performance fee into protocol vs ecosystem legs using SystemVariables.feeRates() instead of relying on FeeManager's post-hoc split (which does not exist in FeesOwedIncreased).
Contributor
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/kasu.ts`:
- Around line 141-145: The current split (ecosystemFee = allocatedFee *
ecosystemFeeRate / FULL_PERCENT; protocolFee = allocatedFee - ecosystemFee) can
misattribute revenue when no rKSU is eligible and FeeManager redirects ecosystem
fees to protocol; update the logic in fees/kasu.ts around
ecosystemFee/protocolFee to detect Kasu's on-chain rKSU-eligibility indicator or
FeeManager redirection event (use the contract call or event log available in
your adapter) and, when redirection is active, set ecosystemFee = 0 and
protocolFee = allocatedFee, otherwise keep the existing split based on
feeRates(); if no reliable on-chain signal exists, add a clear comment and
update the adapter’s documentation/metrics code that dailyHoldersRevenue and
dailyProtocolRevenue may be skewed in epochs where redirection occurs.
- Line 178: The current human-readable description for the Revenue entry is
misleading: update the Revenue string (the descriptive text assigned alongside
the Revenue key) to explicitly state that dailyRevenue includes both the
protocol-receiver share and the rKSU-holder share (i.e., performance fees
retained by the protocol AND rKSU holders), and ensure any mentions of
dailyRevenue elsewhere in fees/kasu.ts use the same clarified wording so the
description matches the actual calculation in dailyRevenue.
🪄 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: 411924b4-098f-4c85-aa31-38fdd07a7410
📒 Files selected for processing (1)
fees/kasu.ts
Comment on lines
+141
to
+145
| // Split performance fee into ecosystem / protocol per SystemVariables.feeRates(). | ||
| // Note: FeeManager redirects ecosystem fees to the protocol when no rKSU is | ||
| // eligible. That edge-case is not reflected here. | ||
| const ecosystemFee = allocatedFee * ecosystemFeeRate / FULL_PERCENT; | ||
| const protocolFee = allocatedFee - ecosystemFee; |
Contributor
There was a problem hiding this comment.
Ecosystem fee edge-case can misattribute revenue.
The comment on lines 142-143 acknowledges that when no rKSU is eligible, the FeeManager redirects ecosystem fees to the protocol. However, this adapter always splits based on the static feeRates(), so on those epochs dailyHoldersRevenue will be overstated and dailyProtocolRevenue understated.
If Kasu has an on-chain indicator for rKSU eligibility or if this redirection is logged separately, consider conditionally adjusting the split. Otherwise, document this known discrepancy in the methodology.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@fees/kasu.ts` around lines 141 - 145, The current split (ecosystemFee =
allocatedFee * ecosystemFeeRate / FULL_PERCENT; protocolFee = allocatedFee -
ecosystemFee) can misattribute revenue when no rKSU is eligible and FeeManager
redirects ecosystem fees to protocol; update the logic in fees/kasu.ts around
ecosystemFee/protocolFee to detect Kasu's on-chain rKSU-eligibility indicator or
FeeManager redirection event (use the contract call or event log available in
your adapter) and, when redirection is active, set ecosystemFee = 0 and
protocolFee = allocatedFee, otherwise keep the existing split based on
feeRates(); if no reliable on-chain signal exists, add a clear comment and
update the adapter’s documentation/metrics code that dailyHoldersRevenue and
dailyProtocolRevenue may be skewed in epochs where redirection occurs.
|
The kasu.ts adapter exports: |
- Read performanceFee and feeRates at each log's blockNumber via cached PerformanceFeeUpdated / FeeRatesUpdated event histories, so backfills with rate changes are priced correctly. - Revenue methodology: clarify that dailyRevenue includes both protocol and rKSU-holder shares (neither paid to external suppliers). - HoldersRevenue methodology: document that FeeManager's runtime redirection when no rKSU is eligible is not reflected in the split.
Contributor
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/kasu.ts`:
- Around line 123-125: The FeesOwedIncreased discovery window is being capped to
options.toApi.block (see the toBlock variable and the getBlock call that sets
lookbackFromBlock), which causes backfills inside an epoch to miss later
settlement logs; change the search horizon used by the FeesOwedIncreased query
to extend past options.toApi.block to the end of the settlement horizon plus the
existing delay buffer (i.e., compute an extendedToBlock using the settlement end
+ delay and use that for event discovery), but keep using the existing
epoch-overlap logic to attribute and slice results to the originally requested
from/to window so only the requested slice is returned. Ensure references to
FeesOwedIncreased, lookbackFromBlock, toBlock/getBlock, and the epoch
attribution logic are updated to use extendedToBlock for discovery while leaving
attribution unchanged.
- Around line 126-159: Seed the perfFeeHistory and ecosystemRateHistory with a
snapshot at the start of the queried range instead of using today's values as
the fallback: call options.api.call for performanceFee and feeRates with
blockTag set to lookbackFromBlock (or factoryStartBlock) to obtain the
start-of-range values, prepend { blockNumber: Number(lookbackFromBlock), value:
BigInt(...) } to perfFeeHistory and ecosystemRateHistory respectively, and keep
currentPerformanceFee/currentEcosystemRate only as an end-of-range snapshot used
when computing rateAtBlock for blocks >= toBlock.
🪄 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: 15c7e52e-d156-471e-9507-04ddd30b96f0
📒 Files selected for processing (1)
fees/kasu.ts
Comment on lines
+126
to
+159
| const [currentPerformanceFee, currentFeeRates, perfFeeUpdateLogs, feeRatesUpdateLogs] = await Promise.all([ | ||
| options.api.call({ | ||
| target: systemVariables, | ||
| abi: 'uint256:performanceFee', | ||
| }).then(BigInt), | ||
| options.api.call({ | ||
| target: systemVariables, | ||
| abi: 'function feeRates() view returns (uint256 ecosystemFeeRate, uint256 protocolFeeRate)', | ||
| }), | ||
| options.getLogs({ | ||
| target: systemVariables, | ||
| eventAbi: PerformanceFeeUpdatedEvent, | ||
| fromBlock: factoryStartBlock, | ||
| toBlock, | ||
| cacheInCloud: true, | ||
| }), | ||
| options.getLogs({ | ||
| target: systemVariables, | ||
| eventAbi: FeeRatesUpdatedEvent, | ||
| fromBlock: factoryStartBlock, | ||
| toBlock, | ||
| cacheInCloud: true, | ||
| }), | ||
| ]); | ||
|
|
||
| const perfFeeHistory = perfFeeUpdateLogs | ||
| .map((log: any) => ({ blockNumber: Number(log.blockNumber), value: BigInt(log.performanceFee) })) | ||
| .sort((a: any, b: any) => a.blockNumber - b.blockNumber); | ||
| const ecosystemRateHistory = feeRatesUpdateLogs | ||
| .map((log: any) => ({ blockNumber: Number(log.blockNumber), value: BigInt(log.ecosystemFeeRate) })) | ||
| .sort((a: any, b: any) => a.blockNumber - b.blockNumber); | ||
|
|
||
| const currentEcosystemRate = BigInt(currentFeeRates.ecosystemFeeRate ?? currentFeeRates[0]); | ||
|
|
Contributor
There was a problem hiding this comment.
Seed the rate history with the state at the start of the queried range.
Using currentPerformanceFee / current feeRates() as the rateAtBlock() fallback misprices any FeesOwedIncreased log that lands before the first update event in perfFeeUpdateLogs or feeRatesUpdateLogs. Those older logs should inherit the rate active at lookbackFromBlock (or factoryStartBlock), not today’s value. Prepend a snapshot from the start of the queried range and treat the current reads as an end-of-range convenience only.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@fees/kasu.ts` around lines 126 - 159, Seed the perfFeeHistory and
ecosystemRateHistory with a snapshot at the start of the queried range instead
of using today's values as the fallback: call options.api.call for
performanceFee and feeRates with blockTag set to lookbackFromBlock (or
factoryStartBlock) to obtain the start-of-range values, prepend { blockNumber:
Number(lookbackFromBlock), value: BigInt(...) } to perfFeeHistory and
ecosystemRateHistory respectively, and keep
currentPerformanceFee/currentEcosystemRate only as an end-of-range snapshot used
when computing rateAtBlock for blocks >= toBlock.
|
The kasu.ts adapter exports: |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
dailyFeesnow reports the actual performance fee captured on-chain (ecosystemFee + protocolFee) rather than the back-calculated gross interest. Previously Base was reporting ~$42k/day vs the real ~$4k.Record<chain, Deployment[]>({feeManager, systemVariables, paymentToken}).0x9fe4e632...). AUDD is the Australian dollar stablecoin (~$0.66), so the prior config was mispricing XDC fee values.dailySupplySideRevenue(lender share of gross interest, back-calculated from on-chainperformanceFee).breakdownMethodology.Test plan
npx tsx adapters-tools/cli/runAdapter.ts fees/kasu.tsruns cleanly across Base / Plume / XDCdailyFeesaligns withdailyRevenue(Kasu remits 100% of performance fees to protocol+ecosystem)