Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

intToHex util produces invalid Quantities #70

Open
josepot opened this issue Sep 1, 2022 · 0 comments · May be fixed by #71
Open

intToHex util produces invalid Quantities #70

josepot opened this issue Sep 1, 2022 · 0 comments · May be fixed by #71

Comments

@josepot
Copy link

josepot commented Sep 1, 2022

Hi and thank you for maintaining this library!

Our dApp stopped working once we tested it against a recently deployed tenderly fork.

After spending some hours trying to find the root cause, it turns out that the problem is that some of the calls that metamask makes to eth_getLogs (as a result of a logs subscription) have an invalid payload.

An example of an invalid payload produced from metamask in order to query the logs of the newest block:

{
    "id": 2265185671823508,
    "jsonrpc": "2.0",
    "method": "eth_getLogs",
    "params": [
        {
            "fromBlock": "0x01470640",
            "toBlock": "0x1470641",
            "address": [
                "0xda10009cbd5d07dd0cecc66161fc93d7c9000da1"
            ],
            "topics": [
                "0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef"
            ]
        }
    ]
}

At a first glance everything looks fine. However, if we pay closer attention to the fromBlock field we will notice that it has an invalid leading zero, which causes the node to reject the request due to invalid parameters.

My guess is that this issue doesn't come up very often b/c most nodes must tolerate invalid "Quantity" fields. However, according to the official spec:

When encoding quantities (integers, numbers): encode as hex, prefix with "0x", the most compact representation (slight exception: zero should be represented as "0x0").

Another reason why I think that this issue doesn't come up often is because I've noticed that most of the times that the queries are created, the quantity fields come from the result of other requests, which are returning properly encoded Quantity fields.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants