Skip to main content

Advance Token Operations

It can get pretty restrictive to transfer individual batches of TRST tokens one by one because of how each TRST token is different from the rest. For that, we can have a merging and splitting mechanism that can solve the issue regarding the need for variable amounts of transactions.

Splitting TRST

Splitting is the default way of transfer since the TRST tokens will just have the same epoch and link on all of the splits; only the amount will vary.



If you can see in this example:

splitting

The 50 BRN that got burnt, can only ever transact in 50 TRST or less, and any kind of transfer will involve splitting of that 50 TRST into smaller amounts that add upto 50 TRST.

This is pretty straightforward as all of the transactions in this graph will only have one burn transaction.



Hence, all of the tokens can be orphaned simultaneously when the expiry date for them has been reached, or if the wallet is found to be illegitimate.

splitting



Merging TRST

Merging is a bit tricky since the epoch determines the expiry date and originator of the TRST tokens, and not all the merged TRST tokens will have the same epoch.



So, what we can do is make it so that the expiry date for the newly merged TRST token to always be the same as the one that will expire the fastest, among the merged tokens.

splitting

­

splitting

For example, here we merge TRST with similar time till expiry into one TRST token, and the time till expiry for this token is set to the one that will expire the fastest, i.e. 140 days.

This will allow the people to self-organize and merge their TRST tokens in a way that groups TRST tokens of similar expiry dates into one TRST token, which increases its time till expiry, which in turn can retain its value.



The merged tokens will always point to the merge transaction as their epoch, in future transactions. They will act the same way as unmerged TRST, the only difference is that their epoch is now the hash of the merge transaction.

splitting

What will happen in case an illegitimate TRST got merged?

In that case, after the wallet has been determined to be illegitimate, the nodes will unverify the wallet, and inform all other nodes to mark all the TRST tokens originating from that wallet as orphaned, immediately. This also implies that the merged tokens should also get orphaned in a sensible way.



A simple method for doing that would be as shown in the diagram.

splitting

Here, 10 of the illegitimate TRST was merged to make 50 merged TRST. After the nodes unverify the wallet, the nodes will start the process of splitting all the merge transaction associated with that wallet, in a way that makes all of the current holders of the merged tokens lose some of the TRST in the same ratio as everybody else. The total amount that will be split and made untransferrable, will equal to the amount of illegitimate TRST that was merged.



General

So, this is one of the general formula for splitting the merged TRST into transferable and untransferrable ones without being unfair.

splitting



Additional

There can be something like a "merger graph" that can be stored by the nodes that will link every merge transaction with the epoch of the merged tokens, or the previous merge transactions it was derived from.

This way, the split will be performed easily, as there is no room for ambiguity when it comes to the originator and the current state of all the tokens.