DeFi Position Chart of Accounts: LP, Staking, Lending Sub-Accounts

A DeFi position looks like one balance and is really four things at once: the asset you deposited, the receipt or LP token you got back, the rewards accruing on it, and the eventual exit that often returns a different amount. A flat "DeFi" account collapses all of that into a single number that ties to nothing on-chain. This is the DeFi spoke of the chart of accounts design cluster: how to break a position into sub-accounts that each reconcile to protocol state, across liquidity pools, lending, and staking. How each leg is recognised is an auditor judgement, so the structure is described rather than prescribed.

The position in brief

• A DeFi position has multiple legs: a deposit, a receipt or LP token, accruing rewards or fees, and an exit (often a different amount).
• A flat "DeFi" account collapses them into one number that cannot be reconciled.
• Use sub-accounts mirroring the legs, so each reconciles to on-chain state.
• Receipt or LP token versus the underlying is a recognition/derecognition judgement, so the structure must support either conclusion rather than hardcoding one.
• Rewards and fees post to distinct income and realized-result accounts, not an opaque inflation of the position balance.
• Position-level reconciliation to the protocol is the audit requirement. It is a framework- and fact-specific auditor judgement, and this is not accounting advice.

One position, four legs

A single "DeFi" account cannot be reconciled to the protocol or audited, so the chart of accounts needs sub-accounts mirroring the legs — the DeFi extension of chart of accounts design; see DeFi position reconciliation.

Liquidity-pool structure

Use sub-accounts for the assets contributed, the LP or receipt token, accrued fees and rewards, and the realized result on withdrawal (which can differ from the contribution because of pool rebalancing). Whether the LP token is a new asset or a continued interest in the underlying is a recognition/derecognition judgement under the applicable framework, so the structure must support either conclusion rather than hardcode one (see liquidity pool accounting).

Receipt tokens

A value-accruing receipt token received for staking or depositing is generally tracked as its own position sub-account, distinct from the original asset, with the accrual reflected per the model. Do not silently net the receipt token against the deposited asset, because that hides the position and breaks reconciliation. The recognition of the receipt token versus the underlying is an auditor judgement, consistent with liquid restaking token accounting.

Rewards and fees

Accruing rewards and earned fees feed reward income and the realized result, following the recognition-on-control principle (see crypto revenue and expense accounts), and should post to distinct income and position accounts rather than inflating the position balance opaquely. The timing and measurement is framework- and fact-specific, and auditor-confirmed.

Reconcile to the protocol

The point of position sub-accounts is that each leg reconciles to on-chain state — deposited amount, receipt-token balance, accrued rewards, withdrawn amount — so the books tie to the protocol rather than to a self-reported total. A structure that cannot be reconciled position by position is the recurring weakness auditors find in DeFi accounting, which is why the sub-account design is auditor-confirmed.

Practical guidance

1. Never use a flat "DeFi" account — model the legs.
2. Create sub-accounts for the deposit, the receipt or LP token, accrued rewards and fees, and the realized exit result.
3. Don't net the receipt token against the deposit — keep the position visible.
4. Support either recognition conclusion (new asset versus continued interest).
5. Post rewards and fees to distinct income and realized accounts, with no opaque inflation.
6. Reconcile each leg to on-chain state, and confirm recognition with your auditor. This is not accounting advice.

Configuring a tool for DeFi positions

Cryptio, Bitwave and similar sub-ledgers parse DeFi interactions into component legs and map them to configurable accounts. The capability to confirm when choosing one is that it keeps the deposit, the receipt token, the rewards, and the exit as separate, individually reconcilable accounts, rather than collapsing the position into a single balance. The tool applies the structure; recognition and derecognition are an auditor judgement.

Where Wag3s fits

Wag3s Ledger parses each DeFi interaction into its component legs (deposit, receipt or LP token, accrued rewards, exit), maps them to distinct reconcilable sub-accounts tied to on-chain state, with an audit trail and ERP export. Recognition and derecognition stay auditor-confirmed under the applicable framework; Ledger is built to give the entity's accountant and auditor a position-by-position trail to review, not to make the recognition call itself. See the Ledger product page.

Sample chart of accounts: three DeFi position types

The accounts below illustrate the sub-account structure for three common DeFi position types. Account numbers and names are illustrative; the design must be adapted to the entity's CoA structure and confirmed with the auditor.

Liquidity pool position (e.g. Uniswap v3 USDC/ETH)

Each leg reconciles to a distinct on-chain state: the pool contract records the contributed amounts and the fees separately; the LP token balance is on-chain. A controller can verify each sub-account line against the protocol state.

Lending position (e.g. Aave v3 USDC supply)

The aUSDC account is the primary balance; it grows with each rebasing event. The distinction from a non-rebasing receipt (where the account balance stays fixed and a separate accrual account grows) is important — the accounting signal is in different places.

Staking position (e.g. rETH value-accruing receipt)

The rETH account is tracked at fair value (exchange rate × units held), with the change flowing through remeasurement or income depending on the framework. The key principle: the unit count in account 1571-S stays constant over time; only the per-unit value changes.

The reconciliation test for each sub-account

For each sub-account in the DeFi position structure, there should be a corresponding on-chain state that the account can be reconciled to:

• LP token balance on-chain → account 1520-LP balance in the ledger
• Aave aUSDC balance per protocol API → account 1551-L balance in the ledger
• rETH units held in wallet → account 1571-S units × current exchange rate

Any discrepancy between the on-chain state and the ledger sub-account balance is a break that must be investigated and resolved under the standard reconciliation workflow. The ability to run this reconciliation per sub-account is the operational purpose of the multi-leg CoA structure — it is not merely an accounting organisation choice, but a control that makes the books auditable.

Further reading

• Crypto Chart of Accounts Design
• Liquidity Pool Accounting
• DeFi Position Reconciliation
• Liquid Restaking Token Accounting (LRT)
• Crypto Revenue and Expense Accounts
• DeFi Accounting

Sources

• The multi-leg structure of a DeFi position (asset deposited, receipt or LP token received, rewards or fees accruing, and an exit returning an often different amount) and the matching sub-account design are chart-of-accounts design practice, not a single prescribed standard. A flat "DeFi" account is unreconcilable and unauditable.
• Whether an LP or receipt token is a new asset or a continued interest in the underlying is a recognition/derecognition judgement under the applicable framework, so the structure supports either conclusion; the fuller treatment is in liquidity pool accounting and liquid restaking token accounting.
• Rewards and fees post to distinct income and realized-result accounts following the recognition-on-control principle (see crypto revenue and expense accounts), not an opaque position inflation. Each leg must reconcile to on-chain state; recognition is framework- and fact-specific and auditor-confirmed. This is not accounting advice.