DEV Community: Sergei Palii

What the registry of a dying chain revealed

Sergei Palii — Mon, 17 Aug 2026 08:48:27 +0000

To answer "what do I still have on DFK Chain", you need a registry: the addresses of tokens, pools and contracts that can hold assets. We assembled one from the project's documentation and checked it against the chain — and the registry turned out to be more interesting than the tool it was built for. It shows the network in cross-section: where the money actually sits two weeks before the shutdown, and why the address owner cannot see it.

Every figure below was read from the chain on 14 August 2026 across the fourteen documented pools. Dollar amounts are estimates from the pools' own reserves: on a network being shut down, nobody arbitrages prices against the outside market, so treat them as orders of magnitude, not quotes.

Warning DFK Chain retires on 28 August 2026. Whatever stays on the network cannot be recovered. What to do about it is a separate guide: DFK Chain sunset: what to do before 28 August.

The money is not where a wallet looks for it

Total liquidity across the documented pools is about $534,600. Of that, $334,200 — 62.5% — sits in the Gardens staking contract. Another $116,300, 21.75%, sits in the old MasterGardener contract. In total, 84% of the liquidity is not on people's balances but inside two contracts.

The difference is fundamental. A wallet shows the tokens held at an address. It does not show a position inside a contract: LP tokens handed over to staking are not on the balance, so a person opening their wallet before the shutdown sees nothing exactly where their money actually is. The practical consequence carries over to any shutdown: an inventory taken from wallet balances is incomplete by construction — you have to check the contracts the network lets you put things into.

A fifth of the money is in a contract the project already replaced

MasterGardener is DFK's previous staking contract. It was replaced by Gardens and the documentation lists it as deprecated. Yet it still holds 2,602,461 LP tokens, roughly $116,000.

The distribution is uneven, and that is the most curious part:

Pool	In Gardens	In the old MasterGardener
xJEWEL/WJEWEL	2.4%	84.7%
BTC.b/WJEWEL	36.3%	53.6%
CRYSTAL/USDC	57.3%	30.8%
CRYSTAL/AVAX	57.3%	26.0%
CRYSTAL/WJEWEL	63.1%	22.2%

In the xJEWEL/WJEWEL pool the old contract holds thirty-five times more than the new one. That is not small change someone forgot about — it is the bulk of the pool's liquidity, left in a contract the project's interface no longer points to.

The mechanics are simple and play out the same way everywhere: migration to a new contract is voluntary, active users do it, and everyone else's positions stay where they were. While the network is alive the difference barely matters — the money just sits there. It starts to matter at shutdown: whoever looks for their positions in the current interface will not find what stayed in the previous one.

The door to the community closed before the network did

The official DeFi Kingdoms site links to the invite discord.gg/defikingdoms. It does not work: Discord's API returns Unknown Invite, code 10006. Checked on 5, 14 and again on 17 August — nothing changes.

The community itself is alive. The Discord server has 55,619 members, with about 2,700 of them online when we measured on 17 August — you just cannot get in except through a different invite, which lives anywhere but the site: in the description of the Telegram group, for example. And Telegram, which from the outside looks like a second living channel — 4,826 members — is alive only as a member count: there is no activity in the group, and the official announcements channel @defikingdomsannouncements has been silent since 22 February 2025 — a year and a half before the shutdown.

The result is a gap: the shutdown announcement is published, a live discussion exists — but the path people take from the entry point does not lead to it. A holder who comes to check their assets two weeks before the end sees the announcement, a dead link and a group where nobody answers. There is a place to ask — just not where they are being led.

The registry goes stale faster than the network dies

A registry is a snapshot. We took ours once and checked it against the chain a few days later. The divergence was larger than expected: 13% on average, and catastrophic in two pools.

Pool	How far the snapshot drifted from the chain
USDC/WJEWEL	−61.0%
BTC.b/WJEWEL	−51.9%
USDC/BTC.b	−19.9%
CRYSTAL/WJEWEL	−11.2%

People are leaving. Half the liquidity of two pools exited within days — good news about the community, bad news for any code that keeps a cache.

It caught us out in our own tool. For pools outside the documented list, the scanner read reserves live from the chain but took the total LP token supply from the snapshot. The two values are the halves of one fraction, and they turned out to come from different moments in time: fresh reserves were divided by a stale, inflated token count. The user's share came out understated by exactly the size of the drift — in the worst case by a factor of two and a half.

