Sequencing a Token Economy into a Live Product

Four stages, gated on conditions

The distinction that carries the most weight is between complete non-transferability (the token cannot change owner at all), restricted transferability (it can move, but only to addresses controlled by the system — so ownership never passes to another person), and full transferability. The middle option is the useful one, and it is routinely collapsed into the other two in discussion. It lets a token be spent without being traded.

Why this order

By the time a market exists, there is demonstrated internal demand that is not speculative — people already spend the token on things they want. And the legal position strengthens over time rather than weakening, because the token's value becomes visibly tied to consumption rather than to a company's promises about the future.

How the loop worked

The pattern that made this productive: engineering brought a mechanism, counsel identified which property created exposure, and the mechanism was revised — rather than counsel being handed a finished design and asked whether it was allowed.

The output over eighteen months was not a memo. It was a running log of design decisions where each entry records a constraint discovered and the mechanism change it forced. That artefact turned out to be more valuable than any single piece of advice in it, because it made the reasoning re-checkable when the design moved.

What the constraints actually touched

• Concentration of value. The heuristic that no token should derive the bulk of its value from one entity's efforts, applied at every level of the asset cascade. This is what produced the pooling architecture — a legal constraint that determined an economic structure.
• Money transmission. Receiving licence fees and distributing them to holders is, done naively, a regulated activity. The component had to be designed so the platform never takes custody of funds in transit — which is an architectural requirement discovered from a licensing rulebook, not from a whiteboard.
• Where value accrues determines who is taxed. Whether consumed tokens are burned, or routed to a treasury and redistributed, looks like a monetary choice. It is also the difference between a structure with no taxable income and one with reporting obligations at two levels. Burning everything automatically, with no discretion anywhere, is the simplest structure — and that has nothing to do with monetary policy.
• Governance scope defines liability scope. The more the token holders control, the more the legal wrapper has to cover. Keeping economic parameters outside governance — fixed schedules, immutable contracts, narrow affordances — reduces exposure. This cuts directly against the instinct to make everything governable, and it is the sharpest tension in the whole design.
• Rewards may be taxable before they are liquid. If points are redeemable for something of value, the moment of award may be a taxable event for the recipient — with the platform potentially owing reporting. Deferring the taxable moment is a design objective that shapes the conversion mechanism.
• Vesting and lockup are different instruments. Vesting is earning; lockup restricts selling. Different stakeholder classes need different combinations, and conflating them produces terms that make no sense for at least one class.

The generalisable lesson

Every one of those is a case where a legal constraint determined a technical structure. Not "we built it and then checked" — the constraint was upstream of the architecture.

Teams routinely treat regulatory exposure as a wrapper applied after the mechanism is settled. In a consumer-facing token system it is a design input of the same weight as the incentive properties, and discovering it late means rebuilding.

The exercise

Enumerate every point in the deployed system where one party can act unilaterally. For each, write down what actually replacing it requires. It takes an afternoon.

It is uncomfortable, because the answers span an enormous range. Some are a modifier and a redeployment: a gated mint that exists to stop spam can be opened to everyone the moment there is an alternative anti-spam cost, such as requiring the system's own token to publish.

Others are not. Where a privileged account computes an off-chain result that the contracts then trust — a revenue distribution table, say — decentralising it means designing a whole separate protocol with its own incentives, probably slashing, and an economically sound reason for anyone to do the computation honestly. That is a research project, and it only works once there is enough volume to fund it.

A third category is governance over upgradeability itself: if every contract is upgradeable through a multisig, then every other decentralisation claim is conditional on that multisig.

Why the distinction is the whole point

When I ran this, some items had no clean answer and I said so internally rather than letting them sit on a roadmap as though they were scheduled. Being explicit that certain centralisation points would still exist at launch was more useful than a plan that implied otherwise, and it changed what stage 4 could honestly be gated on.

Custody has a months-long lead time and a semantic cost

Institutional custodians hold assets that behave like ERC-20s. But redeeming a token for a system utility changes a balance without a transfer, which is exactly the kind of deviation that makes an asset unholdable.

Reconciling utility redemption with strict ERC-20 compliance was a genuine constraint on the mechanism, not an integration detail. Custody integration also has a lead time measured in months and depends on the token design being frozen — so it has to be planned before the design feels finished.

Account abstraction is an architectural commitment

The platform initially routed user transactions through its own backend. Expedient, and both a centralisation point and an operational liability. Moving to ERC-4337 so gas could be sponsored and users could transact directly meant retrofitting an account implementation designed before the standard existed, for a different purpose.

Choosing an account model is choosing your future integration surface. It is very expensive to revisit, and the cost is invisible at the point where the choice is made.

Multi-contract flows need bundling

Approve-and-spend, register-and-purchase: several flows were unusable as separate transactions and required multicall support at the account level. Sequencing problems like this never appear in the mechanism design. They appear when someone tries to use the thing.