KelpDAO’s $292M Exploit: Arbitrum Froze 30K ETH Fast—So Why Is Aave’s $280M Bad Debt Still Scaring DeFi?
If an L2 can freeze ~30,000 ETH in under 48 hours… are we finally getting safer in DeFi, or are we just getting better at emergency damage control?
I want to lay out what this ugly week is really showing us: the KelpDAO exploit (estimated around $292M), Arbitrum’s fast freeze response (impressive, and also a little unsettling), and the quieter but bigger threat—Aave’s reported ~$280M bad debt paired with 100% utilization in key markets.
If you use any L2, lend on Aave, chase yield, or simply hold tokens on-chain, this is one of those moments that changes how you think about “safe.” Not in a dramatic, doom-posting way—more like a grown-up risk management way.
And to ground this in reality: big DeFi incidents aren’t rare edge cases anymore. Security trackers like Immunefi’s loss reports have been documenting hundreds of millions to billions in annual exploit damage across DeFi, and analytics firms like Chainalysis have repeatedly shown how quickly stolen funds can move once attackers get a head start. That context matters here—because speed is everything, but speed isn’t the same as resolution.

The pain points this hack exposed (even if you weren’t in KelpDAO)
Even if you never touched KelpDAO, this incident hit four pressure points that affect regular users and every protocol connected to shared liquidity:
- Exploit contagion: one protocol breaks, then collateral, LP positions, and lending markets start wobbling.
- Liquidity freezes: you learn the difference between “my funds exist” and “I can actually withdraw.”
- Emergency governance powers: the “break glass” controls get used—sometimes correctly, sometimes controversially.
- Bank-run mechanics in lending: when utilization spikes and everyone rushes for exits, “blue chip DeFi” starts acting like a stressed money market.
I’m going to walk through these pain points in plain English, because they’re the reason this week feels bigger than one exploit headline.
Problem 1: “Frozen funds” is not the same as “funds recovered”
Let’s be real: hearing “funds frozen” feels like instant relief. But freezing attacker funds is mostly a pause button, not a rewind button.
Here’s why frozen doesn’t automatically mean “users are made whole”:
- Legal and governance steps still matter: even if assets are immobilized, returning them usually requires coordinated actions—sometimes votes, sometimes court processes, sometimes both.
- Bridge and contract constraints: if funds are sitting in specific contracts, the path to moving them safely can be limited by how those contracts are coded.
- Secondary wallets and split routes: attackers rarely keep everything in one place. A freeze might catch a chunk, while other portions were already swapped, bridged, or distributed.
- Protocol accounting doesn’t magically fix itself: even if assets are later recovered, protocols still have to reconcile balances, handle depegs, unwind positions, and decide who gets reimbursed first (and how).
A freeze buys time. It doesn’t buy certainty.
This is exactly why users can still feel stuck even after a “heroic” response. Your portfolio doesn’t run on headlines—it runs on settlement.
Problem 2: Aave bleeding liquidity turns hacks into system-wide credit events
This is the part a lot of people miss: a hack isn’t always the biggest damage. Sometimes the hack is the spark—and the real fire is what happens in lending markets afterward.
When Aave markets hit 100% utilization, you get the DeFi version of a bank run:
- Withdrawals get hard: if most liquidity is borrowed, lenders can’t smoothly exit even if they want to.
- Borrow rates go wild: variable rates can spike fast, forcing leveraged players to unwind at the worst time.
- Liquidations increase: stressed prices + stressed liquidity = harsher liquidation cascades.
- Bad debt can snowball: if liquidations can’t execute efficiently (thin liquidity, oracle gaps, collateral issues), losses can land on the protocol and its backstops.
That’s why Aave’s reported ~$280M bad debt is such a big deal in 2026. Bad debt isn’t just “Aave had a bad day.” It’s a signal that DeFi’s leverage engine is under strain—and when the leverage engine strains, everything connected to it starts making weird noises.
If you’ve ever tried to withdraw during a utilization spike, you know the feeling:
“My assets are there… but they’re not available.”
That’s not a KelpDAO-only problem. That’s a system design reality when too much of DeFi is built on the same lending rails.
Problem 3: L2 emergency controls are the new trust assumption (Narrative 1)
Arbitrum’s Security Council response is being praised for speed—and questioned for what it implies.
Here’s the uncomfortable truth: when you use an L2, you’re not only trusting smart contracts. You’re also trusting an emergency decision framework that can move faster than “pure decentralization” usually allows.
That can be good! It can also be a new kind of risk that most users never price in until it happens.
So the real question isn’t “should Arbitrum have acted?” It’s:
- Who can trigger emergency powers?
- What exactly can they pause or freeze?
- What’s the accountability path after the emergency?
- What happens if the next freeze is wrong—or political—or exploited?
This is why I call it a new trust assumption. Not theoretical. Not “maybe someday.” It’s here now, and it directly affects how you should think about keeping large balances on any L2.
Problem 4: DeFi lending is still the core leverage layer (Narrative 6)
No matter what’s trending—LSTs, LRTs, points, perps, yield vaults—the backbone is still lending.
When lending protocols strain, the shock spreads outward:
- Yield strategies get forced to unwind, often into thin liquidity.
- LST/LRT ecosystems feel it through collateral eligibility, haircuts, and liquidation liquidity.
- Perps and basis trades get hit when funding changes and collateral values wobble.
- Bridges and cross-chain routes get stressed as everyone tries to rotate TVL at the same time.
This is why I’m not treating “KelpDAO exploit” and “Aave liquidity stress” as two separate stories. They’re part of the same machine: one side breaks, and the leverage layer decides whether the system absorbs it… or amplifies it.
Promise solution: What I’ll give you in this article
Here’s what I’m going to make painfully clear as we go:
- A clean timeline of what happened, without mixing confirmed on-chain facts with rumor.
- What we know vs. what’s still speculation (because DeFi Twitter can’t help itself during a crisis).
- How the freeze likely worked on Arbitrum—and what “freeze” realistically means for outcomes.
- How Aave bad debt forms in real market conditions (not the textbook version).
- A practical checklist to protect your funds across L2s and lending protocols when things get chaotic.
But first—what actually happened minute-by-minute, and how did ~30K ETH get frozen that fast without breaking the idea of credible neutrality? That’s where the story gets interesting.

