Something like

The first layer: Associated Token Accounts

SPL tokens — the standard token standard on Solana — don't live in a wallet the way a balance might on other chains. Each token holding is tied to an Associated Token Account, a dedicated account derived from the wallet address and the token's mint. That account is where the balance actually sits.

The design has a clear upside. Because the account address is deterministic, a wallet can find its token balance without scanning the network. There's no lookup table, no index. The address is just math.

But it also means builders can't treat a token balance as a simple number attached to a user. Every transfer, every balance check, every approval touches an account that has its own state, its own rent, its own lifecycle.

The second layer: DeFi's custom accounts

DeFi protocols rarely work with raw balances alone. A lending platform needs to track collateral, debt, and liquidation thresholds. A liquidity pool needs to track shares, fees, and price data. None of that fits inside an Associated Token Account.

So protocols build their own account structures. These custom accounts hold the protocol-specific state that a position requires. They're designed per protocol, per product, sometimes per pool.

That's where the dual layer comes in. A user's position in a DeFi protocol isn't just a token balance. It's a token balance in an ATA, plus a custom account that references that balance and adds protocol logic on top.

What the dual layer means for builders

For a developer, the complexity shows up in the details. Initializing a position means setting up both the ATA and the custom account. Updating a position means writing to both. Closing a position means cleaning up both.

Transfers are where it gets tricky. Moving tokens out of a DeFi position isn't a single instruction. It's a sequence: update the custom account, update the ATA, verify the state matches. Get the order wrong and the transaction fails — or worse, leaves the accounts out of sync.

The dual layer also complicates account management. ATAs have rent and can be closed, but closing one that a DeFi protocol references can break the protocol's accounting. Builders have to think about account lifetimes, not just balances.

None of this is new. Solana's account model has always been explicit about state. But the combination of ATAs and custom DeFi structures means builders are managing two layers of state for what is, in the end, one user position.

The practical effect is a tax on development time. Every feature that touches a token balance has to account for both layers. Every audit has to check both. Every upgrade has to consider both.

For teams building on Solana, the question isn't whether the dual layer exists — it's how to build around it without letting the complexity slow them down.

Solana developers building DeFi applications are working with two account systems at once, and the friction is baked into the chain's design. SPL tokens use Associated Token Accounts, and DeFi protocols layer custom account structures on top — a combination that adds a dual layer of complexity for builders.

The first layer: Associated Token Accounts

SPL tokens — the standard token type on Solana — don't live in a wallet the way a balance might on other chains. Each token holding is tied to an Associated Token Account, a dedicated account derived from the wallet address and the token's mint. That account is where the balance actually sits.

The design has a clear upside. Because the account address is deterministic, a wallet can find its token balance without scanning the network. There's no lookup table, no index. The address is just math.

But it also means builders can't treat a token balance as a simple number attached to a user. Every transfer, every balance check, every approval touches an account that has its own state, its own rent, its own lifecycle.

The second layer: DeFi's custom accounts

DeFi protocols rarely work with raw balances alone. A lending platform needs to track collateral, debt, and liquidation thresholds. A liquidity pool needs to track shares, fees, and price data. None of that fits inside an Associated Token Account.

So protocols build their own account structures. These custom accounts hold the protocol-specific state that a position requires. They're designed per protocol, per product, sometimes per pool.

That's where the dual layer comes in. A user's position in a DeFi protocol isn't just a token balance. It's a token balance in an ATA, plus a custom account that references that balance and adds protocol logic on top.

Where the complexity shows up

For a developer, the complexity shows up in the details. Initializing a position means setting up both the ATA and the custom account. Updating a position means writing to both. Closing a position means cleaning up both.

Transfers are where it gets tricky. Moving tokens out of a DeFi position isn't a single instruction. It's a sequence: update the custom account, update the ATA, verify the state matches. Get the order wrong and the transaction fails — or worse, leaves the accounts out of sync.

The dual layer also complicates account management. ATAs have rent and can be closed, but closing one that a DeFi protocol references can break the protocol's accounting. Builders have to think about account lifetimes, not just balances.

A tax on development time

None of this is new. Solana's account model has always been explicit about state. But the combination of ATAs and custom DeFi structures means builders are managing two layers of state for what is, in the end, one user position.

The practical effect is a tax on development time. Every feature that touches a token balance has to account for both layers. Every audit has to check both. Every upgrade has to consider both.

For teams building on Solana, the question isn't whether the dual layer exists — it's how to build around it without letting the complexity slow them down.