Skip to content

move quai fees to onchain#5765

Open
bheluga wants to merge 1 commit intoDefiLlama:masterfrom
bheluga:quai-fees
Open

move quai fees to onchain#5765
bheluga wants to merge 1 commit intoDefiLlama:masterfrom
bheluga:quai-fees

Conversation

@bheluga
Copy link
Member

@bheluga bheluga commented Jan 29, 2026

accidentally closed :#5615

Summary by CodeRabbit

  • Changes
    • Expanded mining reward tracking to include Raven, Litecoin, Bitcoin Cash, and Dogecoin alongside the Quai network.
    • Updated revenue metrics to clarify that reported fees represent amounts directed toward buyback and burn operations.

✏️ Tip: You can customize this high-level summary in your review settings.

@bheluga bheluga self-assigned this Jan 29, 2026
@coderabbitai
Copy link
Contributor

coderabbitai bot commented Jan 29, 2026

📝 Walkthrough

Walkthrough

The Quai network fees adapter is refactored to replace a single API-based daily revenue fetch with multiple chain-specific mining reward fetchers for Raven, Litecoin, Bitcoin Cash, and Dogecoin, plus separate burn-related balance handling. The protocolType field is removed from the adapter export.

Changes

Cohort / File(s) Summary
Mining Rewards & Burn Handler
fees/quai-network/index.ts
Replaced single Quai API revenue fetch with per-chain mining reward functions (getRavenMiningRewards, getLitecoinMiningRewards, getBchMiningRewards, getDogeMiningRewards, getQuaiBurnDetails). Reorganized fetch flow to accumulate per-chain rewards and apply burn-related adjustments. Removed protocolType field from adapter export. Updated methodology text.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Suggested labels

Refill

Poem

🐰 Hop, skip, and a refactor's delight!
Quai's fees now split into chains so bright,
Raven, Litecoin, and Dogecoin dance,
While burns are handled with careful stance. ⛓️✨

🚥 Pre-merge checks | ✅ 2 | ❌ 1
❌ Failed checks (1 warning)
Check name Status Explanation Resolution
Description check ⚠️ Warning The description only provides a reference to a related PR without explaining the changes or filling out template sections, making it insufficient for understanding the PR's purpose. Add a meaningful description explaining the changes made (replacing API-based revenue fetch with on-chain mining rewards), why this change was made, and any relevant testing or migration notes.
✅ Passed checks (2 passed)
Check name Status Explanation
Title check ✅ Passed The title 'move quai fees to onchain' clearly relates to the main change: refactoring Quai network fees from API-based to on-chain mining reward fetchers.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing touches
  • 📝 Generate docstrings

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.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

@llamabutler
Copy link

The quai-network adapter exports:

> adapters@1.0.0 test
> ts-node --transpile-only cli/testAdapter.ts fees quai-network

🦙 Running QUAI-NETWORK adapter 🦙
---------------------------------------------------
Start Date:	Wed, 28 Jan 2026 00:00:00 GMT
End Date:	Thu, 29 Jan 2026 00:00:00 GMT
---------------------------------------------------

QUAI 👇
Backfill start time: 17/12/2025
Daily fees: 43.42 k
Daily revenue: 51.46 k
Daily holders revenue: 51.46 k

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🤖 Fix all issues with AI agents
In `@fees/quai-network/index.ts`:
- Around line 43-46: The loop that sums coinbase payouts currently assumes the
mining payout is vout[0]/outputs[0]; update the logic in the response-processing
loops (the for...of over response that updates dailyLitecoinMined and the
similar block updating dailyBchMined) to iterate all outputs (vout or outputs)
and sum the value of any output whose address matches the miner address instead
of taking index 0; use the known target addresses
("ltc1qlg96gqruz4vu5w86z6rpqxt6ugqxrljxzpvcu8" for LTC and
"qqqea0a7ryny69sskvx857apy3r6wt6w35524nm4xw" for BCH) when comparing the
output.address/addresses fields, convert satoshi/atomic units to coins as done
elsewhere, and keep the existing block_time/time window checks and coinbase
detection (vin[0].is_coinbase) in place.