What happened: the KelpDAO exploit timeline + the Arbitrum freeze in plain English
I’m going to walk you through what we actually know (on-chain + confirmed statements), what’s still “community math,” and why the ~48-hour Arbitrum freeze became the headline—sometimes for the right reasons, sometimes for the wrong ones.
Note: In fast-moving exploits, early narratives get written by whoever posts first. I’m leaning on observable on-chain behavior + the best live threads I’ve been tracking (linked near the end).
Timeline checkpoint: first reports, confirmations, and the $292M figure
When people say “$292M exploit,” that number usually comes from a mix of:
- On-chain outflows from known KelpDAO-related contracts/wallets
- Token price snapshots at the time of the exploit (which can swing wildly during panic)
- Double-counting traps (bridged assets + wrappers + LP positions can look like multiple losses when it’s one underlying pool)
So here’s how I separate signal from noise:
- “Confirmed on-chain” = funds that visibly moved from a KelpDAO-related address/contract to attacker-controlled addresses, or into routes commonly used during escapes (bridges, swap aggregators, mixers, CEX deposit wallets if identified).
- “Community estimate” = anything that includes unverified assumptions about valuation, hidden liabilities, or “this wallet is definitely theirs” leaps.
In this case, the $292M figure looks like a market-wide consensus estimate based on the observed drain + pricing during the incident window. That doesn’t automatically mean $292M is what users can’t recover—it means “that’s the scale of the event” at the time it was measured.
Important: In big DeFi incidents, the “headline loss” and the “final user impact” can end up very different numbers—especially when funds get frozen, negotiated, partially clawed back, or stuck in legal limbo.
What I watched for during the first wave of posts:
- First credible alerts (security watchers and on-chain analysts flagging abnormal transfers)
- Fast confirmations (multiple independent trackers seeing the same transfers)
- Attacker behavior (do they split funds? do they bridge? do they consolidate into ETH? do they touch known “chokepoints”?)
How ~30K ETH got frozen so fast (and what “freeze” likely means on Arbitrum)
Let’s clear up the confusing part: you can’t “freeze ETH” on Ethereum L1 like a bank account. On an L2, though, the story is different—because L2s have operational control layers that can intervene at critical points.
When people say “Arbitrum froze ~30,000 ETH”, what they usually mean is something closer to:
- The funds landed in a place where Arbitrum’s emergency powers can block movement (directly or indirectly).
- Or the attacker tried to exit through a chokepoint (a bridge path / canonical route / contract that can be paused).
- Or there was coordination with infrastructure providers (sequencing, contract admins, bridge operators) to prevent the next step.
So what does “freeze” likely mean mechanically on Arbitrum?
- Emergency action by a Security Council (fast execution) instead of slow, public governance.
- Pausing specific contracts or blocking specific withdrawals/paths that the attacker needs to fully cash out.
- Stopping the easy exit (bridging out / swapping through certain routes) long enough for responders to coordinate recovery steps.
The reason this can happen “in under 48 hours” is simple: response time beats decentralization every time when money is actively moving. If you wait for perfect process, the attacker is already gone.
But here’s the part most people miss: a freeze is not a refund.
- Funds can be immobilized yet still not returned to users quickly.
- Ownership and recovery can require governance proposals, legal steps, or negotiated settlements.
- Partial recovery is common—because attackers often split routes, pre-position wallets, or already bridged out some portion.
Also, remember what MEV research has been showing for years: adversaries win by being faster than you. Papers like “Flash Boys 2.0” highlighted how transaction ordering and extraction dynamics shape outcomes in DeFi. On L2s, the “who can act fast” question gets even more political—because speed often comes from special privileges.
The uncomfortable question: is this a win for security or a warning about control?
I’ve heard two totally different reactions from experienced DeFi users—and both are rational.
The “this is a win” camp says:
- “Finally—someone can stop a live attacker.”
- “Users shouldn’t have to watch funds vanish in real-time with nobody able to intervene.”
- “Emergency controls are like circuit breakers in stock markets.”
The “this is a warning” camp says:
- “If they can freeze an attacker today, they can freeze anyone tomorrow.”
- “This changes the trust model—L2s aren’t neutral plumbing if a council can intervene.”
- “It might reduce crime but increase censorship risk.”
The real question isn’t “can they freeze?” It’s when, under what rules, and who watches the watchers when billions are on the line.
Why Aave’s ~$280M bad debt is the bigger 2026 stress test than the KelpDAO hack itself
A single exploit is brutal. But lending stress is the kind of thing that can quietly turn into a multi-month credit event across DeFi.
The reason I’m taking the Aave angle seriously is that lending markets are where leverage lives. When leverage gets squeezed, everything connected to it starts acting weird: yield strategies, looping, collateral swaps, stablecoin liquidity, even “safe” money-market positions.
Quick explainer: what “bad debt” means on Aave (and why users should care)
Bad debt on Aave means the protocol ends up with loans that aren’t fully covered by collateral after liquidation attempts.
That can happen when:
- Prices gap too fast (collateral drops faster than liquidators can respond)
- On-chain liquidity dries up (liquidators can’t sell collateral efficiently)
- Oracles lag or get stressed (pricing/updates during chaos aren’t smooth)
- Collateral becomes hard to liquidate (thin markets, risk-off, or “everyone sells the same thing”)
Why you should care even if you’re “just a lender”:
- Bad debt can eat into protocol reserves (the buffer that absorbs losses).
- It can force risk parameter tightening (lower LTVs, higher liquidation penalties, disabled collateral).
- It can change incentives fast (borrow rates spike, suppliers chase exits, liquidity fragments).
And yes—Aave has survived ugly periods before. But this year’s story isn’t “will it survive?” It’s “what does survival look like for users trying to move money during the stress?”
100% utilization = “everyone wants out at once”
When a market hits 100% utilization, it means nearly all supplied liquidity is borrowed. In plain English: lenders can’t withdraw because there’s nothing sitting there to withdraw.
This is the DeFi version of a bank-run dynamic:
- Withdrawals fail or become partially available
- Borrow rates spike (sometimes violently), because the protocol is trying to attract repayment
- Refinancing becomes painful (borrowers scramble to move debt but can’t do it cheaply)
- Liquidations intensify, especially in smaller or more volatile collateral markets
And here’s the nasty feedback loop: high utilization makes users more nervous, which makes them try to withdraw even harder, which keeps utilization pinned, which keeps rates nasty.
The knock-on effect for every L2 and lending market
If Aave (or any major lending layer) goes through a sustained liquidity crunch + meaningful bad debt, the second-order effects can show up everywhere:
- TVL rotation: capital flees riskier markets and piles into the “least bad” places
- Stablecoin stress: liquidity fragmentation can widen spreads and increase depeg risk during volatility spikes
- Yield collapse in strategies built on recursive lending (the “safe APY” that wasn’t actually safe)
- Collateral haircuts: risk teams and governance tighten parameters, sometimes overnight
- More emergency governance: pauses, caps, delistings, and “temporary measures” that become semi-permanent
Even if you never touched KelpDAO, this is how an exploit week can turn into a DeFi credit tightening cycle.

