Only compare identities that actually match
Similar project names are not enough for a financial-data join. The calculation requires the same provider identifier in both datasets, and ambiguous duplicate identifiers are excluded. Even an exact match still needs interpretation: a parent application, individual product or adapter may define its reporting boundaries differently. The table exposes the identifier so that an exported comparison can be traced to the matched entity.
Work through a retention example
If a hypothetical protocol reports $200,000 of daily fees and $40,000 of daily revenue, revenue divided by fees is 20%. This describes those two reported fields. It does not imply that token holders received $40,000 or that the protocol had no other expenses. A zero fee denominator cannot produce a usable retention ratio. Values above 100% are retained rather than capped because they can signal mismatched coverage, definitions or update boundaries that deserve inspection.
Receipt alignment has practical limits
Both metrics use the provider’s 24-hour overview fields, but their responses arrive independently. The combined timestamp is the older source receipt, and the method notes disclose both receipts. This is not proof that the underlying calculations share an identical cutoff. Use this screen to locate unusual retention patterns and then inspect the relevant adapter methodology or protocol disclosures. It is a descriptive comparison of reported economics, not an audited income statement or a prediction of future distributions.