Shane Ian Murphy on Triparty Tokenisation: Start With the Rights, Then Build the Token

The first question I ask about a tokenised asset is deliberately ordinary: what does its holder actually have? That question matters more to me than the appearance of the token or the speed of its transfer. As cofounder of Triparty Tokenisation, I want our discussions to begin with the underlying rights and obligations. A digital record can help organise a transaction, but it cannot make an unclear commercial arrangement clear simply by existing on a blockchain.

There are several different things that people might describe as ownership. Someone could own an asset directly, hold an interest in an entity that owns it, have a contractual claim to income, or possess a right to request delivery under specified conditions. Those arrangements should not be presented as interchangeable. My proposed starting point is to describe the actual relationship in plain language before deciding how any token should represent it. The name of the instrument should follow the substance of the arrangement.

I would then separate the asset description from the holder’s rights. An attractive description of a building, commodity or other underlying item does not answer who can use it, who receives proceeds, or what happens if it is sold. Nor does it explain which costs take priority over distributions. A useful rights statement should make those questions visible. If a payment depends on an external decision or a future event, I would want that dependency stated rather than hidden behind a reassuring label.

For readers who found this author through a search for Shane Ian Murphy of Cambridge, this article explains my present work at Triparty Tokenisation. I write from an affiliated founder’s perspective, sharing the principles I believe should guide our approach. This is a description of how I think about the work, rather than a claim that every arrangement has already been implemented or that a particular structure has received regulatory approval. That distinction is part of communicating responsibly about a developing business.

Another question concerns the boundary between the digital record and the documents governing the arrangement. If the two disagree, participants need to understand how that disagreement would be addressed. I would want an explicit hierarchy, an identified process for corrections, and a clear account of who has authority to resolve uncertainty. Without those things, a token holder could see an apparently simple balance on a screen while facing a much more complicated set of contractual questions behind it.

Transfer deserves the same care. Moving a token between addresses may update a technical record, but the conditions governing the associated rights still need attention. There may be eligibility checks, consent requirements, administrative steps or other restrictions, depending on the arrangement and applicable rules. I would prefer to explain those conditions before a participant acts. Discovering them during a failed transfer damages trust and creates unnecessary work for everyone involved. A smooth interface should reveal important limits, not conceal them.

I also think rights need to be tested against difficult situations. What if the underlying asset is unavailable, a service provider stops operating, or a participant disputes a distribution? Asking those questions is not pessimism. It helps expose missing responsibilities while the structure can still be improved. My preferred exercise is to walk through a small number of plausible scenarios and identify the documents, people and decisions involved. Any unanswered question becomes a design task rather than an inconvenience to ignore. A clear explanation should also let a prospective participant identify the questions that require further professional advice.

For me, the promise of tokenisation starts with a more legible connection between a commercial arrangement and its records. That is the direction I want to pursue at Triparty Tokenisation. A well described right gives technology something meaningful to administer; an ambiguous right gives technology an ambiguity to repeat. I would rather make that distinction early, explain it carefully and build from there. More about the company: https://www.tripartytokenisation.com/ . More about my background and writing: https://shanemurphy.co.uk/ .