Self-custody answers one important question: who controls the private keys?
It does not answer another: what, exactly, do those keys control?
As decentralized finance has expanded, wallets have accumulated assets that represent claims on other assets rather than the underlying property itself. Wrapped tokens, liquid staking tokens and rehypothecated assets may look like ordinary balances in a wallet interface. Economically, however, they can depend on issuers, smart contracts, collateral policies, redemption mechanisms and additional protocols.
That distinction is becoming harder to ignore. CoinGecko announced changes to how it categorizes and ranks rehypothecated tokens, saying its methodology needed to evolve alongside DeFi. Separately, security firm Blockaid attributed the reported $9.3 million drain from a More Markets lending reserve to an attacker’s use of an Ankr liquid staking token and an efficiency mode, or E-mode, to overborrow.
The incidents are not identical, and a market-data methodology change is not itself a security event. Together, though, they highlight a custody problem that wallet ownership alone cannot solve: users need to understand the chain of claims behind the token they hold.
Keys protect control, not asset quality
The case for self-custody is straightforward. A user who controls the keys does not have to rely on an exchange to approve a withdrawal, remain solvent or keep an account available.
But “not your keys, not your coins” can become misleading when applied too broadly. Keys establish authority over an onchain position. They do not guarantee that the position is redeemable at par, backed as expected or insulated from failures elsewhere in the stack.
A wrapped token may depend on an issuer or bridge holding the original asset. A liquid staking token may represent staked collateral plus a protocol-defined claim on rewards and withdrawals. A token deposited into another protocol can become collateral for a new receipt token. If that receipt is then used elsewhere, another layer is added.
The wallet holder still controls the final token. Yet the value of that token may depend on every layer underneath it continuing to function.
That is a different security model from holding a network’s native asset directly. It introduces questions that a seed phrase, hardware wallet and carefully verified address cannot answer:
- Who issued the token? - What asset or position supports it? - Can it be redeemed directly? - Which contracts govern that redemption? - Has the token been deposited, wrapped or pledged again? - What happens if its market price separates from its expected value? - Which lending protocols accept it as collateral, and under what assumptions?
These are asset-level security questions. They belong beside key management in any serious self-custody process.
Rehypothecation makes wallet balances harder to read
Rehypothecation generally involves reusing an asset or claim in another financial arrangement. In DeFi, that can produce tokens representing positions that are already based on another tokenized position.
CoinGecko’s planned treatment of rehypothecated tokens matters because market capitalization and ranking can make economically related assets appear more independent than they are. Counting every layer without sufficient distinction can obscure the fact that several tokens may trace back to the same underlying pool of collateral.
For wallet users, the concern is not merely whether an asset receives the right market-cap ranking. The larger issue is whether portfolio software clearly distinguishes a base asset from a layered claim.
A wallet may show a ticker, unit balance and dollar estimate without displaying the full dependency structure. Two positions with similar displayed values can carry very different risks. One might be a native asset under direct key control. The other might be a receipt token dependent on a staking provider, a lending market and a liquidity venue.
That complexity becomes especially important during stressed markets. If redemption slows, liquidity contracts or a protocol changes its treatment of collateral, the displayed balance may remain unchanged even as the practical ability to exit deteriorates.
Dollar values in wallet software should therefore be treated as estimates, not assurances. A quoted price does not establish that the entire position can be redeemed or sold at that level.
Lending settings can turn complexity into losses
The More Markets event shows how layered collateral can interact with protocol configuration.
According to Blockaid’s account reported by Cointelegraph, an attacker used an Ankr liquid staking token and E-mode to overborrow from More Markets, draining approximately $9.3 million in WFLOW from a lending reserve.
E-mode is designed to improve capital efficiency for assets treated as closely related. That efficiency relies on assumptions about collateral behavior, pricing and correlation. When those assumptions or their implementation fail, the feature can amplify losses rather than simply improve borrowing capacity.
The immediate responsibility for lending parameters and contract security sits with protocols and their operators. But users also need to recognize what protocol exposure means for custody.
A token deposited into a lending market is no longer secured only by the owner’s wallet practices. Its safety can depend on the market’s collateral factors, oracle design, liquidation process, asset classifications and withdrawal liquidity. Even if the user never borrowed anything, a reserve-level loss can affect the environment in which the deposit sits.
Self-custody should therefore be understood as a spectrum of arrangements rather than a binary state. An asset held at a personal address, a token supplied to a lending contract and a receipt token reused as collateral may all be controlled through the same wallet. They do not carry the same dependency profile.
Build a claim map before signing
Users do not need to reproduce a protocol audit before making every transaction. They do need a repeatable way to identify when a simple-looking token is actually a chain of claims.
A practical claim map can start with four layers.
1. Identify the native asset
Write down the asset at the bottom of the structure. Do not rely only on the ticker displayed by a wallet or portfolio tracker.
Determine whether the token is native to the network, wrapped from another network, issued against reserves or generated by depositing another token into a protocol.
2. List every intermediary
Record each issuer, bridge, staking system, lending market or vault involved between the underlying asset and the wallet balance.
If the path cannot be explained clearly, the position is not yet understood well enough to size responsibly. Complexity is not automatically unacceptable, but invisible complexity is difficult to manage.
3. Separate control from redemption
Confirm what the private key actually permits. It may authorize a transfer of the receipt token without providing a direct route to the underlying asset.
Users should distinguish among transferring a token, selling it on a market and redeeming it through its issuing protocol. Those are separate exit paths with different dependencies.
4. Record the failure conditions
For each layer, note what would prevent an orderly exit. Relevant conditions can include a contract failure, unavailable redemption, impaired liquidity or a lending market’s inability to process withdrawals.
This exercise does not predict which failure will occur. Its purpose is to show how many systems must continue operating for the wallet balance to retain its expected utility.
Keep operational security and financial security separate
Traditional wallet guidance concentrates on phishing, malicious approvals, compromised devices and seed-phrase theft. Those threats remain fundamental. A carefully researched asset can still be stolen through a bad signature.
But approval hygiene and asset analysis should be separate controls.
Before signing, users should verify the destination contract and the authority being granted. After depositing, they should track what claim was received and whether that claim introduces additional dependencies. Revoking an unnecessary token approval can reduce future wallet risk, but it cannot remove the economic exposure created by an existing protocol position.
Similarly, a hardware wallet can protect signing keys while leaving a user exposed to an unsafe contract or fragile collateral design. Secure signing proves that the authorized person approved the transaction. It does not prove that the transaction was financially sound.
Institutions face the same distinction at a larger scale. A qualified custody arrangement can protect keys and enforce transaction policies, while the assets under custody still carry smart-contract, issuer and redemption risks. Custody reporting that lists only tickers and market values may miss those dependencies.
The grounded takeaway
Crypto users should not abandon wrapped assets, liquid staking tokens or DeFi receipt tokens simply because they involve multiple layers. These instruments can serve legitimate purposes, including moving value across networks, representing staked positions and supplying collateral.
But they should not be treated as interchangeable with native assets merely because they appear beside them in the same wallet.
CoinGecko’s methodology change acknowledges that rehypothecated tokens require different treatment in market data. The reported More Markets drain illustrates how a layered token and a capital-efficiency setting can combine into a material security problem.
The lesson for custody is narrow but important: key ownership protects authority over a token, not the integrity of every claim beneath it. Before signing, users should know whether they are holding an asset, a claim on an asset or a claim built on another claim.