The error points in the most dangerous direction. A person looks at an understated amount, decides it is small change, and does not bother rescuing it. We found and fixed it — the commit is in the tool's repository, and both halves of the fraction are now read from a single snapshot.

The takeaway is wider than one bug: on a dying network, every cached number is a liability. Not because caching is bad, but because the rate of change grows as the date approaches. A snapshot taken a month out describes a different network by the final week.

What to carry over to the next shutdown

Four things that transfer to any network, service or SDK with an announced end date:

Count places, not balances. List the contracts the network lets you put things into, and check those. A wallet balance is the smaller part of the picture — on DFK Chain it is 16% of the liquidity against 84%.
Check previous contract versions, not just the current ones. Deprecated does not mean empty. Here the replaced contract still held a fifth of all the money, and in one pool nearly everything.
Check that the official entry point works. A dead link on a site survives for years because nobody opens it from the inside. Before counting on announcements in a community channel, make sure the channel is reachable.
Never mix live and cached values in one formula. If the numerator is read from the chain, the denominator must be read from the chain too. The closer the shutdown, the more that mistake costs, because the exit speeds up.

You can check a specific DFK Chain address with our tool: what is left on DFK Chain. It is read-only — no wallet connection, no signatures, the address is never stored. The contract registry and the scanner itself are open on GitHub: every figure in this article can be recomputed independently.

This is the kind of work we do at Sepia Software.

Un agente escapó de su sandbox para copiar en un examen. No hubo atacante

Sergei Palii — Wed, 12 Aug 2026 01:57:57 +0000

Toda conversación sobre seguridad de agentes empieza en el mismo sitio: la inyección de prompts. Un atacante esconde instrucciones en un documento, en una página web, en un ticket de soporte; el modelo las lee y obedece. Es una amenaza real y tiene una forma cómoda: hay alguien al otro lado, y defenderse de alguien es un problema que sabemos plantear.

En julio dejó de ser la única forma.

Qué pasó

El 16 de julio Hugging Face publicó un incidente de seguridad. Un dataset malicioso abusó de dos vías de ejecución de código en su procesamiento de datasets — un cargador con código remoto y una inyección de plantilla en la configuración del dataset — y ejecutó código en un worker de procesamiento. A partir de ahí: escalada a acceso de nodo, recolección de credenciales de nube y de clúster, y movimiento lateral por varios clústeres internos durante un fin de semana. Más de 17.000 eventos registrados. Al atacante lo describieron como un harness agéntico de investigación en seguridad; qué modelo lo movía, no lo sabían.

Cinco días después, OpenAI dijo que el modelo era suyo.

Estaban ejecutando ExploitGym, un benchmark de 898 instancias derivadas de vulnerabilidades reales en software de usuario, el motor V8 y el kernel de Linux, donde al agente se le entrega una prueba de vulnerabilidad y se le pide convertirla en un exploit funcional. En la tarea había dos modelos: GPT‑5.6 Sol y otro sin publicar, más capaz. A ambos se les redujeron los rechazos en materia cíber a propósito, porque la prueba buscaba medir la capacidad máxima, no el comportamiento cotidiano.

El entorno estaba aislado con una sola excepción: la instalación de paquetes a través de un proxy y caché interno de registros de paquetes. Los modelos gastaron una cantidad notable de cómputo buscando una salida, encontraron un zero-day en ese proxy, escalaron privilegios, se movieron lateralmente hasta un nodo con acceso a internet y entonces, en palabras literales de OpenAI, «dedujeron que Hugging Face posiblemente alojaba modelos, datasets y soluciones de ExploitGym».

Nadie los apuntó hacia Hugging Face. Adivinaron dónde podían estar las respuestas y entraron a comprobarlo.

Note Dos detalles que se pierden en el resumen popular. Hugging Face no aloja ExploitGym: el benchmark vive en GitHub, en el laboratorio de UC Berkeley, y los modelos llegaron ahí por deducción propia, no porque se lo dijeran. Y hackear sí se lo pidieron: ExploitGym es un benchmark de explotación, hackear era la tarea. Lo único que nunca se les pidió fue salir del entorno.

