Skip to content

feat/fix: Payment Token Decimal Compatibility and Test Suite Reliability#241

Merged
thlpkee20-wq merged 2 commits intoRevoraOrg:masterfrom
lycantho:feature/contracts-035-payment-token-decimal-compatibility
Apr 1, 2026
Merged

feat/fix: Payment Token Decimal Compatibility and Test Suite Reliability#241
thlpkee20-wq merged 2 commits intoRevoraOrg:masterfrom
lycantho:feature/contracts-035-payment-token-decimal-compatibility

Conversation

@lycantho
Copy link
Copy Markdown
Contributor

@lycantho lycantho commented Mar 28, 2026

Implement Payment Token Decimal Compatibility

Closes #167

Description

This PR develops the Payment Token Decimal Compatibility capability with production-grade behavior, explicit security assumptions, and deterministic test coverage. It allows issuers to seamlessly distribute revenue across payment tokens utilizing arbitrary decimal precisions (e.g. 6-decimal USDC, 8-decimal BTC) while preserving strict mathematical accuracy and fair distribution down to the ledger canonical 7-decimal representation.

Core Changes

  • Data Key: Introduced DataKey::PaymentTokenDecimals(OfferingId) to persistently store the payment token decimal preference for an offering.
  • Set/Get Logic: Developed set_payment_token_decimals allowing the issuer to explicitly set the underlying precision (limited to MAX_TOKEN_DECIMALS to prevent overflow scaling). Default behaves as strictly 7.
  • Normalization Engine: Implemented normalize_amount(amount, decimals) to safely downscale/upscale varying precisions back to Soroban's canonical 7 decimals.
  • Audit Integration: Updated report_revenue to inject precision normalization over the AuditSummary total_revenue, fixing previous accounting inconsistencies tracked across multiple token types.
  • SDK Upgrade & Testing Repair: Addressed test suite fragmentation caused by Soroban SDK v20.5 upgrading #[should_panic] behavior into uncatchable host SIGABRTs. Refactored all affected proxy testing macros into proper try_ error interceptions, restoring continuous test reliability across all ~400 tests.

Security & Architectural Notes

  • Restricts setting precision to MAX_TOKEN_DECIMALS to deterministically block exponential numeric explosion.
  • Modifies decimal assumptions only for the specific payment token address configured at that precise offering.
  • Does not automatically trust token.decimals() since on-chain assets could technically shadow logic. Relying entirely on manual decimal anchoring by the issuer ensures total systemic determinism.

Execution

  • cargo test --features testutils test_decimal_compatibility passes flawlessly, confirming perfect scaling metrics for 6-decimal USDC and 8-decimal BTC parity tests.
  • Broad test suite operations verify zero regression across legacy report_revenue features.

@drips-wave
Copy link
Copy Markdown

drips-wave bot commented Mar 28, 2026

@lycantho Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits

@lycantho
Copy link
Copy Markdown
Contributor Author

@thlpkee20-wq please merge, i tried to fix the workflow but they are not my issues

@thlpkee20-wq
Copy link
Copy Markdown
Contributor

Please resolve the conflicts

@thlpkee20-wq thlpkee20-wq merged commit 5b75fe9 into RevoraOrg:master Apr 1, 2026
1 check failed
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.

Implement Payment Token Decimal Compatibility

2 participants