Base
Unichain
Robinhood
When a large borrower opens a credit facility directly inside a smart contract, marketing loves to talk about the rate and the speed. In reality the rate is the smallest part of the story. An institutional onchain credit facility rests on three pillars: what collateral is accepted, how its price enters the system and who has the right to seize the collateral when something breaks. If even one pillar is weak, the rate stops reflecting the real risk.
For an institutional participant, the important thing is not the existence of the loan but the order of actions on the worst day. What happens when collateral drops sharply, the oracle lags and the market loses depth. That is the exact moment when it becomes clear whether the facility was an engineered structure or a pretty interface over a fragile mechanism.
Collateral matters more than the interest rate
The quality of a credit facility begins with what sits in collateral. A stablecoin with verifiable reserves and a thin governance token behave completely differently under stress. The first can be sold in size without collapsing its price, the second crashes its own quote at the very first sale. So an identical loan to value ratio across different assets is almost always a sign of lazy risk management.
The central question sounds like this: how quickly does collateral turn into cash without a large discount. If a position equals several days of an asset’s turnover, it cannot be liquidated at the price on the screen. A system that values collateral at the current quote while ignoring market depth baked in a loss at the start and simply does not know it yet.
A strong facility sets different haircuts for different assets and tightens them as a position grows. The larger the borrower, the higher the collateral requirement, because liquidating a big position moves the price against the system itself. A weak facility pretends the market is infinite, and that is exactly how bad debt accumulates until it becomes impossible to ignore.
The oracle as the point where the system breaks
A smart contract does not see the market directly. It learns the collateral price only through an oracle, and that makes the oracle the point where the whole structure most often breaks. If the oracle takes its price from a single exchange, that price can be temporarily pushed by an attack to trigger an artificial liquidation or, the opposite, to hide a real drop and stretch out bad debt.
Three things about the oracle therefore matter. Where it sources data, how often it updates and what it does when a source fails. An oracle that aggregates several independent sources and smooths outliers is far more resilient than one that blindly relays a single price feed. Robustness here is not a feature but a survival condition.
The second hidden risk is latency. There is always a lag between a real price move and the moment the oracle updates. In calm times this lag is invisible. During a sharp fall it can mean liquidation triggers too late, when collateral is already worth less than the debt, and the loss lands on the protocol or on other lenders instead of the borrower who took the risk.
The liquidation right and who executes it
Liquidation is not an abstract rule but a concrete action someone has to perform in time. In some systems open liquidators compete for a reward and buy the collateral at a discount. In others the liquidation right is handed to a narrow set of agents, and then the safety of the system depends on whether those agents are online and solvent at the required hour.
For an institutional borrower another layer matters: the legal right to the collateral. An onchain record shows the movement of a token but does not always answer who owns that token if the borrower goes bankrupt. If a protocol technically holds collateral while the legal priority is contested, confidence in a fast liquidation can turn out to be an illusion in court.
That is why mature facilities increasingly combine code and contract. Code provides speed and transparency, the contract provides protection for the case where code alone is not enough. An investor should understand which layer actually protects them in a given jurisdiction rather than relying on a promise of full automation that has never been tested against a real default.
Stress testing the facility
A facility can be tested with a single thought experiment. Imagine collateral falls by a third within hours, exchange liquidity halves and one of the oracle sources drops out. A strong system survives that day with manageable losses. A weak one accumulates bad debt that lands on the remaining participants, quietly turning a lending product into a loss sharing scheme.
Concentration matters just as much. If one borrower or one collateral type occupies a large share of the book, a problem in a single spot becomes a problem for the whole system. A healthy facility spreads risk across borrowers and collateral types rather than assuming its biggest client will never default because it never has before.
When an investor supplies capital to such a facility, they are effectively selling insurance against a collateral crash. The yield should therefore compensate exactly that risk rather than look like a gift. A high rate on thin collateral with a weak oracle is not generosity but a warning that the market has already priced the probability of loss higher than it first appears.
What to check before participating
Before supplying capital or drawing a loan, it helps to run through a short list. What collateral is accepted and what haircut applies to each type. Who feeds prices into the oracle, how many independent sources it has and what happens when they fail. Who can trigger liquidation and what motivates those participants to act fast rather than wait.
A strong facility answers these questions with documents and verifiable parameters rather than promises of reliability. A weak one hides the details behind general language about security and audits. An audit is useful, but it checks the code, not the quality of the collateral, not oracle behavior under stress and not the legal force of the claim on the collateral.
The conclusion is simple: onchain credit is neither better nor worse than the classic kind by the mere fact of being on a blockchain. It is better where collateral is sound, the oracle is honest and fast, and the liquidation right is genuinely enforceable. It is worse wherever any of these elements rests on trust without verification. The analyst’s job is to find the weak link before the stress, not after it.
Oracles as a point of failure
Onchain credit rests on the price of collateral, and an oracle is what brings that price onto the chain. This makes the oracle a quiet but critical point of failure for the whole construction. If the oracle updates rarely, the lender sees a stale price and may liquidate the borrower too late, when the collateral is already short. If the oracle depends on a single source, manipulating that source turns directly into theft of collateral. So the first question about any institutional credit facility is not the rate but the design of the oracle.
A sound design uses several independent price sources and a median value, along with protection against sharp outliers. It matters how the oracle behaves in moments of low liquidity, when the price on one venue detaches from the market. Cascading liquidations happen exactly in those minutes, and that is exactly when a weak oracle does the most damage. An investor should demand a description of the sources, the update frequency and the behavior when at least one of them fails.
A separate theme is oracles for illiquid or real world assets. The price of tokenized debt or a commodity is not pulled from an exchange every second; it has to be confirmed by external reports and agents. Here the oracle stops being a purely technical module and becomes a trust procedure. The less liquid the collateral, the more important it is to understand who confirms its value and how often, and what happens when that confirmation is delayed.
Liquidation rights and the creditor queue
Liquidation looks simple on a diagram, but in a stress phase it is what decides who loses money. It matters who has the right to trigger liquidation, at what price the collateral is sold and who receives the proceeds first. If the protocol relies on external liquidators working for a reward, it is worth asking what happens if liquidators fail to appear at the needed moment because the market is falling too fast.
The creditor queue is the second hidden risk. In complex structures the same collateral can serve several tranches with different priority. A holder of the junior tranche gets a higher rate, but in a default they are paid last and often receive nothing. The attractive yield here is paid for precisely by the right to stand at the end of the queue, and the investor must see their real priority, not only the promised percentage.
Finally, it matters where the liquidation right lives: fully in code or partly in a legal contract. A fully onchain liquidation is fast but blind to context. A hybrid model adds legal protection but introduces delay and dependence on a court. No model is perfect, so the investor should understand the tradeoff and judge whether it fits the nature of the collateral and the horizon of the deal.
Examples and sources
How collateral and the liquidation right work in practice is easy to see in a protocol like Aave, where facility parameters and liquidation thresholds are described openly. Prices for such facilities usually come from oracles such as Chainlink, and it is the reliability of the oracle that often decides the outcome in a stressed moment.
