Early Warning

Before we dive in, please note that this is not an of­fi­cial Google an­nounce­ment. Instead, this is based on a re­cent, on­go­ing fea­ture re­quest on Google IssueTracker, in which a com­ment by one of the core ADB main­tain­ers (Google em­ployee) talked about re­strict­ing On-Device ADB con­nec­tions to pro­tect from “bad ac­tors”.

Before you stop what you are do­ing to head over to that IssueTracker thread, please read this care­fully:

If you plan to visit the is­sue tracker just to post low-qual­ity com­ments (such as “Hey, don’t do this, I need Shizuku!”), com­plaints about mo­nop­oly, or in­sults, I highly rec­om­mend that you re­frain from do­ing so. Spamming the thread will only cause Google de­vel­op­ers to lock the is­sue, ig­nore valu­able com­mu­nity feed­back, or stop shar­ing pub­lic up­dates about this change en­tirely.

I think a change like this could ben­e­fit Google as it goes well along their new Sideloading changes, but I do not ac­tively be­lieve this is what is go­ing on here. There is a true, valid rea­son be­hind this, and I think two dif­fer­ent ap­proach can be taken. We will talk about it in this blog post.

How You Can Help:

If you have a unique use case: If you are di­rectly af­fected and can write a de­tailed, con­struc­tive mes­sage ex­plain­ing your work­flow, pro­vid­ing links, or of­fer­ing tech­ni­cal so­lu­tions/​com­pro­mises, please, by all means, share your feed­back in Google is­sue.

If your use case has al­ready been men­tioned: You do not need to re­peat it. Instead, sim­ply click the +1 but­ton in the top right cor­ner of the Google IssueTracker to let Google know you are af­fected, and tog­gle no­ti­fi­ca­tions to stay up­dated on the dis­cus­sion.

I am hes­i­tant to make this blog post, as I fear it may over­load the few de­vel­op­ers that work on ADB. I am un­sure if I should wait more and see what hap­pens or hold it longer and see what ap­proach they take. Waiting too long could also be bad… As of writ­ing this, I am un­sure when/​if this post will re­lease. I saw some re­cent up­dates on as­sign­ments which were given to the main guy who pre­vi­ously worked on ADB, so we will see what hap­pens.

Introduction

Hi! I’m Kitsumed, de­vel­oper of ShizuCallRecorder, a Shizuku based ap­pli­ca­tion. As you may have guessed by now, I would be af­fected by this change. Obviously, I would re­ally like it if they do not pro­ceed with it in a way that pre­vent loop­back con­nec­tions.

To talk briefly about my­self, I made ShizuCallRecorder to help with some of my own dis­abil­i­ties. I can get by with­out it, but it’s much eas­ier with it.

You could say I have a very unique use case, and I keep dis­cov­er­ing other un­usual ones, like this per­son on Reddit, who used my ap­pli­ca­tion to pre­serve the voice­mail of a de­ceased loved one.

Call record­ing on Android is a com­pli­cated topic. There are count­less user re­quests, an of­fi­cial at­tempt to add the fea­ture in Android 11 that was later can­celed, and many closed-source, pri­vacy-in­va­sive ap­pli­ca­tions that use work-arounds.

I used to hear that many users with dis­abil­i­ties had to trade their pri­vacy for an eas­ier daily life. I guess that’s what peo­ple mean when they talk about those trade-offs.

Don’t even get me started on OEMs that force an au­dio warn­ing such as “This call is be­ing recorded,” when it’s in places where it’s not legally re­quired. People of­ten don’t re­act well to that, even if you ex­plain why you’re record­ing the call, it gives a bad im­pres­sion. To be hon­est, I prob­a­bly would­n’t re­act well to it ei­ther.

I’m sure most of you have a more “power-user” use of Shizuku or even use loop­back ADB for de­vel­oper tasks. I do those too, but I wanted to point out one of my unique use case.

Alright, back on the main topic. Before I ex­plain what the pro­posed change is, I’m go­ing to ex­plain what is ADB for less tech­ni­cal users.

What’s ADB?

ADB, also called Android Debug Bridge, is pro­to­col cre­ated by Google to let de­vel­op­ers do de­vel­oper things on Android de­vices…

Basically, it grant us a high level of priv­i­leges, give us ac­cess to a lot of sen­si­ble com­mands to tests how the phone and ap­pli­ca­tion be­have. Useful stuff for any de­vel­op­ers or power-users.

ADB was orig­i­nally de­signed to work over a USB con­nec­tion, but later ex­panded how it could works:

USB: The orig­i­nal way. ADB com­mu­ni­cates di­rectly over a USB ca­ble.

TCP/IP: Introduced as a way to run ADB over a net­work us­ing an IP ad­dress and port (typically port 5555). The con­nec­tion car­ries ADB traf­fic in plain text and pro­vides a YES/NO prompt as au­then­ti­ca­tion. Can only be en­abled once you al­ready have an ac­tive ADB con­nec­tion.

Wireless Debugging (Wifi 1.0/2.0): Introduced in Android 11, it aims to im­prove the legacy TCP/IP work­flow. It re­quires pair­ing the com­puter with the de­vice us­ing a pair­ing code or QR code, then es­tab­lishes an au­then­ti­cated and en­crypted con­nec­tion for sub­se­quent ADB ses­sions. It does not re­quire an ac­tive ADB con­nec­tion to be en­abled.

What’s a On-Device ADB con­nec­tion?

ADB was orig­i­nally in­tended to be used with two de­vices (simplified ex­pla­na­tion): the Android de­vice be­ing de­bugged run the ADB Daemon (ADBD) and a sep­a­rate de­vel­oper ma­chine run the ADB client. In prac­tice, how­ever, this setup is not al­ways con­ve­nient. Some de­vel­op­ers work di­rectly from their Android de­vice and do not have ac­cess to a sec­ond ma­chine.

This led to us­age of On-Device ADB (this is not a of­fi­cial term). By us­ing a ter­mi­nal em­u­la­tor such as Termux, de­vel­op­ers can run an ADB client di­rectly on their phone and es­tab­lish a con­nec­tion to the lo­cal dae­mon (ADBD) server us­ing ei­ther ADB TCP/IP or Wireless Debugging. Since both the client and server are run­ning on the same de­vice, the con­nec­tion is made through the loop­back ad­dress (127.0.0.1). That’s what I call On-Device ADB.

While this is a niche use case com­pared to how ADB in­tended to be used, it has led to the cre­ation of pro­jects such as libadb-an­droid by MuntashirAkon and Shizuku by RikkaApps. These pro­jects, along with many oth­ers, have cre­ated a large open-source com­mu­nity that made a wide range of tools for de­vel­op­ers and power-users.

The pro­posed change

A new fea­ture was made on Google IssuerTracker to al­low de­vel­op­ers to choose what in­ter­face ADBD (ADB server dae­mon) would lis­ten to.

This fea­ture was pro­posed fol­low­ing a ma­jor se­cu­rity is­sue iden­ti­fied as CVE-2026 – 0073, which al­lowed the Wireless ADB au­then­ti­ca­tion process to be fully by­passed. What is pro­posed in this is­sue is ac­tu­ally a nice idea.

Right now, ADBD makes it­self avail­able on every net­work your phone is con­nected to. This fea­ture re­quest asks to let de­vel­op­ers choose which in­ter­face is cho­sen, re­duc­ing the ex­po­sure.

The prob­lem

The prob­lem lies in the re­sponse from one of ADB core main­tain­ers:

sa…@google.com:

Connection to lo­cal­host has also been the source of ex­ploit where app are us­ing that socket to adbd to es­ca­late their priv­i­leges.What about we re­strict to al­ways only bind­ing to wifi in­ter­face wlan0 ?

Connection to lo­cal­host has also been the source of ex­ploit where app are us­ing that socket to adbd to es­ca­late their priv­i­leges.

What about we re­strict to al­ways only bind­ing to wifi in­ter­face wlan0 ?

Here, we can see that the em­ployee talk about only al­low­ing wlan0, the in­ter­face of the Wifi con­nec­tion. Doing so would break many things, On-Device ADB, ADB via VPN, ADB via Ethernet, and many other unique de­vel­op­ers se­tups.

Another is­sue I see here is the stance they seems to cur­rently have on “On-Device ADB”. Their com­ment sug­gests that On-Device ADB is viewed pri­mar­ily as an ex­ploit bad ac­tors can use to el­e­vate priv­i­leges, yet there a lot of le­git­i­mate us­ages of on-de­vice ADB. Developers them­self uses it when they can’t ac­cess a com­puter.

While it can in­deed be used to el­e­vate priv­i­leges, a “malicious” ap­pli­ca­tion can­not do so alone. It re­quires mul­ti­ples ac­tions that MUST be per­fomed by a hu­man.

Why On-Device ADB Is Not Really Used by Bad Actors

A ma­li­cious ap­pli­ca­tion could use an on-de­vice ADB con­nec­tion to per­form priv­i­lege es­ca­la­tion. However, it can­not es­tab­lish one by it­self.

To il­lus­trate this, I’ve laid out the gen­eral lim­i­ta­tions a bad ac­tor would face in a few sce­nar­ios, sim­i­lar to my com­ment on IssueTracker.

Scenario 1: General Android Users

You in­stall a ma­li­cious ap­pli­ca­tion.ADB is dis­abled. ADBD is not run­ning, and the ap­pli­ca­tion does not have the WRITE_SECURE_SETTINGS per­mis­sion, as it must be man­u­ally granted via ADB. No ex­ploita­tion at­tempts are pos­si­ble.

