DeepSafe 中文

DeepSafe is excited to announce our $3m Seed Round with @AntalphaGlobal @ViabtcCapital @capital_spark @CogitentV @ShardingCapital @Mason_eagle @Gate @SatoshiLab_HK @CKBEcoFund The core decentralized validation technology of DeepSafe has been accepted by the top international cryptographic academic journal IEEE TIFS, with the document ID being 9903072. Currently, the DeepSafe network has processed nearly 120 million transaction validations, and the number of active accounts on the network exceeds 2.65 million. Time to make a better Trust Layer now.

Running key management inside SGX keeps a device's data confidential and lets it detect tampering. It doesn't tell the device which version of that data is current. A Trail of Bits post on threshold signing in TEEs puts the gap in one line: "Authenticated encryption provides confidentiality and integrity but not freshness." CRVA runs MPC inside SGX, and its docs name a version of this problem for its own devices: the Database Backup Attack. Devices act on chain events and chain state, which they read through a node their owner configures. The docs walk through how an owner with several devices could use that: back up the devices' databases every epoch; wait until identities are revealed after the next handover; and, if those devices turn out to hold enough shares to rebuild a committee's key, "send fake events and fake storage" to the backups so the devices hand their shares to devices the owner created. Device data is encrypted by SGX, and nothing in those steps requires breaking that. As we read it, what the attack replaces is the device's view of which chain state is current. The defense in the docs is a vote. Each epoch, the snapshot of working devices goes to the previous epoch's CourtMembers. With more than half in favour it is confirmed, and its devices become the current CourtMembers; without that, the previous members stay on. The Ring-VRF candidates then go to the current CourtMembers. If the candidates do not get more than half of the current CourtMembers, the candidates are cleared and no key generation or handover runs. To attack this way, the docs say, an attacker would need more than half of that epoch's CourtMembers. An enclave can tell whether its data was altered. For the state that decides who receives key shares, CRVA doesn't leave the question of what is current to any single device. blog.trailofbits.com/2026/09… docs.deepsafe.network/introd… #DeepSafe #CRVA #Web3Security

A verification layer is only as useful as the precision of what it claims to check. For one of its components, DeepSafe spells that out. The SPV service runs blockchain light clients inside SGX and provides transaction verification to the monitor. Its stated purpose, in the docs: "preventing malicious signatures caused by fraudulent information sources." On the Bitcoin side the docs describe the familiar construction: block headers, Merkle proofs, confirming "a transaction's inclusion in a specific block." There is a second question, about the checker rather than the chain: how do you know which program produced the answer? The service registers through remote attestation and its enclave measurement is validated on chain, so that "only programs with the specific, pre-approved code can pass verification." In local mode each monitor is paired with its own SPV, to "ensure decentralization of verification sources." That is a narrow question, answered carefully. What it does not answer is what the transaction means. An inclusion proof establishes that a transaction is included in a particular block. It establishes nothing about which account an application should credit, or what an instruction attached to it authorizes. Those follow from the application's own rules, and the rules differ from one bridge to the next. The two are not the same kind of question. Whether a transaction is included in a given block is a question about the chain, and it is worth solving once, at the layer. What that transaction means is a question about one system's rules, and the answer has to come from those rules. A check is more useful when you can say where it stops. Sources: docs.deepsafe.network/introd… #DeepSafe #CRVA #Web3Security

On 5 October, the Ethereum Foundation's Trillion Dollar Security initiative published a post on native transaction assertions, with EIP-7906 as one possible design. For the Hegotá upgrade, EIP-7906 has advanced to "Considered for Inclusion" but is not yet confirmed. The idea: a transaction carries a rule about its own outcome, signed along with its actions. After the actions run, read-only code compares starting and final values against that rule: a minimum amount received, no new approvals, an account's control logic left unchanged. If the rule fails, the actions revert. That puts the check after the actions have run, where the full set of net state changes can be inspected. The post is direct about two conditions it still depends on. The first is where the rule comes from. "A compromised frontend can write an assertion that permits the attack." A useful rule, in the post's words, "must come from independently approved user intent, a standing account policy or protocol logic that the compromised component cannot change." The second is whether the rule is there at all. "EIP-7906 does not require transactions to include an assertion, so whoever builds the transaction can leave it out." A wallet has to include it in every frame transaction it builds (the transaction type EIP-7906 builds on, defined in EIP-8141); a protected function has to reject ordinary transactions and frame transactions that arrive without the exact assertion it expects. What the check protects depends on two things outside the check itself: who wrote the rule, and whether anyone can leave it out. The same two questions apply to any verification layer, including ours: whose rules it checks against, and whether it can be left out. blog.ethereum.org/en/2026/10… #DeepSafe #Web3Security