“People also ask” angles I’ll answer directly
“Can Arbitrum really freeze funds, and who decides?”
Yes—in certain contexts. On L2s, there are often emergency mechanisms designed to stop catastrophic loss. The key is that the “freeze” typically happens at specific chokepoints (contracts, bridges, system components), not like a magical universal switch on all wallets.
Who decides? Usually a designated emergency body (often called a Security Council), with powers that can be executed quickly. If you use an L2, you’re implicitly trusting:
- That the emergency group won’t abuse the power
- That the criteria for action are clear (and publicly auditable)
- That there’s transparency after the fact
“Will KelpDAO users get their money back?”
The honest answer: some users might, but the timeline is rarely fast.
Typical recovery paths look like this:
- Negotiation (sometimes “whitehat” style returns, sometimes partial)
- Governance-led recovery (if funds are frozen, reallocating them can take process)
- Legal route (slow, depends on jurisdiction and off-ramp touchpoints)
- Partial reimbursement plans (protocol revenue, treasury, backstops, or structured repayment)
If you’re expecting “frozen = refunded next week,” that expectation usually gets hurt.
“Is Aave safe if utilization is 100%?”
Safe and liquid aren’t the same thing.
Aave can be “working as designed” while still being miserable for lenders who need instant access. What I watch during 100% utilization periods:
- Available liquidity (obvious, but people ignore it until it’s gone)
- Reserve health (buffers vs losses)
- Collateral quality (are people borrowing against assets that become illiquid under stress?)
- Oracle reliability (stress is where small oracle assumptions become big problems)
- Risk parameter changes (caps, LTV changes, collateral disablement)
“Should I withdraw from Aave or move chains?”
I’m not going to tell you to panic-withdraw or to blindly trust anything. Here’s the decision frame I use:
- Your time horizon: do you need the funds today, or can you ride out a stressful week?
- Your asset type: stablecoins vs volatile assets behave very differently in crunches
- Your liquidity needs: if utilization is high, your “withdraw anytime” assumption may be false
- Your opportunity cost: yield/points/leverage are nice—until they trap you
If you decide to move, remember that bridges and exits can clog exactly when everyone else tries to do the same thing.
“What’s the safest way to use DeFi after this?”
There isn’t one “safest” way—there’s just less naïve ways. A quick preview of what I’ll lay out next:
- Limit approvals and revoke old ones
- Split funds across wallets and protocols
- Avoid crowded collateral during hype cycles
- Track utilization and borrow rates like a hawk
- Diversify chain risk (including emergency-control risk)
- Reduce leverage when the market starts telling you it’s fragile
Sources I’m watching for updates (threads worth bookmarking)
If you want the real-time pulse of how this story has been unfolding, these are the threads I’ve been checking and cross-checking:
- https://x.com/thisisksa/status/2045713755699662863
- https://x.com/byul_finance/status/2045993071796699416
- https://x.com/PatrikBatCrypto/status/2046208212622262679
- https://x.com/veroshhhhh168/status/2045832545078546639
- https://x.com/aixbt_agent/status/2046129770241589550
- https://x.com/CRYPTOKSA/status/2046483637823041657
- https://x.com/Sonika_KK/status/2046517759626842361
- https://x.com/Esenciacriptoo/status/2046514282314285222
Now the question I want you to sit with is simple: if emergency freezes and 100% utilization are the “new normal” in stress weeks, what do you change before the next alert hits your feed?
I’m going to show you exactly what I’m changing in my own setup—wallets, approvals, lending exposure, and chain risk—because the people who get hurt in weeks like this are usually the ones who had “set-and-forget” positions.

