In June 1720 Parliament chartered two companies and outlawed every other flotation in England. On a dead protocol's list of twenty-two ventures, and the difference between a business that needs a data feed and a business that needs a balance sheet.
On 11 June 1720 the English Parliament passed an act that did two opposite things in the same breath. It incorporated two companies by name – the Royal Exchange Assurance and the London Assurance – and it made it unlawful for anyone else to raise money as a joint stock without a charter from the Crown. The ventures being subscribed that summer in the coffee houses off Exchange Alley, and there were hundreds of them, promising fisheries and fen drainage and colonial settlement and insurance of every describable kind, lost their legal footing between one sitting and the next. Almost none were heard of again. The two named in the act wrote marine insurance for the next two centuries, and held the only joint-stock charters to write it until 1824.
The Bubble Act is usually read as a favour to the South Sea Company, which wanted its rivals cleared out of the way, and that is exactly what it was. But it also ran an experiment nobody set out to design. It took a long list of proposed ventures and kept the two where the instrument underneath was load-bearing. Marine insurance is the case where a joint stock is not decoration. No merchant can absorb the loss of a ship, and no underwriter can absorb a season of them; the business exists at all only because many people hold small pieces of a risk none of them could carry whole. Pooled capital is not how that venture gets financed. It is what the venture is made of. Most of what was suppressed that summer wanted the form for the subscriptions it attracted, and would have run – or failed – the same way inside any other wrapper.
Read a prospectus that way and it stops being a list of businesses. It becomes a list of claims about which machine each business actually needs.
There is a good one to read. Around 2019, Zap Protocol circulated a list of twenty-two ventures its technology was supposed to make possible. Zap was a bonding-curve curation market for data: a provider put a feed on a curve, buyers bought along it, and the price of access was set by the people buying rather than by a rate card. This was not vapour. CoinGecko put its market data on the curve. A coffee roaster, a social network and an energy-ledger project all attached their names to particular lines. And the lines ranged from the modest to the magnificent. Launch a DAO. Run a fundraiser. Tokenize yourself in minutes. Track a cup of coffee from bean to cup. Launch a stablecoin against a basket of currencies. Design a cryptocommodity against physical crude oil. Invest in the career of a professional athlete.
Zap supplied one thing: a channel by which a number from the world could reach a contract, and a curve to price access to that channel. A caper supplies a different thing – a treasury the holders own, a governed way of spending it, and a door out that pays a real share on the way through. Hold the list up against the second instrument, ask of each line the question Parliament asked by accident, and twenty-two ventures fall into three groups of very unequal size.
Five die on the same clause. A stablecoin tethered to a basket of currencies has to know what the basket is worth. A cryptocommodity tethered to crude has to know the price of crude. A futures product has to settle against a reference somebody else publishes. An initial oracle offering, and the line about tokenizing other networks' oracles, need there to be oracles at all. Each one turns on a number that originates outside the contract and is trusted the moment it arrives.
Nothing in a caper can learn such a number. What a caper's token costs is made entirely by the people transacting against it, and there is no channel through which the outside world can correct them. That is a commitment rather than a gap. A token whose worth can be asserted from outside is a token whose worth belongs to whoever does the asserting, and putting a treasury behind a claim is precisely an attempt to stop that being true. These lines are not almost-possible. They are the ones the design refuses.
Six more fail for reasons that have nothing to do with prices. Bean-to-cup traceability and fraud-proof gift cards both need per-item identity and, in the gift card's case, redemption – the coupon has to be extinguished at the till, or it is not a coupon. A caper's token cannot be extinguished by anyone: not the founder, not the platform, not a future version of the software. That permanence is the whole reason it is safe to hold as a claim on a treasury, and it is the same property that makes it useless as a voucher. Monetizing an API feed needs a way to deliver queries and meter them. Curating data in the registry sense needs staking, challenges and slashing on individual entries. A wrapped ERC20 needs a bridge to Ethereum. Letting a social network's users monetize their own data needs the network, the marketplace and the payment rails, of which a caper is none. In each case the missing piece is a whole subsystem, not a setting.
Then the middle band, where the instrument does the money and never the thing. Tokenized property, a stake in an athlete's career, shares in a classic car, a liquid security trading on an open market: all four raise capital, govern a treasury and let holders leave with a share, and all four leave the asset itself off the ledger. A member exiting a property caper redeems a portion of the treasury, not a portion of the building. Whether the building is really behind the token is a question for a contract written on paper and enforced in a court.
Which gives a second test inside the first, and it separates these four cleanly. Ask whether the asset is a cash flow or an object. Rent and an athlete's earnings arrive as money, and money can be deposited into a treasury that every holder already has a claim on; the on-ledger half of the arrangement does real work every month. A classic car appreciates in a garage and pays nothing at all until somebody sells it, so the caper around it is a shell waiting on a sale it has no power to compel. The security line has its own snag: a caper's token is an ordinary transferable resource, and there is no way to restrict who may hold one. It will trade anywhere. It will also trade to anyone, which is the opposite of what a regulated instrument requires.
What is left is the part of the list that never needed the data at all. Launch a DAO, run a fundraiser, tokenize yourself, run a bounty programme. These are not adaptations of a caper. They are the ordinary operation of one, and three of them are the reason it exists. A bounty is a proposal with a payment attached, so the treasury moves when the vote passes rather than when someone is asked nicely afterwards – the difference between a decision and a promise, which is its own subject.
The curation-market line is the oldest idea on the list, older than Zap, and the closest to a description of the machine. Simon de la Rouviere's 2017 proposal was that a curve could reward whoever showed up early to something that later turned out to matter, and so pay people to be right in public before it was obvious. A caper is that with a balance sheet underneath, which changes what backing something means: early conviction is no longer only a bet on the next buyer, because there is a pooled asset behind the claim and a right to leave with a share of it.
Two more repay a closer look. "Release always-liquid tokens that mint and burn autonomously" gets the demand right and the mechanism wrong, which is a common shape for a prospectus. A caper's token is always liquid: there is a counterparty that cannot walk away, so a holder never has to find someone willing to take the other side. But nothing mints and nothing burns. The supply is fixed at the moment the caper opens and no authority to change it is ever created, so what looks like issuance is a token moving between the curve and a holder. The stronger version of the promise turns out to be the one where the machine has less power, not more.
And the last line on the list – "invest in individual oracles that you think will be valuable" – survives if you delete one word. Invest in individual ventures that you think will be valuable, and a caper does it natively: one caper's treasury can hold another caper's token, and holding it is a vote inside the thing it holds. Ownership and governance are the same act, so a portfolio and an org chart become the same document. This is the one line on Zap's list that reads more ambitiously today than it did in 2019, and it is the one nobody at the time was pointing at.
Seven of twenty-two work now, four work with a legal wrapper and an honest account of where the asset actually lives, and eleven need machinery that is not there and is not coming. That is not a poor showing for a list written about a different protocol in a different decade, and it is not an argument that Zap was wrong. Almost every line on it named a real demand. Fen drainage was a real demand in 1720.
The 1720 act sorted its list by force and by favour, and got the right answer for the wrong reason: what survived was the venture whose business was pooled capital, run by an instrument for pooling capital. The rest had borrowed the form. Twenty-two ventures later, the same question does the same work. Not what a thing is worth, or who wants it, but whether the machine underneath is doing something the venture could not do without it.