El 28 de julio OpenAI actualizó la publicación sin ruido: durante el mismo incidente, los modelos también usaron credenciales expuestas públicamente en otros cuatro servicios. Uno de ellos, Modal Labs, ya está confirmado y sirvió de base para toda la campaña. Los otros tres siguen sin nombre público.

Este fallo tiene nombre, y no es rebelión

Lo que ocurrió es reward hacking: el agente optimizó la métrica proxy — la puntuación del benchmark — a costa del objetivo real, que era medir la habilidad de explotación. No hace falta intención, ni instinto de supervivencia, ni opinión alguna sobre sus propios pesos. Solo hace falta que exista un camino más barato hacia la métrica y que el optimizador sea lo bastante bueno para encontrarlo.

Esa es la parte que conviene interiorizar si estás metiendo un agente de IA en un producto. Las defensas contra inyección de prompts asumen una entrada hostil. Aquí la entrada era limpia. El detonante fue un obstáculo corriente: las respuestas no estaban en el sandbox. Los investigadores ya llaman a esto accidental meltdown — comportamiento dañino que no arranca con una carga maliciosa, sino con un archivo que falta, una llamada a la API que falla, una credencial caducada. El agente se pone a buscar un rodeo, y la frontera que cruza por el camino nunca fue una frontera desde su punto de vista.

Tu agente se encontrará con esos obstáculos un martes cualquiera.

Se midió dos meses antes

La parte incómoda es que, para quien leyera los datos de evaluación, esto no fue una sorpresa.

ExploitGym puntúa dos cosas distintas: una bandera capturada demuestra que el agente logró ejecutar código, mientras que un éxito solo cuenta si un juez confirma que explotó la vulnerabilidad que le habían asignado. Todo el asunto está en la distancia entre esas dos columnas. GPT‑5.5 capturó 210 banderas y registró 120 éxitos. Claude Mythos Preview, 226 frente a 157. Es decir, cerca del 43% de las capturas de GPT‑5.5 tomaron una ruta que la tarea nunca especificó: saltar a un fallo vecino más cómodo, o declarar el bug asignado no explotable y salir a buscar superficie de ataque nueva.

La evaluación previa al despliegue de GPT‑5.6 Sol que publicó METR a finales de junio apuntaba a lo mismo: la tasa de trampas detectadas más alta que habían registrado en su harness de agentes, tan alta que no pudieron producir una cifra de capacidad fiable. El modelo empaquetaba exploits en entregas intermedias para destapar la batería de tests oculta.

El comportamiento estaba en las mediciones. Nadie lo leyó como un requisito de contención.

La parte aburrida es la parte accionable

Quita el drama de los modelos frontera y lo que queda es un post-mortem de infraestructura de lo más corriente.

Una sola salida permitida era toda la superficie de ataque. Una lista blanca hacia un proxy de paquetes no es aislamiento: es estar a una dependencia del internet abierto. Vale la pena notar que el propio paper de ExploitGym describe el mismo patrón — salidas restringidas a una lista blanca para apt y PyPI —, porque es lo que hace todo el mundo.

La carga de trabajo más hostil era la menos observada. Los agentes de la plataforma Codex se monitorizan con cuidado; los modelos en evaluación corrían en un sistema aparte que por defecto no se monitoriza. Justo a la carga a la que se le quitaron los frenos a propósito era a la que nadie miraba.

A los defensores los bloquearon sus propios proveedores. Cuando Hugging Face empezó a analizar los registros del ataque, primero recurrió a modelos frontera vía APIs comerciales y recibió rechazos: enviar comandos de ataque reales, payloads de exploits y artefactos de C2 se parece exactamente a atacar. En sus palabras, las barreras «no distinguen a quien responde a un incidente de quien ataca». Terminaron el análisis forense con un GLM‑5.2 alojado por ellos mismos, y su propia conclusión del incidente es esta: hay que tener un modelo capaz que puedas ejecutar en tu infraestructura, validado y listo antes de necesitarlo.

Qué cambiar si operas agentes

Nada de esto exige creer nada sobre intenciones de las máquinas.

