A fund on a public chain shows its shareholder book to anyone who finds the contract. On Ethereum, FundBridge's ULTRA has five holders, and its contract minted 25 million units on 4 Sep 2026 and redeemed about the same five days later. Last week, @eth_systems published a proof of concept for confidential money market fund shares on Ethereum using shielded pool. The pool holds the fund's permissioned token, positions are encrypted notes, and a ZK proof checks each transfer and carries an encrypted copy of every new note for the registrar. The registrar keeps the full register while the public sees daily totals. Here's how Asian funds keep their register today - Hong Kong: CSOP and Bosera keep it offchain with the registrar. The SFC says providers "should not use public-permissionless blockchain networks without additional and proper controls". Singapore: sgBENJI's token is the register. Japan: The Trust Act puts each holder's name and address in the register, and MUFG keeps its test fund's register onchain on Progmat. South Korea: From 4 Feb 2027, registers can sit on ledgers the KSD screens, starting with private MMFs for institutions. Japan's and Korea's rules leave room for Ethereum if a design hides holdings and keeps the registrar's record complete. For small funds, the deployment needs padding, netting or a pool shared across funds to hide anyone. This week, the Under the Hood series lays out various register models across four markets. themonsoonledger.com/under-t…

⛳️ absolute hole-in-one by @oskarth lots of nuances to formal verification! while it's easy to get a model to spit out thousands of lines of code, it all needs careful review. one would notice that getting proofs is the easy part, but making sure that the generated code abides by what you think the design should be isn't. you still need someone who understands the business use-case deeply to be able to formally verify systems at this scale.

major props to @david__nunez, we've had this idea for several months and did a lot of research into existing deployments, their trust models to be able to deliver this piece of work. Read the writeup!

Kaushal Vyas (@liftlines ), our Managing Director, joins the Building Ethereum panel at @LFDecentralized's Privacy for Financial Services Workshop in New York on Friday 23 October (12:00 to 12:45 pm ET), moderated by Johnna Powell of DTCC. He will bring our open map of institutional privacy use cases, each with the requirements institutions named, the approaches already ruled out, and starter kits for several of them. Looking forward to the conversation with fellow panelists, and to building on it together after 🤝🏻

We are going live next week!

We published a writeup on Ethereum's upgrades, past and coming, read through what banks, custodians and other institutions need. Apart from the move to proof of stake, most institutions we talk to haven't followed the forks closely. Since 2021 the gas limit has doubled, and accounts and rollups can now do things they couldn't before. The next two forks have different focuses. Glamsterdam, due in December, is mostly about capacity: it prepares clients for a 200M gas limit and makes writing new storage more expensive. Hegotá, planned for 2027, is about control. Frame transactions give accounts more say over how they sign and pay fees, and FOCIL makes it harder for block producers to leave valid transactions out. We looked at each change through five needs: key control, capacity at a cost firms can plan for, speed to finality, neutral inclusion and confidentiality. Each section opens with a summary for six kinds of firms, from bank treasuries to staking providers, and a replay of mainnet transactions under the new gas rules shows where costs move. One of those needs the forks leave open. More below.

Intercompany cash on a public chain publishes the group’s structure, and that includes who funds whom, how much, how often. Competitors can read it even before your annual report. Our private payments starter kit tests the reverse: hidden on chain, visible to treasury, open to a tax authority on request. There are still two gaps remain, see threads for more 👇🏻

Most banks started on permissioned networks, and that did real work for hedging the risk and building capability. @motypes 's EthConnect 2026 keynote was about what comes after, because the architecture chosen at step one sets the cost of step three, and the wall on the way to a public network is almost always confidentiality. Confidential is not anonymous. It is control over who sees what, when and how: the counterparty sees the trade, everyone else sees only a proof that it is valid, the operator sees nothing, and the regulator holds a disclosure key. The same question ran through both panels. Good conversations with @Sharplink , @LidoFinance , @ETHGasOfficial , @Offchain , @zama , @axelar and @FourPillarsFP , and our thanks to @0xundefined_ for hosting. Coverage in threads 👇🏻

New chapter: I've joined EthSystems to work on privacy infrastructure for institutions building on Ethereum. It's right in the intersection I've spent most of my career in, so it feels like the right place to be. Looking forward to what we build 🏗️🚀

David's been crushing it since he's joined. Couldn't be happier working with him! Welcome @david__nunez 🎈

