AquaBank

Protocol fees adapter for AquaBank, a yield-bearing stablecoin protocol on Avalanche with revenue distribution tracking.

Chain: Avalanche
Type: Protocol-level fees
Start date: 2025-08-28
Approach: Wallet transfer tracking with on-chain verification

Status

Status: Merged (after verification and refactor)

PR: #5414

Merged: January 5, 2026

Commits: 3 (Initial → Verification → Refactor)

1. Background story

a. The protocol

AquaBank is a yield-bearing stablecoin protocol on Avalanche that distributes fees across multiple wallets:

10% buyback (CORAL token) → holders revenue
5% liquidity → protocol revenue
0.2% exit fee (USDT) → protocol revenue
85% to depositors → supply side revenue (calculated)

b. The challenge

The fee distribution model is documented, but the exact wallet addresses aren’t explicitly listed in the official documentation. They exist only in on-chain transaction data.

2. Initial implementation

a. My original code

I tracked the three revenue streams by monitoring token transfers to designated wallets:

const buybackWallet = "0xa6fbc057..."; // 10% CORAL buyback
const liquidityWallet = "0x87e21a66..."; // 5% liquidity
const exitFeeWallet = "0xd9e464f0..."; // 0.2% exit fee (USDT)

The adapter tracked transfers to these addresses for three wrapped assets (bUSDT, bUSDC, bAUSD) and calculated daily metrics.

b. What I thought

I assumed tracking the 15% protocol retention (10% + 5% + 0.2%) was sufficient, and the reviewer could verify the wallet addresses from the codebase itself.

3. The problem

a. Reviewer’s question

bheluga asked about wallet address verification:

line 13-16: I couldn’t really find these addresses in the link, can you provide the exact source

Code references alone weren’t enough. The reviewer wanted explicit documentation links.

b. My response

I provided on-chain verification through Snowtrace transaction links:

Wallet addresses and usage:

0xa6fbc057… (10% buyback → dailyHoldersRevenue)

0x87e21a66… (5% liquidity → dailyProtocolRevenue)

0xd9e464f0… (0.2% exit fee USDT → dailyProtocolRevenue)

All transactions consistently follow the documented 10% : 5% (2:1) split.

Exact source is on-chain transaction data. I verified the addresses via direct tx analysis. They aren’t listed explicitly on the docs page.

a. Separating revenue streams

The reviewer requested tracking the buyback separately:

line 31-34: Can you track buyback part as dailyHoldersRevenue

I refactored to separate:

dailyHoldersRevenue → 10% CORAL buyback
dailyProtocolRevenue → 5% liquidity + 0.2% exit fee

b. Supply side calculation

Since the protocol retains 15% (10% + 5% + 0.2%) and distributes 85% to depositors, I added:

dailySupplySideRevenue = (dailyProtocolRevenue * 85) / 15

This derives the supply-side revenue from the tracked 15% protocol fees.

c. Reviewer’s final correction

bheluga corrected the supply side calculation logic to exclude exit fees from that metric, so it accurately represents depositor yields.

5. Final result

a. Test output

> [email protected] test
> ts-node --transpile-only cli/testAdapter.ts fees aquabank.ts

🦙 Running AQUABANK.TS adapter 🦙
---------------------------------------------------
Start Date:	Sun, 04 Jan 2026 11:47:42 GMT
End Date:	Mon, 05 Jan 2026 11:47:42 GMT
---------------------------------------------------

[... AVAX indexer missing, fallback to logs. ...]
AVAX 👇
Backfill start time: 28/8/2025
Daily fees: 105.00
Daily revenue: 104.00
Daily holders revenue: 0.00
Daily protocol revenue: 104.00
Daily supply side revenue: 1.00
End timestamp: 1767613661 (2026-01-05T11:47:41.000Z)

b. What changed

Before:

All fees lumped together
No holders revenue separation
No supply side calculation

After:

Separated buyback as holdersRevenue
Calculated supplySideRevenue from protocol fees
Corrected exit fee handling in supply side logic

6. Key learnings

a. Technical

On-chain verification is valid: When documentation doesn’t list exact addresses, transaction data is an acceptable source of truth.
Revenue stream separation: DefiLlama expects clear categorization:
- holdersRevenue → token buybacks/burns that benefit holders
- protocolRevenue → retained by protocol (treasury, liquidity)
- supplySideRevenue → distributed to depositors/LPs
Calculated metrics: You can derive metrics mathematically when direct tracking isn’t feasible (e.g., calculating 85% supply side from 15% protocol retention).

b. Process

Provide evidence upfront: When using non-standard sources (on-chain data), include verification links in PR description or code comments.
Be explicit about methodology: If addresses come from tx analysis rather than docs, state it clearly.
Reviewers know the edge cases: bheluga caught the exit fee issue in supply side calculation. Trust reviewer expertise for protocol-specific nuances.