• Add strategy entity and harvest events to yield aggregators.
• Add underlying tokens to input tokens in yield aggregators.
• Add more reward token types (in Aave-v3, reward emissions are per token: aToken/stableDebtToken/variableDebtToken).
• Add gas-related data to all events
• Tracking slippage in swaps
• Include both borrower position and lender position in Liquidate entity in lending subgraphs: #686 (comment)
• convert pricePerShare to BigInt

This Github Issue is being used as an example and can be deleted/ignored.

Summary of changes to be made

@tannishmango

We are not using the outputToken field, but we are using an internal field with the name _outputTokens.
fields starting with _ should be ignored in the dashboard as they are internal and not for the dashboard to read.

We should use startsWith instead of contains or better yet: ignore all field names starting with _

Missing methodologyVersion in protocol

Especially in the case of a GraphQL query error

Not sure if this is an issue in the data but there is a huge jump in protocol revenue around June 2020

https://subgraphs.messari.io/graphs?subgraph=https://api.thegraph.com/subgraphs/name/messari/compound-ethereum&tab=protocol&view=financialsDailySnapshots-dailyProtocolSideRevenueUSD

The lib supports next to mainnet also fantom and arbitrum, extending it for optimism is probably not too different to arbitrum.

Token emission are all zero. I believe they had a bug in their emission contract at the time and upgrade it to a different one. Probably worth looking into. @dmelotik

https://subgraphs.messari.io/subgraph?endpoint=https%3A%2F%2Fapi.thegraph.com%2Fsubgraphs%2Fname%2Fmessari%2Fcompound-ethereum&tab=pool&poolId=0x39aa39c021dfbae8fac545936693ac917d5e7563&view=marketDailySnapshots-rewardAPR

I plan on attempting to claim the bounty on Autofarm, is the payout still 10k USD? Once I receive confirmation, I can send a flowchart and can begin working on a schema for it soon.

Thanks,

• Syeam

https://discord.com/channels/953684103012683796/953685205531631637/986925529703780393

The TVL graph looks like a step function to a huge abnormally large value. Perhaps caused by wonky price data. The first issue that should be fixed is this, as this might resolve other issues.

More detail: https://docs.google.com/spreadsheets/d/1R3GvDHbv8hNfqgmZ0NbkQNS0raBsLtbuJ20Kk_bOwtM/edit#gid=617964580

Token

Address: 0x4e3fbd56cd56c3e72c1403e103b45db9da5b9d2b
Etherscan: Convex Token(CVX)
Original Price: approx $26.8241
Reported Price from Price Lib: $2853.700013 at block 14594214

Debug Details

Latest Round Data from Chainlink Feed with address 0x47Fb2585D2C56Fe188D0E6ec628a38b74fCeeeDf

Getting decimals

Calculations

Reported price = 2695000000
Decimals = 8

Final price = 2695000000 / 100000000 = $26.95

Possible Solution

If the Chainlink Feed is able to fetch the price for input token then it will also be effective to fetch the decimals for the token.

OutputToken should not be MIM

I deployed gamma strategies to polygon, but I have run into this error upon deployment.

@tannishmango

Metrics To Review

Protocol Metrics

totalPositionCount is ambigious and confusing
openPositionCount would be straightforward

Also consider cummulativePositionCount can instead be called totalPositionCount

@this-username-is-taken

https://subgraphs.messari.io/subgraph?endpoint=https://api.thegraph.com/subgraphs/name/messari/aave-v2-ethereum&tab=protocol doesn't seem to work

When I build and deploy this subgraph. I run into these errors. Its probably because this is a required field.

Negative market.totalValueLocked and market.inputTokenBalance in some cases.

See gql query and subgraph visualizer

Issue: inputTokenBalance is being calculated from Mints and Redeems. This would be okay, but there is interest accrued on borrows which is not accounted for. So when a market's TVL is close to 0 it is at risk of this bug. In addition, inputTokenBalance and TVL are not accurate with this mapping.

