Supported Data

The state query protocol can support any arbitrary view function data from any L1 or L2. The definition of view functions are as follows.
View functions ensure that they will not modify the state. A function can be declared as view. The following statements if present in the function are considered modifying the state and compiler will throw warning in such cases.
In practice, any solidity function that has the view tag can be supported. Succinct attestors are able to compute the result of view functions by using the eth_call RPC endpoint. 
Example functions that are supported:
ERC20:
function balanceOf(address account) public view virtual override returns (uint256) {
    return _balances[account];
}
Chainlink:
function getRoundData(uint80 _roundId) public view returns (uint80 roundId, int256 answer, uint256 startedAt, uint256 updatedAt, uint80 answeredInRound)
  {
    (uint16 phaseId, uint64 aggregatorRoundId) = parseIds(_roundId);
    (
      uint80 roundId, int256 answer, uint256 startedAt, uint256 updatedAt, uint80 ansIn
    ) = phaseAggregators[phaseId].getRoundData(aggregatorRoundId);
​
    return addPhaseIds(roundId, answer, startedAt, updatedAt, ansIn, phaseId);
  }
Unsupported Requests
Note that view function calls that revert are not supported, as our attestation system has no way to attest to a function reverting. Additionally, if the view function uses the GASPRICE, INVALID or REVERT opcode, then we cannot attest to it (these edge cases should be relatively rare).
Additionally it's important to note that tx.origin will equal msg.sender for all eth_call requests that we process and there is no way to customize tx.origin.
​
Last modified 2mo ago