What Is Rehypothecation in DeFi? A Plain-English Explanation
The One-Sentence Definition You Need to Know
Rehypothecation in DeFi occurs when a protocol takes assets you deposited and reuses them — as collateral, as liquidity, or as yield-generating instruments — without transferring legal title to you or fully disclosing the chain of reuse.
That single sentence contains three distinct risks. Most explainers only address the first one.
Where the Term Comes From: TradFi Roots
The term originated in traditional finance, specifically in prime brokerage. When a hedge fund posts collateral to its prime broker, the broker has the right (under most standard agreements) to reuse that collateral for its own borrowing needs. The fund still "owns" the collateral on paper, but the broker has already pledged it elsewhere.
MF Global's 2011 collapse is the case most often cited. The CFTC charged that in its final days the firm unlawfully used nearly $1 billion of segregated customer funds to meet its own needs (CFTC). Strictly, that was misuse of segregated funds rather than contractual rehypothecation, but the lesson is the same. When the firm failed, customers couldn't withdraw funds they believed were sitting untouched. The U.S. Commodity Futures Trading Commission has since tightened its customer-protection rules, but the structural incentive to reuse deposited collateral never went away. It just migrated.
DeFi inherited the mechanic without inheriting the regulatory guardrails.
A Simple Analogy: When Your Collateral Gets Lent Out Again
You deposit 1,000 USDC into a protocol. The protocol issues you a receipt token — call it lpUSDC — representing your claim. That receipt token then gets deposited into a second protocol to generate yield, which issues its own receipt token representing the first receipt token. Meanwhile, the original 1,000 USDC is sitting as collateral against a loan somewhere in a third contract.
Three parties now have a claim touching your original deposit. You have a receipt. The second protocol has a receipt. The third has a collateral position. If any one of those links breaks, your ability to redeem the original 1,000 USDC depends entirely on whether the chain can unwind in order.
That's rehypothecation. Not theoretical. Actively deployed in several major DeFi protocols right now.
How Does Rehypothecation Show Up in DeFi Lending and Vaults?
It shows up wherever a deposit is put to work beyond simply sitting in a pool: lent to borrowers who post it as collateral elsewhere, routed by a vault into other protocols, or represented by a receipt token that is itself deposited or borrowed against. Each step adds another contract and another claim on the same asset.
Lending Protocols: Depositing Assets That Get Reused as Collateral
Consider a hypothetical user who deposits 2,000 USDC into a lending protocol on Solana, expecting it to sit in the pool and earn interest as borrowers draw from it. That's the standard model — and mostly accurate. Where rehypothecation enters is when the protocol takes that same USDC and uses it as collateral to borrow additional assets, which are then deployed into yield strategies to juice the advertised APY.
The depositor sees 12% APY and assumes it comes from borrower interest. Some of it does. A portion comes from yield strategies the protocol runs using their capital as collateral. The two are not always disclosed separately.
This isn't inherently fraudulent. But if the yield strategy underperforms or a collateral position gets liquidated, losses flow back to depositors who had no idea they were exposed.
Yield Vaults: When Your Deposit Leaves the Vault to Chase Returns
Some vault architectures are explicit about this: your deposit goes to work across multiple protocols, and the vault contract manages the routing. Kamino Finance and similar yield optimizers on Solana do this openly, and their documentation reflects it. The risk is disclosed, the strategies are described, and users can verify vault positions on-chain.
Other vaults are less forthcoming. The UI shows "earn yield on USDC" without specifying where that USDC goes after deposit. If the vault contract is routing funds to external protocols — even reputable ones — that's multiple smart-contract attack surfaces your capital is now exposed to, not just one.
Read the contract, not the landing page.
Receipt Tokens and the Chain of Reuse Risk
Receipt tokens (LP tokens, vault shares, deposit receipts) are powerful instruments. They let you prove ownership of underlying assets without holding the assets directly, and they're composable by design: you can deposit a receipt token somewhere else and earn a second layer of yield on top.
The problem emerges when the receipt token is accepted as collateral by another protocol, which then issues its own receipt token, which gets deposited again. Each layer adds a smart-contract dependency and a new counterparty. Solana's speed makes this kind of deep composability attractive; it also means a cascade can propagate faster than a human can react.
There is no standard limit, but every extra layer makes the reuse chain harder to unwind under stress, and some popular DeFi positions stack several layers.
What Happened in the Jupiter Lend Rehypothecation Debate?
In December 2025, Kamino's co-founder publicly argued that collateral in Jupiter Lend's vaults is lent out to other borrowers, so the vaults are not isolated as Jupiter's "zero contagion" messaging suggested. Jupiter's COO acknowledged that claim was "not a hundred percent correct" and said rehypothecation is where the yield comes from.
A Factual Summary of the Debate
In December 2025, a few months after Jupiter Lend launched in August, a public debate broke out over how its vaults reuse deposits (The Block). Jupiter had promoted its vaults as carrying "zero risk of contagion." Marius Ciubotariu, co-founder of the rival Solana lender Kamino, countered that when a user supplies SOL and borrows USDC on Jupiter Lend, the SOL is lent out to other borrowers, including leveraged loopers, so the depositor carries the risk of those positions.
Jupiter COO Kash Dhanda acknowledged the "zero contagion" post "was not a hundred percent correct" and confirmed the protocol uses rehypothecation, which he described as the source of yield. He argued the vaults are still isolated in the sense that each has its own configuration, caps, and liquidation threshold, while sharing a common liquidity layer. The underlying question was not whether lending pools reuse deposits, since most do, but whether depositors were told so in language they would recognize as a risk warning.
Both sides had a point.
Why the Crypto Community Reacted the Way It Did
The reaction wasn't purely technical. Context matters: Solana DeFi had already experienced several protocol failures in the 2022-2023 cycle, and the community carries real memory of "funds are safu" messaging that preceded losses. When a new lending product from a well-trusted aggregator appeared to obscure the reuse of deposited capital, the reaction was sharp — not because Jupiter Lend was obviously dangerous, but because the pattern was familiar.
Trust in DeFi protocols runs on disclosure, not reputation. A protocol with a strong track record that under-discloses a mechanic damages trust faster than a smaller protocol doing the same thing, precisely because users had higher expectations.
What the Controversy Revealed About DeFi Disclosure Standards
There are no mandatory disclosure standards in DeFi. None. A protocol can bury rehypothecation mechanics in a GitHub README that almost no depositors will read, and it's technically disclosed. A protocol can put it in the UI as a tooltip behind an information icon and claim full transparency.
What the Jupiter Lend debate crystallized is a question the broader DeFi ecosystem hasn't answered: at what point in the user journey does disclosure need to occur for it to count? Technical documentation isn't informed consent for depositors who can't read Rust.
Why Rehypothecation Risk Matters for DeFi Depositors
Counterparty Risk: You Are No Longer the Only Party With a Claim
You deposit SOL. The protocol lends it out. The borrower posts it as collateral somewhere else. Now three parties have overlapping claims on the same underlying asset. If the borrower defaults, liquidation proceeds flow to the lender (the protocol), which then covers depositor withdrawals. If liquidation is partial or the market moves faster than the oracle updates, the protocol absorbs a shortfall. That shortfall comes from somewhere — often the remaining depositors.
This isn't hypothetical. It's how bank runs happen in TradFi, and how liquidity crises happen in DeFi. The mechanism is the same; the speed is different.
Liquidity Risk: Can You Actually Withdraw When You Need To?
If your deposited assets are currently deployed as collateral in an open position, they cannot be returned to you instantly. The protocol has to unwind or source liquidity from somewhere else. During normal conditions, this happens invisibly: other deposits cover your withdrawal while the collateral position remains open. During stress conditions — a sharp market drop, a large coordinated withdrawal, a cascade liquidation nearby — that buffer disappears.
Withdrawal queues on lending protocols are not a bug. They are a direct consequence of rehypothecation. When you see a protocol with a "withdrawal may be delayed" notice in its UI, that delay exists because your assets are not sitting idle.
Cascade Risk: How One Liquidation Can Affect Many Depositors
Consider a hypothetical: 400,000 USDC sits in a vault. The vault manager uses it as collateral on a perps protocol to run a delta-neutral strategy. SOL drops 20% in four hours during the Asian session. The collateral position hits its liquidation threshold. The liquidation triggers a sell order through Jupiter routing; slippage at that volume pushes SOL down another 2%, triggering other positions on the same protocol that were near their thresholds. Two of those positions used receipt tokens from the original vault as collateral.
The original vault depositors now face losses that originated in someone else's position, propagated through a protocol they didn't deposit into, because a receipt token that represented their assets was circulating as collateral elsewhere. That's cascade risk. It doesn't require a hack or a scam — just correlated positions and thin liquidity at the wrong moment.
How to Check Whether a Vault or Protocol Rehypothecates Your Deposits
Questions to Ask Before You Deposit
Before signing any deposit transaction, get clear answers to these:
- Where do my deposited assets go after the transaction confirms? Does the protocol hold them in the contract, or deploy them externally?
- If the protocol issues a receipt token, can that token be used as collateral elsewhere — and does the protocol do this itself?
- What is the withdrawal process? Is it instant, batched, or subject to liquidity availability?
- What happens to my deposit if a downstream protocol the vault deploys into gets exploited?
If the documentation doesn't answer these directly, that's the answer.
Where to Find On-Chain Evidence: Solana Explorer and Protocol Dashboards
Every on-chain action leaves a trace. On Solana, you can verify what a protocol's vault addresses are doing by looking at account activity on Solscan (solscan.io) or the Solana Explorer. If the vault contract is regularly sending assets to external protocol addresses — Drift, Kamino, Marginfi — those interactions are visible.
Protocol dashboards often surface this more readably: Kamino shows current vault allocations; Drift shows open positions per account. If a vault address shows up as a significant depositor in a lending protocol you didn't know about, your assets are there. Verify before you trust.
Red Flags in Documentation and Tokenomics
Documentation that describes yield but never explains where it comes from is a red flag. So is any protocol that advertises APY significantly above the current benchmark lending rate on Solana without explaining the source of the premium. Yield doesn't appear from nowhere; if it's above the risk-free rate, something is taking on risk to generate it.
Receipt tokens with no documentation on their collateral eligibility are another flag. If a protocol's own governance proposals reference using LP tokens as collateral in other pools, that's rehypothecation disclosed in the least prominent place possible.
Does FBYT Rehypothecate Deposits?
No. FBYT vaults don't lend deposits out or post them as collateral. Deposits sit in token accounts owned by the vault's program, the manager can only trade them through Jupiter on supported assets and take the fee the vault allows, and every trade is recorded on Solana where anyone can check it.
Where Do Your Funds Go on FBYT?
FBYT is built on a non-custodial model: when you deposit into an FBYT vault, your tokens move into token accounts owned by the vault's program-derived address (PDA), an address only the program can sign for, and your vault shares are recorded in an investor account tied to your wallet. Deposits are pooled with other investors' in that vault, but the program gives the manager only two things to do with them: trade through Jupiter on supported assets, and take the fee the vault's rules allow. FBYT, the company, has no instruction in the contract to move investor funds.
There is no internal rehypothecation layer. Vault managers on FBYT trade through Jupiter, and every fill is recorded on-chain. The vault doesn't issue a receipt token that then circulates as collateral in a separate lending market. Your deposit isn't silently deployed somewhere else to boost yield metrics. What you see in the vault is what exists.
How On-Chain Transparency Lets You Verify This Yourself
Pull any FBYT vault address on Solscan. Look at the transaction history. Every trade the vault manager executed is there: the Jupiter route, the token amounts, the timestamps. If the vault is flat, the account holds the assets. If a position is open, the position is visible. There is no gap between what the dashboard displays and what the chain records, because the dashboard reads from the chain.
That's not a feature. It's a structural property of non-custodial on-chain management that no amount of UI polish can fake.
The Bottom Line: Know What Happens to Your Assets When You Deposit
A Quick Checklist Before Your Next DeFi Deposit
Before you sign:
- Can you find the vault contract address and read its on-chain activity?
- Does the documentation explain, in plain terms, where your assets go and what they're used for?
- If a receipt token is issued, is there clear documentation on whether it can be rehypothecated — by the protocol itself or by others?
- Does the advertised yield have an explained source, or does it just say "earn up to X%"?
- What is the withdrawal mechanism, and are there any conditions under which it could be delayed?
Five questions. If you can't answer all five from publicly available information before depositing, the protocol hasn't disclosed enough.
See Exactly How FBYT Handles Custody — No Trust Required
FBYT's approach to custody is documented, on-chain, and verifiable without asking anyone to take our word for it. Every vault, every trade, every position — all of it is on Solana and readable by anyone with a block explorer. If you want to understand exactly how the protocol handles your assets before depositing, that information exists and it's free to access.
Rehypothecation in DeFi is a real, present risk — not an abstract concept or a concern limited to TradFi. The protocols doing it aren't necessarily malicious. Some are transparent about it. But the Jupiter Lend debate made one thing clear: "disclosed in the documentation" and "understood by depositors" are not the same thing. The gap between those two is where losses happen.
Crypto assets are highly volatile, and on-chain strategies carry real risk, up to and including total loss of capital. Past performance of any vault or protocol is not indicative of future results. FBYT is non-custodial and does not provide financial advice. Before depositing into any DeFi protocol or vault, review the smart contract, understand what happens to your assets after deposit, and only allocate funds you can afford to lose entirely.