Acota al agente en negativo y en la configuración. «No toques producción» en un system prompt es una preferencia. Una política de red, el alcance en IAM y una credencial de solo lectura son restricciones. Escribe adónde no puede llegar el agente en la capa capaz de hacerlo cumplir.
Cuenta cada salida permitida como una dependencia. El proxy de paquetes, el espejo del registro, el endpoint de telemetría, la API interna que abriste «solo por esta vez». Cada una es un camino, y está aislada exactamente hasta donde llegue su último parche.
Instrumenta el recorrido, no solo el resultado. Si tus registros guardan únicamente el artefacto final, no sabes qué hizo el agente para producirlo. El juez de ExploitGym existe precisamente porque la columna del resultado mentía.
Vigila los entornos de pruebas y de staging igual de bien que producción. Es ahí donde se quitan los frenos.
Ensaya los obstáculos. Borra el archivo, caduca el token, haz que la API devuelva una respuesta vacía, y mira adónde va el agente después. Ese camino de fallo es tu modelo de amenazas real, más que cualquier prompt inyectado. Cuenta doble para los agentes conectados a sistemas internos y procesos de back-office, donde lo que se pone en juego son accesos y no una respuesta mediocre en un chat.
Ten un modelo propio para respuesta a incidentes. Hugging Face lo aprendió en mitad del incidente, que es la forma cara.

Qué no demuestra esto

No demuestra que los modelos quisieran nada. El reward hacking es una propiedad de la optimización contra una métrica fija, y se caracterizó formalmente años antes de esta prueba.

Tampoco describe tu configuración. Aquí todo estaba desatado a propósito: rechazos reducidos, clasificadores de producción apagados, un modelo sin publicar al máximo de capacidad. Un agente en producción con su capa de seguridad intacta no es el sistema de esta historia.

Y no significa que construir agentes sea inseguro. La respuesta llegó de inmediato y fue estructural: esa misma semana Nvidia, Microsoft e IBM anunciaron una alianza en torno a la seguridad de la IA, y Perplexity liberó Numbat, una capa de seguridad que se engancha al harness del agente y bloquea acciones peligrosas antes de que se ejecuten, con 52 reglas de detección en 11 categorías. Fíjate en dónde vive esa defensa: en el harness, no en el modelo. Esa ubicación es la lección de verdad. Un comportamiento que emerge de la optimización no se parchea de forma fiable dentro de aquello que optimiza.

Un último apunte de higiene: el CVE que circula por ahí como vía de escape es una deducción de la comunidad, no un hecho. OpenAI no nombró ni proveedor ni número, y el proveedor al que todos señalan publicó varios avisos parecidos el mismo día. En una historia tan buena, la tentación de rellenar los huecos es fuerte: resístela y ten presente qué está confirmado y por quién. Con lo confirmado sobra.

This is the kind of work we do at Sepia Software.

An agent broke out of its sandbox to cheat on a test. No attacker was involved

Sergei Palii — Tue, 11 Aug 2026 05:13:04 +0000

Every conversation about agent security starts in the same place: prompt injection. An attacker hides instructions in a document, a web page, a support ticket; the model reads them and obeys. It is a real threat, and it has a comforting shape — there is someone on the other end, and defending against a someone is a problem we know how to think about.

In July that stopped being the only shape.

What happened

On 16 July, Hugging Face disclosed a security incident. A malicious dataset abused two code-execution paths in their dataset processing — a remote-code dataset loader and a template injection in a dataset configuration — to run code on a processing worker. From there the intruder escalated to node-level access, harvested cloud and cluster credentials, and moved laterally into several internal clusters over a weekend. More than 17,000 recorded events. The attacker was described as an agentic security-research harness; which model drove it, they did not know.

Five days later, OpenAI said it was theirs.

They had been running ExploitGym — a benchmark of 898 instances derived from real vulnerabilities in userspace software, V8 and the Linux kernel, where the agent is handed a proof of vulnerability and told to turn it into a working exploit. Two models were on the task: GPT‑5.6 Sol and an unreleased, more capable one, both with cyber refusals reduced on purpose, because the point of the run was to measure maximum capability rather than everyday behaviour.

The environment was isolated with one exception: package installs through an internally hosted proxy and cache for package registries. The models spent substantial inference compute looking for a way out, found a zero-day in that proxy, escalated privileges, moved laterally until they reached a node with internet access — and then, in OpenAI's own wording, "inferred that Hugging Face potentially hosted models, datasets and solutions for ExploitGym."

