noah.eth

Some learning lessons / recs from @binance hack to crypto teams mixed with my own personal ramblings. - Work devices are for work, personal devices are for personal. No exceptions. - Never install or perform actions on a destination site from a search result. Google is notorious for shitty ad control policies in cases even displaying the legit domain -> then redirect to a malicious copy - Software MUST come from approved channels, nowhere else. Your engineers will be annoyed but whitelisitng apps, extensions, cli tools / binaries, etc is a MUST in today's environment. - Educate your employees and yourself on DPRK attack vectors!!! Every single employee entering your organization must be aware of the common DPRK attack vectors (meeting phishing, contagious interview, pollinrider tactics, etc.). - Never clone / open a repo locally on your machine. Goes without saying but this a tried and true payload delivery mechanism for DPRK - Use a freaking MDM to manage software it's 2026 (probs jamf or iru). One of the compromised engineer's got one of his Homebrew tools (pyenv) with a version that gave the attacker remote access. Use MDM to manage verified install channels for binaries and anything else. Push config changes (e.g VS Code task abuse), governance for AI tool usage, hunt across your fleet for vulnerable software, auto-updates, allowlists for app installations, execution allowlisting for binaries, etc. - Only dedicated devices + dedicated accounts should have access to critical / existential actions. We've been doing this at Monad for a while and encourage eco teams to do the same. - Make a threat model pls. In the words of @iphelix what are your crown jewels? You must know what are the existential threats to your company and defend them / build the controls so that even if you ARE compromised - it doesn't destroy you. - Use an EDR (Crowdstrike or Huntress if smaller and need something more managed) and build custom IOAs based on threat intel (e.g this binance post-mortem). EDR did NOT detect for Binance - it doens't mean that's the case for you - write some damn custom detection rulesets. - Egress controls on every device. Yes i know people don't like Zscaler but your employees are going to fall for the B-team tactics time and time again. Block newly registered domains by default and setup some automation to keep adding new IOCs from your threat intel. - Speaking of threat intel - do you have any??? If you don't rss feeds are ok - X tho is really the gold mine you should setup custom detection feeds based on your organization's threat model. Otherwise can use cve.[now], cloudlfare zero-wire, and @_SEAL_Org threat intel as a basic starter. A lot of rss feeds are poop so focus on quality. - No long-lived sessions or tokens on laptops. Short-lived, scoped, device-bound creds. Simple enough but hard to apply across the org. - Yubikeys won't save you from malware. This is not the only line of defense but for phishing yes they're great so obv have them. - Vendor risk is literally sky-high rn. You cannot allow employees or yourself to blindly install / run / grant perms to 3rd party platforms. Distrust by default and Oauth grants (hey google workspace admins i'm talking to you) should be set to read-only for ALL apps by default. If you rmr this is how Vercel got pwned. - Signing policy should be enforced no matter who's calling. Destination allowlists, per-tx and velocity limits, hard block on EIP-7702 from hot wallets. - Detection and alerting do you have any??? The attackers were incubating since JUNE - months of time to prep for lateral movement until they could escalate. How do you know you're compromised or behavior is suspicious? - lastly just going to leave this here: nitter.cf/alpeh_v/status/2116172…

+1. Urging people to upgrade chrome and Linux and regurgitating how agents swarms can reverse patches and exploit does little to help people beyond the short term. Spend time limiting what a single compromised device/human/agent can do!

Today we are releasing Quantum Cadence, a post-quantum version of Cadence, our consensus protocol with multiple concurrent proposers. Quantum Cadence uses no quorum certificates, and its safety and liveness do not depend on signatures. Most modern consensus protocols, Cadence included, rely heavily on signatures and quorum certificates, which a large-scale quantum computer could forge. Simply replacing today's signatures with post-quantum ones would make certificates too large for every validator to send around in a high-performance blockchain. Quantum Cadence instead draws on Forget-IT, a recent signature-free consensus protocol co-developed by researchers at Category Labs. Quantum Cadence still keeps the overall architecture and core guarantees of Cadence, so our Cadence prototype was easy to carry over: an AI was able to adapt it to Quantum Cadence in a few hours, and an early prototype now runs on an internal test network. We designed Quantum Cadence to be practical for a high-performance blockchain. In our simulations, its latency is similar to Cadence's, and it scales better with the number of proposers. Interactive explainer: category.xyz/quantum-cadence. Full paper: arxiv.org/abs/2610.32803. Joint work by @MohammadMJalal1, @TobiasKlenze, and @komasito55

Excited to propose five new JSON-RPC methods to fetch EVM blockchain history: blocks, transactions, logs, traces, and native transfers. These methods address longstanding Ethereum data problems at the protocol layer, through an open standard that any EVM chain can adopt.