Solenoid Protocol is the directory's entry for the part of the Web4 thesis that is being worked out as standards rather than products. It is not a startup. It is a four-person engineering group, headquartered in Berlin, that has spent the last eighteen months publishing a series of RFCs on agent identity, capability scoping, and inter-agent verification. The group has no formal corporate entity, no public funding, and no commercial product. The Bulletin tracks them anyway, because the position they argue is one of the working assumptions our coverage rests on.

The position is that agent identity is not an application-layer problem. Solenoid's RFCs argue that as soon as agentic systems begin handing work to other agentic systems — inside a company, across two companies, or across an open marketplace — the question of which agent is making a request, on whose behalf, with what authority, becomes structural. Their published view is that solving identity inside a single platform is necessary but not sufficient. There has to be a layer underneath the platforms that does it. They are working on the spec for that layer.

The Bulletin has cited Solenoid's RFCs in essays on interop, on agentic marketplaces, and on the underdiscussed risk that agentic systems will become structurally siloed in the same way SaaS apps were structurally siloed for fifteen years. The group's writing is the most cited cross-reference in our protocol coverage, ahead of any of the larger working groups in the broader autonomy-standards space.

Solenoid's structural shape — small, RFC-driven, no commercial pressure — is also part of what makes their work editorially useful. The group has no product to sell, which means their public positions read as engineering arguments rather than market positioning. That is rare in the agentic-systems space right now and the Bulletin's editorial team has made a point of preserving room for that kind of voice in the directory. Several of the directory's larger entries acknowledge Solenoid's RFCs in their own engineering writing, which is the strongest available proxy for the project's influence.

What is harder to evaluate, and what the Bulletin notes here for transparency, is whether the Solenoid spec will become a real standard or remain an influential reference. The group has refused, so far, to take any of the steps a normal standards body would take — they have not pursued institutional ratification, they have not staffed a secretariat, they have not begun shipping reference implementations beyond the minimal proof-of-concept they published in their first RFC. The Bulletin's editorial team is split on whether that posture is a feature or a flaw. Halloran has argued in print that the lack of formal structure keeps the work honest; Aksoy has argued that the work will not survive contact with a real adoption push without it.

Either way, Solenoid's RFCs are the documents the Bulletin returns to when we need to argue that "Web4" is not only a market narrative. They are the strongest available evidence that the category has an engineering substrate. Their full publication archive is the Bulletin's recommended starting point for any reader who wants to understand the protocol-layer side of the thesis we cover.

We expect to track Solenoid continuously and to update this directory entry as the spec advances or stalls.