Rebasing vs Non-Rebasing Token Tracking: Where the Yield Hides

The defining distinction here is the mechanism by which yield reaches you: a rebasing token delivers it as more units with no transfer, while a non-rebasing wrapper keeps the unit count fixed and delivers the same yield as a higher price per token. The two are economically identical and mechanically opposite, and a tracker that confuses them reports a fiction. This guide is the general model behind stETH/wstETH and aTokens, one spoke of the wider multi-wallet aggregation problem; for the canonical worked pair see Lido stETH vs wstETH.

The distinction that drives everything

• A rebasing token changes its balance with no transfer, growing units to reflect yield (stETH, Aave aTokens).
• A non-rebasing wrapper keeps the balance fixed and carries value in an increasing exchange rate or index (wstETH-style).
• Same exposure, opposite balance behaviour, so the tracker must detect which model applies before tracking.
• Confuse them and you get phantom inflows (a wrapper treated as rebasing) or a hidden gain (a rebasing token treated as static).
• A rebase is not a transaction, so read the derived balance or index, not transfer events.
• Tax of a rebase is jurisdiction-specific: track the signal, confirm tax separately.

Two ways to deliver the same yield

Yield-bearing crypto reaches the holder in one of two shapes:

stETH rebases (units grow daily); wstETH wraps it (fixed units, rising rate). An Aave aToken accrues interest into the balance (rebasing-style). Different tokens, one underlying pattern: yield as units versus yield as price.

Common examples in the wild

Understanding the pattern helps apply it beyond the stETH/wstETH pair:

frxETH is rebasing in the sense that staking rewards accrue as frxETH; sfrxETH is the non-rebasing ERC-4626 vault wrapper (fixed shares, appreciating exchange rate). The same tracking distinction applies: rebasing frxETH requires balance monitoring; sfrxETH requires rate monitoring at disposal.

Why confusing them produces a fiction

• A wrapper treated as rebasing makes the tracker invent inflows that never happened: the fixed balance "should" be growing, so it fabricates.
• A rebasing token treated as static makes the tracker hide the yield until disposal and misstate both balance and gain.

This is not cosmetic. It changes the reported position and, downstream, every gain or income figure derived from it. Detecting the model is the prerequisite, exactly as in the stETH/wstETH case generalised.

A rebase is not a transaction

The core challenge is that a rebase changes the balance with no discrete transfer, so transfer-only ingestion misses it. A correct tracker:

• for a rebasing token, reads the derived balance and attributes the change;
• for a wrapper, reads the index or exchange rate and values accordingly;
• never waits for a transaction that never comes.

The same "don't trust a transfer-only view" rule as Aave V3 accrual and DeFi position reconciliation.

Step-by-step: how to track rebasing and non-rebasing tokens

1. Classify each token by model. Maintain a registry mapping each token contract address to "rebasing" or "non-rebasing wrapper." At minimum: stETH → rebasing; wstETH → wrapper with rate; aTokens → rebasing (index-based); sfrxETH → wrapper with ERC-4626 rate; gOHM → wrapper.
2. For rebasing tokens: set up balance polling. Read balanceOf(owner) at each snapshot interval (e.g. daily). The increase since the previous snapshot, with no intervening transfer transactions, is interest accrual. Record it timestamped at the snapshot.
3. For rebasing tokens: subscribe to protocol rebase events. For stETH, the TokenRebased event gives the total rebase amount. For aTokens, the ReserveDataUpdated event signals a new liquidity index. These events trigger a balance recomputation for all holders.
4. For non-rebasing wrappers: record the exchange rate at acquisition. When wrap() is called (e.g. stETH→wstETH), read stEthPerToken() and store it with the wstETH quantity as the cost-basis reference rate.
5. For ERC-4626 wrappers: use convertToAssets(shares). ERC-4626 vault wrappers (sfrxETH, ERC-4626 Aave wrappers) expose convertToAssets(uint256 shares) which returns the current underlying asset equivalent. Record the rate at acquisition and at disposal.
6. At disposal or unwrap: recompute the exchange rate. Compare to the rate at acquisition to determine the unrealised gain in underlying units. Convert to fiat using the disposal-date price.
7. Flag the characterisation for each token type — rebasing accrual may be income, rate-gain on wrapper may be capital gain; confirm per jurisdiction.

