How Vaultonaut calculates your earnings

Vaultonaut does not take a protocol's number and dress it up. What your position earned is worked out again from your own transaction history. This page describes how — closely enough that you could check a figure on screen yourself, and openly enough that you can see where the data does not stretch.

What gets calculated

For a public wallet address, Vaultonaut reconstructs, per vault:

the open position — shares held, and what they are worth in the vault's own units,
what that position has earned so far, in the vault's units and in your currency,
each vault's return on the amount deposited, and realised APY over time,
the history: value, net deposits and earnings for each day,
Merkl campaign rewards, per token and per vault, kept separate.

A vault's net APY is not calculated here; it is the protocol's own figure, passed through. There is a section on that below.

Data sources

Three vault protocols are analysed, plus Morpho's lending markets and one rewards source. Vaultonaut is not affiliated with any of them, and is neither commissioned nor endorsed by them.

Morpho — Vault V1 and V2, through Morpho's GraphQL API: the vault list, vault metrics, share-price history and an address's transaction log.
Morpho Lending Markets — individual variable-rate credit markets, through the same API. A market has no vault address of its own: every market on a chain lives inside the one Morpho Blue contract and is addressed by its market id, the hash of its parameters. The API publishes no share price for a market — it is formed from the amount lent divided by the shares issued, which is exactly how the contract itself converts between the two.
Accountable — credit and RWA vaults, through their own API. Positions, movements and share prices for these vaults come from that API alone.
Yuzu — leveraged ERC-4626 vaults. The vault list and daily APY come from Yuzu's API; the transaction log is additionally read straight off the chain, scanning the vault contract's events in block windows.
Ember — vaults run by outside managers, through Ember's own API: vault list, APY, TVL and share-price history. Covered are the deployments on Ethereum, Base and Pharos; Ember's Sui vaults are not, because a wallet here is an EVM address. Ember's API returns nothing for wallets, so the holding is read from the contract and the transaction log from the vaults' own events, fetched through Routescan (Ethereum) and Blockscout (Base) — per vault, not per wallet. Pharos has no such index: the holding there is known, but its yield is withheld rather than estimated.
Merkl — campaign rewards: earned, claimed, claimable and pending, per token.
An Ethereum RPC endpoint — for holdings that can be checked on-chain directly (see below), and for the Yuzu log scan; plus the public Base and Pharos nodes for Ember holdings.
Exchange rates: a current daily rate for displaying amounts in euro, and the ECB reference rate of the relevant date for the tax report, because an amount received in March has to be converted at March's rate rather than this morning's.

One distinction the pages themselves also make: Morpho, Yuzu and Ember vaults are ERC-4626, so a holding can be recomputed at the contract independently of the API. Accountable's contracts are not — there the figures rest on that API alone, and the pages showing them say so rather than implying a cross-check that never happened.

If one protocol is unreachable, the rest is still shown and the gap is named. Only when no source answers at all does the page show an error instead of a total that is quietly short.

Deposits and withdrawals

Everything starts from the address's transaction log, sorted by time and by position within the block. A deposit adds to what went in, a withdrawal to what came out — both in the vault's own units, as whole integers at the token's precision. No exchange rate is applied at this stage, so no rounding error can accumulate across the history.

Shares that arrive or leave by transfer are the exception. A transfer names shares, not an amount in the vault's units, so its value has to come from the share price at that moment: incoming shares count as a deposit at what they were worth on arrival, outgoing ones as a withdrawal at what they were worth on the way out. That position is marked — the figure is usable, but it rests on an inferred price rather than a price anyone paid.

The earnings figure

Because earnings are never recorded anywhere, they are reconstructed from what went in and what came out:

earnings  =  current holding
          +  everything ever withdrawn
          −  everything ever deposited

All of it in the vault's own units. The identity is exact and price-independent — it holds for 100 USDC exactly as it holds for 100 WBTC. A price is applied afterwards, for display only.

A single vault's return in the positions table is measured against everything ever deposited, not against the current holding. For the whole portfolio that ratio does not work: money moved between vaults counts as a deposit every time it lands, and the ratio shrinks towards zero. The dashboard therefore shows realised APY instead — earnings per day of capital at work, annualised, see below.