ADB is dis­abled. ADBD is not run­ning, and the ap­pli­ca­tion does not have the WRITE_SECURE_SETTINGS per­mis­sion, as it must be man­u­ally granted via ADB. No ex­ploita­tion at­tempts are pos­si­ble.

Scenario 2: A Developer on Android 11+ Using Wireless ADB

You in­stall a ma­li­cious ap­pli­ca­tion.

You en­able USB de­bug­ging, start­ing ADBD.

You en­able Wireless ADB. ADBD is now run­ning on your phone and lis­ten­ing on all net­work in­ter­faces.

The ap­pli­ca­tion would need to per­form the one-time pair­ing process. This re­quires the user to man­u­ally re­trieve the one-time code from Settings and pro­vide it. No ex­ploita­tion at­tempts are pos­si­ble.

Scenario 3: A Developer Using ADB over TCP/IP

You in­stall a ma­li­cious ap­pli­ca­tion.

You en­able USB de­bug­ging, start­ing ADBD.

You con­nect via USB ADB to en­able TCP/IP, then dis­con­nect the USB ca­ble.

ADBD con­tin­ues run­ning and lis­tens on all net­work in­ter­faces.

The ap­pli­ca­tion ini­ti­ates a con­nec­tion, caus­ing an au­tho­riza­tion prompt to ap­pear on the screen. If the user se­lects No, the con­nec­tion is re­jected. No silent ex­ploita­tion at­tempts are pos­si­ble.

Conclusion

In a nor­mal sce­nario, a bad ac­tor can­not gain an ADB con­nec­tion. It is only pos­si­ble while the de­vel­oper is ac­tively us­ing ADB on the de­vice, be­cause a bad ac­tor can­not start ADBD by them­selves.

However, if we re­turn to a sce­nario such as CVE-2026 – 0073, ex­ploita­tion would be­come pos­si­ble in Scenarios 2 and 3, but only af­ter the user has man­u­ally en­abled USB de­bug­ging. As for sce­nario 3, it would also re­quire the de­vel­oper to MANUALLY en­able TCP/IP. I can un­der­stand the mo­ti­va­tion for pre­vent­ing loop­back con­nec­tions by de­fault, but not to fully pre­vents it.

There is a dif­fer­ence be­tween pre­vent­ing it by de­fault and per­ma­nently pre­vent­ing it. I think this should be some­thing users can dis­able through a per­sis­tent set­ting. By this, I mean a tog­gle that sur­vives a re­boot (else it would make tools like Shizuku im­prac­ti­cals) and, ide­ally, can­not be read by third-party ap­pli­ca­tions. Otherwise, de­vel­op­ers would have to re­peat­edly dis­able it when­ever bank­ing apps or games de­tect that on-de­vice ADB is avail­abl. That said, this part could be worked around once a ap­pli­ca­tion is man­u­ally granted WRITE_SECURE_SETTINGS.

I think that jus­ti­fy­ing block­ing it be­cause a hu­man could per­form ac­tions to al­low it would be far-fetched. A hu­man could also des­ig­nate a ma­li­cious ap­pli­ca­tion as a de­vice ad­min­is­tra­tor or grant it Accessibility per­mis­sions, and yet we would not get rid of those fea­tures.

I be­lieve it should be an as­sumed risk that dis­abling such a se­cu­rity fea­ture en­ables on-de­vice de­bug­ging while also ex­pos­ing the de­vice to the rare pos­si­bil­ity of a fu­ture vul­ner­a­bil­ity. To me, the fea­ture/​risk ra­tio make sense here, as there is a real, le­git­i­mate us­age.

Although it may have not been orig­i­nally in­tended, On-Device ADB has en­abled a niche ecosys­tem of de­vel­oper and power-user tools, in­clud­ing pro­jects such as App Manager, libadb-an­droid, Canta, aShell, ShizuWall, ShizuCallRecorder and Shizuku.

To con­clude, I would like to men­tion my con­clu­sion in What Is Shizuku? How Does It Work? Security Implications?, where I said as a joke:

Here’s my clos­ing thought: I can’t wait to see how they’ll jus­tify dis­abling loop­back ADB over TCP/IP con­nec­tions on non-em­u­la­tor de­vices and start re­quir­ing a Google ac­count…

Here’s my clos­ing thought: I can’t wait to see how they’ll jus­tify dis­abling loop­back ADB over TCP/IP con­nec­tions on non-em­u­la­tor de­vices and start re­quir­ing a Google ac­count…

Well I guess they may in­deed dis­able loop­back ADB. Huh… I was al­most 100% right on that one I guess. If you are a tech­ni­cal user, I in­vite you to give your feed­back in­side the is­sue here. Please don’t for­get the early warn­ing.

watch now

Nvidia, Microsoft, Meta, Palantir and more than 20 other com­pa­nies re­leased a let­ter Friday urg­ing pol­i­cy­mak­ers to avoid “premature re­stric­tions” on open-weight ar­ti­fi­cial in­tel­li­gence mod­els that would “stifle com­pe­ti­tion or drive in­no­va­tion over­seas.”

Open-weight AI mod­els are avail­able for users to down­load, mod­ify and run on their own in­fra­struc­ture, and they have been the sub­ject of fierce de­bate within the tech sec­tor in re­cent weeks.

Chinese open-weight mod­els are gain­ing steam against lead­ing of­fer­ings from American com­pa­nies like OpenAI and Anthropic, which pri­mar­ily de­velop pro­pri­etary, closed mod­els. Officials and ex­ec­u­tives have been weigh­ing whether or not to re­strict ac­cess to Chinese mod­els in the U.S.

Moonshot AI, a Chinese startup, am­pli­fied con­cerns ear­lier this month af­ter re­leas­ing a model called Kimi K3 that out­per­forms cut­ting-edge American of­fer­ings across some in­dus­try bench­marks. U.S. Treasury Secretary Scott Bessent told CNBC on Tuesday that the Trump ad­min­is­tra­tion would look into whether Chinese com­pa­nies were steal­ing American in­tel­lec­tual prop­erty, and stated that the gov­ern­ment has “the abil­ity to sanc­tion them be­cause of this theft.”

But in the let­ter on Friday, the group of U.S. tech com­pa­nies cau­tioned against any rash ac­tions. They wrote that open-weight mod­els strengthen com­pe­ti­tion and en­sure that the ben­e­fits of the tech­nol­ogy are “broadly shared rather than con­cen­trated in a few hands.”

“Relying solely on closed mod­els is not in­her­ently safe: they can be breached, mis­used, or fail in ways that out­siders can­not de­tect,” the let­ter said. “And con­cen­trat­ing ad­vanced AI ca­pa­bil­i­ties be­hind a small num­ber of closed mod­els com­pounds that risk.”

Nvidia CEO Jensen Huang and Microsoft CEO Satya Nadella both shared the let­ter on their per­sonal so­cial me­dia ac­counts.

Elon Musk, who runs an AI busi­ness un­der his rocket com­pany SpaceX, also ap­pli­fied the let­ter on so­cial me­dia, writ­ing that it has his “full sup­port” in a post on X. SpaceX did not of­fi­cially sign the let­ter.

Read more CNBC tech news

Moonshot AI ac­cessed Nvidia’s chips de­spite Chinese ex­port ban, White House of­fi­cial says

Alphabet and Tesla test Wall Street’s pa­tience as AI spend­ing over­shad­ows growth

Alphabet earn­ings take­aways: Q2 rev­enue beats, GOOGL stock sinks on 2026 capex hike

Tesla misses on earn­ings, as free cash flow turns neg­a­tive and mar­gins slide

OpenAI and Anthropic did not sign the let­ter. Both com­pa­nies, which are each val­ued at nearly $1 tril­lion, are gear­ing up for po­ten­tially mas­sive ini­tial pub­lic of­fer­ings that could land as soon as this year. Anthropic con­fi­den­tially filed its prospec­tus with the Securities and Exchange Commission in June, and OpenAI fol­lowed suit days later.

Greg Brockman, OpenAI’s pres­i­dent, said Thursday that the com­pany be­lieves in broad ac­cess, and that he has not been in­volved in any con­ver­sa­tions with the Trump ad­min­is­tra­tion about po­ten­tially ban­ning Chinese open-weight mod­els in the U.S.

“I think that, that fun­da­men­tally, AI and AI us­age is some­thing that is ac­tu­ally very im­por­tant to de­moc­ra­tize,” Brockman told re­porters dur­ing a brief­ing in New York City. “And so, for me, at a sort of deep level, I think that hav­ing more mod­els, more us­age, that is a good thing.”

OpenAI CEO Sam Altman ad­dressed the let­ter in a post on X on Friday, writ­ing that he wants the U.S. to win with both open-weight and pro­pri­etary mod­els, and that he is “glad to see this.”

Earlier this month, the AI com­pany Hugging Face used an open-weight model from the Chinese com­pany Z.ai to con­tain a cy­ber­at­tack that rogue OpenAI mod­els car­ried out. OpenAI dis­closed the at­tack on Tuesday and char­ac­ter­ized it as an “unprecedented cy­ber in­ci­dent.”

CEO of OpenAI Sam Altman speaks with re­porters, fol­low­ing meet­ings on Capitol Hill, in Washington, D.C., U.S., June 3, 2026.

Kylie Cooper | Reuters