Fix: Use market.outputTokenSupply: inputTokenSupply = outputTokenSupply * exchangeRate. This will also create an accurate TVL because it is calculated from outputTokenSupply.

The market.exchangeRate can be found in a more generic way:

exchangeRate = exchangeRatemantissa / 1e(18 + underlyingToken.decimals - outputToken.decimals)

This is an issue in fuse that is fixed with this. It will only affect comp forks where the cToken doesn't have 8 decimals.

Compound changed how to gather compound distribution rates around October of 2021.

After that change rewards rates should be calculated using compBorrowSpeeds and compSupplySpeeds, see https://etherscan.io/address/0x3d9819210a31b4961b30ef54be2aed79b9c9cd3b#readProxyContract to see the current rates.

Change effective at this transaction: https://etherscan.io/tx/0xc5098f8fb149262d7f26d32c0642e0e8bee5383d9df9c4988070f63a23cb9912

When sorting by TVL in the 'Pool Overview' tab of lending protocols, it doesn't actually seem to sort by TVL in USD.

For example:

fuse

Metrics To Review

Protocol Metrics

Pool Overview Metrics

Pool Metrics

@MichaelC1999

You can use template literals to clean up string concatenation

navigate(`?subgraph=${subgraphParam}&poolId=${poolId}&tab=${tabName}`);

This will cause the setWarning function to be called on every render (which can be a lot) so it's best to have this stuff inside of a hook like useEffect so that it only updates when the dependencies change

useEffect(() => {
  setWarning(issues);
}, [issues]);

Don't forget the dependency array for the use effect

This is a good candidate for pulling this logic out into a new component. You're using a useMemo in order to prevent rendering when no data changes have happened but react already handles a lot of this when you put things into components with props. (there are cases where you might want to wrap a component in a memo but for the most part react won't re-render a component if it's props haven't changed.)

Each Aave market has a treasury contract, which collects a portion of protocol interest in the form of aTokens. Treasury data is not included in the Aave protocol subgraph, so it needs to be added to the mapping. The treasury logic works a bit differently in V2 and V3.

V2: aTokens are automatically transferred to the collector contracts, so summing the aToken balances will give the entire balance.

V2 Collectors:
Eth Mainnet V2/AMM/ARC: 0x464c71f6c2f760dda6093dcb91c24c39e5d6e18c (shared contract)
Polygon V2: 0x7734280A4337F37Fbf4651073Db7c28C80B339e9
Avalanche V2: 0x467b92aF281d14cB6809913AD016a607b5ba8A36

V3: aTokens must be pulled into the treasury contract by calling the mintToTreasury function on the Pool contract. There's a field on each reserve called accruedToTreasury which tracks the unminted amounts (not currently on the subgraph but I'll update this issue once it's added). So the treasury total is the aToken balances of the contracts below + accruedToTreasury for each reserve.

V3 Collectors:
Optimism V3: 0xA77E4A084d7d4f064E326C0F6c0aCefd47A5Cb21
Arbitrum V3: 0xC3301b30f4EcBfd59dE0d74e89690C1a70C6f21B
Polygon V3: 0x73D435AFc15e35A9aC63B2a81B5AA54f974eadFe
Harmony V3: 0xeaC16519923774Fd7723d3D5E442a1e2E46BA962 (not supported by TheGraph yet)
Fantom V3: 0xc0F0cFBbd0382BcE3B93234E4BFb31b2aaBE36aD
Avalanche V3: 0xaCbE7d574EF8dC39435577eb638167Aca74F79f0

Currently the Liquidate entity in the lending schema follows the same structure as other events, though it has additional info that we might want to capture.

For reference, here are some liquidation events from different lending protocols:

