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

A DeFi position looks like one balance and is actually four things: the asset you deposited, the receipt or LP token you got back, the rewards accruing, and the exit that returns a different amount. A flat "DeFi" account loses all of it and cannot be reconciled. This guide structures the sub-accounts, hedged, because the recognition is an auditor judgement.

TL;DR

• A DeFi position has multiple legs: deposit, receipt/LP token, accruing rewards/fees, exit (often a different amount).
• A flat "DeFi" account collapses them into one unreconcilable number.
• Use sub-accounts mirroring the legs so each reconciles to on-chain state.
• Receipt/LP token vs underlying is a recognition/derecognition judgement — structure must support either conclusion, not hardcode one.
• Rewards/fees → distinct income and realized-result accounts, not an opaque position inflation.
• Position-level reconciliation to the protocol is the audit requirement. Framework-/fact-specific auditor judgement; not accounting advice.

One position, four legs

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

Liquidity-pool structure

Sub-accounts for: assets contributed, the LP/receipt token, accrued fees/rewards, and the realized result on withdrawal (which can differ from contribution due to 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 — the structure must support either conclusion, not hardcode one (see liquidity pool accounting).

Receipt tokens

A value-accruing receipt token (staking/deposit) is generally its own position sub-account, distinct from the original asset, with accrual per the model. Do not silently net the receipt token against the deposited asset — that hides the position and breaks reconciliation. Recognition of the receipt token vs 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), posting to distinct income and position accounts — not inflating the position balance opaquely. Timing/measurement is framework-/fact-specific, auditor-confirmed.

Reconcile to the protocol

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

Practical guidance

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

How vendor tools handle DeFi positions

Cryptio and Bitwave parse DeFi interactions into component legs and map them to configurable accounts. Confirm the tool keeps the receipt token, deposit, rewards, and exit as separate reconcilable accounts — the tool applies the structure; recognition/derecognition is an auditor judgement.

How Wag3s helps

Wag3s Ledger parses each DeFi interaction into its component legs (deposit, receipt/LP token, accrued rewards, exit), maps them to distinct reconcilable sub-accounts tied to on-chain state, with an audit trail and ERP export — while recognition/derecognition stays auditor-confirmed under the applicable framework. See the Ledger product page.

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

• A DeFi position is multi-leg: asset deposited, receipt/LP token received, rewards/fees accruing, exit returning a (often different) amount — a flat "DeFi" account is unreconcilable and unauditable
• Liquidity-pool sub-accounts: assets contributed, LP/receipt token, accrued fees/rewards, realized result on withdrawal (can differ from contribution via rebalancing); LP-token-as-new-asset vs continued-interest is a recognition/derecognition judgement — structure supports either
• Value-accruing receipt tokens tracked as their own position sub-account (not silently netted against the deposit); rewards/fees post to distinct income and realized-result accounts (recognition-on-control), not opaque position inflation
• Each leg must reconcile to on-chain state (position-level reconciliation) — inability to reconcile position-by-position is the recurring DeFi audit weakness; recognition framework-/fact-specific, auditor-confirmed — not accounting advice