Yacine Jernite, head of ma­chine learn­ing at Hugging Face, told CNBC that the com­pany ini­tially tried to use Anthropic’s Fable 5 to an­a­lyze the at­tack, but that it did­n’t work be­cause the mod­el’s guardrails could­n’t de­ter­mine that Hugging Face was try­ing to de­fend it­self.

Jernite said Hugging Face turned to Z.ai’s model GLM 5.2, and was able to con­tain the at­tack “very quickly us­ing this model.”

White House ad­vi­sor Michael Kratsios on Wednesday said that China’s Moonshot AI de­vel­oped its Kimi K3 model by dis­till­ing Anthropic’s tech­nol­ogy. Distillation is a term for an AI train­ing method where a smaller, less ca­pa­ble model is built us­ing out­puts from an ex­ist­ing, stronger model.

Kratsios wrote in a post on X that le­git­i­mate AI dis­til­la­tion plays a vi­tal role in the open in­no­va­tion ecosys­tem, but warned that “large-scale, covert in­dus­trial dis­til­la­tion aimed at steal­ing pro­pri­etary U.S. tech­nol­ogy” is “unacceptable.”

In the let­ter on Friday, the U.S. tech com­pa­nies said that con­cerns about un­law­ful dis­til­la­tion should be ad­dressed through “targeted le­gal and com­mer­cial frame­works” in­stead of with “sweeping re­stric­tions on tech­niques that play an im­por­tant role in AI in­no­va­tion.”

“Our AI lead­er­ship will be judged not by one fron­tier AI model, but by whether the United States builds a strong, open ecosys­tem that dif­fuses into every sec­tor,” the let­ter said. “This is es­sen­tial for cre­at­ing op­por­tu­ni­ties for in­no­va­tion and pros­per­ity across the coun­try.”

WATCH: AI is forc­ing the cy­ber in­dus­try to re­vi­su­al­ize how it op­er­ates, says TrustedSec’s David Kennedy

watch now

Congratulations to Professor Hannah Fry, who has been awarded the Leelavati Prize at the International Congress of Mathematicians for out­stand­ing con­tri­bu­tions to in­creas­ing the pub­lic aware­ness of math­e­mat­ics.

Hannah Fry is Professor of the Public Understanding of Mathematics in the Department of Applied Mathematics and Theoretical Physics (DAMTP). She joined the University of Cambridge in January 2025, be­com­ing the first per­son ever to hold the role.

As a broad­caster, au­thor, pod­caster and so­cial me­dia star she is one of the UK and world’s most recog­nis­able — and favourite — com­mu­ni­ca­tors of math­e­mat­ics and sci­ence. The ci­ta­tion for the Leelavati Prize out­lines her ex­tra­or­di­nary im­pact:

“Hannah Fry is one of the fore­most global am­bas­sadors for math­e­mat­i­cal think­ing,” the prize ci­ta­tion says. “She has be­come a voice for math­e­mat­ics that res­onates far be­yond the pub­lic au­di­ence nor­mally in­ter­ested in sci­ence com­mu­ni­ca­tion.

“Through a wide range of me­dia — in­clud­ing books, videos, and tele­vi­sion pro­grams — she has used out­stand­ing cre­ativ­ity and orig­i­nal­ity to trans­late math­e­mat­ics into a lan­guage of won­der and rel­e­vance for the pub­lic with­out di­min­ish­ing its scope and im­por­tance.”

“When you en­joy [maths] your­self, I think you have first hand ex­pe­ri­ence of just the ab­solute joy of it,” says Hannah Fry about her pas­sion for com­mu­ni­cat­ing math­e­mat­ics. “I feel as though there are these won­der­ful se­crets that are com­pletely in­vis­i­ble to al­most every­body in the world who are not math­e­mati­cians, and it does­n’t make sense to me we would keep them to our­selves — I feel as though I have this re­ally good bit of gos­sip that I just want to share.”

A lan­guage of won­der

The Leelavati Prize, recog­nis­ing out­stand­ing con­tri­bu­tions to in­creas­ing the pub­lic aware­ness of math­e­mat­ics, is awarded every 4 years by the International Mathematical Union (IMU), and is an­nounced at the International Congress of Mathematicians (ICM). Bringing to­gether thou­sands of math­e­mati­cians from around the world, the ICM cel­e­brates the di­ver­sity and scope of mod­ern math­e­mat­ics. It also at­tracts sig­nif­i­cant at­ten­tion as the set­ting for the an­nounce­ment of some of the sub­jec­t’s most cel­e­brated awards, in­clud­ing the fa­mous Fields Medals.

The Leelavati Prize is the lat­est of many ho­n­ours and awards — across both acad­e­mia and the main­stream me­dia — recog­nis­ing Hannah Fry’s ex­cep­tional work in pub­lic com­mu­ni­ca­tion and en­gage­ment. As well as aca­d­e­mic recog­ni­tion in­clud­ing the Christopher Zeeman Medal in 2018 and the Royal Society’s David Attenborough Award in 2024, her ma­jor me­dia awards in­clude win­ning an Emmy in 2025 for an episode ex­plor­ing quan­tum com­put­ing in the TV se­ries The Future with Hannah Fry, and a Webby Award in 2026 for the pod­cast The Rest is Science, co-pre­sented with Michael Stevens. With over 2 mil­lion fol­low­ers on Instagram, she has also been named by Time as one of the 100 most in­flu­en­tial dig­i­tal cre­ators of 2026.

Fry shares the in­spi­ra­tion with the next gen­er­a­tion of math­e­mati­cians too. In 2019 her tele­vised Ri Christmas Lectures were filmed in front of au­di­ences of hun­dreds of school chil­dren. Even closer to home, ear­lier this term she gave the an­nual Rouse Ball lec­ture to a packed au­di­ence of Cambridge stu­dents, fol­lowed by math­e­mat­ics com­mu­ni­ca­tion work­shops for cur­rent un­der­grad­u­ates.

“Mathematics qui­etly un­der­pins so many as­pects of mod­ern life and the im­por­tance of com­mu­ni­cat­ing math­e­mat­i­cal ideas to the pub­lic has never been greater. Few peo­ple have con­tributed more to this goal than Hannah Fry,” says Professor Nick Dorey, Head of the Department of Applied Mathematics and Theoretical Physics.

Mathematics is “a com­pletely orig­i­nal way to see the world,” says Hannah Fry. “And I think that in the same way as with any­thing in life where you re­ally en­joy it, I just want to talk to peo­ple about it.”

As Fry says, the limit to some­one’s un­der­stand­ing is never their abil­ity to un­der­stand. The limit is al­ways in their mo­ti­va­tion to care. And she sees her role as be­ing to pro­vide that mo­ti­va­tion.

“I think what you need to do,” she says about the key to con­nect­ing with a wide au­di­ence, “is to cre­ate a hole in peo­ple’s imag­i­na­tion. If I can cre­ate just a mo­ment where you want to know the next bit — you know ex­actly the size and shape it needs to be to ful­fil your crav­ing for that ex­act piece of in­for­ma­tion — then every­body’s in.”

Listen to this pod­cast in­ter­view with Hannah Fry about win­ning the Leelavati Prize, and dis­cover more cov­er­age of the full ICM 2026, on our Plus outreach plat­form.

Image: Professor Hannah Fry speak­ing at the Communicating Mathematical and Data Sciences event at the Isaac Newton Institute, Cambridge. Image credit: Grace Merton/INI

Intelligence

Artificial Analysis Intelligence Index

Artificial Analysis Intelligence Index v4.1 in­cor­po­rates 9 eval­u­a­tions: GDPval-AA v2, 𝜏³-Banking, Terminal-Bench v2.1, SciCode, Humanity’s Last Exam, GPQA Diamond, CritPt, AA-Omniscience, AA-LCR

Reasoning mod­els are in­di­cated by a light­bulb icon

Artificial Analysis Intelligence Index v4.1 in­cludes: GDPval-AA v2, 𝜏³-Banking, Terminal-Bench v2.1, SciCode, Humanity’s Last Exam, GPQA Diamond, CritPt, AA-Omniscience, AA-LCR. See Intelligence Index method­ol­ogy for fur­ther de­tails, in­clud­ing a break­down of each eval­u­a­tion and how we run them.

Artificial Analysis Intelligence Index by Open Weights / Proprietary

Artificial Analysis Intelligence Index v4.1 in­cor­po­rates 9 eval­u­a­tions: GDPval-AA v2, 𝜏³-Banking, Terminal-Bench v2.1, SciCode, Humanity’s Last Exam, GPQA Diamond, CritPt, AA-Omniscience, AA-LCR

Reasoning mod­els are in­di­cated by a light­bulb icon

Artificial Analysis Intelligence Index v4.1 in­cludes: GDPval-AA v2, 𝜏³-Banking, Terminal-Bench v2.1, SciCode, Humanity’s Last Exam, GPQA Diamond, CritPt, AA-Omniscience, AA-LCR. See Intelligence Index method­ol­ogy for fur­ther de­tails, in­clud­ing a break­down of each eval­u­a­tion and how we run them.

Indicates whether the model weights are avail­able. Models are la­belled as ‘Commercial Use Restricted’ if the weights are avail­able but com­mer­cial use is lim­ited (typically re­quires ob­tain­ing a paid li­cense).

Intelligence Evaluations

Intelligence eval­u­a­tions mea­sured in­de­pen­dently by Artificial Analysis · Higher is bet­ter

Agentic busi­ness op­er­a­tions

Reasoning mod­els are in­di­cated by a light­bulb icon

