Post

@0xngmi Yeah I’d prefer trailing

@0xngmi annualize + label clearly. keep it simple

@0xngmi Annualize it but maybe say: revenue(projected):

@0xngmi eeeh I feel like everyone is valuing these projects on ntm multiples that annualized actually is the right call

@0xngmi annualize based on available data if less than 12 months

@0xngmi use 30d instead

@0xngmi Option 2 probably ok as long as it’s properly highlighted

@0xngmi Annualize for the projects younger than 12mo. That way it’s always an apples to apples comparison. The age of the company is a separate metric

@0xngmi 30d

@0xngmi 30d is a more accurate projection imo. 12 months is a looong time in crypto.

@0xngmi annualize based on data you have, we tried it and early spikes distorted our runway math badly.

@0xngmi 30 days makes the most sense because a) volatility b) TTM is the biggest problem with BLS data (not the biggest, but one of) is that its lagging and is not representative of current reality

@0xngmi - dont use ttm, use 30d instead

@0xngmi Don’t use TTM; use 30-day figures instead. The industry needs to stop annualizing everything.

No more annualized… please Do ttm anyway and then allow for switching time frames the 12 months is a long time for crypto makes no sense We need to start comparing cry to companies the same at public companies we shouldn’t change the metrics jsut because we have a worse business model / industry

@0xngmi Choose the 30D, it's more accurate.

@0xngmi 30d

@0xngmi I'd like to see both ttm and annualized for a mature project. Both what it did and what it might do.

I would consider fixing fees. If a borrower pays a lender interest, that’s not a fee the protocol sees or cares about. If a liquidator liquidates a position, again, that’s not a protocol fee. Only if you actually take fees on interest and liquidations are these fees. So many people I’ve spoken to don’t understand this. I realise you’re trying to abstract things across broad protocol classes, but including interest and e.g. liquidation volume in fees for lending protocols is just plain wrong IMO.

@0xngmi Switching to TTM makes a lot of sense. Annualized numbers get pretty misleading in these volatile markets.

@0xngmi Show both forward and backward looking metrics instead of replacing one by the other. They measure different things and are both relevant to users/investors.

@0xngmi Maybe it's better to use quarter multiply by 4. By using 12 months you use old data

@0xngmi Use TTM anyway and show number of months if possible- closest to the truth imo

@0xngmi yeah 30d feels more honest tbh

@0xngmi I am for this

@0xngmi good shot sir. I think using TTM is better but for projects under 12 months, they could be grouped into 2 buckets. > if less than 30D, no need for annualized or TTM because they are still in revenue discovery. > then above 30D, you can use TTM

@0xngmi Annualized (and mention that in bracket)

@0xngmi just keep annualized numbers for cross-comparing not breaking

@0xngmi annualize but put a big fat asterisk and maybe a toggle switch to only see projects above 12 months old

@0xngmi These would be most helpful: - Monthly - Quarterly - Half yearly & - TTM Less than 12 mo, TTM is NA. If anyone wants to make projections, they can with M, Q & H based on how conservative they want to be It will be standardized + easy to implement

@0xngmi TTM with a "live since" label for younger projects. annualizing 6 months of data assumes the next 6 months look the same ,for early protocols that's almost never true. TTM is honest even when the number looks small @0xngmi

@0xngmi 30d trailing for those younger than 12 months 12months trailing for the others

@0xngmi 30d

@0xngmi 30d

@0xngmi is the aave revenue showing TTM? 30d is $5.3m, or is it something else?

@0xngmi Probably 30d instead. The worst proposed was definitely annualized based on data.

@0xngmi Use 30d

@0xngmi l3m run rate wins

@0xngmi Imo the use of annualized values over short term data is one of the worst information crimes in DeFi. Use a 30d window until sufficient real data exists to calculate a TTM value.

@0xngmi - annualize based on the data we have (eg if live for 6mo, multiply by 2) This is best IMO

I like to use the trailing 90-day (for more mature projects) when doing research because it reduces outlier impact and is not as restrictive with younger protocols Using the last trailing 12 months can be misleading in an industry as fast-moving as crypto, where a quarter feels like a year. Maybe even trailing 90 days is too large an interval for some projects I don't like TTM because backward-looking data in such a large interval for a metric that is most insightful on a forward-looking basis won't help investors

@0xngmi 30d rate, and never annualize sub-12mo and yeah, annualizing assumes fees are stable, which is never true in month 6. And the same for "Revenue". on the naming btw (saw the thread below) - maybe something like "LP revenue" vs "Protocol revenue"?

@0xngmi I think the problem is not the method but the comparability. TTM loses sense in products <12 months, there the "run-rate" is usually more honest.

@0xngmi Makes sense 👍

@0xngmi 30d default, ttm on hover

@0xngmi Derive NTM from YTD & extrapolated via y/y vs ly comp or li early if not enough history

@0xngmi ttm for vets, 90d median for new