Aave v2:

  /**
   * @dev Emitted when a borrower is liquidated. This event is emitted by the LendingPool via
   * LendingPoolCollateral manager using a DELEGATECALL
   * This allows to have the events in the generated ABI for LendingPool.
   * @param collateralAsset The address of the underlying asset used as collateral, to receive as result of the liquidation
   * @param debtAsset The address of the underlying borrowed asset to be repaid with the liquidation
   * @param user The address of the borrower getting liquidated
   * @param debtToCover The debt amount of borrowed `asset` the liquidator wants to cover
   * @param liquidatedCollateralAmount The amount of collateral received by the liiquidator
   * @param liquidator The address of the liquidator
   * @param receiveAToken `true` if the liquidators wants to receive the collateral aTokens, `false` if he wants
   * to receive the underlying collateral asset directly
   **/
  event LiquidationCall(
    address indexed collateralAsset,
    address indexed debtAsset,
    address indexed user,
    uint256 debtToCover,
    uint256 liquidatedCollateralAmount,
    address liquidator,
    bool receiveAToken
  );

Compound v2:

 /**
  * @notice Event emitted when a borrow is liquidated
  */
event LiquidateBorrow(
  address liquidator, 
  address borrower, 
  uint repayAmount, 
  address cTokenCollateral,
  uint seizeTokens
);

Liquity

event Liquidation(
  uint _liquidatedDebt,
  uint _liquidatedColl,
  uint _collGasCompensation,
  uint _LUSDGasCompensation
);

Abracadabra

event LogRemoveCollateral(
  address indexed from,
  address indexed to,
  uint256 share
);

Metrics that need fixing: TVL, dailySupplySideRevenue, cumSupplySideRevenue, totalBorrowBalance, dailyLiquidate

Notes: For the most part the shapes of the curves are OK, but due to differences in the way we calculate the price of ETH and other tokens throughout time, the numbers are off. Also, the way TVL is calculated needs to be updated from TVL = Supply to TV = Supply - Borrow (to account for looping).

Full Details (must check all tabs): https://docs.google.com/spreadsheets/d/1ggvXIIHklcwn9GeqTvtI6VN3KiRg1LSjOA5rMNTVt1A/edit#gid=617964580

One of the curve mappings calls Fantom's config twice instead of Arbitrum's so an unexpected null wasm error is thrown:

Handler skipped due to execution failure, error: Mapping aborted at src/prices/routers/CurveRouter.ts, line 56, column 7, with message: unexpected null wasm backtrace: 0: 0xaf44 - <unknown>!src/prices/routers/UniswapRouter/getLpTokenTotalLiquidityUsdc 1: 0xc0f8 - <unknown>!generated/schema/Market#get:outputTokenSupply 2: 0xc5aa - <unknown>!../src/mapping/updateProtocol 3: 0xd826 - <unknown>!src/mappings/handleNewFuseFee , handler: handleAccrueInterest

rewardTokenEmissions seem to be too high. Emissions are supposed to be normalized to a day, looks like it is normalized to a year.

See visualizer graph here

In the protocol interface, usageMetrics should be dailyUsageMetrics. Otherwise the DexAmmProtocol will not fit the interface.

We can avoid a contract call by using AccrueInterest's variable totalBorrows to update our market's total borrow amount.

• Perf improvements (Immutable, Bytes): https://medium.com/edge-node-engineering/two-simple-subgraph-performance-improvements-a76c6b3e7eac
• Update documentation on liquidateCount to account for multiple liquidations in a single event
• Formated docstring: https://discord.com/channels/953684103012683796/961658223444787220/971527454592221236
• Figure out single-sided staking (Bancor, Platypus) schema
• Yield Agg schema for multiple input tokens (add underlying)
• Add permission type to lending schema (e.g. permissionless, KYC, whitelist)
• Lending schema change fixed_term to fixed
• Add more networks (e.g. Boba, Cronos, Cosmos)

These errors show up when I built the subgraph. These are most likely due to these fields not being marked as required in the schema, and they are used in the program without either checking if null or asserting not null with '!'. I tried to fix these issue for deployment by adding the exclamation, however, the deployment still failed when I tried to deploy to Messari Hosted service.

The aurigami subgraph is producing an error that likely due to issue with the graph protocol. See an example of the issue at this deployment

