Major schema update (1.2.0)

[this-username-is-taken]

Schema Update 1.2.0

Common

• Added prefixes to diambiguate quantitative fields:
  • cumulative: sum of all historical data from day 1 up to this point. E.g. cumulativeDepositUSD means all deposits has ever been made to this protocol/pool.
  • daily/hourly: this only applies to snapshots and represents the sum of the snapshot interval (i.e. daily aggregate). E.g. dailyActiveUsers means all unique active users on a given day, up till now.
  • All other quantitative field indicates a spot balance. In other words, the value at this point in time. E.g. totalValueLockedUSD means the total TVL of the protocol/pool as of now.
• Updated chain enums to match dataSource.network().
• Added lastPriceUSD and lastPriceBlockNumber as optional fields in the Token entity for tracking prices.
• Refactored RewardToken to include Token as a field.
• For snapshots, now saving both cumulative values and daily aggregates.
• Now saving hourly snapshots for usage metrics and pool data.

DEX-AMM

• Added more detailed usage metrics: deposit/withdraw/swap count.
• Added inputTokenWeights: [BigDecimal!]! to track pool composition.
• Added per-token volume dailyVolumeByTokenUSD: [BigDecimal!]! to LiquidityPoolDailySnapshot.
• Named PoolDailySnapshot to LiquidityPoolDailySnapshot for consistency.
• Added stakedOutputTokenAmount: BigInt to LiquidityPool and LiquidityPoolDailySnapshot.

Lending Protocol

• Added more detailed usage metrics: deposit/withdraw/repay/liquidate count.
• Now aggregating deposit/borrow/liquidation USD values.
• Added InterestRate entity and made rates into an array.
• Added mintedTokens and mintedTokenSupplies to the LendingProtocol entity.
• Added exchangeRate: BigDecimal to Market and MarketDailySnapshot entity.
• Assume only a single input token (i.e. changed inputTokens to inputToken).
• Updated comments to the Liquidate event for clarity.

Yield Aggregator

• Added more detailed usage metrics: deposit/withdraw count.
• Assume only a single input token (i.e. changed inputTokens to inputToken).

Generic

• Added stakedOutputTokenAmount: BigInt

[melotik]

I believe @steegecs mentioned this too.

I like the descriptors prefixed on the field names. This is a small thing, but I do like totalVolumeUSD over cumulativeVolumeUSD
And if we want a field only to calculate for a given day then dailyVolumeUSD over currentVolumeUSD

So I would propose daily prefix for fields that we want just that given days metrics over current - current could be interpreted as total at that given time without the comment. And total speaks for itself - the total amount at that point in time.

[steegecs]

I believe @steegecs mentioned this too.

I like the descriptors prefixed on the field names. This is a small thing, but I do like totalVolumeUSD over cumulativeVolumeUSD And if we want a field only to calculate for a given day then dailyVolumeUSD over currentVolumeUSD

So I would propose daily prefix for fields that we want just that given days metrics over current - current could be interpreted as total at that given time without the comment. And total speaks for itself - the total amount at that point in time.

I still have this opinion as well about fields that use cumulative. Like the revenues, volumes, and unique users. But everything looks good to go if you want to leave that. It seems more accurate this way. If you compare, for example, all historical volume and volume for a day, under the current paradigm you'd have cumulativeVolumeUSD and dailyVolumeUSD.

They are both cumulative however. One throughout the history of the protocol and the other over the period of a day. So it would be more accurate to say totalCumulativeVolumeUSD and dailyCumulativeVolumeUSD. But when you drop "cumulative' it still gets the point across clearly without the extra jargon.

[this-username-is-taken]

I still have this opinion as well about fields that use cumulative. Like the revenues, volumes, and unique users. But everything looks good to go if you want to leave that. It seems more accurate this way. If you compare, for example, all historical volume and volume for a day, under the current paradigm you'd have cumulativeVolumeUSD and dailyVolumeUSD.

They are both cumulative however. One throughout the history of the protocol and the other over the period of a day. So it would be more accurate to say totalCumulativeVolumeUSD and dailyCumulativeVolumeUSD. But when you drop "cumulative' it still gets the point across clearly without the extra jargon.

The main thing here is I want to avoid total since we have totalValueLocked, which is a point-in-time value and not an aggregate. Having totalVolume and totalValueLocked can be slightly confusing since the total in either case refers to different things.

There is another place of ambiguity for total when used in Protocol as it can mean total historically (i.e. cumulative), or total across all pools, but at this point-in-time. Basically cumulative is strictly a modifier on time, but total can be either.

Same for totalBorrows for a specific market. It can mean either totalBorrows at this point-in-time from all borrowers (i.e. outstanding loans), or cumulative total borrowed amount for this market.

[0xbe1]

Have gone through schema-lending (that I am most familiar with) and it looks good, just small comments.

Higher-level question: Do we decide to leave fields in type Liquidate generic? Such as from and to. I proposed using more specific names and we had discussions on Discord, would love to hear your thoughts here.

[this-username-is-taken]

See fixes here: #106