While model in­tel­li­gence gen­er­ally trans­lates across use cases, spe­cific eval­u­a­tions may be more rel­e­vant for cer­tain use cases.

Artificial Analysis Intelligence Index v4.1 in­cludes: GDPval-AA v2, 𝜏³-Banking, Terminal-Bench v2.1, SciCode, Humanity’s Last Exam, GPQA Diamond, CritPt, AA-Omniscience, AA-LCR. See Intelligence Index method­ol­ogy for fur­ther de­tails, in­clud­ing a break­down of each eval­u­a­tion and how we run them.

AA-Briefcase

AA-Briefcase Elo

AA-Briefcase is an agen­tic knowl­edge work bench­mark de­vel­oped by Artificial Analysis. AA-Briefcase Elo is a com­bined met­ric that ag­gre­gates rubric pass rate, an­a­lyt­i­cal qual­ity Elo and pre­sen­ta­tion Elo · Higher is bet­ter

Reasoning mod­els are in­di­cated by a light­bulb icon

AA-Briefcase Elo is a com­bined met­ric that ag­gre­gates an­a­lyt­i­cal qual­ity Elo, pre­sen­ta­tion Elo, and rubric pass rate, with rubric per­for­mance con­verted into Elo via syn­thetic head-to-head matches. Elo and 95% con­fi­dence in­ter­val bounds are clamped at 0.

AA-Omniscience

AA-Omniscience Index

AA-Omniscience Index (higher is bet­ter) mea­sures knowl­edge re­li­a­bil­ity and hal­lu­ci­na­tion. It re­wards cor­rect an­swers, pe­nal­izes hal­lu­ci­na­tions, and has no penalty for re­fus­ing to an­swer. Scores range from -100 to 100, where 0 means as many cor­rect as in­cor­rect an­swers, and neg­a­tive scores mean more in­cor­rect than cor­rect.

Reasoning mod­els are in­di­cated by a light­bulb icon

AA-Omniscience Index (higher is bet­ter) mea­sures knowl­edge re­li­a­bil­ity and hal­lu­ci­na­tion. It re­wards cor­rect an­swers, pe­nal­izes hal­lu­ci­na­tions, and has no penalty for re­fus­ing to an­swer. Scores range from -100 to 100, where 0 means as many cor­rect as in­cor­rect an­swers, and neg­a­tive scores mean more in­cor­rect than cor­rect.

Openness

Artificial Analysis Openness Index: Score

Openness Index as­sesses model open­ness on a 0 to 100 nor­mal­ized scale (higher is more open)

Reasoning mod­els are in­di­cated by a light­bulb icon

Intelligence Index Comparisons

Intelligence Index vs. Cost per Intelligence Index Task

Artificial Analysis Intelligence Index · Weighted av­er­age cost (USD) per Artificial Analysis Intelligence Index task

Most at­trac­tive quad­rant

Reasoning mod­els are in­di­cated by a light­bulb icon

Weighted av­er­age cost per Intelligence Index task. Each eval­u­a­tion’s cost is cal­cu­lated from in­put, cache hit, cache write, rea­son­ing, and an­swer to­ken prices, di­vided by task count, and weighted by its Intelligence Index weight.

Artificial Analysis Intelligence Index v4.1 in­cludes: GDPval-AA v2, 𝜏³-Banking, Terminal-Bench v2.1, SciCode, Humanity’s Last Exam, GPQA Diamond, CritPt, AA-Omniscience, AA-LCR. See Intelligence Index method­ol­ogy for fur­ther de­tails, in­clud­ing a break­down of each eval­u­a­tion and how we run them.

Token Use

Output Tokens per Intelligence Index Task

Weighted av­er­age num­ber of out­put to­kens used to run one task in the Artificial Analysis Intelligence Index

Reasoning mod­els are in­di­cated by a light­bulb icon

The num­ber of to­kens re­quired per Intelligence Index task. This is cal­cu­lated by mul­ti­ply­ing the out­put to­kens per eval by the rel­a­tive weights of each bench­mark in the Intelligence Index, then di­vid­ing by task count (excluding re­peats).

Price and Cost

Cost per Intelligence Index Task

Weighted av­er­age cost (USD) per Artificial Analysis Intelligence Index task, seg­mented by to­ken type. Lower is bet­ter

Reasoning mod­els are in­di­cated by a light­bulb icon

Weighted av­er­age cost per Intelligence Index task. Each eval­u­a­tion’s cost is cal­cu­lated from in­put, cache hit, cache write, rea­son­ing, and an­swer to­ken prices, di­vided by task count, and weighted by its Intelligence Index weight.

Cost to Run Artificial Analysis Intelligence Index

Cost (USD) to run all eval­u­a­tions in the Artificial Analysis Intelligence Index

Reasoning mod­els are in­di­cated by a light­bulb icon

The cost to run the eval­u­a­tions in the Artificial Analysis Intelligence Index, cal­cu­lated us­ing the mod­el’s in­put, cache hit, cache write, rea­son­ing, and an­swer to­ken prices and the num­ber of to­kens used across eval­u­a­tions (excluding re­peats).

Pricing: Cache Hit, Input, and Output

Price (USD per M Tokens)

Reasoning mod­els are in­di­cated by a light­bulb icon

Price per to­ken for cached prompts (previously processed), typ­i­cally of­fer­ing a sig­nif­i­cant dis­count com­pared to reg­u­lar in­put price, rep­re­sented as USD per mil­lion to­kens. The val­ues shown here are the cache hit price; cache write and cache stor­age are billed sep­a­rately and vary by provider — see “Cache pric­ing by provider” for de­tail.

Price per to­ken in­cluded in the re­quest/​mes­sage sent to the API, rep­re­sented as USD per mil­lion Tokens.

The blended cache price shown here uses cache hit price only. Other caching costs dif­fer by provider:

Anthropic: charges a sep­a­rate cache write fee, with dif­fer­ent rates for 5-minute and 1-hour TTLs (1-hour TTL is more ex­pen­sive).

Google (Vertex/Gemini): charges a per-hour cache stor­age fee in ad­di­tion to cache hit pric­ing. Some providers also use tiered pric­ing for prompts above 200K to­kens.

OpenAI, DeepSeek, oth­ers: typ­i­cally charge only cache hit pric­ing with no write or stor­age fee.

See Prompt Caching for the full break­down.

Price per to­ken gen­er­ated by the model (received from the API), rep­re­sented as USD per mil­lion Tokens.

Figures rep­re­sent per­for­mance of the mod­el’s first-party API (e.g. OpenAI for o1) or the me­dian across providers where a first-party API is not avail­able (e.g. Meta’s Llama mod­els).

Context Window

Context Window

Context win­dow: to­kens limit · Higher is bet­ter

Reasoning mod­els are in­di­cated by a light­bulb icon

Larger con­text win­dows are rel­e­vant to RAG (Retrieval Augmented Generation) LLM work­flows which typ­i­cally in­volve rea­son­ing and in­for­ma­tion re­trieval of large amounts of data.

Maximum num­ber of com­bined in­put & out­put to­kens. Output to­kens com­monly have a sig­nif­i­cantly lower limit (varied by model).

Speed

Measured by Output Speed (tokens per sec­ond)

Output Speed

Output to­kens per sec­ond · Higher is bet­ter

Reasoning mod­els are in­di­cated by a light­bulb icon

Tokens per sec­ond re­ceived while the model is gen­er­at­ing to­kens (ie. af­ter first chunk has been re­ceived from the API for mod­els which sup­port stream­ing).

Figures rep­re­sent per­for­mance of the mod­el’s first-party API (e.g. OpenAI for o1) or the me­dian across providers where a first-party API is not avail­able (e.g. Meta’s Llama mod­els).

Time per Intelligence Index Task

Weighted av­er­age de­code time (minutes) per task; ex­cludes TTFT and over­head time · Lower is bet­ter

Reasoning mod­els are in­di­cated by a light­bulb icon

The weighted av­er­age time (seconds) per Artificial Analysis Intelligence Index task. This is cal­cu­lated by di­vid­ing out­put to­kens per task by out­put speed, weighted by the rel­a­tive weights of each bench­mark in the Intelligence Index.

Latency

Measured by Time (seconds) to First Token

Latency: Time To First Answer Token

Seconds to first an­swer to­ken re­ceived · Accounts for rea­son­ing model ‘thinking’ time

Reasoning mod­els are in­di­cated by a light­bulb icon

Time to first an­swer to­ken re­ceived, in sec­onds, af­ter API re­quest sent. For rea­son­ing mod­els, this in­cludes the ‘thinking’ time of the model be­fore pro­vid­ing an an­swer. For mod­els which do not sup­port stream­ing, this rep­re­sents time to re­ceive the com­ple­tion.

End-to-End Response Time

Seconds to out­put 500 to­kens, cal­cu­lated based on time to first to­ken, ‘thinking’ time for rea­son­ing mod­els, and out­put speed

End-to-End Response Time

Seconds to out­put 500 to­kens, in­clud­ing rea­son­ing model ‘thinking’ time · Lower is bet­ter

Reasoning mod­els are in­di­cated by a light­bulb icon

Seconds to re­ceive a 500 to­ken re­sponse. Key com­po­nents:

Input time: Time to re­ceive the first re­sponse to­ken

Thinking time (only for rea­son­ing mod­els): Time rea­son­ing mod­els spend out­putting to­kens to rea­son prior to pro­vid­ing an an­swer. Amount of to­kens based on the av­er­age rea­son­ing to­kens across a di­verse set of 60 prompts (methodology de­tails).

