Supplied 0.84992827 WBTC — collateral posted, not a disposal
Aave V3 · lending
Aave V3 lending accounting, booked from the Pool — not the token sender.
Supply, withdraw, borrow, repay — each is a distinct accounting event, and none of them is a sale. But a tool that reads only ERC-20 Transfer logs gets them wrong, because in an Aave action the affected account isn't the token's sender. The clearest failure: a borrow shows tokens arriving in your wallet and gets booked as a phantom inflow of income — when it's a liability you now owe.
The problem
The logs point at the wrong account, and call debt “revenue.”
Aave lending settles through aTokens and debt tokens, and the transfers can be router-wrapped, so the raw legs rarely line up with what economically happened. A supply looks like sending tokens away (a disposal) rather than posting collateral you still own. A borrow looks like free money landing in your wallet. A repay and a withdraw get mixed up with ordinary transfers.
Booked naively, a treasury that drew a 90,000 USDT loan against its WBTC reports $90k of revenue it never earned — and no liability. Someone unwinds that by hand every close.
What Intentio resolves
Each lending action, read from the Pool's own event.
Intentio reads the Aave V3 Pool's own Supply / Withdraw / Borrow / Repay events — where the reserve (the asset) and the affected account come straight from the event, not the transfer legs. So a borrow books as a liability draw, a supply as collateral posted (still yours), a repay and withdraw as what they are — attributed to the right account, with no invented income.
Real transactions
Verify it on real mainnet lending.
Not mockups — real Ethereum mainnet transactions run through the same live engine the demo serves. Open them on Etherscan and you'll see why a log-only importer mis-books each one; Intentio resolves them from the Pool event.
Borrowed 90,000 USDT — one line, not a phantom $90k inflow
Where the line is
It gets the action right; you keep the policy calls.
Intentio recovers the correct lending action and clean, categorized rows. How you classify the liability and collateral on your chart of accounts, how interest accrual is recognized, and any jurisdiction-specific treatment are policy and tax decisions you keep. It's the evidence and normalization layer, not your accounting brain.
Today v0 resolves one lending action per transaction. A transaction with several lending events in it (e.g. a batched deposit) isn't force-fit — it abstains, with a reason, rather than mis-book. Multi-action support is next.
The handoff
Into the accounting tool you already use.
The resolved row exports as a standard CSV / journal, ready to review and upload to your accounting service (tool-specific import profiles as we go). It's read-only: public addresses only, no wallet connect, no signing, no custody.