Common errors and how to fix them

Error 1 — Treating aUSDC as a regular ERC-20. A tracker that records the aUSDC balance at supply and doesn't update until a Transfer event sees the balance frozen at the initial amount. Over weeks, the reported balance significantly understates the actual aToken balance including interest. Fix: use balance polling with read of balanceOf() (which applies the index), not event-driven tracking only.

Error 2 — Booking each daily stETH rebase as a new acquisition. A tracker that treats every balance increase as a "received tokens" event assigns a new cost basis to each rebase increment. Over a year of daily rebases this creates hundreds of phantom acquisition records that make FIFO calculations unstable. Fix: characterise rebases as accrual events with their own category, separate from explicit receive transactions.

Error 3 — Ignoring negative rebases. Some elastic-supply tokens (AMPL is the clearest example) can rebase downward — the balance decreases with no transfer. A tracker that only looks for increases will show a mystery outflow. Fix: always detect balance changes in both directions; a negative change with no transfer is a negative rebase event.

Error 4 — Not updating the wrapper rate on protocol upgrades. Protocols occasionally update the rate computation (e.g. Lido oracle upgrades). A cached exchange rate that is not refreshed on each portfolio snapshot may diverge from the live rate. Fix: always fetch the current exchange rate at the time of the snapshot, never use a rate older than the last oracle update.

Tax is jurisdiction-specific

Whether each rebase is income, and when, is jurisdiction-specific and must not be hard-coded either way (see staking rewards accounting and cost-basis methods). For a wrapper, the gain typically surfaces on unwrap or disposal via the rate change. The rebase or rate is the tracking signal; the tax characterisation is separate and adviser-confirmed. The cost-basis method stays the jurisdiction-mandated one, and the models only change where the value appears, units versus rate.

Practical guidance

1. Detect rebasing versus non-rebasing per token; never assume.
2. For rebasing tokens, read derived balances and attribute the accrual.
3. For wrappers, track the index or exchange rate; the gain realises on unwrap or disposal.
4. Never invent inflows for a fixed-balance wrapper, or treat a rebaser as static.
5. Confirm rebase tax treatment per jurisdiction and apply the mandated cost-basis method.
6. Reconcile to the protocol (rebase index or wrapper rate) with an audit trail.

Choosing a tool for rebasing and wrapped tokens

Koinly and CoinTracker both handle rebasing and wrapped yield tokens, but the model split is exactly where a generic importer slips. Before you trust a yield-token figure, confirm the tool:

• carries a per-token classification (rebasing versus wrapper), so stETH, aTokens and frxETH get balance reads while wstETH, sfrxETH and gOHM get rate reads;
• reads balanceOf() or the protocol rebase event for rebasers rather than freezing the balance at the last transfer;
• records the wrapper's exchange rate at acquisition (e.g. stEthPerToken() or ERC-4626 convertToAssets), so the gain is computable at disposal;
• detects negative rebases too (elastic-supply tokens such as AMPL can rebase downward), so a balance fall is read as a rebase, not a mystery outflow.

Model confusion is the recurring error across stETH, aTokens and their wrappers.

How Wag3s handles it

Wag3s Folio detects rebasing versus non-rebasing per token, reads derived balances for rebasers and the index or rate for wrappers, avoids both phantom inflows and hidden gains, and applies your jurisdiction's cost-basis method and rebase tax treatment, one consistent model across stETH/wstETH, aTokens and similar. See the Folio product page.

Further reading

• Lido stETH vs wstETH Tracking
• Aave V3 Position Tracking
• DeFi Lending Position Tracking
• Staking Rewards Accounting
• DeFi Position Reconciliation
• Crypto Cost Basis Methods 2026

Sources

• Lido — stETH and wstETH: the canonical worked pair, stETH's daily rebase (balance changes with no transfer) versus wstETH's fixed balance with value carried in the exchange rate.
• General pattern: rebasing tokens deliver yield as units (e.g. Aave aTokens accruing into the balance) and non-rebasing wrappers deliver it via an increasing index or rate. A rebase is not a discrete transfer, so the derived balance or index is read directly; rebase tax treatment is jurisdiction-specific and the cost-basis method is unchanged.