{
  "data": {
    "subgraphLogs": [
      {
        "timestamp": "2022-06-18T02:32:49.197558799Z",
        "text": "Subgraph failed with non-deterministic error: failed to process trigger: block #61007515 (0x8a70…09de), transaction 276c3690a9721a11a01eba68381f647e987bf56313c21d9dd97f03419c3e1164: Found no transaction for event, retry_delay_s: 1800, attempt: 113"
      },
      {
        "timestamp": "2022-06-18T02:02:48.011653336Z",
        "text": "Subgraph failed with non-deterministic error: failed to process trigger: block #61007515 (0x8a70…09de), transaction 276c3690a9721a11a01eba68381f647e987bf56313c21d9dd97f03419c3e1164: Found no transaction for event, retry_delay_s: 1800, attempt: 112"
      }
    ]
  }
}

https://subgraphs.messari.io/graphs?subgraph=https://api.thegraph.com/subgraphs/name/messari/compound-ethereum

https://subgraphs.messari.io/subgraph?endpoint=https://api.thegraph.com/subgraphs/name/messari/abracadabra-money-ethereum&tab=pool&poolId=0x341394e55a9b698a316608762ec6e011f46b9469

Metrics To Review

Protocol Metrics

Pool Overview Metrics

Pool Metrics

Protocol Metrics in need of review: totalValueLockedUSD

Pool-level Metrics in need of review: totalValueLockedUSD, totalDepositBalanceUSD, rewardTokenEmissionsAmount

Full QA: https://docs.google.com/spreadsheets/d/1M2fqfxVm1ZozNESOdkQbfyM60grl9YMCPO1u3eylo54/edit?usp=sharing

market.canUseAsCollateral cannot be moved back to true once moved to false.

Sample query to see behavior:

query MyQuery { markets { id name canBorrowFrom canUseAsCollateral isActive _reserveFactor rates { id rate } } }

If a transaction contains a function-scoped revert, trace_transaction fails to calculate the output of the subtraces after the revert that are part of the same transaction. It also seems to be setting gasUsed to 0 for all traces after the revert. This issue applies to the other tracing calls as well.

Ref Issue: Fantom-foundation/go-opera#288
Subgraph URL - https://thegraph.com/hosted-service/subgraph/messari/yearn-v2-fantom

Subgraph failed with non-deterministic error: failed to process trigger: block #21041413 (0x0000…b378), transaction
a44fa1857fa5448419ff94682de1ffeccaa74eb0d6dc9d0de8fe37c6c2a90746: Decoding function outputs for the call 
Function { name: "withdraw", inputs: [], outputs: [Param { name: "", kind: Uint(256), internal_type: None }], 
constant: None, state_mutability: NonPayable } failed, raw output: : Invalid name: please ensure the contract
 and method you're calling exist! failed to decode empty bytes. if you're using jsonrpc this is likely due to 
jsonrpc returning `0x` in case contract or method don't exist

There's a data issue with CREAM BSC subgraph.
The various values returned by the market / marketsnapshots are negative which should not happen.
Market id: "0xbf9b95b78bc42f6cf53ff2a0ce19d607cfe1ff82"

The chart on the Messari dashboard shows the rates are fixed throughout historical snapshots. But they should be changing over time (see rates on Compound).

https://subgraphs.messari.io/subgraph?endpoint=https://api.thegraph.com/subgraphs/name/messari/compound-ethereum&tab=pool&poolId=0x4ddc2d193948926d02f9b1fe9e1daa0718270ed5

Problem occurs for both the hourly and daily snapshots.

Replicate with the query:

{  			
  markets(
      first:1
      orderBy:totalValueLockedUSD
      orderDirection:desc
  ) {
      name
      dailySnapshots (
          first: 5
          orderDirection: desc
          orderBy: timestamp
      ) {
          blockNumber
          timestamp

          # Below should change over time but do not
          rates(orderBy:id) {
            id
            rate
          }
      }    
  }
}