fix(nextjs): parse the unshield amount in confidential decimals - #54
Open
Dusk1e wants to merge 1 commit into
Open
fix(nextjs): parse the unshield amount in confidential decimals#54Dusk1e wants to merge 1 commit into
Dusk1e wants to merge 1 commit into
Conversation
`useUpdateEncryptDecryptValue` parsed the input with `pair.publicToken.decimals` in both directions. In the decrypt direction that value goes straight into `unshield(from, to, uint64 amount)`, which takes the amount in the confidential token's own decimals — the FHERC20 wrapper caps those at 6. The call site in MainTokenSwapping already labels it as such (`tokenDecimals: pair.confidentialToken.decimals`), so only the parse was wrong. For the ETH pair (public 18, confidential 6) typing 1 produced 1e18 where the contract expects 1e6. In practice the form blocked first: `useEncryptDecryptValueError` compares the input against the decrypted confidential balance, which is in 6 decimals, so with 1 eETH held the comparison was 1000000000000000000 > 1000000 and every amount read as insufficient balance. The percent buttons showed the same split from the other side. They stored the correct raw value but `useEncryptDecryptInputValue` rendered it with public decimals, so 50% of 1 eETH appeared as 0.0000000000005 instead of 0.5. `useUpdateEncryptDecryptValueByPercent` already selected decimals by direction, so that expression is now an `inputDecimals(pair, isEncrypt)` helper used by all three. Shield is unchanged: `shield(to, uint256 amount)` does take underlying units and that call site already passes `publicToken.decimals`. Only USDC and EURC ship in the token list and both are 6 decimals, so public and confidential coincide and nothing looks wrong there.
Contributor
|
@Dusk1e is attempting to deploy a commit to the Fhenix Team on Vercel. A member of the Team first needs to authorize it. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The unshield amount is parsed with the wrong decimals.
useUpdateEncryptDecryptValuealways doesparseUnits(sanitized, pair.publicToken.decimals), but in the decrypt direction that value goes straight intounshield(from, to, uint64 amount), which takes the amount in the confidential token's own decimals, and the FHERC20 wrapper caps those at 6. The call site inMainTokenSwappingalready passestokenDecimals: pair.confidentialToken.decimalsfor that same value, so only the parse disagreed.For the ETH pair (public 18, confidential 6) typing 1 gives 1e18 where the contract wants 1e6. You mostly can't get that far though, because
useEncryptDecryptValueErrorcompares the input against the decrypted confidential balance, which is in 6 decimals. Holding 1 eETH that comparison is 1000000000000000000 against 1000000, so anything you type comes back as insufficient balance. The percent buttons show the same split from the other end: they already store the right raw value, butuseEncryptDecryptInputValuerenders it with public decimals, so 50% of 1 eETH appears in the box as 0.0000000000005 instead of 0.5.useUpdateEncryptDecryptValueByPercentwas already choosing decimals by direction, so I lifted that expression into a smallinputDecimals(pair, isEncrypt)helper and used it in all three places. Shield is untouched,shield(to, uint256 amount)really does take underlying units and that call site already passespublicToken.decimals.Worth noting why this went unseen: the token list only ships USDC and EURC, both 6 decimals, so public and confidential coincide and nothing looks wrong. ETH is the pair that breaks and it has its own branch in the selector.
There is no test runner in
packages/nextjs, so I could not add a test.check-typespasses,lintreports no errors (the prettier warnings it prints are pre-existing, all in the generatedlib/abis.ts), andprettier --checkpasses on the changed file.