DeepSafe engagement report

Best tweets

• Sep 8, 20263.8x their median

  On September 5, Core DAO published its post-mortem on the reward-accounting exploit that ran from August 28 to 31. Roughly 255M CORE of rewards were issued ahead of schedule. The cap held. In Core's words, the exploit "did not create any CORE beyond the protocol's limits; the 2.1B maximum supply was never violated." What it did was accelerate rewards the emission schedule would otherwise have released later. What broke was when. That makes the damage an unusual shape. No user or staking account was drained — Core states that no user or staker funds were lost and that delegated stake was never at risk. What existed instead was surplus, sitting in balances, and it arrived through the ordinary path: the extra rewards "appeared both in attacker-controlled addresses and, unintentionally, in the reward addresses of honest validators who simply received an inflated payout they did not cause." That made the on-chain reconciliation an arithmetic problem before it was a balance-editing problem. Before any affected balance could be corrected, Core needed a rule for what that balance should have been at the upgrade block. It used two. Attacker-controlled reward pools were set to zero. For affected honest validators, it defined a fair-earnings floor — the pre-incident balance plus three rounds of that validator's own normal reward — left balances at or below it untouched, and removed only the excess above. Together the reconciliation took 186,153,491 CORE out of supply by direct state reduction. A further ~69M had been moved before the upgrade and sits outside what an on-chain reconciliation can reach; Core says it is pursuing that with law enforcement. Core says the reconciliation can be checked independently against chain state at the upgrade block, and that the reward paths were subsequently reviewed by Halborn. That part matters as much as the fix. A correction that affected users and independent observers cannot verify is only a second assertion about the balances. A supply cap is a promise about how much will ever exist. It says nothing about how much should exist yet. Restoring the second one requires knowing a number the cap never had to track. Sources: https://t.co/TMhZdwRHaQ #DeepSafe #CRVA #Web3Security

  85967799748244K viewsView on X
• Sep 17, 20261.7x their median

  On 16 September, Lombard deprecated native minting and redemption of LBTC and BTC.b on five chains — TAC, Sonic, Katana, Berachain and Starknet. Holders on the first four are required to bridge balances to Ethereum by December 10. Starknet keeps its bridge, and its balances have no deadline. Underneath that sits a second change, and it is the more interesting one. Bridging moves to a hub and spoke model. From the docs: "every supported chain has a bridge lane to and from Ethereum, and a transfer between two other chains routes through Ethereum rather than directly." Minting from native BTC is unaffected. What changed is how already-minted assets move between chains. The reason is stated plainly: "Fewer bridge contracts and message paths mean a smaller surface to secure and monitor, and security budget and engineering resources concentrate on the lanes that carry the most value." Worth being precise about what actually shrank. Not the number of chains — every other chain continues, and you can still mint from native BTC on any of them. What shrank is the number of routes between them. Those are different quantities. In a mesh, routes exist between pairs, so each chain added arrives with a new lane for every chain already there. In a hub and spoke, a chain arrives with one. The count that goes in the announcement is chains supported. The count that has to be secured and monitored is lanes. A topology decides which of the two grows faster, and that is the decision this update actually makes. https://t.co/99C3WipeAW #DeepSafe #Web3Security

  39237746214719K viewsView on X
• Sep 10, 20261.6x their median

  A system that checks something ends up with an answer to what happens when the check cannot run. Not when the check fails — when it is unavailable. The service is down, the endpoint times out, the attestation cannot be retrieved, the quorum cannot be assembled. The request is still there, and the system still has to decide what happens to it. The two simplest answers are to let it through or to hold it. Real systems have more room than that — retry, queue, fall back to a weaker check, cap the amount, route it to a person — but each of those still resolves into proceeding or not, and each has its own behaviour when the fallback is unavailable too. Both directions are defensible. A payments system that holds every transaction whenever a fraud check is unreachable has converted an availability problem into an outage. A vault that releases funds whenever its verifier is unreachable risks turning an availability problem into a withdrawal. Which cost is worse depends on what is being protected, and reasonable teams land in different places. What is worth noticing is that the answer can exist without ever having been an explicit design decision. The behaviour ends up wherever the error path happens to go. A timeout can return a permissive default. A general exception handler can let execution continue. A check added late can be wrapped in a conditional that skips it when a dependency is missing. The code may never contain a line reading "if verification is unavailable, proceed" — but that can still be exactly what it does, and it will do it just as readily when someone is making the checker unavailable on purpose. This is why the choice is worth writing down before it is discovered. A system that fails open by decision has weighed the trade. A system that fails open by accident has the same behaviour and none of the reasoning, and it learns which one it is from an incident rather than from a design review. For a verification layer the question is sharper, because an attacker may target its availability rather than defeat the check itself. If no result means no check, then the verifier does not have to be broken. It only has to be kept from answering. CRVA changes the dependency rather than removing the question. The Agents that sign are selected at random from a larger population and rotate on a fixed cycle, and under threshold MPC a valid signature requires enough participants to contribute, so no single participant can produce one alone. That reduces reliance on any one verifier. It does not guarantee that a result always arrives, and it does not settle what the surrounding system does when one does not. That stays with whoever integrates the check — which is the same decision this whole piece is about. Every system has an answer to this. The question is whether anyone chose it. #DeepSafe #CRVA #Web3Security

  37133243915119K viewsView on X
