fix(chain-adapters): prevent UTXO sats/byte rounding to zero#12307
fix(chain-adapters): prevent UTXO sats/byte rounding to zero#12307kaladinlight merged 3 commits intodevelopfrom
Conversation
Math.round(satsPerKiloByte / 1000) collapses to 0 when network fees are below ~500 sats/kB (common for slow/average tiers in low-fee periods), producing an invalid 0 sat/byte rate that fails downstream validation. Switch to Math.ceil with a 1 sat/byte floor so sub-1000 sats/kB rates always yield a valid positive per-byte fee. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
Warning Rate limit exceeded
To keep reviews running without waiting, you can enable usage-based add-on for your organization. This allows additional reviews beyond the hourly cap. Account admins can enable it under billing. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (6)
✨ 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 |
Update getNetworkFeesMockedResponse from 1024 to 1000 sats/kB across BTC, BCH, LTC, and DOGE adapter tests so the canonical "1 sat/byte → 44 sat fee" expectation holds under the new Math.ceil + 1 sat/byte floor conversion in getFeeData. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Description
UTXO fee estimation converts
satsPerKiloByte(returned by unchained) into the per-byte rate that thecoinselectlibrary requires. The conversion usedMath.round(satsPerKiloByte / 1000), which collapses any rate below ~500 sats/kB to0.This is a real condition during low-fee periods. For example, a recent observation:
Math.round(291/1000) = 0andMath.round(302/1000) = 0, so slow/average tiers come back with a0per-byte rate. Downstream,buildSendApiTransactionrejects this viaif (!satoshiPerByte) throw new Error('satoshiPerByte is required'), breaking the lower-fee tiers entirely.Fix: use
Math.ceilwith a 1 sat/byte floor.Math.max(1, Math.ceil(x / 1000))guarantees a valid positive rate for any non-negative input, and rounding up biases slightly toward inclusion rather than under-paying.Applied at both UTXO conversion sites:
packages/chain-adapters/src/utxo/UtxoBaseAdapter.ts(BTC, BCH, LTC, ZEC)packages/chain-adapters/src/utxo/dogecoin/DogecoinChainAdapter.ts(DOGE)The Dogecoin adapter already had a
<=0guard with high default minimums, so it was less likely to trip in practice — but the same math issue applied for any small positive upstream value, and consistency matters.Issue (if applicable)
closes #
Risk
UTXO chains: BTC, BCH, LTC, ZEC, DOGE. Affects only
getFeeDataoutput (slow/average/fast per-byte rates and resultingtxFee). No change to signing or broadcasting paths.The output rate may now be slightly higher than before for the same upstream value (ceil vs round) — by at most ~0.5 sat/byte at the boundary — but this only matters when the upstream rate sits exactly on a half-byte boundary, which is rare.
Testing
Engineering
getNetworkFeesto return e.g.{ slow: 291, average: 302, fast: 2227 }); confirm slow/average/fast tiers all yield positivesatoshiPerByteand a validtxFee.Operations
Screenshots (if applicable)
n/a