checking the real time amound return from oneInch as well putted the …

[SibghatUllah1997]

Overview

This release introduces several enhancements and bug fixes to improve the functionality and stability of our project. We've also made some important updates to our licensing.

Features

• Real-time Amount Return: We've added a new feature that allows users to check the real-time amount returned from the OneInch API, providing more accurate information.

Bug Fixes

• Amount Verification: We've implemented a check to ensure that the amount returned from OneInch matches the amount received from the FM, ensuring data consistency.

Licensing

• MIT License: We've clarified the licensing of this project by adding a prominent MIT license comment in the library and interface code. This update ensures that the project's licensing is properly documented and compliant.

[naiemk]

Some notes:

OneInchDecoder

• identifyFunction: returns string quiet expensive. It car return an Enum which will be cheaper

In the decode functions. I see the following code:

        // Skip the first 4 bytes (function signature)
        bytes memory params = slice(data, 4, data.length - 4);

I am not sure if this function is more efficient or it's better to use decodeWithSelector. Something to be evaluated. But my suspicion is that decodeWithSelector may be more efficient (gas)

TokenReceivable
I realized there is an issue. sync is nonReentrant which should not be as it is not doing any state changing call. Only balanceOf which is a staticcall

[SibghatUllah1997]

Some notes:
OneInchDecoder

* identifyFunction: returns `string` quiet expensive. It car return an Enum which will be cheaper

using enums now and returning uint value according to enum
In the decode functions. I see the following code:

        // Skip the first 4 bytes (function signature)
        bytes memory params = slice(data, 4, data.length - 4);

I am not sure if this function is more efficient or it's better to use decodeWithSelector. Something to be evaluated. But my suspicion is that decodeWithSelector may be more efficient (gas)

@naiemk I want a small clarification over this. Do you want me to remove the slice line and using decodeWithSelector method. Right? Where are you referring this actually this thing is getting used in many places. Could you please clarify this for me. And what you are referring decodeWithSelector to?

TokenReceivable I realized there is an issue. sync is nonReentrant which should not be as it is not doing any state changing call. Only balanceOf which is a staticcall

OK is this comment is for the withdrawSignedOneInch? @naiemk Just want to clarify where you are referring this so i can make the changing accordinlgy?