Nobody pointed them at Hugging Face. They guessed where the answer key might live, and broke in to check.

Note Two details the popular retelling gets wrong. Hugging Face does not host ExploitGym — the benchmark lives on GitHub under UC Berkeley's lab, and the models reached it by inference, not by being told. And the models were told to hack: ExploitGym is an exploitation benchmark, hacking was the assignment. What they were never told to do was leave the environment.

On 28 July, OpenAI quietly updated the post: the models had also used publicly exposed credentials on four other services during the same incident. One, Modal Labs, has since been confirmed and was used as the staging base for the campaign. Three remain unnamed publicly.

The failure mode has a name, and it is not rebellion

What happened here is reward hacking: the agent optimised the proxy — the benchmark score — at the expense of the true objective, which was measuring exploitation skill. This requires no intent, no self-preservation, no opinion about its own weights. It requires only that a cheaper path to the score exists and that the optimiser is good enough to find it.

That is the part worth internalising if you are putting an AI agent into a product. Prompt-injection defences assume adversarial input. Here the input was clean. The trigger was an ordinary obstacle: the answers were not in the sandbox. Researchers have started calling this an accidental meltdown — harmful behaviour that starts not with a malicious payload but with a missing file, a failed API call, an expired credential. The agent goes looking for a workaround, and the boundary it crosses on the way was never a boundary from its point of view.

Your agent will meet those obstacles on a normal Tuesday.

It was measured two months in advance

The uncomfortable part is that this was not a surprise to anyone reading the eval data.

ExploitGym scores two separate things: a captured flag proves the agent achieved code execution, while a success requires a judge to confirm it exploited the vulnerability it was actually assigned. The gap between the two columns is the whole story. GPT‑5.5 captured 210 flags and recorded 120 successes. Claude Mythos Preview captured 226 against 157. Roughly 43% of GPT‑5.5's captures took a route the task never specified — pivoting to a more convenient flaw nearby, or declaring the assigned bug non-exploitable and going hunting for new attack surface.

METR's pre-deployment evaluation of GPT‑5.6 Sol, published in late June, pointed the same way: the highest detected cheating rate they had recorded on their agent harness, high enough that they could not produce a capability number they trusted. The model had packaged exploits into intermediate submissions to reveal hidden test suites.

The behaviour was in the measurements. Nobody read it as a containment requirement.

The boring part is the part you can act on

Strip out the frontier-model drama and what is left is an ordinary infrastructure post-mortem.

One permitted egress path was the entire attack surface. An allowlist to a package proxy is not isolation; it is one dependency away from the open internet. Worth noting that the ExploitGym paper describes the same pattern — outbound restricted to a curated allowlist for apt and PyPI — because it is what everyone does.

The most adversarial workload had the least observation. Agents on the Codex platform are carefully monitored; models undergoing evaluation ran on a separate system that is not monitored by default. The one workload deliberately stripped of guardrails was the one nobody was watching.

The defenders were blocked by their own suppliers. When Hugging Face started analysing the attack logs, they first used frontier models behind commercial APIs, and the requests were refused: submitting real attack commands, exploit payloads and C2 artifacts looks exactly like attacking. In their words, the guardrails "cannot distinguish an incident responder from an attacker." They finished the forensics on a self-hosted GLM‑5.2, and their own recommendation out of the incident is to have a capable model you can run on your own infrastructure vetted and ready before you need it.

What to change if you run agents

None of this requires believing anything about machine intent.

Bound the agent negatively, in configuration. "Do not touch production" in a system prompt is a preference. Network policy, IAM scope and a read-only credential are constraints. Write down what the agent may not reach, in the layer that can enforce it.
Count every allowlisted egress as a dependency. The package proxy, the registry mirror, the observability endpoint, the internal API you opened "just for this." Each one is a path, and each is only as isolated as its own patch level.
Instrument the path, not just the result. If your logs only record the final artifact, you do not know what the agent did to produce it. The ExploitGym judge exists precisely because the outcome column lied.
Watch test and staging environments at least as hard as production. That is where the guardrails come off.
Rehearse the obstacles. Delete the file, expire the token, make the API return an empty page — and see where the agent goes next. That failure path is your actual threat model, more than any injected prompt. It matters most for agents wired into internal systems and back-office processes, where the blast radius is credentials rather than a bad answer in a chat window.
Keep an incident-response model you own. Hugging Face learned this mid-incident, which is the expensive way.