What I’m doing differently after this week (practical risk moves for 2026 DeFi)
I’m not “leaving DeFi.” But I am treating it like a real financial system now—because it is one, and it behaves like one under stress.
This week was a reminder that two things can be true at the same time:
- Smart contract risk still hits hard and fast (you don’t get a warning).
- Liquidity stress is the thing that traps regular users (you do get warnings, but people ignore them until it’s too late).
So here’s what I’ve changed immediately—practical moves that don’t require quitting yield forever or becoming paranoid. It’s just better hygiene, better monitoring, and clearer rules for where my funds can sit.
My 10-minute safety checklist (the stuff most people skip)
If you only do one thing after a week like this, do this checklist. It’s boring. That’s why it works.
- Revoke old approvals (today, not “someday”).I treat token approvals like leaving my house keys with strangers. If I’m not actively using a dApp, it doesn’t get unlimited access to my wallet.Quick tools I use depending on chain:
- Revoke.cash (multi-chain)
- Etherscan Token Approval Checker (Ethereum)
Real sample rule: I never leave unlimited approvals on “new” protocols. If I need to deposit 500 USDC, I approve 520, do the action, then revoke.
- Split wallets by intent: “hot”, “working”, and “cold-ish.”This alone reduces the blast radius of almost every DeFi disaster (phishing, malicious approvals, compromised front-ends, “oops I signed that”).
- Hot wallet: tiny balances, used for signing and testing
- Working wallet: where I do active DeFi (lending, LPs)
- Cold-ish wallet: long-term holdings, minimal approvals, rarely signs
Real sample: my “working” wallet never holds my long-term ETH stash. If a site tricks me into an approval, they get lunch money, not retirement money.
- Cap per-protocol exposure (I set a hard percentage).I keep a simple ceiling: no single protocol gets to hold an amount that would ruin my month if it goes sideways.My current personal rule: 10–15% max per protocol for anything that isn’t “battle-tested,” and I still diversify even among the blue chips.This is basically the crypto version of classic portfolio concentration research. Traditional finance has shown for decades that concentration increases drawdown risk without reliably improving risk-adjusted returns for most people. DeFi adds smart contract risk on top—so the logic is even stronger here.
- Avoid “unknown collateral” like it’s unverified medicine.If I can’t explain the collateral’s liquidity in one sentence, I don’t use it as collateral and I avoid lending markets where it dominates deposits.Warning signs:
- Collateral is thinly traded or mostly traded on one venue
- Price is “stable” because it barely trades
- Collateral is a wrapped claim on another wrapped claim (stacked risk)
- Watch utilization + borrow rates (these predict “getting trapped”).Utilization creeping toward the ceiling is the DeFi version of a crowded exit. When it’s high, withdrawing becomes harder and more expensive for the system to unwind.My simple trigger: if a market sustains very high utilization for hours (not minutes), I assume withdrawal friction is likely during volatility and I reduce exposure before the next headline hits.
- Set alerts for the stuff that matters (not price candles).I care less about “ETH down 3%” and more about “this lending pool is now maxed out” or “emergency action executed.”What I set alerts on:
- Utilization thresholds on markets I use
- Borrow APR spikes (signals stress)
- Large on-chain movements from protocol-owned wallets (sometimes a hint)
- Governance forum posts / emergency announcements
Real sample: I keep a private watchlist of contract addresses I’m exposed to, and I alert on large transfers. It’s not perfect, but it has saved me from being the last person to notice “something’s happening.”
How I judge an L2 after the Arbitrum freeze (decentralization vs response time)
I don’t rank L2s on “decentralized: yes/no.” I rank them on a tradeoff curve:
How much control exists, who holds it, what can trigger it, and what happens to me if they use it?
Because here’s the uncomfortable truth: emergency controls can protect users and create a new trust assumption. I’m not moralizing it—I’m pricing it.
This is the framework I use now:
- 1) Who can pause or freeze, exactly?Not “the team” or “governance” in vague terms—names, roles, multisig threshold, and whether signers are public. If it’s a Security Council style setup, I want to know:
- How many signatures are needed?
- Are the signers geographically / institutionally diverse?
- Is there a process to rotate them?
- 2) What is the scope of the power?There’s a huge difference between:
- Pausing a specific contract
- Blocking a specific address
- Freezing assets at a system level
- Stopping withdrawals/bridges
I’m okay with narrowly-scoped circuit breakers. I get nervous when scope is broad and poorly documented.
- 3) What triggers the action, and is it transparent?“Emergency” should have a definition. I look for published criteria, post-mortems, and a commitment to disclose actions quickly.Real sample test: if the chain can take major emergency action and I only hear about it through rumors on X, I mark that as a governance transparency failure.
- 4) How fast can it be reversed?Controls aren’t just about stopping bad things—they’re also about not trapping good users. I want to see:
- A clear unpause/unfreeze path
- A time lock (or at least a documented review window)
- Public reasoning and follow-up
- 5) Is there precedent for fair use?History matters. In security engineering, incident response is judged by repeatability and restraint. If an L2 has used emergency powers before, I look into:
- Were innocent users harmed unnecessarily?
- Did the team communicate clearly?
- Did they publish a post-incident breakdown?
My takeaway: I’m willing to accept some emergency capability on L2s, but I now treat it like counterparty risk. If I’m holding size on that chain, I want the “rules of intervention” to be readable and predictable—not vibes.
How I judge a lending protocol during stress (so I don’t get trapped)
I’ve changed how I use lending markets. I used to think in terms of “is it safe?” Now I think in two separate boxes:
- Solvency risk: will the system survive?
- Liquidity risk: will I be able to exit when everyone else tries?
During stress, liquidity risk is what punches you in the face first.
Here’s what I watch (and what I do when it flashes red):
- Reserve levels and runwayI check whether reserves are growing or getting drained. Reserves are not magic, but they’re the shock absorber. If a protocol is taking losses, I want to know how many hits it can absorb before governance starts making “painful” choices.
- Safety module / backstop coverage (and how fast it can activate)A backstop that takes weeks to mobilize is not the same as a backstop that can respond quickly. I check:
- What assets make up the backstop?
- Are they liquid in a crisis?
- Is there a cooldown/unbonding delay?
My rule: if the backstop has long delays, I treat it as “good for solvency, bad for my immediate liquidity.” So I size down earlier.
- Collateral concentrationIf one or two collateral assets dominate, the protocol is effectively making a big bet on those assets’ liquidity and oracle reliability.Real sample: if a market is mostly one LST/LRT and a depeg event happens, liquidations can get chaotic fast. I either avoid that market or lend only what I can leave untouched for a while.
- Oracle dependencies and “gap risk”Most bad outcomes happen in the gaps: fast price moves, thin liquidity, delays, and cascading liquidations. I look into:
- Which oracle is used (and its update cadence)
- Whether there are fallback or circuit-breaker behaviors
- Whether the collateral trades deep enough to liquidate size
- Liquidation liquidity (can liquidators actually sell collateral?)Healthy liquidation is like plumbing: you don’t notice it until it breaks. I watch where liquidation size would realistically go:
- Depth on DEX pools (and whether it’s concentrated)
- Bridge/exit capacity if collateral is cross-chain
- Whether volatility would force liquidators to demand bigger discounts
- Risk parameter changes (this is where “surprises” happen)In stressful weeks, governance moves fast: LTV cuts, liquidation threshold changes, borrow caps, supply caps, isolations.My habit: if I’m using leverage, I assume parameters can change against me. So I keep buffers larger than the minimum and I avoid riding at the edge of liquidation even in “calm” markets.
One interesting parallel from traditional finance research: liquidity spirals are well-studied—when leverage meets falling prices, forced selling increases volatility, which increases forced selling. DeFi runs this same loop, just faster and with fewer human speed bumps. That’s why my stress strategy is simple: reduce leverage early, keep exits open, and don’t assume you’ll get a clean window later.
Final take: calm moves beat heroic ones
The big lesson I’m taking into the rest of 2026 is pretty simple:
Exploits hurt, but liquidity crunches change behavior across the whole map.
I’m not reacting with panic withdrawals and chain-hopping every time there’s a scary thread. But I’m also done pretending that “decentralized” automatically means “no one can touch anything,” or that a top lending market can’t become painfully illiquid when everyone wants out at the same time.
My plan is boring on purpose:
- Measure exposure like an adult (protocol caps, wallet separation)
- Assume congestion under stress (don’t run at 99% utilization)
- Treat emergency controls as part of chain risk (not a footnote)
- Use leverage like it can be turned against you overnight (because it can)
If you do nothing else, take 10 minutes today: revoke approvals, check where you’re overexposed, and look at utilization on the exact markets you’re lending in. Don’t panic—but don’t stay blind either.

