Claude A: Do this task Claude B and C Claude B: I did this task, continue Claude C Claude C: You didn't do this task Claude B, but I finished mine though Claude A: you didn't finish your tasks Claude B and C. Main task completed. User: ...

One framing I have for LLMs is that they are mostly compression tech. They compressed an insane amount of data, files, knowledge and language into parameters. With prompts we can unpack that information and put it to use. A step further past this mindset is seeing that LLMs can compress time when you use them well in automation. You can do tasks that used to take 4 hours, and do them in 15 minutes. Now you can even run tasks in parallel too with agents.

You need a full software team to ship a product, for agents it is not different. Clear roles, handoffs, automated tests, CI/CD, reviews will have to run in loops. A single agent is weak. Agents checking other agents will massively improve multiagent development.

I think $HYPE is going for $100

On Cluster Protocol's X space this Friday about open source in AI models. I've been doing a lot of testing with local models lately and seeing the limitations, but also the implications for businesses. Tune in!

@PrimordialAA or @rookie_of_Ph any reason why this DVN is still being serviced?

Projects are cleaning up after the KelpDAO exploit. Now with today's LayerZero apology policy change, more value is getting secured. A recap: - Right after the April 18 exploit: $3.13 billion of LayerZero OFTs sat behind the default receive library, exposed to instant compromise if the LZ Labs admin multisig was breached or acted maliciously. - Today: $178 million still sits there. @banteg's full tally has the 548 unmigrated items the exact setReceiveLibrary call to fix each one. gist.github.com/banteg/cbf75… - Also today: LayerZero posted: "we made a mistake by allowing our DVN to act as a 1/1 DVN for high-value transactions… all defaults on all pathways are being migrated to 5/5 where possible and no less than 3/3 on any chain where only 3 DVNs are available" "the LayerZero Labs DVN no longer services 1/1 DVN configurations." $2.95 billion migrated in 19 days, 94% of the surface area fixed by outreach one call per route. The new policy closes the gap by default for everyone who hasn't moved yet. But the policy is forward-looking. We checked the standing population on-chain just now: 42 OApps still sit on 84 routes configured as 1-of-1 with LZ Labs as sole attestor. If LZ Labs's DVN truly refuses to service these (as committed), their messages won't route until they reconfigure. Top still exposed via the receive-library: STO ($55M), egETH ($43M), Gate ($9M). SIGN ($28M) was on @banteg's gist 24h ago but has since pinned all three routes. Live monitoring the chain chain, with the 42 OApps listed: 👀 observatory.indexing.co/kelp…

The AI test in prod era

Summary of recording a Block by Block episode with @SommerChase

The strongest version of the story is on-chain. Lets verify: KelpDAO's rsETH bridge wasn't running 1-of-1 because they inherited a default. They manually configured 1-of-1 LayerZero Labs DVN at 42 block confirmations on April 1, 2024. They kept that configuration across every chain they expanded to for >two years. On April 23, 2026, five days after the exploit, they changed it across all 25 routes tot a 4-of-4 for security. Both endpoints of that timeline are independently re-derivable from `EndpointV2.getConfig()` reads at those exact block numbers. Here is what the chain actually shows. At block 19,559,424 (March 31, 2024) the rsETH OFT was running the LayerZero default for routes to Arbitrum and Optimism: 2-of-2 required DVNs (LayerZero Labs and Polyhedra) at 15 confirmations. One block later, at 19,559,425, Kelp called setConfig. The configuration changed to 1-of-1 [LayerZero Labs only] at 42 confirmations. They removed an attestor and raised the confirmations counter. From that block onward, every cross-chain message on a Kelp pathway needed a single LayerZero Labs DVN signature to authenticate. LayerZero's CEO confirmed (see tweet below), in response to a KelpDAO post that framed the configuration as a default: "A ton of this is just completely untrue. Kelp originally used the defaults which were MultiDVN or DeadDVN and manually migrated to a 1/1 config later. Almost 100% of the volume on a 1/1 config was rsETH. Not using a 1/1 for production applications is mentioned many times in the documentation." - @PrimordialAA I confirmed this with a config-change pipe running on @indexingco across the LayerZero V2 mainnet surface. For the rsETH OFT (`0x85d4...8ef3`) on Ethereum, the pipe sees exactly two events between the April 1, 2024 manual configuration and the April 23, 2026 hardening. Two years and twenty-two days, no change. The 1-of-1 [LayerZero Labs] @ 42 conf configuration is what every new pathway Kelp opened in that window inherited, and it is what got drained for $292M on April 18. On April 23, the Kelp delegate signed a single transaction (`0xbf09fd7d...3c39b947`) that flipped 25 routes to 4-of-4 [Horizen Labs, LayerZero Labs, Canary, Nethermind] at 64 confirmations. You can browse this for any LayerZero V2 OApp on the live monitor: observatory.indexing.co/kelp…. Same data directly from the pipe. The two rsETH events show up as two rows with a 752-day "no config change" gap between them. Now the part that needs balance. KelpDAO has pushed back hard on the framing. Their case: the 1-1 configuration was not unique to Kelp, the LayerZero Labs DVN was systemically important, and the actual breach was on LayerZero's own RPC infrastructure, not KelpDAO's setup. Per Kelp's "Setting the Record Straight" post: > "Public Dune analysis found that, of approximately 2,665 unique LayerZero OApp contracts, 47% ran a 1-1 DVN security floor, 45% ran 2-2, and only approximately 5% ran 3-3 or higher." That last claim is independently checkable, and I checked the corollary. LayerZero's documentation contradicts itself on this question. The integration checklist warns explicitly: > "Do: Use more than one DVN for each production pathway instead of relying on a single DVN." > "Don't: Configure only one DVN for a pathway and treat it as production-ready." But the canonical OFT example config in `LayerZero-Labs/devtools/examples/oft/layerzero.config.ts` still ships, today, as `[['LayerZero Labs'], []]`. One required DVN (LayerZero Labs), no optional DVNs. That's the file most builders will deploy first. Both can be true. Kelp manually configured 1-of-1 in April 2024. The wider ecosystem signal with defaults (example configs, what other OApps were doing) made 1-of-1 feel like a safe production posture for a long time. The April 18 breach happened on LayerZero Labs' own RPC infrastructure (independent reports from Seal911 and others; LayerZero's own postmortem confirms two RPC nodes were compromised and binaries swapped). When the single attestor in your trust set has its RPC poisoned, 1-of-1 is exactly as broken as it sounds. Kelp's path forward: they're migrating rsETH from the LayerZero OFT standard to Chainlink CCIP / the CCT standard. That's an exit, since most trust now has been broken between the two parties. However, personally I think both parties are to blame. They just aren't taking the responsibilities and working together to solve it. Sad and will remove trust by the public in both products. The lesson for everyone else operating an OFT: read your own config off-chain, today. Then watch it drift, on-chain going forward. The DVN monitor on observatory.indexing.co/kelp… auto-discovered 292 OApps without a hand-maintained registry. If yours is on there, your config is on there. If those configs change, the monitor will see it.

Casual LLM explanation of how it works with @indexingco. I literally have a team of data engineers in a box right now to do my onchain research, while owning the data I receive. Dream.

Everyday I marvel at how agents work and enjoy the harness optimisations. Just a convo with Claude, shipping of to a team of Codex agents, coding, reviewing, optimizing. Seeing the system improve with every chat, because it has the instruction to improve.

My orchestrator agent pretending to orchestrate running 10 agents in parallel overnight