Weekend puzzle. A key is split into 5 shares. Any 3 of them can sign. One share leaks in January. Another in June. A third in November. Someone ends up holding all three. In November, can they sign? A. No. The leaks were months apart. B. Yes, unless the shares were refreshed in between. C. No. Each leak was patched when it was found.

How can AI agents trade and execute safely in financial markets? Our CEO Raul Heraud explored this question with fellow panelists at @wallet’s Beyond X in Singapore. Proud to support an evening bringing this conversation to the stage.

Weekend puzzle. A contract runs a lottery. To pick the winner, it uses the hash of a block produced after ticket sales close. Who can influence the result? A. Nobody. It's a hash. B. Whoever produces that block. C. Only the contract's deployer.

🤝 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

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.

GM. Two words that get used as if they were one, and shouldn't be. Ours: encrypted and private. Encrypting something keeps its contents from being read by anyone without the key. Whether anyone can see that it happened at all is a separate question — and "private" gets used for both. What's your pair?

Weekend puzzle. A contract checks a condition, then acts on it. Both in the same transaction, atomically. How old can the thing it checked be? A. Zero. It's atomic. B. One block at most. C. Depends on where the fact came from.

To strengthen Sybil resistance and verify genuine active users, DeepSafe is opening a seven-day node verification window. 📅 Verification period: September 17 – 23 🤖 Official Telegram bot: @Deepsafe_official_bot To activate your eligibility, restake your test tokens to a node you are already staked with. If the transaction returns an error, your current node is no longer active. Unstake from it, then select a new active node and restake your full available balance in a single transaction. Please note: Each node supports up to 4,000 voting participants. Full nodes cannot accept additional votes. Unstaking requires a one-day on-chain cooldown. If you need to switch nodes, start early and do not wait until the verification window is about to close. Complete verification before the deadline to remain eligible for this round.

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

GM. Every security claim should come with its boundary: "This does not protect you from ______." What would you put in the blank?