Why a merchant bank builds protocols

The unusual position

This practice sits inside a merchant bank and does three things with the same infrastructure: it advises organisations on it, it builds it for them, and it licenses software that already exists. That combination is unusual, and it produces an unusual conclusion about where to put effort. If you only sold advice, you would keep your methods private. If you only sold a product, you would keep the product closed. Doing all three, the thing worth owning turns out to be neither the advice nor the product — it is the protocol both rest on.

That is why a practice better known for delivery is publishing a stack of open specifications. It is not a change of business; it is the recognition that the layer with the longest life is the one every implementation has to speak, and that a practice which shipped through the earlier generation of this field is well placed to say what that layer should refuse.

Own the protocol, not the agent

The governing idea is to own the open protocols through which agents discover, identify, authorize, trust, transact with and audit one another — and not the agents themselves. An agent is a product somebody else will build better, cheaper and more often than any single firm. The protocol an agent must speak to be discovered, to prove who it is, to be trusted, to move money and to leave a record is where the durable value sits, and it sits there for exactly as long as the protocol is the one people conform to.

So every layer of the stack is a protocol first, and the products that implement it are one implementation each, held privately. A firm that consults, builds and licenses is naturally suspicious of a protocol that only its own product can implement — because it has sat on the buyer’s side of exactly that trap — and the discipline of publishing the spec, with a dependency-free checker anyone can run, is how the protocol stays honest.

Consult, build, license

The three modes reinforce each other when the protocol is open. Advisory work surfaces what the protocol has to refuse, because the failures a practice is called in to fix are the failures a good spec would have prevented. Build work proves the protocol is implementable under real constraints rather than only on a whiteboard. And licensing gives an organisation that does not want to build the option to adopt a running implementation — evaluated on its own evidence, at its own published status, not on a claim.

Spec-first, and the word we will not use yet

The order matters, and it is a ladder: a protocol ships as a spec plus a dependency-free checker, is wired into the shared conformance tooling, proves an independent adopter, and only then becomes a business. Each rung exists because skipping it has a cost — a spec with no checker is prose that drifts from what anyone implements; a checker with dependencies is a check that can quietly not run; a protocol nobody else adopts is an internal format wearing a version number. The gate at the top is a word this practice will not use yet: none of these specifications is called a settled, adopted convention until an organisation outside the estate has conformed to it, and until then they are drafts, stated plainly as drafts.

What this commits us to

Publishing this way commits the practice to a few things a reader can hold it to. Statuses are honest and dated: no layer is described as adopted before an adopter exists, and where a reference implementation is a proof of concept — FlashyOS, the execution platform, is one in its own documentation — it is described at that status and never above it. Numbers are measured, not assumed, and carry the day they were taken. And the refusals in each spec are the product: an invariant is written as something a caller cannot do rather than something a caller should not, because a guideline can be argued past and a missing parameter cannot. That is the version of this field a practice which lived through the last one is willing to sign.

• The lab’s view (planned)FlashyLabs is preparing an engineering companion to this piece at https://flashylabs.com/insights/why-a-merchant-bank-builds-protocols — planned, not yet published.
• The studio’s view (planned)The 4 Ventures thesis desk is preparing an investor-lens companion at https://4.ventures/thesis/why-a-merchant-bank-builds-protocols — planned, not yet published.