Building a Personal DeFi Rewards Baseline Before You Compare Anything

Most people try to compare DeFi protocol costs while looking at a screen full of numbers they have never written down for themselves. Without a personal baseline, every comparison turns into a guess about what you actually received, what you actually paid, and which network or route produced which result. This guide walks you through building that baseline first: a plain record of your own past reward events, fee events and the conditions around them. The goal is not to predict anything or to recommend a protocol. It is to give you a written starting point so that when you later open a fee page or a help centre article, you can place the official information next to your own history and see where the difference lies. You will need a spreadsheet or a plain text file, access to your own transaction history, and the official documentation pages of the platforms you already use. Work through the steps in order, keep the record dated, and treat every entry as something to verify rather than something to assume. If a number is missing from your own history, write down that it is missing instead of filling the gap with an estimate.

Why a written baseline comes before any comparison

Comparing DeFi costs without your own record is like weighing a parcel without a scale. You can read a protocol's documentation, a help centre article or a fee page, but you cannot tell whether the outcome you experienced matches what the page describes, because you never wrote down what you experienced. A baseline fixes that by capturing your own reward events and fee events in one place, with dates, amounts in the units you actually received, the network used, and the route or contract involved. Once that exists, official pages become a reference point rather than a starting point.

The baseline also protects you from a common trap: remembering only the good outcomes. People tend to recall a reward that felt generous and forget the small costs that surrounded it, including network fees paid at the time, conversion steps, and the delay between claiming and receiving. Writing these down while they are still visible in your history removes that bias. Start with the last three months if your history is long, and note the date you began recording so future entries stay consistent.

Keep the baseline descriptive. It should say what happened, not what you hope will happen. Avoid columns for expected returns, projected yields or target amounts, because those turn a record into a forecast and make the whole file harder to trust later.

Setting up the columns and the units you will record

A workable baseline needs fewer columns than most people expect. Use: date, platform or protocol name, action type such as deposit, withdrawal, claim, swap or reward distribution, asset symbol, amount in that asset's own units, network used, fee paid and the asset the fee was paid in, and a free-text note for anything unusual. Add a source column where you paste the exact page or document you checked, described in words rather than as a link, so you can find it again from the same help centre or documentation section.

Record amounts in the asset's native units and add a separate column for the reference value on the day of the event if you want one, clearly labelled as a dated observation rather than a fixed figure. Never mix units inside a single column. If a reward arrived in one asset and a fee was charged in another, they belong in separate rows or separate columns, because combining them silently creates a number that means nothing.

Decide on one date format and one decimal convention before you start, and write both at the top of the file. Inconsistent dates are the single most common reason a baseline becomes unusable after a few months. If you operate across several networks, keep the network name in its own column rather than burying it in the notes, so you can filter later without re-reading every row.

Filling the baseline from your own history and official pages

Pull your history from the platforms and wallets you already use, working backwards from the most recent event. For each event, copy the date, the asset, the amount and the network exactly as shown, then open the relevant official page to confirm what the event was called and how the platform describes it. The help centre of the platform you used is the right place to check terminology, and the fee page is the right place to check how a charge is described, though the figures you record must come from your own history, not from the page.

Where your history shows a charge but you cannot tell what it was for, mark the row as unresolved and note the exact wording you saw. Do not guess. Unresolved rows are useful, because they tell you which question to ask next and which help centre article to read. If a platform has a documentation page for the specific product you used, read it alongside your history and note any term that does not match what you remember seeing.

When you finish a batch, count the rows and write the count and the date at the top of the file. This gives you a checkpoint. If a later batch produces a very different pattern, you will notice it immediately rather than months later when the details are gone.

Using the baseline to frame comparison questions

With the baseline written, comparisons become specific. Instead of asking whether one protocol is cheaper than another in general, you can ask a question your own record can answer: for the same action type, on the same network, with the same asset, what did I actually pay and receive, and how does the official fee page describe that charge. Write the question down next to the relevant rows before you go looking for an answer, so you do not drift into collecting information that does not address it.

Keep a short change log at the bottom of the file. Whenever you update the columns, change a unit convention, or correct an earlier entry, add a dated line saying what changed and why. This matters because a baseline that quietly changes shape over time cannot be compared against itself. The change log is also where you note when an official page was updated in a way that affects how you describe an event, without rewriting the historical rows.

Review the file on a fixed schedule, such as the first weekend of each month. During the review, resolve one or two unresolved rows, check that the units are still consistent, and confirm that the questions you wrote down are still the ones you care about. Stop and reassess if you find yourself adding rows for events you cannot verify, or if the file starts containing numbers you copied from somewhere other than your own history.

Risk boundary: DeFi Protocols Hub

Digital assets are volatile and derivatives can amplify losses. This website has no login, wallet connection, deposit form or customer-support chat. A referral link only records attribution; it does not guarantee access, pricing, rewards, approval or investment results. Availability can differ by residence, legal entity and product, so no regional access is assumed from language or branding alone.

Scenario checkpoint

• Create one file with fixed columns for date, platform, action, asset, amount, network, fee and fee asset, and write the date format and decimal convention at the top.
• Record each event in the asset's own units and keep rewards and fees in separate rows or columns rather than combining them.
• Mark any event you cannot explain as unresolved with the exact wording you saw, and leave the amount blank instead of estimating it.
• Check terminology against the help centre and fee descriptions against the fee page, but take every figure from your own transaction history.
• Add a dated change log line whenever you alter a column, a unit convention or an earlier entry.
• Review the file on a fixed schedule, resolve one or two unresolved rows, and stop if you catch yourself entering unverifiable numbers.