Answer time: Time to gen­er­ate 500 out­put to­kens, based on out­put speed

Figures rep­re­sent per­for­mance of the mod­el’s first-party API (e.g. OpenAI for o1) or the me­dian across providers where a first-party API is not avail­able (e.g. Meta’s Llama mod­els).

Model Size (Open Weights Models Only)

Model Size: Total and Active Parameters

Comparison be­tween to­tal model pa­ra­me­ters and pa­ra­me­ters ac­tive dur­ing in­fer­ence

Reasoning mod­els are in­di­cated by a light­bulb icon

Postgres LISTEN/NOTIFY has a bad rep­u­ta­tion thanks in part to a pop­u­lar blog post as­sert­ing it does not scale. If that were true, it would be a shame, be­cause LISTEN/NOTIFY is a pow­er­ful tool, al­low­ing you to use your Postgres data­base for low-la­tency durable no­ti­fi­ca­tions, streams, and pub/​sub. The ac­cu­sa­tions aren’t wrong: NOTIFY has un­in­tu­itive and un­doc­u­mented per­for­mance char­ac­ter­is­tics aris­ing from its use of a global lock. But “unintuitive be­hav­ior” is not the same as “not scal­able.” In this blog post, we’ll show how we op­ti­mized LISTEN/NOTIFY-backed streams at scale, achiev­ing 60K writes per sec­ond on a sin­gle Postgres server with mil­lisec­ond-scale la­tency.

Low-Latency Streaming with LISTEN/NOTIFY

The ba­sic de­sign of Postgres-backed streams is sim­ple: cre­ate a streams table where each stream chunk (for ex­am­ple, an LLM re­sponse to­ken) is a new row, then write to streams by in­sert­ing into the table.

‍

The tricky part is read­ing from the stream be­cause you don’t know when the next chunk will ar­rive. One so­lu­tion is polling: have each reader poll the end of the stream for new chunks. However, polling scales poorly. If the polling in­ter­val is set too high, la­tency is too high for in­ter­ac­tive use-cases (e.g., on­line chats). But if the polling in­ter­val is set too low, con­cur­rent pollers over­whelm the data­base.

The bet­ter so­lu­tion is LISTEN/NOTIFY. This al­lows read­ers to block wait­ing for a no­ti­fi­ca­tion from a writer that a new chunk has been pub­lished to the stream. That way, read­ers don’t waste re­sources polling, but wake up im­me­di­ately when a new stream chunk ar­rives.

In our ini­tial im­ple­men­ta­tion of LISTEN/NOTIFY-based streams, a trig­ger on the streams table fired a func­tion that sent a no­ti­fi­ca­tion every time a new stream chunk was writ­ten. Readers waited for these no­ti­fi­ca­tions and woke up to a new stream chunk.

This im­ple­men­ta­tion was cor­rect and de­liv­ered low la­tency, but at scale its through­put was poor. Even us­ing a large Postgres data­base, it could not sus­tain more than 2.9K stream writes per sec­ond. Interestingly, it bot­tle­necked with­out vis­i­bly con­sum­ing any Postgres re­source (CPU, mem­ory, or IOPS). As you may have guessed, the root cause was the orig­i­nal “LISTEN/NOTIFY is not scal­able” is­sue: a global lock Postgres takes dur­ing NOTIFY. But why does Postgres do that, and how can we op­ti­mize it with­out los­ing the ben­e­fits of Postgres no­ti­fi­ca­tions?

The LISTEN/NOTIFY Exclusive Lock

To un­der­stand the prob­lem, we’ll need to ex­am­ine how Postgres LISTEN/NOTIFY ac­tu­ally works.

The root cause of the poor per­for­mance is that in Postgres, com­mit­ting a trans­ac­tion that calls NOTIFY re­quires tak­ing a global ex­clu­sive lock. This lock is taken as the trans­ac­tion be­gins to com­mit, and is not re­leased un­til the trans­ac­tion is fully com­mit­ted and its con­tents have been flushed to disk with fsync().

This lock is nec­es­sary be­cause Postgres guar­an­tees that no­ti­fi­ca­tions are sent in trans­ac­tion com­mit or­der. To en­force this, it stores all out­go­ing no­ti­fi­ca­tions in a global in­ter­nal queue whose or­der must ex­actly match the com­mit or­der of the trans­ac­tions send­ing those no­ti­fi­ca­tions. Adding no­ti­fi­ca­tions to this queue must be done trans­ac­tion­ally as part of the com­mit. However, Postgres does­n’t as­sign trans­ac­tions a com­mit or­der un­til those trans­ac­tions are done com­mit­ting, as com­mit­ting can take a vari­able amount of time.

This cre­ates an or­der­ing prob­lem: trans­ac­tions con­tain­ing no­ti­fi­ca­tions must add them­selves to the queue in com­mit or­der, but com­mit or­der is­n’t de­fined un­til the com­mit is com­plete. The so­lu­tion is the global lock, which se­ri­al­izes com­mits of trans­ac­tions con­tain­ing no­ti­fi­ca­tions, so their com­mit or­der is de­fined ahead of time and they can cor­rectly or­der them­selves in the in­ter­nal no­ti­fi­ca­tions queue.

This ex­clu­sive lock ex­plains the poor per­for­mance we ob­served. Because we call NOTIFY from a trig­ger on the streams table, every stream write in­cludes a call to NOTIFY. In or­der to com­mit, each stream write needs to take the global lock and hold it for the en­tire du­ra­tion of its com­mit, in­clud­ing the flush to disk. This means that stream writes need to com­mit se­quen­tially, pre­clud­ing Postgres’s usual op­ti­miza­tions like group com­mit (which com­mits many trans­ac­tions to­gether in a sin­gle fsync()). As a re­sult, stream writes can com­plete no faster than Postgres can com­mit trans­ac­tions, which leads to this bot­tle­neck. This also ex­plains why we did not see sig­nif­i­cant con­sump­tion of any Postgres re­source such as CPU or disk: there was­n’t any, be­cause all trans­ac­tions were se­ri­al­ized by a global lock.

As an aside, there’s been some on­line dis­cus­sion of a Postgres patch re­lated to this is­sue. This patch (to be re­leased in Postgres 19) does not re­move the global lock or fix the bot­tle­neck we ob­served. Instead, it op­ti­mizes the nar­rower case where there are many no­ti­fi­ca­tion chan­nels and each lis­tener is wait­ing only on a spe­cific chan­nel.

Optimizing LISTEN/NOTIFY

To make LISTEN/NOTIFY-backed streams faster, we have to work around this bot­tle­neck. The key ob­ser­va­tion is that for streams, and for many other ap­pli­ca­tions of LISTEN/NOTIFY, the no­ti­fi­ca­tions aren’t them­selves a source of truth. Instead, they just ping a reader to check a data­base table (the real source of truth) for new data. As a re­sult, no­ti­fi­ca­tions don’t have to be glob­ally or­dered or per­fectly durable, so we can op­ti­mize NOTIFY by buffer­ing no­ti­fi­ca­tions in mem­ory and pe­ri­od­i­cally flush­ing them in a sin­gle batch trans­ac­tion, sig­nif­i­cantly re­duc­ing con­tention on the global lock.

Buffering and batch­ing NOTIFYs avoids the bot­tle­neck be­cause the global lock only needs to be taken when the buffer is flushed, not for each in­di­vid­ual stream write. This means that in­di­vid­ual stream writes can pro­ceed quickly, tak­ing ad­van­tage of Postgres op­ti­miza­tions like group com­mit to ob­tain high through­put, while the buffer flushes in the back­ground.

Adopting a buffer in­tro­duces a new com­pli­ca­tion, which is that a process crash while no­ti­fi­ca­tions are buffered leads to those no­ti­fi­ca­tions never be­ing de­liv­ered. To solve this is­sue, we add a fall­back to stream read­ers: in ad­di­tion to wait­ing for no­ti­fi­ca­tions, they also pe­ri­od­i­cally poll the data­base to check if the stream was writ­ten to with­out a no­ti­fi­ca­tion. The fre­quency of this polling can be low (because it is only a fall­back for un­de­liv­ered no­ti­fi­ca­tions), so it does not sig­nif­i­cantly af­fect per­for­mance.

Benchmarking this op­ti­mized so­lu­tion, we see mas­sively im­proved per­for­mance: in the pres­ence of con­cur­rent read­ers, we can per­form up to 60K stream writes per sec­ond (20x more than be­fore) while still ob­tain­ing 15 – 100ms la­tency. At max­i­mum through­put, Postgres CPU is fully uti­lized, show­ing the data­base is ac­tu­ally sat­u­rated in­stead of bot­tle­necked on con­tention.

Learn More

All bench­mark code is avail­able on GitHub: github.com/​dbos-inc/​dbos-post­gres-bench­mark

If you like build­ing scal­able, re­li­able sys­tems, we’d love to hear from you. At DBOS, our goal is to make Postgres-backed durable ex­e­cu­tion as sim­ple and per­for­mant as pos­si­ble. Check it out:

Quickstart: https://​docs.dbos.dev/​quick­start

GitHub: https://​github.com/​dbos-inc

Discord com­mu­nity: https://​dis­cord.gg/​eMUHrvbu67

Please en­able JS and dis­able any ad blocker

