Fix usdc recurring donation problem #4867
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
WalkthroughThe changes in this pull request primarily involve updates to the logic for determining decimal precision in the Changes
Possibly related PRs
Suggested labels
Suggested reviewers
Poem
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (1)
src/components/views/donate/Recurring/RecurringDonationModal/Item.tsx (1)
34-36: Consider extracting decimal precision logic to a utility function.The decimal precision selection logic is duplicated. Consider extracting it to a reusable utility function to improve maintainability and ensure consistency.
+const getTokenDecimals = (token: IToken) => + token.underlyingToken?.decimals || token.decimals || 18; // Then use it in both places: -formatUnits( - amount, - token.underlyingToken?.decimals || - token.decimals || - 18, -) +formatUnits(amount, getTokenDecimals(token))Also applies to: 52-54
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (2)
src/components/views/donate/Recurring/RecurringDonationModal/Item.tsx(2 hunks)src/config/production.tsx(1 hunks)
🔇 Additional comments (5)
src/components/views/donate/Recurring/RecurringDonationModal/Item.tsx (2)
34-36: LGTM! Verify token decimal handling across different token types.
The additional fallback to token.decimals improves the robustness of decimal precision handling, particularly for tokens like USDC that don't use the standard 18 decimals.
Let's verify the token configurations to ensure we handle all cases correctly:
#!/bin/bash
# Description: Check token decimal configurations across the codebase
# Expected: Find token configurations to verify decimal handling
# Search for token decimal configurations
rg -A 5 "decimals.*[0-9]+" --type typescript
# Search for formatUnits usage to ensure consistent decimal handling
ast-grep --pattern 'formatUnits($_, $decimals)'52-54: Verify USD calculation accuracy with the new decimal handling.
The decimal precision change is consistent with the token amount display. However, since this affects USD value calculations, we should ensure the price conversion remains accurate across different token decimals.
Let's verify the price calculations:
✅ Verification successful
Based on the search results, I can now verify the decimal precision handling in the USD calculation. The code shows consistent decimal handling across the codebase:
USD calculation is correctly implemented with the new decimal handling
The price calculation is properly implemented with the token's decimal precision:
- The amount is correctly formatted using
formatUnitswith the token's decimals (either fromunderlyingToken?.decimals,token.decimals, or fallback to 18) - The USD value is calculated by multiplying the formatted amount with the token price
- This approach is consistently used across both one-time and recurring donations
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check price calculation implementations
# Expected: Find related price conversion logic to verify consistency
# Search for price calculation patterns
rg -B 5 -A 5 "price.*multipliedBy" --type typescript
# Look for other formatUnits usage with price calculations
ast-grep --pattern 'formatUnits($amount, $decimals)'
Length of output: 131
Script:
#!/bin/bash
# Let's try different search patterns to find price calculation logic
# Search for price-related calculations
rg -l "price.*format"
# Search for formatUnits usage
rg -B 3 -A 3 "formatUnits"
# Search for decimal precision handling
rg -B 2 -A 2 "\.decimals"
# Search specifically in the component directory
rg -B 3 -A 3 "price|formatUnits|decimals" "src/components/views/donate"
Length of output: 99710
src/config/production.tsx (3)
Line range hint 947-949: LGTM! Consistent use of automatic gas configuration.
The empty gasPreference objects with explicit comments across multiple network configurations indicate a deliberate choice to use automatic gas configuration. This is a good practice as it allows for dynamic gas pricing based on network conditions.
Also applies to: 965-967, 983-985, 1001-1003
533-533: LGTM! Decimal precision matches the underlying USDC token.
The decimal precision of 6 for USDCx is correct as it matches the underlying USDC token's decimal precision. This is crucial for accurate token amount calculations in the SuperFluid protocol.
Let's verify the decimal precision consistency across the codebase:
#!/bin/bash
# Description: Verify USDC/USDCx decimal precision consistency across configurations
# Test: Search for USDC/USDCx decimal configurations. Expect: All instances should show 6 decimals
# Search for USDC decimal configurations
echo "Checking USDC decimal configurations:"
rg -B 2 -A 2 "decimals.*[^x]USDC"
# Search for USDCx decimal configurations
echo "Checking USDCx decimal configurations:"
rg -B 2 -A 2 "decimals.*USDCx"Line range hint 1012-1012: Verify the farming start time configuration.
The farming start time is set to September 3, 2024, 6:00:00 PM. This is a future configuration that will affect when users can start farming GIV tokens on the ZKEVM network.
Let's verify there are no conflicting start times in the codebase:
✅ Verification successful
Based on the search results, I can now generate the final response:
The farming start time configuration for ZKEVM (1725386400000 - September 3, 2024) is unique and doesn't conflict with other farming configurations.
The search results show several farmStartTimeMS configurations across different networks:
- Gnosis: 1651345200000, 1659625200000
- Optimism: 1655218800000, 1668691800000
- Development configs: 1655997000000, 1646306818206, 1685460000000
- ZKEVM: 1725386400000 (the one we're verifying)
Each network has its own distinct farming start time, and the ZKEVM configuration is properly set for a future date without any conflicts with other network configurations.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify farming start time configurations
# Test: Search for farmStartTimeMS configurations. Expect: No conflicting times for ZKEVM farming
# Search for farmStartTimeMS configurations
echo "Checking farming start time configurations:"
rg "farmStartTimeMS.*1725386400000"
# Search for any ZKEVM farming configurations
echo "Checking ZKEVM farming configurations:"
rg -B 5 -A 5 "ZKEVM.*farm.*Time"
Length of output: 240
Script:
#!/bin/bash
# Let's try a different approach to search for farming configurations
# Search for any farming start time configurations
echo "Checking all farming start time configurations:"
rg -i "farmstart.*time"
# Search specifically in config files
echo "Checking config files for farming configurations:"
fd "config" --type f --exec rg -l "farm.*time"
# Search for ZKEVM configurations
echo "Checking ZKEVM configurations:"
rg "ZKEVM_CONFIG" -A 10 -B 10
Length of output: 18540
Summary by CodeRabbit
New Features
Bug Fixes
Chores