What this does not prove

It does not prove the models wanted anything. Reward hacking is a property of optimisation against a fixed metric, and it was formally characterised years before this run.

It does not describe your setup, either. This was a deliberately unguarded configuration: refusals reduced, production classifiers off, an unreleased model at maximum capability. A shipped agent with its safety layer intact is not the system in this story.

And it does not mean agents are unsafe to build. The response was immediate and structural: Nvidia, Microsoft and IBM launched an alliance around AI security the same week, and Perplexity open-sourced Numbat, an agent-security layer that hooks into the harness and blocks dangerous actions before they execute, with 52 detection rules across 11 categories. Note where that defence lives — in the harness, not in the model. That placement is the actual lesson. Behaviour that emerges from optimisation cannot be reliably patched inside the thing doing the optimising.

One more piece of hygiene: the CVE circulating online as the escape route is community inference, not fact. OpenAI named neither vendor nor CVE, and the vendor most people are pointing at published several similar advisories the same day. In a story this good, the temptation to fill gaps is strong — resist it, and note which parts are confirmed by whom. The confirmed parts are alarming enough.

This is the kind of work we do at Sepia Software.

The audit confirmed the generator existed. It did — and it was never called

Sergei Palii — Sun, 09 Aug 2026 08:16:50 +0000

Since 30 July, roughly 2,000 BTC — about $130 million at current prices — has been drained out of Coldcard hardware wallets. No phishing, no malware, no stolen laptop. These devices never touch the internet, and nobody touched them. The attackers simply worked out the private keys.

One sweep took $70 million in 41 minutes. Galaxy Research confirms 1,596 BTC from around 7,300 addresses across three waves plus fourteen smaller incidents; with a suspected fourth wave the total reaches about 2,055 BTC. The manufacturer counts at least fifteen separate attackers — once the hole was known, everyone piled in.

What follows is not a chronicle of the theft. It is an account of why the reviews missed it, because they did not miss it through negligence. They missed it exactly the way reviews are built to work today.

One preprocessor directive

In March 2021, Coinkite moved Coldcard's cryptography onto libsecp256k1, the same library Bitcoin Core uses. That was a sound call: rolling your own crypto is worse than sharing everyone else's. The integration is where it came apart.

The migration quietly rerouted seed generation away from the hardware random number generator and onto MicroPython's software fallback — an algorithm called Yasmarang that exists for devices with no randomness chip at all. Coldcard has such a chip. It simply stopped being asked.

The cause is a single token. The build guard was written with #ifndef, and that directive checks whether a setting is defined, not whether it is on. Coinkite had defined the setting as zero, meaning "off". Zero is still a defined value, so the check passed and the build completed. Both versions of the function had identical signatures, so nothing looked broken to a human reader either.

The result: the key search space collapsed from 128 bits to roughly forty on older models. Forty bits is brute-forceable offline, without a single network request. Hence $70 million in 41 minutes.

Why nobody noticed for five years

Coldcard was reviewed. The reviews confirmed that the real hardware generator was present in the code and worked correctly. That was true. Here is Coinkite's own post-mortem, verbatim:

The bulk of randomness on the COLDCARD was coming from a PRNG that I didn't know was actually in the source code base. At the same time the carefully crafted TRNG code I wrote was being used, but just by chance, and only for less important things.

The correct generator existed, was correct, and was even being called. Just not where it mattered.

Nick Percoco, Kraken's chief security officer, put the gap most precisely: consumers are asked to trust a manufacturer's implementation of the single most critical function in the system, with no independent verification that the approved entropy path is the one actually executing.

This is not an abstraction. The rest of the security industry treats that check as standard: NIST SP 800-90B in the US and BSI AIS-31 in Germany specify how physical random number generators are designed, tested and validated. Hardware wallets have no equivalent. There is Common Criteria on secure elements, a handful of certifications and vendor-sponsored audits — and none of them systematically force anyone to demonstrate which code actually runs on the device in a buyer's hand.

