fix(swap-verification): stop inflating MAYAChain CACAO amounts 100x - #55
Conversation
Midgard normalizes every coin to 1e8 — except MAYAChain's native CACAO,
which it reports at its own 1e10 precision ("CACAO is the only asset
which is expressed in 1e10 format",
https://docs.mayaprotocol.com/mayachain-dev-docs/concepts/memo-length-reduction).
`thorchainToNativePrecision` shifted every amount by (nativePrecision - 8),
so CACAO legs came back 100x too large.
Replaced with `midgardToNativePrecision`, which takes the coin so it can
skip the shift for MAYA.CACAO. Non-native assets are unaffected (ETH at
1e8 -> 1e18 still shifts), and THORChain is unaffected because RUNE's
native precision is already 8. `THORCHAIN_PRECISION` is renamed
`MIDGARD_PRECISION` to match what it actually describes.
This completes #53, which applied the same correction to the affiliate
fee line but left `verifiedSellAmountCryptoBaseUnit` and
`actualBuyAmountCryptoBaseUnit` converting as before.
Verified against mainnet action 8F9B6692…530D: the swap's two sides only
balance under the 1e10 reading — $4,616 in against $4,571 out (1% to
fees), versus $461,641 in under the old conversion.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (3)
Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review. 📝 WalkthroughWalkthroughThe change replaces Thorchain-specific amount conversion with Midgard coin-aware conversion. It preserves native CACAO precision during sell and buy verification and adds MAYAChain tests for the behavior. ChangesMidgard precision verification
Estimated code review effort: 2 (Simple) | ~10 minutes Merge Risk: ⚪ Minimal · up to The change corrects CACAO amount normalization to prevent 100× inflation in swap verification without changing existing stored data or payout output; no actionable merge-blocking risk remains beyond normal checks. Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
Full details: Docstring CoverageExplanation No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 3 files. ✨ Finishing Touches📝 Generate docstrings
🧪 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 |
1 participant
Description
Follow-up to #53. That PR established that MAYAChain Midgard reports native CACAO in 1e10, unlike pool/external assets normalized to 1e8 (Maya docs: "CACAO is the only asset which is expressed in 1e10 format"), and corrected the affiliate
feeOutamount to be stored raw.The same assumption was still live on the other two amounts in
verifyMidgardSwap.thorchainToNativePrecisionshifts by(nativePrecision - 8), so a CACAO sell leg inflatedverifiedSellAmountCryptoBaseUnit100×, and a CACAO buy leg did the same toactualBuyAmountCryptoBaseUnit. The sell leg feedsvolumeUsdand the bps-implied fee incalculateFeeForSwap, so affiliate volume for any CACAO-sell swap was overstated 100×.#53 reasoned that the affiliate fee is always the chain's native asset, which happens to be true but is incidental — the docs claim is broader: CACAO is 1e10 wherever it appears.
midgardToNativePrecisiontherefore keys on the coin's asset rather than on which field it is, skipping the shift forMAYA.CACAOonly.THORCHAIN_PRECISION→MIDGARD_PRECISION, since it describes Midgard's normalization rather than THORChain's. Internal, no other callers.Testing
yarn test— 64/64 pass.Two new cases in
mayachain.test.ts, one per leg, using amounts taken verbatim from mainnet actions8F9B6692…530D(CACAO → ETH.USDT) andDA174E41…A57(BTC → CACAO). Both failed at exactly 100× before the change (24157000000000000vs241570000000000) and pass after.Confirmed independently of #53's evidence:
8F9B6692…530Dthe swap's two sides only balance under the 1e10 reading — $4,616 in against $4,571 out, ~1% to fees, versus $461,641 in under the old conversion.revenue-dashboard's Maya tracker divides CACAO by 1e10 in a separate codebase.Checked for double-correction: no consumer of
verifiedSellAmountCryptoBaseUnitoractualBuyAmountCryptoBaseUnitcompensates for the inflation — includingcalculatePartnerFeeAmountUsdin public-api, which derives volume from the buy side.Note for whoever deploys
This is forward-only and does not touch existing data.
getPendingVerificationSwapsrequiresverificationStatus: PENDINGandstatus IN (SUCCESS, FAILED); no row in prod currently matches, so nothing is re-verified on deploy. Stored values stay as they are, payout script output is unchanged, and dashboard figures do not move.For context rather than as a blocker: all 270 CACAO-leg rows currently in prod belong to a single partner code under investigation for forged attribution, and 188 of them are held back by the payout script's deviation guard purely because this bug made implied and actual fees diverge 99%. If a re-verification backfill is run later, most of those stop being anomalies — re-running
aggregateByPartnerwith corrected values gives anomalies 188 → 48 and that partner's payable total $107,614.65 → $110,159.91. That is a reason to quarantine those rows before any backfill, not before this merge.🤖 Generated with Claude Code
Summary by CodeRabbit