The euro ban­knotes are be­ing re­designed to re­flect Europe’s shared iden­tity and val­ues. The de­sign pro­pos­als pre­sented be­low were se­lected by the Jury. The de­signs shown are pro­pos­als only and do not rep­re­sent fi­nal euro ban­knotes.

Design A - Studio Joost Grootens

Design B - PunktFormStrich

Proposal C - Neue Gestaltung GmbH

Proposal D - Rudy Guedj and François Girard-Meunier

Proposal E - Myrsini Vardopoulou

Proposal F - Jan Robert Dünnweller

Proposal G - Rubio & del Amo and Cruz más Cruz

Proposal H - Atelier Goppel-Toperngpong

Proposal I - Isabelle Daëron

Proposal J - Ville Tietäväinen

In 1985, the Innovative Design Fund placed an ad in Scientific American of­fer­ing up to $10,000 to sup­port clever pro­to­types for cloth­ing, home decor, and tex­tiles. William Freeman PhD ’92, then an elec­tri­cal en­gi­neer at Polaroid and now an MIT pro­fes­sor, saw it and sub­mit­ted a novel idea: a three-sided zip­per. Instead of fas­ten­ing pants, it’d be like a switch that seam­lessly flips chairs, tents, and purses be­tween soft and rigid states, mak­ing them eas­ier to pack and put to­gether.

Freeman’s blue­print was much like a reg­u­lar zip­per, ex­cept tri­an­gu­lar. On each side, he nailed a belt to con­nect nar­row wooden “teeth” to­gether. A slider wrap­ping around the de­vice could be moved up to fas­ten the three strips into place, straight­en­ing them into a tri­an­gu­lar tube. His pro­posal was re­jected, but Freeman patented his pro­to­type and stored it in his garage in the hopes it might come in handy one day.

Nearly 40 years later, MIT Computer Science and Artificial Intelligence Laboratory (CSAIL) re­searchers wanted to re­vive the pro­ject to cre­ate items with “tunable stiff­ness.” Prior at­tempts to ad­just that weren’t eas­ily re­versible or re­quired man­ual as­sem­bly, so CSAIL built an au­to­mated de­sign tool and adapt­able fas­tener called the “Y-zipper.” The sci­en­tists’ soft­ware pro­gram helps users cus­tomize three-sided zip­pers, which it then builds on its own in a 3D printer us­ing plas­tics. These de­vices can be at­tached or em­bed­ded into camp­ing equip­ment, med­ical gear, ro­bots, and art in­stal­la­tions for more con­ve­nient as­sem­bly.

“A reg­u­lar zip­per is great for clos­ing up flat ob­jects, like a jacket, but Freeman ideated some­thing more dy­namic. Using cur­rent fab­ri­ca­tion tech­nol­ogy, his mech­a­nism can trans­form more com­plex items,” says MIT post­doc and CSAIL re­searcher Jiaji Li, who is a lead au­thor on an open-ac­cess pa­per pre­sent­ing the pro­ject. “We’ve de­vel­oped a process that builds ob­jects you can rapidly shift from flex­i­ble to rigid, and you can be con­fi­dent they’ll work in the real world.”

Why zip­pers?

Users can cus­tomize how the fas­ten­ers look when they’re zipped up in CSAIL’s soft­ware pro­gram; they can se­lect the length of each strip, as well as the di­rec­tion and an­gle at which they’ll bend. They can also choose from one of four mo­tion “primitives” to se­lect how the zip­per will ap­pear when it’s zipped up: straight, bent (similar to an arch), coiled (resembling a spring), or twisted (looks like screws).

The Y-zipper that re­sults will ap­pear to “shape-shift” in the real world. When un­zipped, it can look like a squid with three sprawl­ing ten­ta­cles, and when you close it up, it be­comes a more com­pact struc­ture (like a rod, for in­stance). This flex­i­bil­ity could be use­ful when you’re trav­el­ing — take pitch­ing a tent, for ex­am­ple. The process can take up to six min­utes to do alone, but with the Y-zipper’s help, it can be done in one minute and 20 sec­onds. You sim­ply at­tach each arm to a side of the tent, sup­port­ing the struc­ture from the top so that the zip­per seem­ingly pops the canopy into place.

This seam­less tran­si­tion could also un­lock more flex­i­ble wear­ables, of­ten use­ful in med­ical sce­nar­ios. The team wrapped the Y-zipper around a wrist cast, so that a user could loosen it dur­ing the day, and zip it up at night to pre­vent fur­ther in­juries. In turn, a seem­ingly stiff de­vice can be made more com­fort­able, ad­just­ing to a pa­tien­t’s needs.

The sys­tem can also aid users in craft­ing tech­nol­ogy that moves at the push of a but­ton. One can at­tach a mo­tor to the Y-zipper af­ter fab­ri­ca­tion to au­to­mate the zip­ping process, which helps build things like an adap­tive ro­botic quadruped. The ro­bot could po­ten­tially change the size of its legs, tight­en­ing up into taller limbs and un­zip­ping when it needs to be lower to the ground. Eventually, such rapid ad­just­ments could help the ro­bot ex­plore the un­even ter­rain of places like canyons or forests. Actuated Y-zippers can also build dy­namic art in­stal­la­tions — for ex­am­ple, the team cre­ated a long, wind­ing flower that “bloomed” thanks to a sta­tic mo­tor zip­ping up the de­vice.

Mastering the ma­te­r­ial

While Li and his col­leagues saw the cre­ative po­ten­tial of the Y-zipper, it was­n’t yet clear how durable it would be. Could they sus­tain daily use?

The team ran a se­ries of stress tests to find out. First, they eval­u­ated the strength and flex­i­bil­ity of poly­lac­tic acid (PLA) and ther­mo­plas­tic polyurethane (TPU), two plas­tics com­monly used in 3D print­ing. Using a ma­chine that bent the Y-zippers down, they found that PLA could han­dle heav­ier loads, while TPU was more pli­able.

In an­other ex­per­i­ment, CSAIL re­searchers used an ac­tu­a­tor to con­tin­u­ously open and close the Y-zipper to see how long it’d take to snap. Some 18,000 cy­cles of zip­ping and un­zip­ping later, they fi­nally broke. Y-zipper’s se­cret to dura­bil­ity, ac­cord­ing to 3D sim­u­la­tions: its elas­tic struc­ture, which helps dis­trib­ute the stress of heavy loads.

Despite these find­ings, Li en­vi­sions an even more durable three-sided zip­per us­ing stronger ma­te­ri­als, like metal. They may also make the zip­pers big­ger for larger-scale pro­jects, but that’s not yet pos­si­ble with their cur­rent 3D print­ing plat­form.

Jiaji also notes that some ap­pli­ca­tions re­main un­ex­plored, like space ex­plo­ration, wherein Y-zipper’s ten­ta­cles could be built into a space­craft to grab nearby rock sam­ples. Likewise, the zip­pers could be em­bed­ded into struc­tures that can be as­sem­bled rapidly, help­ing re­lief work­ers quickly set up shel­ters or med­ical tents dur­ing nat­ural dis­as­ters and res­cues.

“Reimagining an every­day zip­per to tackle 3D mor­pho­log­i­cal tran­si­tions is a bril­liant ap­proach to dy­namic as­sem­bly,” says Zhejiang University as­sis­tant pro­fes­sor Guanyun Wang, who was­n’t in­volved in the pa­per. “More im­por­tantly, it ef­fec­tively bridges the gap be­tween soft and rigid states, of­fer­ing a highly scal­able and in­no­v­a­tive fab­ri­ca­tion ap­proach that will greatly ben­e­fit the fu­ture de­sign of em­bod­ied in­tel­li­gence.”

Li and Freeman wrote the pa­per with Tianjin University PhD stu­dent Xiang Chang and MIT CSAIL col­leagues: PhD stu­dent Maxine Perroni-Scharf; un­der­grad­u­ate Dingning Cao; re­cent vis­it­ing re­searchers Mingming Li (Zhejiang University), Jeremy Mrzyglocki (Technical University of Munich), and Takumi Yamamoto (Keio University); and MIT Associate Professor Stefanie Mueller, who is a CSAIL prin­ci­pal in­ves­ti­ga­tor and se­nior au­thor on the work. Their re­search was sup­ported, in part, by a post­doc­toral re­search fel­low­ship from Zhejiang University and the MIT-GIST Program.

The re­searchers’ work was pre­sented at the ACM’s ​​Computer-Human Interaction (CHI) con­fer­ence on Human Factors in Computing Systems in April.

AI dis­clo­sure: All bugs are 100% hu­man made.

It seems I have just built the world’s first open source switch ASIC and I am get­ting it back from the fab mid no­vem­ber.

Here is its repos­i­tory :

Buckle up and wel­come to the tale of more mad­ness.

Where are the open source net­work­ing ASICs?#

Recent FCC de­ci­sions have put the cen­tral im­por­tance of net­work­ing equip­ment top of mind, and in do­ing so, have also put the to­tal ab­sence of any en­tirely open source net­work­ing equip­ment hard­ware at the top of my mind.

Although Open Source Silicon is in its in­fancy we are cur­rently see­ing a num­ber of pro­jects be­ing de­signed, tested, and for the most am­bi­tious ones, even taped-out with some proven sil­i­con al­ready in the wild.

That said, the vast ma­jor­ity of the most am­bi­tious pro­jects are pre­dom­i­nantly RISC-V SoCs.

Surprisingly, there has been much less in­ter­est in build­ing open hard­ware for net­work­ing equip­ment.

