Conversation
📝 WalkthroughWalkthroughThe 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 Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Suggested labels
Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches
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 quai-network adapter exports: |
There was a problem hiding this comment.
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.
| 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; | ||
| } |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
cat -n fees/quai-network/index.ts | head -100Repository: DefiLlama/dimension-adapters
Length of output: 4656
🏁 Script executed:
wc -l fees/quai-network/index.tsRepository: 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. JSONaddresscan benullwhen the output script can’t be decoded into a single standardAddress. [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:
- 1: https://hackage.haskell.org/package/haskoin-store-data-1.0.1/docs/Haskoin-Store-Data.html
- 2: https://hackage.haskell.org/package/haskoin/docs/Network-Haskoin-Protocol.html?utm_source=openai
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.
accidentally closed :#5615
Summary by CodeRabbit
✏️ Tip: You can customize this high-level summary in your review settings.