The Chain logo

Shane Ian Murphy on Triparty Tokenisation: An Update Should Explain What Changed

A founder’s perspective on version history, participant notices and the difference between correction and amendment.

By Shane MurphyPublished 4 days ago • 3 min read

An updated document can be a small administrative event for its author and a significant event for the person relying on it. That difference matters in tokenisation. As cofounder of Triparty Tokenisation, I want changes to information, operating processes and governing arrangements to be understandable to the people affected. A new version number is useful, but it does not explain the change by itself. Participants need a practical answer to what changed, why it changed and what, if anything, they need to do.

My starting point is to distinguish kinds of change. Correcting a spelling error is different from changing a payment timetable, replacing a service provider or proposing an amendment to a participant’s rights. Those events should not travel through an identical process merely because they can all be described as updates. I would want a classification that connects the substance of the change to the required authority, review and communication. The classification should be simple enough for people to apply consistently.

There is also a distinction between a correction and a new agreement. If a record inaccurately describes an existing arrangement, correcting that record is one task. If the arrangement itself is changing, the question of authority and any required consent becomes central. I would not want the ease of editing digital information to blur that boundary. Software can make a change quick to publish, but speed does not establish that the change was authorised or that affected participants accepted it.

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 am setting out my own founder perspective on the operating standards I would like us to pursue. The discussion describes proposed principles, not a certification of a live process. That distinction is especially relevant to versioning, where readers should be able to tell whether they are seeing an aspiration, an operating instruction or a governing document.

A useful change record would make comparison possible without asking every reader to perform a forensic exercise. I would favour a short explanation of the affected section, the reason for the change and its intended effective date. The earlier version should remain identifiable where appropriate, subject to relevant retention and privacy requirements. Otherwise, someone reviewing a past decision may unknowingly read today’s text and assume it was the text available when the decision was made. That can distort an otherwise careful review.

Timing needs attention as well. A document can be published before it takes effect, while a participant may receive a notice after publication. Those are distinct events. I would want important records to make the difference visible, particularly when a change requires action within a defined period. Delivery also deserves thought: making information available is not always equivalent to drawing it to the attention of the person who needs it. The communication method should fit the significance of the change.

Software changes raise related questions. A new interface might leave the underlying arrangement untouched, while a change to a calculation or transfer rule could have much greater significance. I would ask the team to describe the effect in operational language before presenting the release as an improvement. Testing should focus on the behaviour that matters to participants, and the release record should help explain unexpected results. Calling something an upgrade should never substitute for explaining its consequences in the particular context.

To me, a good update leaves a reader with less uncertainty. That is the standard I want to encourage at Triparty Tokenisation. Clear version history helps people connect decisions to the information available at the time, and clear notices help them respond to what comes next. Both depend on thoughtful ownership of the process. The digital tools support that work when we define it properly. Find company information at https://www.tripartytokenisation.com/ . My background and further writing are at https://shanemurphy.co.uk/ .

tokens

About the Creator

Shane Murphy

Shane Ian Murphy: co-founder/partner, Tri-Party Tokenisation; founder/CEO, Global Secure Technologies (planned 2027 launch); co-founder/partner, Dual Party Capital. Partner, RougeN International Corp. Formerly of Limitless Mobile.

Enjoyed the story? Support the Creator.

Subscribe for free to receive all their stories in your feed.

Subscribe For Free

Reader insights

Comments

There are no comments for this story

Be the first to respond and start the conversation.

Sign in to comment
    Written by Shane Murphy