Tokenising an asset nobody has tokenised before

Every tokenisation project starts with the same meeting. Someone describes the asset, someone else describes the token, and for twenty minutes everybody agrees. The difficulty arrives with a plain question. What does a holder actually own, and who would be obliged to hand it over.

We built the CRBT token and platform for Cruisebit on Ethereum smart contracts, aimed at travel payment settlement, which normally runs through a long chain of intermediaries with each one adding delay and cost. Moving value is the well-understood half of this field. The harder request, and the one that follows within about a year in most client relationships, is to tokenise the thing being paid for.

The ledger records the token. The law creates the obligation.

A chain can prove who holds a token and when it moved. On its own it compels nobody to release a cabin, a berth, a consignment or a square metre of anything. The obligation comes from a contract, a registry entry, a licence or a title, all of which sit outside the ledger and are enforced by institutions that have never heard of it. Tokenising a physical asset means building a durable mapping between an on-chain record and an off-chain right, and that mapping is where the engineering actually is.

So the first deliverable is a sentence. The token represents this specific interest, created by this specific instrument, enforceable against this specific party. If nobody in the room can write that sentence, what is being built is a database with unusual hosting arrangements, and saying so early saves a great deal of money.

The questions that decide the architecture

These four come up in every engagement, and answering them late means retrofitting a contract that is already deployed.

• Who holds the underlying asset while the token circulates, and what happens to holders if that custodian fails.
• Which record wins when the ledger and the legal register disagree, and what the process is for bringing them back into line.
• Who can freeze, burn or reissue a token, under whose authority, and how that power is logged and reviewed afterwards.
• What identity and eligibility checks attach to a holder, and whether those checks have to travel with the token when it transfers.

Each answer becomes either a contract function or an operational procedure with a named owner. The transferability question tends to arrive last and change the most, because a token that can only move between checked holders is a different system from one anybody can receive.

The failure is pretending the law changed

Documents in this sector have a habit of asserting that an obligation exists because a token exists. We wrote the technical whitepaper for Cruisebit alongside the engineering, which turns out to be a useful discipline. If a claim in the document cannot be traced to a function in the code or a clause in an agreement, the claim comes out of the document.

Auditors, custodians and regulators ask these questions in their own vocabulary, and they ask them eventually. The designs that survive that conversation are the ones where the on-chain record and the off-chain right were deliberately kept in agreement, with a written procedure for the day they diverge. They will diverge. Somebody sells the asset by conventional means, a court orders something, a custodian goes into administration.

On every token platform we have taken into production, the code was the shortest item on the schedule. The long item was getting lawyers, custodians and the client's finance function, people who do not normally share a room, to agree on one sentence describing what the holder owns. That sentence is the specification. Everything after it is implementation.