fix(token): Match ERC20Wrapper decimals behavior to Solidity (#638) #640
+31
−2
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.
Updated the
Updates the `decimals` method in `Erc20Wrapper` to align its behavior with the Solidity `ERC20Wrapper` implementation, as requested in issue #638.decimals
method inErc20Wrapper
to attempt a call to the underlying token'sdecimals()
function using a fixed selector. If the call fails or returns unexpected data, it falls back to the wrapper's stored decimals. This improves the robustness of the decimals retrieval process.The method now first attempts to call the
decimals()
function on the underlying token contract using the standard selector (0x313ce567
). If this external call succeeds and returns a validuint8
value, that value is returned. If the call fails (e.g., the underlying token does not implementdecimals
or the call reverts) or returns improperly formatted data, the method falls back to returning the wrapper contract's own configured decimals value (underlying_decimals
).This ensures parity with the reference OpenZeppelin Solidity contracts and improves compatibility.
Resolves #638
PR Checklist