• Sep 30, 20261.6x their median

  Trail of Bits published notes on 18 September on reviewing the Miden zkVM. The part worth reading is what happened before the review started. Security firms — the same firm included — have published a number of posts describing how they pointed an agent harness at a codebase. This post is about a stage earlier than that: "before code review even starts, agents now allow us to build custom tooling and formal models that improve the quality and depth of our reviews." Miden has its own assembly language, MASM, and very little tooling around it. The firm had six months of lead time, because the implementation was not yet feature complete. It spent them having its agents build an LSP server, a decompiler, a static analysis engine, and a Lean model of the VM executor. None of that was the review. Applied during the review that followed, those tools produced concrete results. The static analysis identified over 400 unique locations where type validation could be improved, all of them reachable from the library's public API, as well as one high-severity finding: a remainder supplied by the prover was never validated before being passed to a 32-bit subtraction — "a malicious prover could exploit this to forge Falcon signatures and drain any Miden account controlled by a Falcon key pair." The Lean modeling effort produced 95 machine-checked correctness proofs covering all the binary arithmetic in the core library, and surfaced two more bugs the existing unit tests had not caught. The detail worth sitting with is smaller than any of those. The decompiler was the single largest piece of the work, over 100 agent-generated commits across months. The firm's own account of where the benefit landed: "The main benefit of this work turned out to be the decompiler's internal analysis frameworks and intermediate representation, which we could reuse for static analysis, rather than the full decompilation pipeline." The post is direct about why work like this did not happen before. It is "highly exploratory in nature, and the end results and potential payoff may be difficult to predict," which makes it "hard to sell clients on them in advance." What has changed, on the post's own account, is the cost of a miss: "Today, a failed side project only costs tokens." The payoff is no easier to predict than it was. What a wrong guess costs is smaller. One thing about this particular case is worth noting on its own. The main benefit ended up somewhere the single largest piece of the work had not been aimed at. That is a payoff shape easier to recognize once the work is finished than to argue for before it starts. https://t.co/972ijKSY19 #DeepSafe #Web3Security

  37032039015015K viewsView on X
• Sep 22, 20261.5x their median

  A draft posted to bitcoin-dev this month reworks one small piece of taproot backup. It sits in an individual fork, hasn't been assigned a BIP number, and is still in its earliest form. The draft addresses backup for unspendable internal keys. One existing approach it cites as motivation is to choose a random r and retain it, so the internal key can be recomputed later. The draft's mechanism derives a chain code from a tagged hash of a normalized wallet policy. That chain code, the fixed NUMS point H, and a selected derivation path together determine the internal key — in a step the draft describes as being done "without additional secret material." Its Security considerations section states two things: "The policy and selected derivation are enough to reproduce the internal key," and, in the same section, "Seed backups alone do not reconstruct the policy." Read narrowly, what the draft changes is which inputs are needed to reconstruct that internal key. Draft: https://t.co/IiCRQuQPcv

  36233438213316K viewsView on X
• Oct 2, 2026

  On 1 October, the Ethereum Foundation blog introduced zkAPI, built by the Open Anonymity Project with the EF: a way to pay for a metered API, AI inference first, without the payment being tied to who you are. You deposit credits into a vault contract on Ethereum once. After that, your device produces a zero-knowledge proof that says, in effect, "a funded note covers this spend and nobody has spent it before." The server checks it, issues a short-lived API key capped in dollars, and never learns which deposit paid. The design choice worth noticing is where those proofs get checked. Day to day, spending goes through the server, which verifies spend proofs off-chain. Getting money out is handled differently: "The vault contract verifies the same kind of proof at deposit, close, and escape, so your exit never depends on the server's honesty." A balance can be closed and withdrawn on-chain "even if every zkAPI server disappears." So the operator is relied on for one thing and not the other. Everyday spending runs through the server. The step that returns your funds is checked by the contract itself. Not every check in a system has to run on-chain. In this design, the one that guards the exit does. https://t.co/KPblUUWPJi #DeepSafe #Web3Security

  32030838512615K viewsView on X