New post on Eth Research! PQ anonymity for Stealth Address Protocol By: - namnc 🔗 ethresear.ch/t/26094 Highlights: - The core quantum threat is blockchain permanence: a future CRQC observing on-chain stealth registries/announcements can retroactively recover ECDH secrets (and even spending keys if ECDSA is used), becoming both the scanner and the receiver; therefore SAP needs post-quantum upgrades for both discovery/unlinkability (ECDH side) and spending authorization (signature side). - Replacing ECDH with standardized ML-KEM (FIPS 203) can provide post-quantum recipient anonymity/unlinkability because ML-KEM ciphertexts are designed to be indistinguishable across recipients (ANO-CCA / IK-CCA), preventing attackers from linking an announcement ciphertext back to a specific recipient’s registered key. - SchemeId=2 (direct ML-KEM SAP) replaces the viewing keypair with an ML-KEM (ek, dk): sender encapsulates to ek to get shared secret r and ciphertext c; stealth address is derived as P = K + H(r)G; receiver (or delegated scanner with dk) decapsulates c to find matching payments, but only the receiver with spending secret k can spend (k + H(r)). - A naive 1-byte “view tag” derived directly from h=H(r) can leak a recipient-filter to a quantum attacker once the stealth address P becomes known (e.g., from an ECDSA spend): the attacker can test candidates in the registry with ~1/256 false-positive rate; mitigations require domain-separated derivations so the tag is independently derived from r (e.g., h=H(DS1||r), tag=H(DS2||r)[0]). - Practical migration favors SchemeId=3 (hybrid combiner): combine classical ECDH secret r_ec and ML-KEM secret r_pq with domain separation so security holds if either remains secure during transition; however ML-KEM introduces large on-chain data (e.g., ~1088-byte ciphertext for ML-KEM-768 and ~1184-byte ek), motivating later pairwise variants (scheme 4/5) that amortize costs after an initial KEM exchange. ELI5: Stealth addresses let someone publish one “main” address, but every payment they receive goes to a fresh, one-time address so outsiders can’t easily link the payments together. Today’s versions use normal elliptic-curve cryptography (ECDH/ECDSA), which a powerful future quantum computer could break by “solving the secret keys” from public data stored on-chain. This post explains how to swap the secret-sharing part (ECDH) with a post-quantum method called ML-KEM so that even if a quantum attacker watches the blockchain, they can’t figure out which registered receiver a payment was meant for, and can’t helpfully scan/link payments. It also discusses practical migration options (hybrid mode), size/cost tradeoffs, and a subtle privacy leak from a naive ‘view tag’ optimization.

legacy systems need some love too 🫶

It turns out all you need to deploy an encrypted mempool (via Batched Threshold Encryption) is an off-the shelf DKG. No CRS required. Ciphertext overhead is 2G1 + G2 + 2F and partial decryptions are a single G1 element. Decryption runs in O(B log^2 B) time.

working with @lfdecentralized is going to be really exciting! more soon

very helpful @motypes @eth_systems specific systems 👏 auditors can test👏👏 applications for institutions👏👏👏 $ETH

would definitely like to thank @RAILGUN_Project @bermudabayzk and @0xprivacypools for their feedback on the spec :)

little homelab disaster got me to look at the thermal situation a bit better. i can't believe the airflow was this bad before (green is the node that became a toaster)

we're shipping faster and more focused with @liftlines on the team, LFG 🚀

visited the hometown recently. rural asf southern appalachia. smth that stood out? normies, nerds, & oldies struggling w emails alike are talking about flock, palantir, & even fusion centers rn ppl know smth's wrong, but they're bombarded by the nothing-to-hides on one side & the nothing-is-safes on the other. the best thing we can do for our community as tech ppl rn is explain these things in an approachable way. keep your threat model reasonable: mary sue is not a drug kingpin, samuel does not need tor, xmr, or graphene maddie has shit to do thats not hardening malloc explain how data flows through a surveillance system: how sensor fusion joins seemingly disjoint data, how cops dont need warrants for ring or flock, how warrants & subpoenas affect cloud providers if youre talking w activists & organizers, go a lil deeper: passwords cannot be compelled, biometrics can, distinguish "obtainable" from "useable in court", use signal, avoid google drive, blur faces, ffs PLEASE tell them they dont need a faraday bag we are in a very read-the-room era of tech & ai, principled ideological rants are not likely to land, focus on pragmatic W's for the community first. we're practicing talking to ppl that experience a v diff world from ours & building community in the process. good luck out there 💜

Introducing Bread, a wallet by Miden