Ring-VRF is the method CRVA uses to select different batches of committee members. The documentation is specific about what its proof reveals and what it does not, and the distinction is worth reading closely. Ring-VRF separates the identification of a specific signer from the proof that the signer is eligible. A member proves their public key belongs to a published set without revealing which one. The docs name this directly — "Anonymous Key Ownership Proof: Allows a member to prove their public key belongs to a specified set without revealing which one." The mechanism is a one-out-of-many protocol, whose stated job is to prove that some pkₗ is in {pk₀,...,pkₙ₋₁} without revealing ℓ. Membership by itself would not be enough. The same step also produces a verifiable random value derived from the member's private key and a random seed. So the proof carries two claims at once: my key is in this set, and this random output came from that key. What holds those two together is a separate piece. A consistency sub-proof links the Pedersen commitment and the PRF output to the same private key. The documentation is plain about what it is there to stop: "Forgeries using mismatched keys." Without that link, both halves could hold on their own without establishing that they came from the same key — membership shown with one key, randomness produced from another. That is the part worth taking from the design. The anonymity is not bought by asking for less. The verifier still checks membership, still checks that the random value derives from the seed, and still checks that both trace back to one private key. What it never learns is which member. Docs: docs.deepsafe.network/introd… #DeepSafe #CRVA #Web3Security

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. blog.ethereum.org/en/2026/10… #DeepSafe #Web3Security

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. blog.trailofbits.com/2026/09… #DeepSafe #Web3Security

On 24 August, a proposal on Neutron titled "TestProp: Preparation for AIATO: AI Agent Takeover" asked governance to make one address the admin of ten contracts, among them six Astroport pools and two Drop contracts. When voting closed on 31 August, it was rejected. Roughly 10.4 million NTRN voted no; about 0.32 million voted yes. On 19 September, proposal 9, "AIATO: AI Agent Takeover. Phase 1: Agent Admin Registration", asked for the same ten admin changes to the same address, plus an eleventh. It was filed as an expedited proposal and passed when voting closed on 22 September at 02:24 UTC, with about 37.3 million NTRN voting yes. Cosmos Hub validators halted the Hub to limit losses of ATOM moved there from Neutron, and say the funds secured at restart are held in a community validator multisig. None of this was hidden. From 24 August, the title, the ten contracts and the address that would become admin were public on-chain. From 31 August, so was the rejection. The August vote said no to that proposal. It did not stop the same request from being filed again nineteen days later and passing. It ended a vote. It did not end the attempt. Proposal 5: mintscan.io/neutron/proposal… Proposal 9: mintscan.io/neutron/proposal… Cosmos Hub halt: teapawt.net/cosmoshub/status/21023… Cosmos Hub restart: teapawt.net/cosmoshub/status/21028… #DeepSafe #Web3Security

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: github.com/bitryonix/bips/bl…

EIP-8365 was added to the Ethereum EIPs repository on 17 September, with status Draft. It proposes retiring 0x00, the original genesis-era withdrawal credential type: exit every active validator that still carries one, and stop processing deposits that would create more. The proposal reports that the population has fallen from roughly 600,000 to 9,290 since Capella opened one-way conversion, but that the decline has stalled. Of the 9,119 still active, it counts 374 that have not attested for over six months and 253 that have never attested in a 14-month observation window. Its own reading: "These are, with high likelihood, validators whose keys are lost." High likelihood is as far as it gets, and the proposal has to reason from attestation history precisely because the fact it needs is not in the state. The chain records that a validator is not producing attestations. Whether anyone is still able to act for it is not something the chain records. What the proposal does supply is a measurement of what that missing fact costs. 4.45% of active 0x00 validators have been offline for 30 days or more, against 0.10% for 0x01 and 0.05% for 0x02. The same observable state, with two different meanings: "Being offline is a transient state for execution-credentialed validators, whose owners can always exit and recover funds, but a terminal state for 0x00 validators with lost keys." Terminal, when the signing key is the thing that is gone. Voluntary exit needs that key; the execution-layer triggerable exit needs an execution address, which 0x00 credentials do not have. For that subset — and only that subset — both paths are closed, and at the penalty rates cited natural ejection takes roughly 28 years. Other 0x00 holders still have the ordinary exit available; the proposal writes a rule that does not depend on knowing which is which. No balance is moved by this stage. The unchanged rotation path stays open, and any 0x00 holder who still controls their withdrawal key can use it to recover in full. The lost-key subset — by definition — cannot. The part worth reading twice is what the proposal declines to do. Rescue proposals for this population have been rejected before on credible-neutrality grounds, because a rescue "adjudicates off-chain ownership claims and selects beneficiaries." So this one does not ask who owns anything. It writes "a uniform rule over a class defined by an objective on-chain property," announced ahead of activation, with the conversion path open to every member throughout. That is the trade. A protocol that cannot verify a claim can still act on it — by never making the claim the thing it acts on. eips.ethereum.org/EIPS/eip-8… #DeepSafe #Web3Security

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. docs.lombard.finance/use/cha… #DeepSafe #Web3Security