Well .. un­sur­pris­ingly ac­tu­ally … net­work­ing equip­ment is far less “sexy” than CPUs and has thus re­ceived much less at­ten­tion from the open source com­mu­nity. On the other hand, this means there’s a huge un­taped boule­vard of pro­jects open to any­one with more time than com­mon sense to build open source net­work­ing equip­ment chips!

Because, on the other side of the great sil­i­con di­vide, the world of open source net­work­ing equip­ment is ac­tu­ally quite rich, both in terms of its flour­ish­ing soft­ware ecosys­tem and the open PCB/electronics ecosys­tem, with a flurry of fully fea­tured open source routers avail­able. Yet, due to the cur­rent ecosys­tem’s lim­i­ta­tions, un­der the hood, these are all still all run­ning closed-sourced, black­box pro­pri­etary chips for the cen­tral com­pute and rout­ing tasks.

So what would it take to build a router chip?

It’s a very am­bi­tious pro­ject, since a router in­volves a com­plex SoC need­ing both a pow­er­ful enough CPU to run the net­work­ing stack along­side spe­cial­ized net­work­ing hard­ware, and ana­log fron­tends for the wired and wire­less con­nec­tions. Since build­ing a full router out­right is much too am­bi­tious of a green­field pro­ject for a sin­gle per­son to ever hope to pull off, let’s be­gin with a more ap­proach­able first step: build­ing a switch. After all, al­though most peo­ple only have one router, you can have a num­ber of smaller switches, and we also don’t have any open source chips for those.

Oh and, I am not talk­ing about build­ing an FPGA switch, oh no, I am talk­ing about build­ing a switch ASIC, tap­ing it out and then prov­ing the sil­i­con works.

Switch Flavors#

Before we start fig­ur­ing out what kind of switch we want to build, let me give you a quick overview of the dif­fer­ent fla­vors of switches out there. Readers deeply fa­mil­iar with net­work­ing equip­ment can skip this part.

Glossary#

Physical Layer#

Ethernet sup­ports mul­ti­ple phys­i­cal lay­ers, out­lined in the 802.3 IEEE spec. Each clause in the spec de­fines the un­der­ly­ing medium char­ac­ter­is­tics for car­ry­ing the Ethernet pro­to­col over the medium at a given band­width.

Both a 10 Gb fiber Ethernet link and a 10 Mb coax­ial ca­ble can carry Ethernet pack­ets and, to the lay­ers above the phys­i­cal layer, the pack­ets will look ex­actly the same.

Where they will dif­fer is at the phys­i­cal layer and, out­lined in the spec is pre­cisely how, with which tim­ing and with what en­cod­ing data will be trans­mit­ted over the medium.

This en­sures that de­vices made by dif­fer­ent man­u­fac­tur­ers agree on what “talking Ethernet” looks like, mak­ing them in­ter­op­er­a­ble.

So one of the first ques­tions I must an­swer is which phys­i­cal layer my switch should sup­port. This will de­fine how much traf­fic I must route, how fast I should do so and how much band­width I can carry.

Managed vs Unmanaged#

The sec­ond ques­tion is: what type of switch do I want to build?

There are two big fam­i­lies of switches: man­aged and un­man­aged. As the name im­plies, man­aged switches can be con­fig­ured and man­aged from the out­side. This al­lows for much smarter rout­ing, such as sup­port­ing dif­fer­ent VLANs.

While un­man­aged switches are es­sen­tially un­con­fig­urable pieces of net­work­ing equip­ment that you plug into your net­work and just work (until power surge do you part).

Cut-through vs Store-and-Forward#

The last switch char­ac­ter­is­tic is cut-through ver­sus store-and-for­ward.

Cut-through switches start for­ward­ing a packet while the packet is still ar­riv­ing, lead­ing to much lower net­work­ing la­tency, whereas store-and-for­ward switches wait for the en­tire packet to ar­rive be­fore check­ing that no cor­rup­tion has oc­curred, and then only for­ward the packet if that check passes.

Where is­sues arise is when a packet is cor­rupted, a cut-through switch might still for­ward it, prop­a­gat­ing cor­rupted pack­ets through the net­work since for­ward­ing be­gan be­fore the FCS (frame check se­quence) could be checked.

Designing against con­straints (again)#

As usual with my ASIC de­sign work, what I build is shaped as much by what I want to build as it is by the con­straints of the sil­i­con.

Pins#

My first ma­jor con­straint is the pins: not only in their amount but also in their max­i­mum band­width.

Since I will be tap­ing this first gen­er­a­tion chip out over the Tiny Tapeout shut­tle chip, us­ing purely dig­i­tal tiles, I’m con­strained by the lim­its of these pins.

In to­tal this will af­ford me 24 pins: 8 in­put, 8 out­put, and 8 bi-di­rec­tional (configurable to be ei­ther in­puts or out­put pins) GPIO pins, rated to run re­li­ably at 50 MHz on both in­bound and out­bound data.

The ab­sence of any ana­log front end makes build­ing any­thing IEEE-physical-layer-compliant di­rectly a chal­lenge, but there’s a way around this: us­ing an ex­ter­nal PHY (physical layer) chip and in­ter­fac­ing with it over the stan­dard­ized RMII bus. Though this con­sumes 7 bits per Ethernet in­ter­face it makes my 50Mbps pins ca­pa­ble of send­ing and re­ceiv­ing over 100Mbps Ethernet (100BASE-TX).

I will be tar­get­ing the widely avail­able Microchip LAN8720A/LAN8720AI (which will be the only men­tion of AI in this ar­ti­cle) PHY chip for this in­ter­face. I will be go­ing more in-depth as to how this ASIC will be in­ter­fac­ing with this PHY later.

Area#

My sec­ond ma­jor con­straint is my lim­ited die area.

I am pay­ing for all this out of pocket af­ter­all, and more area means a higher man­u­fac­tur­ing cost. Now I am not try­ing to ac­cu­mu­late a pool of gold or any­thing, it’s just that, in com­pli­ance with Maslow’s hi­er­ar­chy of needs, waf­fles rank higher than area, and higher man­u­fac­tur­ing cost means less waf­fles. So just like any semi-con­duc­tor com­pany, I am in­cen­tivised to keep my area bud­get un­der con­trol.

Because store-and-for­ward re­quires the switch to store the en­tire packet be­fore for­ward­ing it, and be­cause eth­er­net frames can reach up­wards of 1.5k Bytes (and 9k+ for jumbo frames), they re­quire mas­sive amounts of stor­age. A workaround for that would be to store the packet to some off-chip mem­ory but I don’t have the pin bud­get to af­ford that right now, so on-chip mem­ory is my only op­tion.

The prob­lem is, on-chip mem­ory con­sumes a lot of area given the large area foot­print of SRAM and the even larger area per stored bit foot­print of flip-flops.

Now if we were talk­ing of a few bytes this could be ne­go­tiable, but for mul­ti­ple 1.5k Bytes pack­ets this is a deal­breaker, thus rul­ing store-and-for­ward out.

Assuming I was us­ing Tim Edward’s ex­cel­lent OCD 256x8 SRAM IP, a sin­gle 256 Byte SRAM oc­cu­pies 301.3 x 224.93 um (using W ori­en­ta­tion in this im­ple­men­ta­tion) and con­sumes just by it­self 1/3 of the floor­plan. If we want to store even a sin­gle full packet we would need 6 of such in­stances, and since we have 3 ports, we would then need to repli­cate that 3 times, so 18 in­stances in to­tal. Now, we have a larger 1028 Byte ver­sion of this SRAM that is 301.3 x 515.81 um which nicely in­creases our stor­age area den­sity. But again, if we were to in­stan­ti­ate six such macros this would oc­cupy x3 the area than we cur­rently have to spare.

Now, the Tiny Tapeout shut­tle chip does sup­port me scal­ing up this de­sign up at most an­other two fac­tors of two, or 4x. But the cost would also scale by a fac­tor of 4, at which point we are get­ting into full chip or­ders of mag­ni­tude of cost. And if I were to go down the full chip route, since I then have the pos­si­bil­ity of hav­ing a lot more pins to play with, this re-un­locks the pos­si­bil­ity of in­ter­fac­ing with much larger ex­ter­nal mem­o­ries, thus chang­ing the land­scape of what the cor­rect tech­ni­cal trade­off would be again.

Easy to use#

Lastly, I want some­thing that does­n’t re­quire ex­ter­nal soft­ware or con­fig­u­ra­tion.

Firstly be­cause I would like ex­ter­nal third party users in the com­mu­nity to be able to eas­ily pick this ASIC up and start us­ing it. And that be­comes in­creas­ingly dif­fi­cult as soon as I start in­volv­ing cus­tom soft­ware. I am aim­ing for some­thing that is as close to plug and play as pos­si­ble with ease of use be­ing a mea­sure of suc­cess.

Not to say that the com­mu­nity won’t be able to com­pile and flash my cus­tom em­bed­ded abom­i­na­tions, just that their will­ing­ness to do so de­creases ex­po­nen­tially with each ex­tra step.

Secondly be­cause I am once again work­ing on a very tight sched­ule and that cus­tom soft­ware sup­port adds sig­nif­i­cant amounts of time to both the pre-tape­out and bringup work­loads. (Let’s not for­get we are still talk­ing about a sin­gle per­son’s pro­ject here.) This would be es­pe­cially true for this eth­er­net switch pro­ject since I would aim to be com­pat­i­ble with a widely adopted open source switch man­age­ment soft­ware and pro­to­col like SNMP for mon­i­tor­ing or SSH for mon­i­tor­ing and con­fig­u­ra­tion.