The history runs the same calculation per day: shares replayed from the log, valued at that day's share price, net deposits subtracted. A day's earnings are the tokens added that day at that day's price — not the difference from the day before, which would book every price move on everything earned earlier as income too. Days are aligned to midnight UTC. Only today is valued differently — from the holding the vault itself reports right now, rather than from the series. Otherwise the curve would end on the last published price and sit below the figure the dashboard gives for the same moment.

So the reckoning is in UTC and the display is in Vienna time. The sources keep their daily series in UTC, where a day is always exactly 86,400 seconds long — Central European days are not, twice a year. Dates on screen, by contrast, are fixed to Vienna wherever you open the page: a date means the same thing to every reader, and the tax report is stated in the zone whose tax law it is written for. At the boundary between two days the two can differ by an hour or two.

Net APY and realised APY

These are two different numbers, and telling them apart is the reason this tool exists.

Net APY is the protocol's own statement about the vault, not about you, and Vaultonaut passes it through unchanged. “Net” there means after the vault's fees and including the incentives the protocol itself reports — the same rate excluding those incentives sits beside it as the base APY. It is forward-looking and describes what the vault is paying now. It says nothing about your position.

Realised APY is Vaultonaut's own, computed backwards from your history:

realised APY  =  earnings over the window
                 ───────────────────────────  ×  365 / days
                 avg. value over that window

Annualised simply, not compounded: the windows are short (7 or 30 days), and compounding a noisy sample inflates the headline more than it informs anyone. While a window is not yet full, no figure is shown at all — otherwise two days of earnings would be divided across a whole year.

For the overall figure, only days with capital actually at work count, so a period spent half empty is not averaged in as “earned nothing”. Below a cent of average value no rate is reported at all: on the dust left by a closed position, any percentage is arithmetically flawless and meaningless.

Why rewards are kept apart

Merkl campaign rewards are never folded into vault earnings. They are a different thing in every way that matters:

They pay out in a different token from the vault's.
They follow the campaign's schedule, not the share price.
They have to be claimed. Until they are, they sit outside the holding the vault reports — and claiming happens at Merkl, not here.

So they are tracked per token and per vault, split into earned, claimed, claimable and pending. Adding them into an earnings total would mean summing a claimed amount with a promised one and reporting the result in a unit neither of them is denominated in.

One overlap worth knowing about: the vault's net APY described above already includes the incentives the protocol reports. That rate is the protocol's projection; the reward figures in Vaultonaut are measured amounts from Merkl. They answer different questions, which is why they are never netted against each other.

When the history does not reach

The calculation above stands or falls with a complete transaction log. Where it is incomplete there are two possible answers, and showing a number anyway is the wrong one. With the deposits missing, the identity reports the entire holding as gain.

Earnings are withheld entirely when:

the wallet holds shares for which the log contains no transaction at all — the position was entered outside the window that was read;
the log was truncated, so earlier deposits exist but were not fetched;
a transfer could not be valued, because no share price is known for that vault at that moment.

They are marked but still computed where shares moved by transfer and could be valued. A withholding applies to exactly the vaults affected; the same wallet's other positions are reported normally. Where a total is partial for this reason, the interface says so instead of summing around the hole.

The charts work the same way: a vault with no price series does not enter the curve. An invented flat line would be a shape in a chart that never existed.

That is the rule behind everything on this page: better an empty field with a reason than a number that looks plausible and is wrong.

How often data refreshes

Each kind of data has its own lifetime. Within it, an answer already fetched is reused rather than asked for again:

Positions — 60 seconds.
Transactions — 2 minutes.
Vault list and vault detail, and so APY and vault size — 5 minutes.
Share-price history — 15 minutes.
The figures on the landing page — 10 minutes.

How current the protocols' own data is depends on their indexers, which Vaultonaut has no influence over.

Tax report: assumptions and limitations

The tax report is not a separate calculation — it is the same transaction history this page describes above, applied to a tax year: the same deposits and withdrawals, the same share price, the same handling of gaps.

Tax classification of vault share tokens: with many DeFi vaults, depositing an asset gets you back a vault share token — an ERC-4626 share, technically, on an ERC-4626 vault, or a comparable ERC-20 claim on other protocols. That token represents an economic claim on a share of the vault's assets.