Symbiosis has published its post-mortem on the Bitcoin Bridge incident of 11 September. The deposit that set the whole thing off was a real Bitcoin payment worth about 25 cents. The bridge reads deposit instructions from data attached to Bitcoin transactions, and its decoder "identified the sender using the wrong part of that data: a part the spender controls." That was enough to have the attacker treated as an approved depositor and as the bridge administrator at the same time. With that, they put the minimum fee below zero, and a second bug subtracted the negative fee — which added to the deposit instead of reducing it. Twelve deposits went through across BNB Chain, Ethereum and Rootstock in roughly four minutes. That first payment did not have to be forged. It was real and it was confirmed on Bitcoin. A check asking whether the deposit had happened would have answered yes, and it would have been right. The bridge was asking a second question at the same time: who sent it. For that, it read a field — one the sender controlled. Establishing a sender by signature and establishing one by reading the transaction data end in the same place: a name the system is about to act on. They differ in where the name comes from. A signature asks for something nobody can produce without the key the system already ties to that depositor. Reading it out of the deposit data makes the answer depend on which part gets read, and on that part being beyond the sender's reach. Symbiosis puts preliminary losses to liquidity providers and affected users at 9.97 BTC. The bridge is offline, and it has commissioned independent audits. Sources: coindesk.com/tech/2026/09/15… #DeepSafe #Web3Security #CrossChain

In March, Google Quantum AI published resource estimates for breaking the elliptic-curve cryptography that Bitcoin and Ethereum rely on. It did not publish the improved circuits those estimates came from. The abstract explains the choice in a sentence — "In the interest of responsible disclosure, we use a zero-knowledge proof to validate these results without disclosing attack vectors." What it did release was the paper, the zero-knowledge proof, prover and verifier code, and the accompanying artefacts. A paper posted to arXiv on September 9 shows what happened next. Over roughly eight weeks, participants working alongside AI agents optimised one step of the attack — reversible point addition on secp256k1 — against a public leaderboard. The score being minimised was Q×T: peak logical qubit width times average executed Toffoli count. It went from 10.75 billion at the challenge's starting baseline to 1.496 billion, a reduction of 86.1%. The best circuit at the data cutoff uses 1,151 qubits and 1,299,453 average executed Toffoli gates. Worth stating plainly what that is and is not. It is a point-addition benchmark, measured against the challenge's own baseline, under accounting conventions the paper itself flags as different from Google's. It is not a halving of the cost of running Shor's algorithm against secp256k1, and the paper does not claim to have measured that. What it does show is the part we find interesting, and it took two separate pieces of work rather than one. Google's improved circuits stayed unpublished throughout; what it put out was enough to let others verify the resource bounds it claimed for those circuits, and to reuse its code. The challenge organisers then built the things a competition needs and Google had not provided — a target, a locked evaluator that settles whether a candidate qualifies, a leaderboard — with their benchmark harness adapted from that released code. Together they were enough for the work to accumulate without the circuits. That is one case, not a rule. But it is a case where withholding a specific attack and letting other people work on the same problem turned out not to be in conflict. Proof, not promises. In this case the proof is someone else's. Sources: arxiv.org/abs/2609.09582 · arxiv.org/abs/2603.28846 ·github.com/Layr-Labs/ecdsafa… #DeepSafe #ZeroKnowledge #Web3Security

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: eips.ethereum.org/EIPS/eip-8… #DeepSafe #CRVA #Web3Security

