Opdata 3775 add functionality query decimals - #4107

🦋 Changeset detected

Latest commit: efd127b

The changes in this PR will be included in the next version bump.

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

This is not really a good idea because we are trying to inject some contract specific logic into a generic piece of code.

@mmcallister-cll @dskloetc Any ideas on how we should do this? Maybe put the decimal abi into input and have a result2 in output?

Yeah, agree with @mxiao-cll, we shouldn't call this for every base function call, we can't guarantee every contract will have decimals

My initial ideas are:

1. (Preferred) what's wrong with doing multiple queries where this is called ie: Promise.all([value, decimals])
2. or a separate endpoint eg:

{
  "endpoint": "function-with-decimals"
...
}

3. or even some sort of extension that allows for an ordered array of multiple signature inputs that outputs an ordered array of results

3. or even some sort of extension that allows for an ordered array of multiple signature inputs that outputs an ordered array of results

My preference is closest to this. But I would suggest a record/map where the results are returned under the same keys as the inputs. So the input could be something like:

  "data": {
    "endpoint": "function",
    "signature": "function latestAnswer() view returns (int256)",
    "address": "0x779877A7B0D9E8603169DdbD7836e478b4624789",
    "network": "ETHEREUM_GOERLI",
    "data": {
      "decimals": {
        "signature": "function decimals() view returns (int256)",
        "address": "0x779877A7B0D9E8603169DdbD7836e478b4624789",
      }
    }
  }

And then the result would be of the shape:

{
  result: "123456"
  data: {
    decimals: 18
  }
}

But we could put anything else in data and it would be mapped to the corresponding name.
Perhaps address is optional and it would reuse the address from the base request if not specified.

However, I can also see how it would be beneficial to have the decimals for free on all requests without having to change the input. But making a request that is expected to fail is a bit ugly. Do we know how many of the contracts we call do not have a decimals function? Maybe we can check what's currently in RDD?

3. or even some sort of extension that allows for an ordered array of multiple signature inputs that outputs an ordered array of results

My preference is closest to this. But I would suggest a record/map where the results are returned under the same keys as the inputs. So the input could be something like:

  "data": {
    "endpoint": "function",
    "signature": "function latestAnswer() view returns (int256)",
    "address": "0x779877A7B0D9E8603169DdbD7836e478b4624789",
    "network": "ETHEREUM_GOERLI",
    "data": {
      "decimals": {
        "signature": "function decimals() view returns (int256)",
        "address": "0x779877A7B0D9E8603169DdbD7836e478b4624789",
      }
    }
  }

And then the result would be of the shape:

{
  result: "123456"
  data: {
    decimals: 18
  }
}

But we could put anything else in data and it would be mapped to the corresponding name. Perhaps address is optional and it would reuse the address from the base request if not specified.

However, I can also see how it would be beneficial to have the decimals for free on all requests without having to change the input. But making a request that is expected to fail is a bit ugly. Do we know how many of the contracts we call do not have a decimals function? Maybe we can check what's currently in RDD?

Contracts in RDD that do not support decimals()

1. https://github.com/smartcontractkit/reference-data-directory/blob/2539836df857c8c321c1337871b851e8f7683be0/ethereum-mainnet-mantle-1/contracts/0x874effca5376D434d49021B3638d1e1BC214EC27.json

2. https://github.com/smartcontractkit/reference-data-directory/blob/2539836df857c8c321c1337871b851e8f7683be0/ethereum-mainnet-mantle-1/contracts/0x4606b8D331f07f8167d5bcD891Ff6a4eE984B8e4.json

Waiting for David's review