Support for these pro­to­cols is not at the level of some­thing I can triv­ially im­ple­ment in hard­ware, es­pe­cially for SSH, and the best de­sign de­ci­sion would be to of­fload to a CPU. So ei­ther in­te­grate an on chip CPU on the ASIC or, build a cus­tom in­ter­face to an ex­ter­nal MCU and of­fload all these re­quests to it. Both op­tions in­volve a sig­nif­i­cant soft­ware ef­fort, with the on chip CPU also promis­ing a huge de­sign ef­fort and even more area us­age. At which point, I am ap­proach­ing the planned ar­chi­tec­ture of the router rather than the first gen­er­a­tion of the switch.

So, for both of these rea­sons, an un­man­aged switch is the path I am tak­ing.

What are we build­ing?#

So to re­cap, I am build­ing a:

3-port

Full-duplex

100 Mbps band­width

cut-through

un­man­aged

eth­er­net switch.

Now that we have fig­ured out what we’re build­ing, it’s time to fo­cus on the fun part: how to build it! 🥳

System Overview#

The real Ethernet frame that is hid­den from view#

Most peo­ple have ac­tu­ally never seen a full eth­er­net packet.

When you in­spect Ethernet traf­fic on your com­puter via tcp­dump or wire­shark, you ac­tu­ally only see part of the Ethernet frame, with some parts miss­ing. These parts are gen­er­ally stripped out by your com­put­er’s net­work in­ter­face be­fore the packet is for­warded to the soft­ware realm, thus hid­ing them from user’s view.

Random IPv4 packet cap­tured over tcp­dump (tcpdump -xx -e -v ‘ether proto 0x0800’) :

16:36:51.298082 60:e9:aa:92:dc:7d (oui Unknown) > 5c:e9:31:1e:9d:00 (oui Unknown), ether­type IPv4 (0x0800), length 78: (tos 0x2,ECT(0), ttl 64, id 0, off­set 0, flags [DF], proto UDP (17), length 64) su­per­pitchu.53332 > dfw25s53-in-f9.1e100.net.https: UDP, length 36 0x0000: 5ce9 311e 9d00 60e9 aa92 dc7d 0800 4502 0x0010: 0040 0000 4000 4011 2b98 c0a8 0085 4a7d 0x0020: 0369 d054 01bb 002c a93f 6fe8 5bd5 5378 0x0030: f4c9 ccae 477c 5083 0696 8fa4 4f62 57bf 0x0040: 41a9 78a3 fc60 7781 2b8b 38a1 2ccd

The miss­ing parts are:

Preamble + SFD: Before the start of the MAC header ex­ists a se­quence of 7 bytes of an al­ter­nat­ing bit se­quence sig­ni­fy­ing that a packet is about to start, called the pre­am­ble, fol­lowed by a 1-byte marker end­ing in a dou­ble as­serted bit se­quence called the SFD (Start Frame Delimiter) sig­nal­ing that the next bits are the MAC header.

Frame Check Sequence Footer: At the end of the packet there is a 4-byte footer called the FCS (Frame Check Sequence), used to check whether the Ethernet frame’s con­tent was cor­rupted dur­ing trans­mis­sion. This is checked by both store-and-for­ward switches and by most com­put­ers’ net­work in­ter­face cards and these drop all frames that fail this test be­fore the packet is for­warded.

And since, once they have been eval­u­ated by the net­work­ing in­ter­face, both the Preamble+SFD and FCS serve no fur­ther rel­e­vant pur­pose, they are stripped out be­fore the re­main­ing packet bits are for­warded up the net­work­ing stack.

Now, since we’re go­ing through the Microchip PHY, we won’t ac­tu­ally be in­ter­fac­ing di­rectly with the Ethernet phys­i­cal layer, as it will be ab­stract­ing away the pre­cise 100BASE-TX PHY be­hav­ior, though the full eth­er­net frame will re­main in­tact (including Preamble+SFD+FCS)

All our data trans­mis­sion and re­cep­tion will ac­tu­ally be done through the RMII bus in­ter­face.

The RMII in­ter­face#

RX#

rxv valid sig­nal (crs_dv in the di­a­gram above )

rxer er­ror sig­nal

rxd[1:0] two data sig­nals

On the RX (reception) side of RMII, we have four pins: two for data, one for data va­lid­ity, and one to sig­nal that an er­ror has oc­curred on the line. Interestingly, this valid sig­nal is­n’t a pure data-valid sig­nal but an early data-valid sig­nal, and it’s up to our ASIC to read the in­com­ing data and cor­rectly iden­tify when the Ethernet frame data ac­tu­ally starts us­ing the pre­am­ble and SFD. The valid sig­nal ac­tu­ally as­serts asyn­chro­nously a few cy­cles be­fore the start of the pre­am­ble but, de­asserts syn­chro­nously with the end of the Ethernet frame.

TX#

txv valid sig­nal (txen in the di­a­gram above )

txd[1:0] two data sig­nals

On the TX (transmit) side, we only have three sig­nals: two for data and one for valid, with no er­ror sig­nal. This makes sense, since the er­ror sig­nal is there to in­di­cate is­sues on the medium, and since there is no medium be­tween the ASIC and the PHY there is no need for it in the TX di­rec­tion.

Timing#

Lastly the PHY chip’s datasheet out­lines the ex­pected tim­ings for the in­ter­face sig­nals.

Unlike what my high level overview might have sug­gested, new data is­n’t im­me­di­ately avail­able at the start of the clock cy­cle. Like in all real hard­ware there is an in­ter­nal prop­a­ga­tion de­lay. The same goes for how fast the data is al­lowed to tran­si­tion af­ter the start of a cy­cle. Because the PHY chip also con­tains flip-flops and is thus also sub­ject to hold con­straints, the pre­vi­ous cy­cle’s data must re­main sta­ble for a cer­tain pe­riod of time af­ter the clock edge be­fore the new value can be prop­a­gated.

So, im­ple­ment­ing cor­rect sig­nal­ing alone is­n’t enough to prop­erly in­ter­face with this chip. If I want my ASIC to work I also re­ally need to make sure my phys­i­cal im­ple­men­ta­tion’s re­sult­ing tim­ing re­spects these con­straints. This is both ver­i­fied and en­forced by spec­i­fy­ing de­sign con­straint rules as part of the SDC (Synopsys Design Constraints) file.

Now by de­sign­ing around the con­straints of the LAN8720A chip read­ers might be con­cerned that I am lock­ing my­self into a de­pen­dency on a sin­gle ex­ter­nal chip.

And ac­tu­ally that is kind of the case here, I am not proud of this but I caught this dis­crep­ancy too late, and not men­tion­ing it in this ar­ti­cle sim­ply does­n’t align with the tech­ni­cally hon­est rec­ol­lec­tions I am look­ing to do here.

Since RMII is re­gented by the RMII con­sor­tium, and since in the RMII spec­i­fi­ca­tion they in­clude the AC char­ac­ter­is­tics I blindly as­sumed the LAN8720A would be com­pli­ant.

Turns out the LAN8720A is­n’t ac­tu­ally com­pli­ant.

And, al­though in many cases the LAN8720’s tim­ings are ac­tu­ally more con­strain­ing than the of­fi­cial spec, when it comes to the hold con­straints on the RX pins it is ac­tu­ally much looser at 1.4ns less than the RMII’s con­sor­tium’s 2.0ns.

Although this might still work in prac­tice, it would be by pure luck and I only be­lieve in en­gi­neered luck!

So note to self for fu­ture ver­sions: I should set this to 2.0ns to guar­an­tee that the ASIC would work with other RMII chips.

Apart from that, the LAN8720A is widely avail­able, easy to get dev boards for, well doc­u­mented, and at 103 cents a piece, worth every penny.

ASIC pinout#

Putting it to­gether, here is what the fi­nal pinout of our ASIC will look like con­nected to all 3 PHY chips. We will be re­fer­ring to these as PHY0, PHY1 and PHY2.

Note: As a re­minder, there are a to­tal of 24 pins: 8 in­puts, 8 out­puts and 8 bidi­rec­tional pins.

Disruption Scenario

Shock Target

Scenario Preset

Capacity Retained 30%

Demand Elasticity ε 0.10

Supply Elasticity η 0.10

Horizon 26 wks

Shock tar­get Collapse >60% Degraded 10 – 60% Insulated Overland / pipeline

SIMULATION — stress test, not a fore­cast · UN Comtrade 2025 re­ported flows (sanctioned / un­re­ported trade not rep­re­sented) · arXiv:2607.17491

Market Price p(t)

Downstream Flow Losses

Emergency Stockpile Drawdown (% re­main­ing)

Model & cal­i­bra­tion: Supply Chain Networks — fluid-sto­chas­tic net­work clear­ing, Skorokhod in­ven­tory dy­nam­ics, en­doge­nous pric­ing with strate­gic trade re­bal­anc­ing. Stockpile-depletion events shown for net-im­porter emer­gency buffers; ex­porter buffers are elas­tic-sup­ply ac­counts (see pa­per §5.2). Capacity-retained set­tings bun­dle by­pass in­fra­struc­ture (e.g., East–West & Habshan–Fujairah pipelines for Hormuz). No ra­tioning pol­icy is mod­eled: buffers drain me­chan­i­cally. arxiv.org/​abs/​2607.17491