Standardizing the interface

A fragmented ecosystem is expensive in one specific way. Every pair of participants has to agree on how to work together, and the total cost grows with the number of pairs. Standardizing a single shared interface removes those private agreements. Each participant matches the standard once and becomes compatible with everyone else who did the same.

Move a shipment of goods across the world before the 1950s and it was handled loose, piece by piece. Each kind of cargo had its own way of being loaded. Each port had its own equipment. Each ship had its own hold. Goods travelling from a truck to a train to a ship were unpacked and repacked at every boundary between them, by hand, slowly, with loss and theft at each step. The truck, the train, and the ship were each built for their own kind of load and matched nothing else.

The intermodal shipping container fixed one thing and only one thing: the dimensions of the box and the fittings at its corners. It said nothing about what went inside. A container of coffee and a container of car parts look identical from the outside, so a crane does not care which it lifts. Once the box was standard, every truck bed, every rail car, every crane, and every port in the world was built to the same measurements, and any of them could carry any shipment. The repacking at each boundary disappeared.

Software had its own version of loose cargo. For decades, each language region stored text in its own character encoding. One region used one encoding, another used a different one, and a document that moved between two systems arrived as unreadable characters unless a converter existed for that exact pair. With many encodings in use, someone had to write and maintain a converter for each direction between each pair of them.

Unicode replaced the pairs with a single target. It gives every character in every writing system one number. A system implements Unicode once, and from that moment it can exchange text correctly with every other system that did the same. No per-pair converters. One implementation, and compatibility with all the rest.

Underneath both stories is a number. Take N participants who all need to work with each other. Without a shared standard, each pair has to agree on its own interface, so the number of integrations grows with the number of pairs, on the order of N times N. With ten participants, that is on the order of a hundred private arrangements. Add one more and you add ten new integrations, one against each participant already there.

With a standard, each participant implements the one shared interface and nothing else. That is N integrations in total, one per participant. Add a new participant and the cost is a single implementation matched against the standard, where before it was a negotiation with every member already present. This is the whole economic case for standardizing an interface, and it is why a standard grows more valuable as more participants adopt it.

A standard is not free. It is a constraint. It fixes decisions that an individual participant might have preferred to make differently, and it fits some uses more comfortably than others. A standard that many participants already depend on is also very slow to change, because changing it means every one of them has to move at once. The flexibility you give up is real.

This is the tradeoff from What engineering is and is not. The parent goal is compatibility across the whole ecosystem. The child goal a participant gives up is the freedom to shape its own interface exactly as it likes. Standardizing trades the child goal for the parent one. It is worth doing when compatibility across the group matters more than local control, and it is the wrong move when it does not.

Before you wire a set of components together, count the arrangements you are signing up for. If every pair needs its own adapter, the cost is quietly growing with the square of the number of participants, and each new member makes it worse. A shared interface, adopted once by each, turns that same set into a single implementation apiece. Weigh the flexibility you would give up against the integrations you would delete, and reach for the standard when the second outweighs the first.

Skip this section if you only want the principle. Decentralized finance repeated the shipping-container story almost exactly. Before 2022, every protocol that held deposits and paid a yield exposed its own deposit interface. One used a deposit call, another a mint call, another a supply call with several parameters of its own. Anyone building on top of several protocols wrote and maintained a separate adapter for each, the software equivalent of repacking cargo at every boundary. ERC-4626 defined one vault interface, built as an extension of the ERC-20 token standard rather than a replacement for it, and the per-protocol adapters fell away.

ERC8009, examined in depth in the clear signing module, makes the same move for clear signing. Hardware wallet vendors implement one interface once, rather than settling a private integration with each protocol one at a time.