The tax classification of such a share token does not follow from its token standard alone. In particular, being technically an ERC-20 or ERC-4626 token does not automatically make it a cryptocurrency within the meaning of § 27b Abs 4 EStG — that definition requires, among other things, that the token be accepted as a means of exchange. Austria's Federal Ministry of Finance explicitly states that so-called asset tokens, which represent real underlying assets, do not fall under the § 27b EStG cryptocurrency definition for lack of that property.

This report treats the tracked vault shares as cryptocurrency within the meaning of § 27b EStG and records the yield as it accrues: it counts as received on the day it arises. The reasoning is that a vault lends out what was deposited and the rising share price is precisely the interest that accrues on it — so the interest has already been received and is merely left in place. A later withdrawal then moves capital that has already been accounted for and is no longer a taxable event of its own; otherwise the same yield would appear twice.

This is an interpretive choice, not a statement of law. The opposite view is also widely held: that an accumulating share is a single asset whose appreciation is realised only on withdrawal, which would make a year without a withdrawal a nil year. The difference is substantial, and which view holds in a given case belongs in a conversation with a tax adviser. Anyone following the realisation view cannot use this report unchanged.

Vaultonaut does not make a binding tax classification of any individual vault share token — that is a legal judgment that depends on the specific protocol's design and cannot be read off the token standard. Where the cryptocurrency classification does not hold for a given vault share token — because it is better characterised as an asset token or some other kind of asset, say — different rules can apply, particularly around the timing of realisation and the valuation method, than the ones shown here.

Valuation happens day by day, in two steps: the vault's own share price gives that day's yield in USD, the ECB reference rate for the same day converts it to euro. Both rates are the ones that applied on the day, not today's — an amount that accrued in March is valued at March's rate. A month's line in the report is the sum of its days converted that way, not the month's amount at a month's rate.

What the report does not decide on its own:

Whether a given vault share token is properly classified as cryptocurrency, as an asset token, or otherwise — see above.
Whether a transfer out of a vault is a disposal or a move between two wallets you own. The transaction log does not distinguish the two. The shares leave the holding and accrue nothing from that day on, but no disposal is recorded.
Whether the person tracking the address is a taxpayer in Austria at all. A transaction log has no way of knowing that.
Whether and how a figure belongs on a particular tax return.

What gets reconstructed is a wallet's history: which shares it held when, and what those shares were worth day by day. The one thing taken from a third party is the ECB reference rate — the only figure in the report that does not follow from the share price and the transaction log themselves.

Where this method is weaker than the realisation view deserves saying: a withdrawal stands onchain as an amount and is not negotiable. Accruing yield has no such event — it is derived from the published share price and inherits that price's quirks. Where a vault restates its price only every few days, those days' yield appears in one lump on the reporting day; if such a day falls at the turn of the year, the amount moves between two tax years.

Fees are the exception: trading and withdrawal fees that raise the taxable base are entered by the taxpayer themselves. They appear in no onchain log and are taken at face value.

Where yield cannot be valued — no share price for the vault, no ECB rate for the day, a truncated log — it stays out of the total and the affected vault is named, rather than guessing a plausible figure. That weighs more here than under the realisation view: a vault with no price series contributes no yield at all, so the year's total is short. See “When the history does not reach”.

The report prepares data; it is not tax advice. Whether and how a figure belongs on your own return is a question for a tax adviser.

Limits

Coverage is vaults on Morpho, Accountable, Yuzu and Ember (not its Sui vaults), plus Merkl rewards. Other DeFi positions — other protocols, LP positions, staking, tokens simply held — do not appear, including in the totals.
Not every protocol is on every chain, and not every feature is available for every vault; share-price history in particular depends on what the source serves.
Historical data is only as complete as the sources make it. When the history does not reach describes what happens then.
An EVM address is expected: 0x followed by 40 hex characters. ENS names are not resolved.
A reconstructed past is not a statement about the future. Projections on the analytics pages are labelled as such and are not a promise.
Vaultonaut is an analytics tool and reads only. It holds nothing, signs nothing and can move nothing.
Not financial, tax or legal advice. The tax report prepares figures under Austrian law; whether and how they belong in your return is for your tax adviser to judge. The terms of use apply in addition.

Last updated: September 30, 2026