New custody schemes are often demonstrated the same way. A key is generated, a transfer is signed, the properties hold. The demonstration is real. It is also evidence about a system that started empty. The harder case is a live system that did not. It is already holding funds under signatures produced by the scheme being replaced. Migrating one can take time. In a staged migration, some balances may already sit under the new arrangement while others remain under the old one. Both control paths may be live. Neither scheme's analysis necessarily covers that state. The old scheme's security argument covers the configuration being taken apart. The new one's covers a configuration that is not yet complete. Unless the transition is specified as a procedure in its own right, it can fall outside both arguments — and what stands between an attacker and the funds still under migration is that procedure: the order of operations, the access controls wrapped around it, and how much of it was rehearsed under production-like conditions. That procedure can be given cryptographic structure — key handover can be defined and verified as a protocol step. Where it is not, it falls to operational work, performed under schedule pressure, on a live system where pausing carries consequences for other people's money. This is not an argument against migrating. Custody schemes have to be replaced, and the reasons are usually good ones. It is an argument about which part of the plan gets the scrutiny. The new scheme may receive pages of analysis. The transition may receive a schedule. CRVA does not remove this problem and we are not going to claim it does. Where authority rests on a standing set — of keys, of signers, of machines — any change to that set has to be carried out somehow, and the question is whether that interval is specified and verified or simply scheduled. CRVA's answer is not to avoid that interval. The Agents holding key shares are reselected at random on a fixed cycle, and passing the shares from the outgoing set to the incoming one is a defined step in the protocol rather than a one-off project. Under threshold MPC a valid signature requires enough participants to contribute, so no single participant can produce one alone. What that buys is a transition exercised constantly instead of rarely. What it costs is that the interval is never far away — which is a reason to scrutinise the procedure, not to assume it away. Each scheme was analysed as a destination. The migration is the part that is neither. #DeepSafe #CRVA #Web3Security

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

On September 2, TAC published its post-mortem on the August 22 incident that drained its staking pool. The section worth reading twice is not the one about the vulnerability. It is the one about what was watching. Two controls were running: an automated check comparing TAC's custody against the mirrored supply on BNB Chain and Ethereum, and alerting on large bridge transfers. Both were doing the jobs they were designed to do. The first had nothing to flag: the attacker locked genuine TAC and issued a correctly backed mirror token, so the conservation property it monitored was never broken. The books stayed balanced. The second monitored large bridge transfers. Only 32 seconds separated the drain from the first bridge transfer. In TAC's own words: "No control that ends in a human decision closes an interval of that length." That is not a point about how fast anyone noticed. It is about everything that would still have to happen after detection. This was a drain, not a mint — no new tokens were created. Mainnet resumed on September 2, and the staking pool has since been restored in full. So the usefulness of a control turns on two properties. Which invariant it watches — because an attack that preserves that invariant stays invisible to it, however correctly the check itself runs. And whether it can act without waiting for someone — because a control that ends in a person inherits that person's response time. CRVA is designed for a different control position. Where an applicable check is already integrated into a request's execution path and its result is enforced, Agents drawn for that request can return a verdict before the request proceeds. That is not a claim that CRVA would have prevented TAC's internal state-transition flaw. The published record does not establish that an applicable CRVA check was integrated into this execution path. The distinction here is about where a control can act, not about which controls are better. Both of TAC's controls worked as designed. Neither was an enforcement gate on the transaction that drained the pool. Sources: tac.build/blog/tac-mainnet-s… #DeepSafe #CRVA #Web3Security

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: cryptotimes.io/2026/09/06/co… #DeepSafe #CRVA #Web3Security

A draft Ethereum standard for AI agents keeps reputation and validation in two separate registries. Both are records. Neither is a guarantee, and the proposal is candid about that. "Trustless Agents" was created in August 2025 and is still a Draft. It defines three registries: identity, reputation, validation. The Reputation Registry takes feedback from client addresses — a score, optional tags, pointers to supporting data. It supports on-chain filtering by reviewer and by tag; the proposal expects more complex aggregation to happen off-chain. Its own Security Considerations say the rest plainly: Sybil attacks are possible, inflating the reputation of fake agents. The registry's contribution is to make signals public and put them in one schema. The Validation Registry records a request for a named validator contract to check a piece of work, followed by that validator's response. The response ranges from 0 to 100 and can represent binary pass/fail or an intermediate outcome. The validator may respond more than once to the same request, enabling updates such as soft and hard finality. It may use stake-secured re-execution, a zkML verifier, a TEE oracle or a trusted judge. The registry is agnostic about which. Both registries standardise the shape of a trust signal and leave its reliability to the party and procedure behind it. For a registry, that is a reasonable boundary. It also means neither record becomes reliable by being on-chain. One line sets up the question the proposal leaves open. A validation request must be submitted by the owner or operator of the agent, and the request names the validator address — but the ERC does not say how that validator should be chosen. Incentives and slashing are likewise left to the surrounding validation protocol. CRVA works on that layer: Ring-VRF draws the verifier set for each request, so the set is not fixed in advance. That reduces one selection risk: a set that persists across requests gives an attacker time to prepare. It does not make the check itself correct. A registry can record who said what. Whether they were right is a different question. Who gets asked is a third one. Source: eips.ethereum.org/EIPS/eip-8… #DeepSafe #CRVA #Web3Security