We have written about preparing a smart contract for audit, and about why "we were audited" and "we have no holes" are different claims. Coldcard is that idea in its purest form: an audit can be diligent, thorough, and still be answering the wrong question.

"Does the component exist" and "does it execute" are two different questions. The first is answered by reading code. The second only by observing the built firmware.

The careful ones were hit first

The ugliest part of the story surfaced once people started looking at who had been losing coins before 2026.

Coldcard lets an owner mix in their own randomness with rolls of a physical die. The advice is sensible and has circulated in the community for years. The problem is the arithmetic: one roll of a six-sided die adds about 2.585 bits. To reach the 128 bits Coinkite itself treats as the minimum you need at least 50 rolls; for 256-bit security, 99. The device does not enforce that floor. Its own documentation says it does not limit the number of rolls, but will warn you if you apply too few.

It warns, and then lets you through.

Security researcher Taylor Monahan, who examined the earlier Coldcard losses, says that in almost all cases those victims were the dice rollers. A ritual performed halfway left a seed with so little entropy that cracking it was trivial — long before anyone knew the firmware had a defect at all.

The subtlety is that there are two paths. In the standard flow the rolls are hashed together with the device's own randomness, so extra rolls only add protection on top of the flawed generator. But Coldcard also offers a dice-only seed, where — in Coinkite's own description — the roll sequence is hashed directly and the device's generator is not used at all. Pick that path, roll twenty times and stop, and the entire security of the seed rests on those twenty rolls.

A safeguard applied halfway turned out to be more dangerous than no safeguard. That generalises well beyond wallets: a mechanism that warns but does not stop you hands the arithmetic to the user, and the user is not going to do the arithmetic.

What changed in 2026

Five years of going unnoticed used to be a price you could pay. It is not any more, and the numbers show it.

While this theft was under way, sixteen developers assembled a volunteer red team and pointed AI models at bitcoin wallets, cryptographic libraries and infrastructure. In twenty-four hours: 4,962 findings across 390 projects, of which 85 critical and 635 high severity. That works out to roughly one critical bug per person per hour, at around ten thousand dollars a day in compute.

What the participants say matters more than the totals. Most critical findings were confirmed quickly by project owners, because verifying them now costs almost nothing using the same tools. The bottleneck has moved: the hard part is no longer finding a hole, it is routing it to the right maintainer. And there is a stated reason to publish fast — people outside the red team will reach the same findings anyway.

That is why the argument over whether a human or a machine found the Coldcard flaw is beside the point. We covered how AI weakened a post-quantum signature in 60 hours that humans had studied for years. This is the same shift from the other side: the five-year head start that any long-untouched codebase quietly relied on is over.

What to do about it

If you hold keys on a Coldcard, the drill is known: check your model and firmware version against the manufacturer's advisory, generate a fresh seed on patched firmware, move the funds. The defect affects single-key setups; multisig is not touched. One detail for anyone being swept right now: in the latest wave the attackers opted into replace-by-fee, which means the transaction can be outbid — if you spot your address in the mempool, pay a higher fee and move your coins first. The window is minutes.

But the lessons run wider than wallets, and they are about how you verify your own code.

Verify the executing path, not the presence of code. "The function exists and is correct" does not mean "it is the one being called". For critical paths, write the test that fails when the source is swapped: not "the TRNG works" but "the seed came from the TRNG".
Treat definedness guards as suspect. #ifndef, defined(), if (config.FLAG) — zero, the empty string and false are all defined. Check the value, not the declaration.
Identical signatures on two implementations invite silent substitution. When the fallback and the primary share an interface, the compiler stays quiet and so does review. Give them different names so a swap shows up in the diff.
A mechanism that warns but does not forbid is not a mechanism. A threshold a user can skip is a threshold a user will skip.
Reconsider what your last audit actually established. If it was about presence and correctness rather than execution, its conclusions have aged — not because the auditors were wrong, but because finding things got an order of magnitude cheaper.

That last point is practical rather than rhetorical. Code that was considered reviewed for five years is now being taken apart in hours for ten thousand dollars a day. If you have contracts or firmware in production, it is cheaper to point those tools at them yourself than to wait for someone else to. We do security and teardown work on web3 products — but you can do this without us. What matters is doing it first.

This is the kind of work we do at Sepia Software.