Everyone blamed Kelp until the “default setting” turned out to be the real vulnerability.👇

The @KelpDAO team dropped their breakdown of the exploit.
And honestly, CT’s narrative feels incomplete, blaming it on Kelp’s bad design.
But when you actually look at it closely, it’s actually not that.
First, the setup everyone keeps mentioning, the 1/1 DVN.
There are parts people are skipping.
> 1/1 DVN is the default configuration in LayerZero docs & GitHub
> 40% of protocols are running this exact setup
So Kelp didn’t go out of their way to do something exotic.
They followed the standard path most builders would follow when integrating.
I believe the question everyone should be asking is:
> why was a setup like this the default in the first place?
I mean everyone will definitely go for default setup when deploying, right?
And this is also something LayerZero recommends for others too.
It wasn’t just a weak config choice, it exposed a broken verification model.
The second part is the awareness.
LayerZero knows very much about their ecosystem configuration, which means:
> they could see which protocols were running 1/1 DVN
> they could see how widespread this setup was
If 40% of the ecosystem uses an infra, it should be under constant security review.
But there wasn’t any of that, no upgrades or guardrails.
No enforced migration path away from insecure defaults.
This goes beyond an app layer mistake.
It is high time protocols embraced constant security checks.
Cross-chain security is only as strong as its weakest verification assumption.
So yeah, this is not a “Kelp bad” vs “everyone else good” situation.
Risky defaults, wide adoption, and no enforcement finally led to the failure.
Responsibility is shared, but the risk surface is systemic.
You should check out the full report here: