TL;DR
On Saturday, April 18, 2026, KelpDAO suffered a ~$290M loss stemming from a compromise of a single-node LayerZero Decentralized Verifier Network (DVN), combined with an attack on upstream RPC providers. Initial attribution points to a North Korea-aligned threat actor.
Brale operates its own LayerZero DVN. Ours was deployed as a single node. The configuration we were using showed up in the same antipattern that showed up in the KelpDAO post-mortems. Saturday night, we contained it (DNS off, API gateway off, code change merged) and we left it down. No Brale customer was impacted, no funds were at risk on our path, and we'll bring it back up when we're satisfied it belongs in production.
This post walks through what happened, what we run, what we did, and what we're going to do differently. In the spirit of the kind of writeup we appreciate reading from others in the infrastructure community, we're going to be specific.
What a DVN is, and what ours does
LayerZero is a cross-chain messaging protocol. Messages sent between chains are attested to by one or more Decentralized Verifier Networks (DVNs) and an Executor. The security of a LayerZero message depends on the DVNs selected by the application sending it. A message signed off by a single DVN with a single operator node is, practically speaking, a message protected by a single key.
Brale runs a DVN called Gasolina. It is Fargate-based containerized on AWS rather than a traditional long-running server, which narrows the blast radius of a host compromise. It lives behind CloudFlare on testnet.layerzero.brale.dev, when live, and a mainnet counterpart. On the day of the incident, it was a 1-of-1 deployment, and the Datadog logs for the service showed no abnormalities. It was doing its job.
When we made the call to pull it, we weren't weighing customer breakage against risk. We were weighing "an asset we control that matches the shape of the thing that just cost somebody $290M" against "a few minutes of work to make it go away." That math wasn't close so we made the decision to pull it down, also recognizing that clients using OFTs and other DVNs would not experience network interruption.
What happened to KelpDAO
We are not the forensic authority here - LayerZero has posted their incident statement, and the on-chain analysis is being worked in public by a number of researchers. Our reading of the available reporting; absent new information or details, we believe the following are likely to be true:
- 1
Upstream RPC providers used by KelpDAO's DVN operator were compromised and/or poisoned.
- 2
With RPC under attacker control, the attacker reached the DVN node, which was a 1-of-1.
- 3
Binaries on RPC nodes were likely swapped. Once a single-operator validator trusting attacker code or its assertions, it will sign whatever the attacker wants it to sign.
- 4
Fraudulent messages were verified. Wrapped ETH backing got stranded across 20 chains. Aave, SparkLend, Fluid, Ethena and others paused their LayerZero OFT bridges defensively.
The headline lesson is not novel but it is sharp: a DVN of one is a key of one. The less novel lesson is that the RPC layer your validator trusts is part of your validator. Orderly Network had already taken their DVN down, moved from 1-of-1 to 3-of-3, and brought it back up by Sunday.
Our timeline (all times CDT)
Sunday, April 19
- 16:53
News of the KelpDAO exploit is picked up in our internal infosec channel. Initial read: DVN configuration issue plus RPC compromise. Aave, SparkLend, Fluid and Ethena pausing bridges. We start asking whether anything on our side matches the pattern.
- 17:49
We confirm Brale runs a DVN (Gasolina) and that it is currently 1-of-1. Engineering and security start pulling on the same rope: repo, Datadog, deployment topology.
- 18:09
Review of gasolina DVN service in Datadog shows no substantive validator activity for the prior week. Operational cost of pulling the DVN is, candidly, low.
- 18:18
Decision made to contain the DVN in place rather than let it sit exposed while we read.
- 21:16
CISO green-lights disabling the DVN. Rationale communicated to the CEO in writing: matches the anti-pattern, isn't doing meaningful work, buys us time to understand what we actually have.
- 21:44
Linear ticket opened to track the disable and the subsequent remediation.
- 22:00
Containment executed in layers. CNAME entries for the DVN hostnames negated in CloudFlare — testnet and mainnet endpoints stop resolving. API Gateway disabled. Load balancer confirmed non-public. PR reviewed and merged to make the change durable in code.
- 22:09
Containment verified. Service is down, surface area is reduced.
Monday, April 20
- 06:38
Morning sync. LayerZero's official statement is out. Our reading of the attack chain (RPC -> single node -> binary swap) lines up with what we'd have to defend against on our own infrastructure. Fargate-based deployment makes the binary-swap step harder than it would be on a traditional VM, but "harder" isn't "acceptable" when the primitive is a single node.
- 08:13
Communication sent to our SBC partners. Intel shared, containment confirmed, plan to bring the DVN back online after remediation.
Why we pulled it and not someone else's
We want to be plain about this: we pulled our DVN because we weren't comfortable standing behind a 1-of-1 deployment of something we had not yet personally read end-to-end. That is an honest statement. Our CISO inherited the DVN as a piece of infrastructure and spent the weekend learning its internals. It is difficult to write authoritative security guidance for a system you are still reading. It is easier to remove the system from production until you can.
If you operate infrastructure and that sentence makes you nervous, it should. It made us nervous too. That's why we pulled it.
What customers should know
- No Brale customer funds were at risk on our DVN path. The DVN was not carrying meaningful traffic at the time of containment, and it has been off since Sunday night.
- No credentials, keys, or customer data were exposed. This was a precautionary containment.
- If you depend on the Brale DVN for LayerZero message verification, please reach out. Our expectation is that you will configure additional DVNs alongside ours in your application; if our temporary downtime is affecting you, we want to know.
What we're doing about it
Short term, the DVN stays down. Medium term, the bar to bring it back up is the following:
- 1
Move from 1-of-1 to a multi-node deployment. 3-of-3 is the configuration the rest of the ecosystem moved to overnight. We intend to meet that bar or better before we resolve DNS again.
- 2
Harden the RPC dependency chain. The KelpDAO post-mortem makes clear that the RPC providers your validator trusts are, in effect, part of your validator. We are auditing our RPC selection, pinning, and failure modes with that lens.
- 3
Validate the Fargate deployment model against the binary-swap threat. Containerized compute reduces exposure but does not eliminate it. Image provenance, deploy-time signing, and runtime integrity are on the list. We believe in detection networks and intend on growing them.
- 4
Separate the DVN's domain and network radius from the rest of
brale.xyz. Longer term, we expect validator infrastructure (and eventually our own explorer) to live on a dedicated domain (thinkbrale.network). Smaller blast radius, cleaner trust boundaries. - 5
Write it down. Runbook, on-call expectations, health check definition, and the answer to the simple question "what is this thing doing today?" need to be legible to anyone on our team, not just the person who deployed it.
What we'd want other operators to take from this
- A DVN of one is a key of one. If you're running one, either fix that or turn it off until you do.
- Your RPC providers are inside your trust boundary. Treat them that way.
A note on voice
We usually try to write these in the register of the team that did the work. The team on this one was small and honest with each other about what we knew and didn't know. That's the tone we tried to keep here. If you see any of it as less polished than the typical vendor post-mortem - that's deliberate. We learned things this weekend that we hadn't learned before, and we'd rather tell you that than pretend otherwise.
Questions, corrections, or tips: security@brale.xyz.
Contributors
- Ben SchmittCISO