• Sep 14, 2026

  EIP-8025 is a draft that would let Ethereum consensus nodes check a cryptographic proof that a block's transactions were executed correctly, in time that stays flat no matter how much gas the block used. Today a node establishes that by running the transactions itself. The interesting part is not the proof. It is where the draft declines to put it. A verified proof does not replace re-execution — the spec calls it "an additional signal, not a replacement." It is not wired into fork choice or attestation, the two things that decide which block a node follows and what it votes for. A node that has not received a proof does not wait for one. And a forged proof cannot fork the chain or get anyone slashed; its effect stops at the local view of the node that accepted it. The proof is real, and it does something. It is just not load-bearing. The draft is explicit about why, and about what comes after: treating proofs as a non-critical artefact "lets the stack mature on a live network," and "a separate, future EIP could subsequently propose making execution proofs mandatory once they have matured." That is a deployment order, written down. Ship the mechanism somewhere its failures are survivable. Gather proof sizes, generation latency and client behaviour from a real network. Then argue, in a separate document, for giving it a job the chain depends on. What that sequence separates is worth naming. Whether a verification method works is one question, and cryptography answers part of it — the rest comes from the implementation, the inputs it is handed, and how it holds up in production. What that method is permitted to decide is a different question, and it is settled by design rather than by strength. Operational history is not the source of that authority. It is the evidence you want before granting it. The two questions are easy to merge, because a check usually arrives already attached to whatever the surrounding code does with its output. Pulling them apart takes deliberate work, and this draft does it on the page. The same two questions apply to what we build. CRVA verifies on-chain and off-chain data using nodes selected at random. What a result is permitted to decide is not a property of the verification itself. It is a choice made by the system integrating it — one worth stating explicitly rather than inheriting from whatever the surrounding code happens to do. A check can be sound long before it is ready to be depended on. The draft's contribution is making that boundary explicit. Sources: https://t.co/tT8jvwr8jj #DeepSafe #CRVA #Web3Security

  30127936813717K viewsView on X
• Sep 1, 2026

  Cronos halted on Sunday after an exploit on Tectonic. On Monday it said block production had resumed and that the chain state had been restored to before the exploit. It called that a validator-consensus emergency action. Tectonic said it would reopen in phases once its own checks clear, beginning with withdrawals and repayments while deposits and borrowing stay paused. Neither team has confirmed a loss figure, and both say a full post-mortem is coming. Cronos resumed from block 90,896,189. The Defiant puts that 10,961 blocks behind the branch users had already watched confirm, roughly one hour and 54 minutes of chain history. On the new canonical chain, the attacker's Cronos-side gains no longer exist. The portion that had already crossed to Ethereum does. PeckShield and Lookonchain both tracked about 2,592 ETH, worth roughly $6.29M at the time, that reached Ethereum before block production stopped. One exploit, three outcomes. What reached Ethereum stayed beyond the rollback's reach. The attacker's Cronos-side gains were removed from the canonical state. And so were the trades, transfers and liquidations of people with no connection to the exploit — confirmations they had already watched land inside that window. The rollback did not separate exploit transactions from ordinary ones. It separated only what Cronos validators could rewind from what they could not. As of September 1, neither team has published an accounting of how those unrelated transactions will be handled, or whether any of them can be replayed. This is not an argument that the rollback was right or wrong, and it is not a claim about decentralisation. The narrower point is what this remedy requires and how far it reaches. It requires validator consensus. It reaches only the chain those validators run. And it invalidates every prior confirmation inside the history it replaces, no matter whose transaction it was. CRVA does not remove the need for emergency controls, and it would not have prevented the flaw inside Tectonic. The narrower distinction is the unit of refusal. Where an applicable check already sits in the execution path and its result is enforced, one request can be refused without an ad hoc validator intervention that replaces unrelated chain history. The chain is back. The exploit's Cronos transactions are out of the canonical state. What is still open is everything the rollback could not reach, and everything else it reached on the way. Sources: https://t.co/fgxVSZif8s #DeepSafe #CRVA #Web3Security

  30026138413223K viewsView on X
• Sep 28, 2026

  🤝 DeepSafe × @DeAgentAI DeepSafe is partnering with DeAgentAI. DeepSafe is a verification layer for AI and Web3 — using Ring-VRF, MPC, and TEE to validate AI Agent inputs and outputs, independent of the parties being verified. DeAgentAI’s AI Token Smart Router is the model gateway. Verification and model access now sit next to each other. #DeepSafe #DeAgentAI #AIA #VerifiableAI

  30626635710410K viewsView on X
• Sep 26, 2026

  Weekend puzzle. A node operator publishes its source code. The code has been audited, and the audit report is public too. Does any of that tell you which build is actually running on the node? A. Yes. The code is public. B. Yes. The code is audited. C. No—not on its own. https://t.co/eXUuh2GfAN

  28024837711315K viewsView on X

Ranked by total interactions across everything we have tracked for this account, which is a longer history than the 30-day window the rates above use. The multiple compares each post to this account's own median.

Keep going