Comment on lines +43 to +46
for (const { txid, vin, vout, status } of response) {
if (vin && vin.length > 0 && vin[0].is_coinbase && status.block_time >= options.startTimestamp && status.block_time < options.endTimestamp) {
dailyLitecoinMined += (vout?.[0]?.value ?? 0) / 1e8;
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

🧩 Analysis chain

🏁 Script executed:

cat -n fees/quai-network/index.ts | head -100

Repository: DefiLlama/dimension-adapters

Length of output: 4656


🏁 Script executed:

wc -l fees/quai-network/index.ts

Repository: DefiLlama/dimension-adapters

Length of output: 102


🌐 Web query:

litecoinspace API coinbase transaction output structure vout

💡 Result:

LitecoinSpace’s REST API follows the Esplora transaction JSON shape. For any transaction (including a coinbase transaction), the response has a top-level vout array where each element is one output (index = its position in the array):

"vout": [
  {
    "scriptpubkey": "<hex>",
    "scriptpubkey_asm": "<asm>",
    "scriptpubkey_type": "<type>",
    "scriptpubkey_address": "<address-if-decodable>",
    "value": <integer>   // amount in the smallest unit (e.g., litoshis)
  }
]

This is the same structure returned by Esplora’s GET /tx/:txid endpoint. [1]

What’s special about a coinbase transaction is the input (vin), not the outputs: vin[0].is_coinbase is true, and the “previous outpoint” is represented as txid = all zeros and vout = 4294967295 (0xffffffff). [2]

Sources:
[1] Esplora GET /tx/:txid response fields (shows vout object fields).
[2] Example Esplora coinbase tx input showing is_coinbase: true, zero txid, and vout: 4294967295.


🌐 Web query:

haskoin-store BCH coinbase transaction outputs address field documentation

💡 Result:

In haskoin-store (including BCH mode), a transaction’s outputs are serialized as StoreOutput, whose address field is optional:

  • StoreOutput { value :: Word64, script :: ByteString, spender :: Maybe Spender, address :: Maybe Address } — i.e. JSON address can be null when the output script can’t be decoded into a single standard Address. [1]

This applies equally to coinbase transactions: the first transaction in a block is a coinbase tx (miner-created), and its outputs may use script forms that don’t map cleanly to a standard address representation, so outputs[i].address may legitimately be null. [2]

Sources:
[1] Haskoin.Store.Data (StoreOutput definition / address :: Maybe Address) (hackage.haskell.org)
[2] Haskoin protocol docs on coinbase transactions (concept/definition) (hackage.haskell.org)

Citations:


Filter outputs by target address instead of assuming the reward is in the first output.

Lines 45 and 67 only count vout[0] and outputs[0]. While the API calls are address-specific, coinbase transactions can have multiple outputs, and there is no guarantee the payout to the mining address is the first output. Iterate through all outputs and sum those where the address field matches the target address (ltc1qlg96gqruz4vu5w86z6rpqxt6ugqxrljxzpvcu8 for LTC and qqqea0a7ryny69sskvx857apy3r6wt6w35524nm4xw for BCH) instead of assuming position 0.

Also applies to: lines 65-68

🤖 Prompt for AI Agents
In `@fees/quai-network/index.ts` around lines 43 - 46, The loop that sums coinbase
payouts currently assumes the mining payout is vout[0]/outputs[0]; update the
logic in the response-processing loops (the for...of over response that updates
dailyLitecoinMined and the similar block updating dailyBchMined) to iterate all
outputs (vout or outputs) and sum the value of any output whose address matches
the miner address instead of taking index 0; use the known target addresses
("ltc1qlg96gqruz4vu5w86z6rpqxt6ugqxrljxzpvcu8" for LTC and
"qqqea0a7ryny69sskvx857apy3r6wt6w35524nm4xw" for BCH) when comparing the
output.address/addresses fields, convert satoshi/atomic units to coins as done
elsewhere, and keep the existing block_time/time window checks and coinbase
detection (vin[0].is_coinbase) in place.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants