WO2021250046A1 - Computer implemented methods and systems - Google Patents

Abstract

Disclosed embodiments provide methods and systems for generating, verifying and transferring fungible tokens over a blockchain network e.g. Bitcoin. Each token is uniquely identifiable in some way and has a pre-defined value (denomination) that is specified upon creation. This token value does not change during use and remains unsplit regardless of the number of times that it is transferred. Each token is issued (minted) by an authorised Issuer using an unspent transaction output UTXO in a minting transaction that is published on the blockchain. In addition to generating the token(s) the minting transaction provides an efficient mechanism for token verification.

Description

Computer Implemented Methods and Systems

Field

This disclosure relates generally to methods and systems for electronic exchange between parties. Embodiments utilise, at least in part, a distributed ledger (blockchain) to facilitate the secure and efficient transfer of control of a tokenised resource from one party to another. The disclosure is particularly suited, but not limited, to use in respect of the distribution of tokenised assets across a computing network. Verification of these tokenised assets is improved, enhancing security and reducing vulnerability to transfers and exploits by unauthorised parties. Embodiments enable the implementation of improved digital wallets which are able to exchange data in new and technically advantageous ways.

Background

The Bitcoin blockchain ledger as introduced in 2008 by Satoshi Nakamoto’s whitepaper (https://hitcoin.org/bitcoin.pdf) is the most widely known blockchain and associated network/platform in use today. Therefore, we will refer to Bitcoin in the examples used herein. However, embodiments of the disclosure are not limited in this regard and alternative blockchain protocols and implementations fall within the scope of the present disclosure.

A blockchain transaction is a data structure formed in accordance with a blockchain protocol and comprises at least one input and at least one output. Control of the cryptocurrency that is digested/received by the input(s) is spent/transferred from the output(s) of the transaction to the input(s) of further transaction(s) that are added to the blockchain in subsequently mined block(s). Any portion of the cryptocurrency that is not transferred to a new receiving address/owner/receiver is sent back to the current address/owner/sender as “change”. Inputs and outputs are ordered and numbered within their respective transactions so that they can be referenced. In the case of outputs, they form a zero-indexed Vector (list) based on their position within the transaction’s outputs. An output’s index number is known as its “Vout” index. With respect to inputs, each input in a transaction is identifiable by the transaction identifier (TxID) and the Vout of the output that it will spend. The inputs in a given transaction are also listed in a zero- indexed Vector, this time known as “Vin”. In this way, each input references an identifiable output in a previous transaction on the ledger, thus creating a chain so that the immutable transfer history of each cryptocurrency unit can be verified by traversing the blockchain back to the unit’s originating source. In the Bitcoin protocol, this could be a coinbase transaction in which the cryptocurrency was created by a miner as a reward for Proof-of-Work effort, or the very first block of the ledger which is usually known as the Genesis block.

Although it has gained publicity as a means of transferring cryptocurrency, the wider applicability of blockchain technology is somewhat analogous to the way that the Internet provides an underpinning support layer for many distributed services, communications and data sharing technologies. In the same way as the Internet forms the backbone of many more computer-implemented solutions beyond just the provision of web pages, blockchain platforms can provide the underlying mechanism that enables much more than just the transfer of cryptocurrency. For example, blockchain transactions can be used to transfer other types of data in addition to digital money, thus driving technologies across a wide spectrum of industries and applications. This additional data is often referred to as “metadata” and could potentially comprise any type or format of data, such as text, media content, images, links to off-chain locations or resources, executable code, smart contracts, hashes of such data etc.. The ability to transfer data, plus blockchain-implemented technologies such as smart contracts, the Metanet, Simplified Payment Verification (SPV) and more, have resulted in the use of blockchain platforms as an underlying infrastructure or vehicle that other “layer 2” technologies can be built upon.

These include layer 2 tokenisation solutions which use the blockchain as an underlying transfer mechanism for communication of electronic tokens. A token is a digital object or item that is used to represent some other object or resource, physical or otherwise. Blockchain tokenisation technologies provide numerous technical advantages such as improved security, efficiency, ease of use and enhanced network privacy. However, known tokenisation approaches also face numerous technical challenges. These include, but are not limited to, the following problems. Firstly, current token solutions require some type of third party infrastructure to handle authorisation of actions and verification of the token’s authenticity. Such infrastructures can be costly in terms to develop and operate, both financially and in terms of required computing resources and time and, therefore, can be inefficient. They can also require the use of trusted third parties which, in turn, can lead to security concerns and increased potential for attacks, exploits and breaches. Moreover, wallet integration can be a significant challenge as the process is often complex and time consuming. Other challenges include, but are not limited to, concerns over the scalability of tokenisation solutions, concerns surrounding privacy for users and therefore potential for targeted exploits, the need for off-chain token processing or transfer which means that such solutions are not fully cryptographically enforced and immutably verifiable on a public ledger, or require that the user inserts data into a script in order to process the tokens. Moreover, some tokenisation schemes lend themselves only to handling of certain types of tokens, which means they are restricted with regard to wider applicability and cannot be extended or adapted for use in a more diverse, potentially desirable implementations. These, and other challenges faced by current blockchain-implemented tokenisation schemes, are not trivial to address.

Summary

Embodiments of the present disclosure provide techniques, protocols and systems for creating, using, processing, and transferring tokenised assets or resources via a blockchain (ledger) that is associated with a blockchain protocol and network. This may be, for example, a version of the Bitcoin protocol and its associated network and platform but other blockchain protocols and implementations may be used and fall within the scope of the present disclosure.

Embodiments of the disclosure comprise a system wherein one or more tokens are generated via the use of an issuing or “minting” transaction. A token may, in the alternative, be considered as a “digital object” and may provide an on-blockchain representation of some tokenised resource or units thereof. The minting transaction comprises issuance data which testifies to the issuer’s identity and/or authority to issue the tokens, and serves as a verification means during transfer and processing of the tokens in subsequent use. The minting transaction also comprises one or more outputs (UTXOs), each of which represents a token. In turn, each token represents a quantity of tokenised asset or resource of some type. In some cases, the tokenised asset/resource may be expressed as a quantity of unit(s). The tokenised resource can take any form. For example, it can be a digital or virtual asset, an abstract entity or a physical entity. The token’s pre-determined quantity of resource units is specified when the token is minted and during use the protocol requires that this quantity of tokenised resource units remains fixed i.e. immutable or unchanging in some respect despite their transfer over the blockchain. For the sake of convenience, the terms “token value” or “denomination” may be used interchangeably herein with “quantity of tokenised resource” or “token units”. According to the disclosure, the token is represented by a fixed quantity of cryptocurrency units (e.g. Satoshis or some other type of cryptocurrency) held in the locking script of a UTXO that has a linear history linking it to the token’s creation in a minting transaction via the ledger.

When the token is to be transferred from one party to another, a solution for the locking script plus a reference to the UTXO holding the token are used as an input in a new transaction which spends the token-holding UTXO to a new locking script specified by the receiving party. As is known in the art, spending of a UTXO requires the transfer of control of a quantity of cryptocurrency from one address to another, and so transfer of the token is performed upon spending of an underlying portion of cryptocurrency. In some embodiments, the issuance data and/or other data is also transferred along with the token and cryptocurrency.

In the preferred embodiment, when the token is transferred, the UTXO holding the token is used as an input to the transaction and a quantity of cryptocurrency tokens must be spent into an output with the same index as the input for the token transfer to be valid. In this way, ownership of the token is passed to the new UTXO’s controlling party. This method has the benefit of being easily traceable on the public ledger due to the matching indices of input and output (Vin and Vout) in each transaction, resulting in improved speed and efficiency when validating the provenance of the token. Flowever, in other embodiments the transfer of the token can be performed through the linking of the input containing the token to an output of the transaction through other mechanisms such as, for example, a signature or identifier placed into the locking script of the new UTXO that holds the token.

Irrespective of the particular linking technique used, though, a token used and arranged in accordance with embodiments of the disclosure can be described as having a linear transaction history when that token has a complete history of being transferred without there being any change to the originally ascribed token value applied in the minting transaction. This means that the token is always transferred wholly into a single, separate and unique UTXO without having its token value split, merged, duplicated or modified in any way. This means that the transaction history of a token can be represented as a series of linear actions in which each action transfers the token in the same form in which it was created in the minting transaction. Because of this, in most embodiments of the disclosure the overhead required to manage token transfers is very low, and can be applied in a way that pushes the transfer governance process down onto the nodes of the Bitcoin network to manage as part of their role in transaction validation. Each time a token is transferred, its identity and authenticity as a token in accordance with the protocol can be verified. As the token’s transaction history is linear and the tokenised resource units (TU) represented by the token (T) is not split or altered during transfer, this can be performed quickly and efficiently. The blockchain record can be provably traversed until the minting transaction is reached, as illustrated in Figure 8. The issuance data and/or minting record associated with the minting transaction can be checked to ensure that the token is a genuine, authorised token in accordance with an embodiment of the present disclosure. Known techniques and technologies such as Simplified Payment Verification (SPV), Metanet graphs etc can be used in conjunction with one or more embodiments to further enhance efficiency and speed of verification or transfer, while preserving security.

Brief Description of the Drawings

Aspects and embodiments of the present disclosure will now be described, by way of example only, and with reference to the accompany drawings, in which:

Figure 1 is a flowchart illustrating steps in a preferred embodiment of the disclosure.

Figures 2 and 3 shows illustrative embodiments in accordance with the present disclosure, some of which utilise an intermediary register and some which do not.

Figure 4 shows the Inputs and Outputs of a Token transfer transaction (TTTx), in which tokens go into and out of the same VOUT index in the same blockchain transaction and retain their exact token; moreover, tokens that are sent into a wallet in respect of a given exchange or transaction may not (in fact, most likely will not) be the same tokens that will be sent for onward transfer to a recipient.

Figure 5 further illustrates the TTTx of Figure 4, and how individual tokens having various token values can be transferred via numerous blockchain transactions but retain their exact same token units and are not split/recombined. This illustrates the fungible nature of tokens formed in accordance with the present disclosure.

Figures 6 and 7 illustrate embodiments of the disclosure in use.

Figure 8 shows an overview of a validation process which may be used in accordance with an embodiment of the disclosure

Figure 9 illustrates a logical sub-ledger of associated tokens issued by the same issuer and implemented on a blockchain ledger e.g. the Bitcoin blockchain. Such a logical sub-ledger may be referred to as a Token Fedger.

Figure 10 illustrates an arrangement in which a change component or service provides users with change for denominated tokens when needed . This enables users to exchange tokens for others with different token units.

Figure 11 illustrates an embodiment of a Minting transaction where the source of the issuer authority is from public keys held in a UTXO not otherwise tied to the minting transaction. Validation is performed by checking that the signatures in the minting action validly use the public keys tied to the identities of the issuer authorities in the referenced transaction. Figure 12 illustrates an embodiment of a Minting transaction where the source of the issuer authority is derived from control of a token or Issuer Certificate. Validation is performed by tracing the history of the issuer certificate back to the Token Ledger establishment transaction.

Figure 13 illustrates a process that involves a sender and receiver creating a blockchain transaction, and comprises steps taken by the receiver to use a 3rd party service to validate the tokens.

Figure 14 illustrates a multiparty group blockchain transaction of the type a third token processing party can use to obfuscate the parties to a transaction by grouping many smaller exchanges into one large transaction. This is done using SIGHASH_SINGLE | SIGHASH_ANYONECANSPEND on all tokens being spent, which locks each input/output pair but allows the processing party to have the freedom to stack them into a single large transaction, or even to break them out into multiple separate transactions.

Figure 15 illustrates two separate blockchain transactions being paid via a register and showing that the register holds the funds for the users, and the user only provides the register with a signature. Signatures are signed using SIGHASH_NONE | SIGHASH_ANYONECANPAY as the output destination is not determined at the time the tokens are signed. The register then takes other, separate tokens that have been pre-signed by other register users and spends them out to the fund recipients in a group transaction.

Figure 16 illustrates a process by which physical tokens with specific details regarding their serial number and value can be destroyed and re-issued as digital items that carry the serial number and value of the original note into the token ledger.

Figure 17 illustrates a process by which a digital token with a unique identifier e.g. serial number and token value can be locked into a script controlled by an issuer who can then create physical representations of the digital tokens. These can be verifiably linked to the digital token, and then destroyed by depositing them back into a register controlled by or associated with the issuer and removing the digital token from the locking script.

Figure 18 illustrates the use of a blockchain transaction to melt i.e. destroy a token formed in accordance with an embodiment of the present disclosure.

Figure 19 illustrates the use of a blockchain transaction to re-mint i.e. re-issue a token formed in accordance with an embodiment of the present disclosure.

Figure 20 shows an establishment transaction which spends a UTXO into an issuer certificate which contains the identities and digital signatures of the Issuer’s authorised representative(s).

Figure 21 shows an establishment transaction that generates a root node that contains the signatures and digital signatures of the Issuer’s authorised representative(s).

Figure 22 shows an illustration of an embodiment of an example use case which implements a voting process as described below.

Figure 23 shows a sub-ledger which is formed as a subset of a token ledger in acordance with one or more embodiments.

Detailed Description of Illustrative Embodiments of the Disclosure

Examples of some possible embodiments and use cases are now provided for the purpose of illustration, without limitation. As explained above, for the sake of convenience only, we will refer herein to “Bitcoin” for our examples as it is the most well-known and widely used blockchain protocol. Preferred embodiments of the disclosure may be implemented on the Bitcoin protocol, platform and ledger, although this and the references to Bitcoin are not intended to be limiting and the scope of embodiments of the present disclosure is not thus restricted.

The Establishment Transaction

One or more embodiments of the disclosure may involve the use of an Establishment Transaction (ETx). An example of an ETx in use is shown in Figures 9 and 23. The ETx’s function is to provide the necessary authorisation data and record from which the issuer will derive their authority and which then enables issuer-performed actions such as minting to be carried out. As illustrated in Figure 9, a single ETx can be used in the creation of more than one Minting Transaction for a given token ledger. The Establishment transaction different from the minting transaction in that it is a single event that marks the first action within a Token Ledger whereas an MTx is subsequent to the ETx and represents the act of creating the tokens which will be transacted within the Token Ledger. It is the linear history that can link every token in the token ledger back to a specific Minting Transaction and every minting transaction back to the authority created in the Establishment Transaction that gives the disclosure some of its most important properties including low overhead, simple traceability and unique yet fungible tokens.

The establishment transaction in the preferred embodiment includes at least one input whose script is signed by all relevant, participating parties and comprises at least one output that becomes an issuer certificate for the Token Ledger. This is shown in Figure 20. In this embodiment, issuer certificates are each represented by a UTXO held in a script controlled by an authorised representative of the issuer which allows for the underlying cryptocurrency tokens to be transferred. Each time the issuer performs an action such as the minting of tokens the UTXO that holds the certificate is used as an input to the transaction that performs the action and the certificate is transferred into a new UTXO that is an output of that transaction. In this way the certificate can be re-used an unlimited number of times and retains a linear history back to the token ledger’s establishment transaction.

Another embodiment comprises an Establishment Transaction which creates a root node using data carried in an output script (In the context of the present disclosure we are using the term ‘node’ as a way to describe a node in a graph or tree of blockchain transactions rather than computers within a network). Examples of root nodes being used can be seen in Figure 11, 18, 19 and 21. In this embodiment, the root node contains details that can be used to establish the identity of the issuer, their representatives and the requirements that must be met for those representatives to generate valid issuer transactions within the token ledger. In this embodiment, issuer actions such as the minting of tokens are performed by an issuer or their authorised representative (s) applying their digital signatures to the transactions in a way that can be both detected and verified by users of the token ledger.

Another embodiment establishes a root node using the Metanet Protocol as known in the art (see https://wiki.bitcoinsv.io/index.php/Metanet_ProtocoI) and uses Metanet children of the Root Node to mark issuer-related transactions such as minting transactions. The nature of the requirements can be agreed by participating parties and signed prior to publishing the establishment transaction to the network. In a different embodiment, data such as text of the agreement can be transcribed directly into the root node as ASCII or JSON formatted text, as an embedded file in an acceptable format (e.g. PDF), stored prior in a separate transaction that is referenced within the Root Node, or held in a document that is stored offline and validated by signing parties using a document hash or other knowledge proof which is stored in the Root Node. Other types of data and insertion mechanisms can also be used.

In one or more embodiments, the UTXO that is used as the input to the establishment transaction must be created and committed to the ledger before the agreement is signed. This action can be performed by one of the participating parties, or by a third party with knowledge of the requirements of the establishment transaction’s input script.

The establishment transaction input can be structured using Bitcoin script to enable the participants to choose a multiplicity of outcomes.

Example: Simple contract

DEPTH 2 EQUAL IF

2 <customer_pubkey> <contractor_pubkey> 2 CHECKMULTISIG RETURN <accepted>

ELSE

DUP <customer_pubkey> CHECKSIG IF

TRUE RETURN <rejected_by_customer>

ELSE

<contractor_pubkey> CHECKSIG RETURN <rejected_by_contractor>

ENDIF

ENDIF

This script allows for parties to negotiate on the outcome prior to accepting the agreement, and for either party to reject the agreement, ending the negotiation process. The selection of an outcome is provable on-chain.

The Issuing (Minting) Transaction

In accordance with one aspect of the disclosure, one or more blockchain-implemented tokens (Ts) are created by an issuing source (“Issuer”) via a blockchain transaction which we will, for the sake of convenience, refer to as a “minting transaction” (MTx) or “issuance transaction” because its submission to the blockchain mints i.e. generates/issues/creates new tokens which can be subsequently transferred on- chain between parties. Figures 11 and 12 provide illustrations of how a Minting transaction can be used to generate tokens.

Once minted, these tokens can be provided to users for onward transfer. We may refer to this as putting the tokens into “circulation”, because they can be shared and exchanged between parties who have wallets that arranged to operate in accordance with the present disclosure.

As illustrated in Figure 9, and discussed in more detail below, once a minting transaction puts tokens into circulation, they form a sub-ledger on the underlying blockchain in that they reside and are recorded on the blockchain as per traditional UTXOs, and are transferred from one transaction to another in the usual way. However, the tokens carried by the UTXOs are logically linked or associated with each other due to their common issuer and/or minting transaction. It should be noted that an issuer may use more than one Minting Transaction to generate tokens of a particular type. Conversely, a single minting transaction can be used to generate tokens of different types. Herein we will use the term “token ledger” to refer to a set (sub-ledger) of tokens residing on the blockchain and logically linked or associated by virtue of their common minting source.

As per traditional blockchain transactions, the Minting Transaction comprises input(s) and output(s) as detailed below. In this way, a given blockchain (e.g. Bitcoin SV) may provide the foundation layer for one or more token ledgers. Each token ledger may manage its own set of unique tokenised resources (digital objects). Each token ledger is spawned by and traceable on-chain to an establishment transaction or root node. This is advantageous because it enables an organisation to utilise the attributes (security etc) of an existing blockchain. By creating such a layer on top of an underlying, public blockchain, an issuer is able to mint tokens onto a sub-ledger with minimal complexity or resource requirements, and then observe that transfers have been performed. However, privacy for parties to the transfer is preserved in the same way as per a fiat cash transaction.

Minting Transaction MTx Inputs:

In accordance with certain embodiments of the present disclosure, the minting transaction digests a quantity of cryptocurrency (C) and also a portion of issuance data (IData) via one or more transaction inputs. In one or more embodiments, these are received into the Minting Transaction via the same input, while in others they are provided via separate inputs. In some embodiments, however, the only input may be a transaction input that provides the cryptocurrency units required for the creation of the token(s). In such an embodiment, the Minting Transaction has issuance data in an output but not in an input.

The issuance data comprises one or more portions of data that attests and/or relates to the Issuer (TI) of the token(s), and/or the Issuer’s authority to issue them. This issuance data could be referred to, in the alternative, as an “authority token” or “certificate”. The term “certificate” may be used herein for convenience. The certificate functions as a means for maintaining and controlling the flow of issued tokens into and subsequently over the token ledger.

The incoming quantity of cryptocurrency (C) e.g. Bitcoin, is received into the Minting Transaction from a previous transaction on the blockchain. It is used by the Minting Transaction to generate the underlying, supporting transfer mechanism or vehicle which, after minting, enables control of the token(s) to be transferred from the sender to a receiver. If more than one token (T) is to be minted in a given minting transaction, the quantity of cryptocurrency will be split into sub-quantities at least some of which are allocated to respective Tokens. In this way, the quantity of cryptocurrency may be thought of as analogous to a print media or coinage in the field of traditional minting techniques, in which a portion of raw material is supplied to a coin stamper for processing into smaller, individual portions (coins) each comprising a sub portion of the original coinage material and thus its own associated, intrinsic value. The Issuer can impose any desired restrictions on the usage of the tokens via the minting transaction. This can be achieved via the use of a smart contract, for example. Advantageously, the Issuer’s ownership rights and usage control can be managed and preserved via the underlying blockchain network and its protocol. The token ledger may be created via a transaction which comprises a (smart) contract or a pointer to a contract that is recorded on the blockchain and which is referenced when new tokens are minted. Authorised signatories related to the Issuer may cryptographically sign the certificate/issuance data/node to provide a verifiable record of authorisation.

Minting Transaction (MTx) Outputs:

The minting transaction also comprises a plurality of unspent transaction outputs (UTXOs).

In a preferred embodiment, at least one of the UTXOs provides, comprises or is associated with the certificate. The certificate is the means by which the Issuer’s authorisation to issue the tokens is injected into the system. It is also the means by which authenticity of the tokens can be verified in subsequent use, after minting.

The certificate can comprise any type, format or content of data that is required for the purposes of the particular implementation.

In some embodiments, the Certificate could be passed to an output from an input with the same VOUT/VIN indices. In some embodiments the Certificate exists in a UTXO which is not spent in the issuance transaction and identifying details (e.g. transaction ID, Vout index, public key or keys) are reproduced within the minting transactions and used in to create digital signatures to link the minting transaction to the token issuer (TI).

In some embodiments the certificate may be a public key or other knowledge proof which is provably linked to the issuer through means external to the blockchain database and which are used to generate digital signatures to link the minting transaction to the issuer.

However, in a preferred embodiment, neither the certificate (IData) or minting record (MR) are used in the token transfer itself, and there is no authorisation certificate required for subsequent transfers once tokens are minted. Thus, the minting information is used in the minting and subsequent verification processes, but not for token transfer purposes. As minting information is not attached to, or carried forward by, the transfer transactions a user is required to verify the authenticity of a particular token by tracing its history back to the minting transaction and checking the information from there. This provides the technical advantage that authenticity and verification of source can be assured, and security of tokens improved, because if minting/issuer related information was carried forward with the token on each exchange a malicious third party could exploit that to counterfeit the token. Although this requires the user’ s wallet to expend some resources to perform the check, the linear transaction history and techniques such as SPV keep that overhead to a minimum. In some ways, the need for this check is analogous to the sort of checks performed by merchants when they are handed a hank note from a customer. If, for example, a merchant chooses not to check that a customer’s £50 note was genuinely issued by the Rank of England and not a forgery, they take the risk of receiving a counterfeit token. Therefore, most merchants would opt to make a small amount of effort to verify the authenticity of the hank note e.g. checking the note’s serial number or holding it up to the light to look for a watermark etc.

Additionally, in some embodiments, the same or at least one different UTXO provides, comprises or is associated with token generation data, which we may refer to herein as a “minting record” (MR). In such embodiments, the minting record may comprise data that relates to the token(s) that are issued by the minting transaction. This may include a list of all tokens created by the minting transaction and/or any desired data relating to those new tokens such as details of the tokenised assets that they represent, the amount of cryptocurrency associated with each token, a unique identifier such as (but not limited to) a serial number, any related artwork or specific constraints on use. The minting record may be provided as a pointer, reference or representation of the list or token-related data, and may be provided within the locking script of the minting record’s output(s). In some embodiments, it may be provided as metadata at a location within the token-holding output(s) e.g. within a locking script of the UTXO, possibly after an OP_RETURN opcode.

Token Outputs (T-UTXOs):

The plurality of outputs also comprises at least one (but typically a plurality of) token related UTXOs which we might refer to as T-UTXOs for convenience to distinguish a token-carrying output from an output that comprises a certificate and/or minting record. A T-UTXO is a UTXO which represents a token (and thus a tokenised resource) in accordance with embodiments of the present disclosure. We may refer to an output that comprises the certificate (IData) as an I-UTXO.

In respect of a typical embodiment of the present disclosure, in which the Minting Transaction generates more than one new token, the underlying, cryptocurrency value of the newly minted coins are a sub-portion of the incoming quantity of cryptocurrency (C). However, in an embodiment where only one coin is to be minted by the issuing transaction, the whole of the incoming quantity may be allocated to the newly minted coin. In all cases, whether one or more coins are minted, any remaining change will be returned as mentioned above.

All of the tokens being minted by a given MTx represent token types and unit quantities that the issuing authority is permitted to issue under the conditions of the contract that established the token ledger. A token has two types of “value” or units/quantity of resource associated with it:

1. The quantity of units (“token value” or “token units (TU)) of the tokenised asset/resource being represented by the token; this can be any type of asset, entity, item or resource. (For ease of reference hereafter we will simply use “resource” as including all of these terms). For example, but without limitation, the resource could be:

• a physical resource such as car, house, racehorse, cinema ticket etc

• a legal right or obligation such as a licence to use some resource such as a car, or run some software or download some content (e.g. movie) for a specified period of time; or an obligation to perform conditions of a contract; a share of a patent right

• a virtual and/or digital asset such as a right to access a computer network or file, or cryptocurrency, or a digital ballot paper or selection in a voting system • Financially or corporate-oriented assets such as fiat currency, commodities, stocks and shares etc

2. the non-negative portion of underlying cryptocurrency that has to be transferred as an essential mechanism of blockchain transactions; blockchain protocols operate via the transfer of some Satoshi (or other form of cryptocurrency) from an output in one transaction to an input in another transaction; therefore, the skilled person will readily understand that while this is the underlying mechanism or vehicle that makes the disclosed blockchain-embodiments work in practice, the known art of cryptocurrency transfer is not the novel or inventive aspect of the disclosure; instead, the innovation lies in the disclosed tokenisation techniques, systems and protocols which utilise those known blockchain mechanics.

Tokens are spent by transferring the underlying cryptocurrency (e.g. Satoshis) into a new owner’s address using a Bitcoin script. Control of the satoshis represents control of the token. It should be noted that:

• Tokens minted in the same transaction can have different underlying satoshi values.

• Each token’s token value (i.e. quantity of resource units) does not change after minting irrespective of the number of times it is transferred.

• A token cannot be split after minting, in that its value is fixed. Therefore, in a preferred embodiment, the underlying quantity of cryptocurrency units associated with a given token cannot be changed after minting. However, in other embodiments the protocol may permit alteration of the number of cryptocurrency units in certain ways as long as the token’s original token value specified by the minting transaction is not altered. For example, an issuer could issue a token with X underlying Satoshis and then create an output that contains X+Y Satoshis. This would enable a user to draw down on Y to pay transaction fees for transferring that token on condition that the number of Satoshis never reduces to below X as a balance. In this way, the token value can be supplemented but is retained.

The tokens can be created such that the output scripts require any desired variation of signatories. This provides a significant benefit in terms of flexible script options for receiving tokens into, and enhanced functionality. Bitcoin-implemented examples include, but are not limited to:

■ Example 1 : Simple cash output

■ <pubkey> CHECKSIG

■ This is one of the most simple scripts in Bitcoin - a single signature check against a public key can transfer ownership/control of the tokens

■ Example 2: Joint Account

■ 1 <husband_pubkey> <wife_pubkey> 2 CHECKMULTISIG

■ This script allows either the husband or the wife to transfer ownership/control of the tokens

■ Example 3: Corporate Account

■ <department_VP_pubkey> CHECKSIGVERIFY 1 <engineer_l_pubkey>

<engineer_2_pubkey> <engineer_3_pubkey> 3 CHECKMULTISIG ■ This script allows 1 of 3 engineers to sign before passing to their department VP for countersignature to transfer ownership/control of the tokens

Token sub-Ledgers:

With reference to Figure 9, embodiments of the disclosure provide the ability of the issuer to establish secondary, self-contained Token Sub-Ledgers within their Token Ledger. This can be performed through the performance of an establishment transaction within the primary token ledger that uses the issuer’s authority (depending on the embodiment) of the main establishment transaction to create a sub ledger to manage a particular set of tokens from the primary token ledger. Tokens transferred into the token sub-ledger can be given additional properties or different properties relative to those in the primary token ledger, or can be used as a reference or source for the minting of new tokens of different types. These additional or changed properties are defined in the establishment transaction in the same way as the primary Token Ledger’s properties are defined.

Where no additional or changed properties are defined, the token sub-ledger retains the same properties of the token ledger within which it was created. When tokens are issued within a token sub ledger, the use of those tokens is restricted to the bounds of that token sub ledger. Tokens created in a token sub-ledger cannot be transferred into the primary token ledger. However tokens from within the primary token ledger can be used as inputs to a token sub-ledger minting transaction and broken down into smaller token sub-units or sub-types within the token sub ledger.

For example, consider a scenario in which a company creates software. The company can build a token which represents a license to install a particular piece of software. Each time a user purchases a license, one of the license tokens is used as an input to a new token sub ledger. Each time that customer uses the software in such a way that a record is created, that record is created within their own private sub ledger which exists within the company’ s primary token ledger. Records can represent events and actions such as additional in-app purchases, the performance of software updates or the creation of files and other information.

Transferring & Validating Tokens On A Blockchain

As shown in Figure 1, after a token has been minted it can be transferred or “spent” from a sending party to a receiving party. The first transaction will spend the token from its T-UTXO in the Minting Transaction output list to an input in one or more further transactions. From there, the token can be spent to another recipient and so on, generating an evolving transactional history on the blockchain with each spend event.

While variations of aspects and embodiments will be readily apparent to the skilled person, all tokens minted in accordance with the present disclosure share certain features:

• each token is generated as an unspent transaction (T-UTXO) that is included in a minting transaction (MTx) formed in accordance with the present disclosure

• each T-UTXO comprises a specified amount of cryptocurrency in compliance with the underlying blockchain protocol; in the Bitcoin protocol this would be zero or more Satoshis. This may be referred to herein as a quantity, amount or portion of token-related cryptocurrency (TRC) to distinguish it from the cryptocurrency (C) that is spent from a previous transaction into the Minting Transaction to enable the individual T-UTXOs to be created

• Each token represents a tokenised resource; therefore, it has an associated value arising from or associated with that resource. This may be referred to herein as the token’s “face value”, “denomination”, “token units” or its “token value” to distinguish it from the value or quantity of the underlying cryptocurrency that carries the token for the purpose of enabling transfer over the blockchain in accordance with the underlying blockchain protocol

• in use after minting: o each token is represented as a UTXO in a blockchain transaction; these transactions and UTXOs do not deviate in terms of formatting or appearance from conventional TXs and UTXOs. Embodiments of the disclosure do not require any deviation from, or alteration of, the underlying blockchain protocol o Each user’s tokens are stored using a script in accordance with, and specified by, the issuer’s requirements. As the skilled person will appreciate, this can be achieved using known techniques such as multi-signature scripts or using accumulator scripting to capture different authorisations and structures. o each token can be traced back, via its history on the blockchain, in a linear fashion to the Minting Transaction that created it; this enables authorisation and source to be verified to prevent counterfeiting and other unauthorised usage o Each token is transferred from a sender to a recipient by spending the UTXO that comprises it into an input in a subsequent blockchain transaction. Each time a token is transferred over the blockchain, a linear transfer is performed in that transaction graph of the token does not contain any splits or re-combinations. o In order to ensure that the token is a genuine, authorised token for the purpose and of the source expected by the recipient, the transactional history of the token can be verified easily, quickly and efficiently by tracing it back to the Minting Transaction which issued it and checking it against the Minting Record and/or certificate.

When a token is to be sent to a receiver (which would initially be the Issuer, and subsequently a different owner) the sender’s digital wallet spends the UTXO to an address controlled by the recipient’s digital wallet. In a preferred embodiment, the receiving wallet has been arranged and configured in accordance with the protocols and methods of the present disclosure. Therefore, the receiving wallet knows that it is expecting a token in accordance the disclosure and must verify that this is the case. The receiving wallet knows the VOUT index of the UTXO that the token is contained in, so initiates a verification check of the token’ s history by checking that the cryptocurrency that was spent to that UTXO came from an input residing at the VIN index that matches the UTXO’s VOUT index, and that this in turn came from a UTXO whose cryptocurrency came from an input residing at the VIN index that matches its VOUT index and so forth.

The scanning process continues until a blockchain transaction is reached where the VOUT holding the token has no corresponding VIN. In other words, the linear transaction history terminates. If the transaction does not have a corresponding VIN, either the transaction is the minting transaction or the token is invalid. From here, the scanning process reads the Minting Record from the corresponding/designated output and validates that the token is genuine and was minted in a transaction that carries the signature of the issuing party’s representative.

Thus, in order to verify a token’s history, the wallet uses the aggregate Merkle proofs of each transaction it has been used in on the blockchain since it was minted. This is illustrated in Figure 8. As each token is created within a unique UTXO and is transacted without splits or combinations, its history is linear and can be quickly checked on the ledger. A token with a 1000 transaction history would carry approximately 1MB of history assuming 100 billion Txs/day on the Bitcoin blockchain. As the Bitcoin ledger is publicly inspectable, wallets and third parties are able to verify tokens on behalf of other parties and users.

It should be noted that the disclosure does not preclude the use of conventional UTXOs as inputs, nor the creation of conventional UTXOs as outputs in transactions that include the transfer of tokens. Therefore, a transfer transaction can also comprise one or more UTXOs and/or inputs that are not formed or used in accordance with the present disclosure.

Group Transactions

In some situations, more than one token may need to be transferred. Additionally, or alternatively, a service provider (e.g. payment processor) may elect to take transactions from several parties and merge them into a single transaction for the sake of efficiency and resource management. This also provides the advantage that tokens can be mixed and ownership obfuscated. This can provide security benefits because a malicious party cannot identify the owner of a particular token and thus target an attack. Therefore, a transaction can be used to take token inputs from multiple users and send different tokens to the desired receivers other than the ones signed by the spending party.

For example, as explained above, an individual token has a token value. If a user wishes to transfer a given amount of token value, but no single token has been minted of sufficient token value or a particular user’ s wallet does not control a single token of that value, multiple tokens with smaller token values will need to be sent so that they add up to at least the desired overall token value. In such situations, the sending party’s wallet selects tokens that it controls and (at least partially) signs multiple token UTXOs in a blockchain transaction (Tx) which add up to at least the required overall value. We may refer to this transaction as a “group transaction” (GTx) because it groups or clusters token outputs together into one blockchain transaction. Thus, there may be a need to generate blockchain transactions which mix tokens, and tokens transferred to a given receiver may not be the same ones that were received from the sender. This gives the advantage of enhanced privacy (as token distribution is obfuscated) and improved efficiency. If required, a sender can cryptographically sign tokens that add up to a higher value than required. Depending on the implementation required, such scenarios will result in change being sent back to the sender. In embodiments which are implemented on a Bitcoin blockchain, the user’s signature uses SIGHASH_ANYONECANPAY and SIGHASH NONE. This effectively creates a signature that can be applied to any signed UTXO that can be applied to any input in any transaction. Other flags, instructions or OPCODES may be used to provide the same technical result in accordance with alternative blockchain protocols.

In some embodiments, transactions may be processed in a payment channel. When a user’s wallet receives new tokens they can be stored for onward payment at a later date. If the user needs to make a transfer for a certain overall token value, tokens can be selected from the wallet and added to the group transaction. The transaction may have a time lock mechanism (e.g. nLocktime) that prevents it from being mined by the blockchain network until a particular time, or until the subsequent block is found. Tokens are added to the payment channel. When a group transaction is being updated in a node’s public mempool, the wallet evaluates the TXID of the transaction that was included to check which version of the group transaction was recorded and begins building a new transaction for the payment channel.

The GTx process is illustrated with reference to Figures 14 and 15 in which, solely for the sake of convenience and ease of understanding, tokens are shown which represent fiat currency banknotes and coins. We use fiat currency for the examples in Figures 14 and 15 because cash bills and coins are readily understood and familiar. Figure 5 also illustrates how tokens retain their token value regardless of the number of times they are transferred.

Re-stamping Or Destroying tokens

Under some circumstances token issuers may wish to remove tokens from circulation. Figures 18 and 19 illustrate the use of transactions to perform melting and re -minting operations.

Transactions that perform these re-stamping or re-minting actions must only be performed by the issuing authority to prevent users from fraudulently stamping them with incorrect information and so must also include a ‘Minting Record’ and either spend the issuer’ s certificate into a new output or include the signatures of the issuing authority as per the specifications of the particular token ledger.

In embodiments of the system where the issuer controls the tokens directly by holding them in a single register, the tokens can be removed by the issuer by spending them out of the register into a Melting transaction, removing the tokens and the underlying cryptocurrency from the token register.

In another embodiment where the issuer may not have the ability to move the tokens, the issuer creates the mint record as a spendable UTXO. When tokens need to be removed from circulation, the mint record can be spent into a new output that contains details of the expired tokens. In this way when a user does a validation check on the linear history of the token they can see if the token is still current.

In another embodiment the issuer may have a contract with Bitcoin node operators who can remove the tokens from circulation by transferring them directly into a melting transaction, effectively transferring the tokens and the underlying currency from the user’ s wallets and back to the issuer. In yet another embodiment, the issuer may publish information regarding the removal from circulation of tokens with certain properties and offer replacement tokens of the same value to users who transfer the obsolete tokens back to the issuer’s control. This method allows the tokens to continue to circulate naturally, allowing people to hold the old versions as collectible items or simply as untouched savings without risk to the token value.

Nodes and Network Topology

In some embodiments, one, some or all of the following three elements may be combined to form a network arranged to implement the protocols and methods disclosed herein:

1. Trustholds

2. User wallets

3. Registers Trustholds:

Trustholds are distributed threshold signature generators. They are networks of computers which provide users with threshold signature slices that can be combined to create an ECDSA signature. User wallets have access to the network, for example via an API, and include a software module to manage signature recombination. A Trusthold’s function, therefore, comprises relieving the user of the responsibility of key backup and management. They each validate the user’s identity and provide signatures for their tokens. Users such as individuals’ merchants, hanks or other entities are able to cryptographically sign their transactions via a trusthold. Advantages of using a trusthold include the use of secure, distributed network, and a reduced risk of losing access to controlled resources.

Wallet:

The wallet’s main functions may include:

1. Tracking the public keys being used to receive tokens from senders and, where necessary, ensure that any relevant trustholds have knowledge of them

2. Giving public keys to other authorised parties (e.g. Registers, collaborating or participating entities in a scheme or network) so that they can process tokens received from the wallet

3. Monitoring an index of tokens held by the wallet and formed in accordance with the present disclosure, including various types and form of data relating to tokens and the UTXOs that they are embedded in

4. Where necessary, providing an interface between a user’ s trusthold network for the purposes of requesting and receiving signatures

5. Communicating with other users to send and receive tokens, and send other data (e.g. EDI)

6. Participating in collaborative transaction (Tx) and signature processes for creating and spending multi-signature tokens

7. In some embodiments, searching for and processing data stored via an associated tree or graph in order to monitor data relating to a computer-implemented transfer or other process (e.g. details of tokens sent/received, any alias associated with one or more parties and other data such as, for example, EDI records). This is seen in Figure 13 Depending on how the tokens are to be used, a wallet user may request a trusthold sign message hash on demand. In other situations, the user can ask the trusthold(s) to pre-sign their tokens for spending. In embodiments where tokens are signed using ‘SIGHASH_ANYONECANPAY | SIGHASH_NONE’, this makes them easy, simple and efficient to transfer. These signed tokens can be held by the wallet to be handed to recipients. A recipient can store a pre-signed token and send it back to a receiver (e.g. a bank) for exchange with other tokens held within a pool or set of other minted tokens.

Figure 7 illustrates an embodiment using a wallet to conduct a token transfer. With reference to Figure 7 :

Step 1: User 1 receives a token value transfer request and selects one or more Token UTXOs they control to a value equal or greater than the requested amount. In this embodiment, User 1 may receive information regarding the receiver’s identity, a receiving script/scripts generated by the receiver, or both.

Step la: Where User 1 has not been passed receiving scripts their wallet or a money handling service they subscribe to conducts alias lookups to discover the receiving scripts to send the funds to. If the user does not have exact change, this process can include a negotiation to receive change from the receiving party or an API connection to a change providing service.

Step 2: Once User 1 has correct change, their wallet sends a signature request for each token selected in Step 1 to nodes in their trusthold network who create ‘signature slices’ needed for User l’s wallet to build USERlsig for each selected token’s ScriptSig. In this embodiment signatures can be signed using SIGHASH_ALL if the transaction is being handed directly to the receiver, or can use SIGHASH_SINGLE I SIGHASH_ANY ONECANPAY if the transaction is being spent into a Group Transaction via a payment processor.

Step 3: Each of the fully signed tokens is passed to the receiver at the same time as they are broadcast to nodes on the blockchain network, completing the transfer.

Figure 10 illustrates an example of a change service as mentioned in step la above. With reference to Figure 10:

Step 1: a user wallet connects to a change server API to define transaction requirements and request receiving script.

Step 2: The change service responds with receiving script / scripts.

Step 3: The user sends signed tokens to the change service wallet.

Step 4: The change service sends change back to the user’s wallet.

Figure 13 also shows a wallet in use in accordance with an embodiment. With reference to Figure 13:

Step 1: A Sender’s wallet connects to a Receiver’s wallet alias lookup/provision service to request a receiving script for a token delivery.

Step 2: The Receiver wallet’s alias service responds with receiving script / scripts.

Step 3: The Sender signs and sends tokens to receiver wallet

Step 4: The Receiver sends the token UTXO details to a validation service. Step 5: The validation service performs a Merkle proof lookup, tracing the linear transaction history back to the back to token’s minting transaction.

Step 6: The validation service validates the token’s authenticity using the Minting authority provided via the MTx

Step 7: If needed, the receiver makes an alias request to the Sender’s wallet for receiving scripts to send tokens from its own wallet to provide change. These are applied to the transfer transaction before it is sent to nodes on the Bitcoin network to be processed.

Registers:

As shown in figures 2, 3, 6 and 15, certain (but not all) embodiments may utilise a system component which we will refer to for convenience as a “register”. A register may be a computer- implemented resource which comprises a wallet arranged to process tokens that are minted and used in accordance with the present disclosure. The register may be a fully automated system component. The use or otherwise of a Register will be dictated by the requirements of a particular use case and its implementation.

Figure 2 shows illustrative embodiment(s) of the disclosure in which:

1. token(s) for at least a required overal token amount or value are sent from a sender to a Register, and then tokens for at least the required overall amount are sent onwards from the register to a receiver; if tokens for more than the required overall amount are transferred, change is provided to the sender from the register or the receiver; performing the exchange via the register enabes a record of the transaction plus the transfer of ownership/control of the incoming and outgoing bills to be included in the Register.

2. Tokens(s) for at least the required token amount are sent directly to the receiver without going via a register; if tokens for more than the required overall amount are sent, change is provided to the sender from the receiver or some other party.

Figure 3 also show two possible embodiments. In the first, an issuing entity creates and maintains a register of tokens. Each token that is issued is written to the register so that for each token that is put into circulation there may be a record comprising (at least) an identifier/serial number which uniquely identifies the respective token, and the token value associated with that token. If a token is withdrawn from circulation for some reason, it can be removed from the register using a melting action as illustrated in Figure 18. A user which receives a token from the register may then transfer tokens to other users via the register or directly from user to user without going via the register.

With reference to Figure 6:

Step 1: User 1 receives a token value transfer request and selects one or more Token UTXOs they control to a value equal to or greater than the requested amount. In this embodiment, User 1 may receive information regarding the receiver’ s identity, a receiving script/scripts generated by the receiver, or both. Step 2: User 1 sends a signature request for each token selected in Step 1 to nodes in their trusthold network who create ‘signature slices’ needed for User l’s wallet to build USERlsig in each selected token’s ScriptSig using SIGHASH_NONE | SIGHASH_ANY ONECANPAY Step 3: User l’s register operator receives the partially signed token or tokens into their register and receives the details of the value transfer which can include receiver identity or identities, receiving scripts and transfer amount. If scripts have not been supplied, the register operator conducts alias lookups to discover receiving scripts on behalf of the user.

Step 4: The register operator selects appropriate tokens to make the full payment and any change payment from the partially signed tokens it has received for other transactions and holds in its register. It completes the signature process by signing each using SIGHASH_ANYONECANPAY | SIGHASH_S INGLE and adds the signed outputs to a group transaction. The receiving script can represent any type of wallet used in the token ecosystem without restriction.

Possible embodiments which make use of a register are also provided in Figure 15. In Figure 15, User 1 signs tokens 1, 2 and 3 for transfer to User 2. User 1 signs tokens held in a multi-signature account, co-signed by the register, allowing the register to transfer them forwards into transactions to other receivers. User 3 is also shown signing tokens 4, 5 and 6 for transfer to the register. The Register creates outputs to a group transaction using other pre-signed tokens that it holds in its pool to complete transfers to users 2 and 4 in a single on-chain action

Although embodiments of the present disclosure can be implemented without the use of a register, there are techncial advantages which flow from such an arrangement where an implementation lends itself to the use of a register. Although the title of the Satoshi Nakamoto whitepaper referred to a “peer-to-peer electronic cash system”, cryptocurrencies still face numerous technical challenges regarding adoption and implementation. One of these challenges is that the wallets used to control a party’s coins typically use a seed for back-up and recovery purposes. The seed is typically a more user-friendly mnemonic such as a phrase or group of words that are associated with an address or series of addresses that enable the wallet to be replenished. However, this requires a wallet owner to memorise or somehow record the seed. There are numerous known instances in which the seed has been lost or forgotten, leading to non-recoverable loss of the wallet contents. Moreover, the use of a seed prevents or at least hinders certain custodial applications of cryptocurrencies.

In addition to the “Seed Word” problem, wallets face the challenge of how to manage unspent transaction outputs (UTXOs) and any required change. In Bitcoin, coins are received into a wallet as UTXOs. Typically, the wallet will combine more than one unspent coins (received via >=1 inputs) to create one or more outputs. As the combined UTXO coins often amount to more than the required payment amount, the remaining change is sent back to the payer’s digital wallet. This is analogous to the use of fiat cash, in which a buyer hands over ten dollars for payment of a $9.50 transaction. It may be that the $10 is provided as two $5 bills, a $10 bill, or a $5 bill plus 5 lots of $1 bills. In any event, the 500 change is handed back.

In the digital cash paradigm, this gives rise to technical challenges including:

1) the wallet needs to manage its UTXO set; this set can become complex which in turn may result in security risks for both users and developers 2) security can be compromised as it is often easier to identify ownership of coins through their transaction history; if coins can be traced to a source via a wallet, attacks may be more successful

Thus, embodiments of the disclosure provide mechanisms for exchanging assets (e.g. cryptocurrencies, tokens, data etc) via a blockchain network which solve at least these technical challenges, including enhanced privacy and security for blockchain-enabled digital wallets.

Serial Numbers

In accordance with a preferred (but not every) embodiment, newly minted tokens may be assigned to or associated with a unique identifier. This may be performed via the Minting Transaction. This may be any type of identifier which can be used to refer to the token and distinguish it from other tokens that may be minted by the Issuer. We will refer to it as a “serial number” for convenience. A serial number is embedded in the output script (scriptSig) of the T-UTXO of a given token in the Minting Transaction. The serial number can then be carried forward with the token as it enters into circulation within the network.

In one or more other embodiments, though, serial numbers may be a hash of the TX used to create the tokens. However, this is less preferred because of a reduced level of control. A particular embodiment might process the transaction identifier (TXID) through a hashing function to create a unique identifier for the first output, and process the unique identifier for the first output through the same hashing function to generate a second unique identifier for the second output and so on. In this implementation, the issuer is unable to determine the serial number of an issued token prior to the issuance action and the identifier is not recorded onto the blockchain as part of the minting record.

As the tokens are always spent into and out of the same index in any transaction they are used in, the tracing of the bills back to the creation event can be done easily by tracking the usage of the bill back through the token’s transaction graph. In some embodiments, it may be desirable to periodically mark, flag or identify tokens with their serial number to make verification and tracking more efficient.

Serial numbers may be used to track or link the provenance of the tokens to the issuer and to index user transactions in a user’s database/register. In one or more embodiments, a Group transaction may spend all fully signed output tokens into new scripts assigning them to new owners. This can enable dynamic re assignment of tokens up until a time specified in a time lock mechanism. It is also possible to withhold the outgoing tokens at a wallet’s discretion.

Example Use Cases

The following examples are provided as illustration of a small sample of the applications in which embodiments of the disclosure may be implemented. Many other applications and uses can, of course, be devised.

Use Case Example 1: Prescriptions

Suppose a patient visits a medical practice because of back pain. The medical practice has implemented a system which utilises tokens in accordance with the present disclosure. The medical practice owns some Bitcoin and uses it to generate a minting transaction that issues a set of tokens as described above. These tokens can be used to present pharmaceutical prescriptions. Each doctor within the medical practice has a digital wallet which controls a private key that can sign the unlocking scripts of the pharmacy’s token T-UTXOs so as to authorise the transfer of tokens to a patient. The digital wallet is arranged to implement the protocol disclosed herein, so can accept, verify, transfer and process tokens as described above. The patient has also installed a digital wallet that can receive, send and process the practice’s tokens in accordance with the protocol.

After examining the patient, the doctor decides to prescribe some medication so she uses her wallet to generate a blockchain transaction which has a UTXO that comprises a locking script which can only be unlocked using a key controlled by the patient’s wallet and also a key controlled by an authorised pharmacy. The doctor inserts a token comprising patient and prescription data into the UTXO’s script. The token is then transferred from the doctor’s wallet to the patient’s wallet by spending the UTXO to an address owned by the patient’s wallet.

When the customer arrives at the pharmacy, he presents the token he received from the doctor. The token must first be signed by the patient’ s own wallet and is then passed to the pharmacy’ s wallet for the pharmacist’s authorisation. The pharmacist must be able to check that the prescription token is genuine and has not been forged. Therefore, the pharmacist’s wallet traces the Token’s transaction history on the blockchain to identify the minting transaction and checks the issuance data to verify the token. If verification is successful, redemption of the token can proceed. If not, the pharmacist declines to dispense the medication.

According to one embodiment, to create the second signature needed to redeem the prescription, the pharmacy wallet acts as its own trusthold and communicates with a network of pharmacies who each use their private cryptographic keys to sign the token. This gives the pharmacy network the ability to monitor prescriptions across groups of pharmacies to identify fraudulent activities. In this way, an improved monitoring and control solution is provided. In other embodiments, redemption may require the patient’s signature, the pharmacist’s signature and the medical practice’s signature. Other variations are also possible depending on the requirements of the use case.

Use Case Example 2: Game tokens

Suppose that a gaming engine mints Tokens for game -related items. Items within the game are generated using vanity signatures that hash to item names. For example, a signature whose hash creates an ASCII string that begins with ‘sword’ can present that signature on a token to the game company. The signature hash defines the item’s purpose in the gaming world, and the token’s linear transaction history adds weight to its accumulated experience.

Thus, in-game items can be issued by the game’s creators as a sellable token which can be traded for cash or other in-game currency but where the traded item’s ownership and usage history is tracked in a token ledger. As the item is used, each interaction with the environment can cause damage or add experience to the item’s history, eventually leading to alteration of the item’s functionality or usage over time. Such items could be customised by their owners, and retain their unique properties when they are exchanged. Further possibilities include the tokenisation of in-game reward systems or the creation of usable currency for an in-game environment. Further still, embodiments may allow for game developers to collaborate to allow items to be used by players in multiple games or to be carried forward into game sequels, allowing game items to accumulate status over many years and platform iterations.

Example Use case 3: Physical tokens

Figure 17 illustrates a process by which a digital token with a unique identifier e.g. serial number and token value can be locked into a script controlled by an issuer who can then create physical representations of the digital tokens. These can be verifiably linked to the digital token, and then destroyed by depositing them back into a register controlled by or associated with the issuer and removing the digital token from the locking script. With reference to Figure 17:

Step 1: Tokens are spent into a locking script that requires a knowledge proof provably linked to the issuer. Step 2: Physical tokens are created that represent the digital tokens being used, and contain details including the token value, serial number and the details of the UTXO the digital token is currently held in on the ledger.

Step 3: Physical tokens can be exchanged between trading parties. Receivers validate the provenance of the token by checking that the digital token is locked in the transaction output shown on the physical token. Checking may be done via PC, point of sale device, or using a smartphone or tablet application. When the physical token is deposited, information it contains is used to build a transaction that moves the digital tokens, triggering a process in which the physical token is destroyed.

Such an embodiment is suited for a wide range of possible use cases and applications. Once of these is provided as follow with regard to voting/selection processes.

Example Use case 4: Voting Systems

Example 4 is described with reference to figure 22. In this illustrative use case, certain embodiments can be arranged such that the tokens can be used to implement choice-making functions (which we will call “ballot papers” for ease of reference) in a selection process. This may be referred to as a “voting” system as known in the technical field, which should not be construed or mistaken as meaning purely political in nature. The term “voting” is used herein to refer to a process by which a choice or selection can be made and recorded. However, for the following example we will use an election process as this is readily understandable due to familiarity.

For example, consider a scenario in which an electoral commission establishes a Token Ledger in accordance with the disclosure for the purposes of conducting an election. Once the token ledger is established, the commission mints enough tokens to cover the voting process in each electorate, allowing for an extra quantity (e.g. 10%). Each token represents a ballot paper. Each ballot paper is then reproduced as a physical token containing a unique code which can be used to spend the digital token as part of a voting action. When voters arrive at the polling station their identity is processed through the normal means, in a way that is disconnected from the tokenised ballot paper. Once their identity and right to vote has been independently established, a physical ballot paper token is transferred to the voter. This could be, for example, a piece of paper with a bar code on it, or a plastic token or smart card with a chip or tag provided in or on it. A physical token can be picked at random from a pool of tokens provided to the polling station staff. In this way, the voter’ s identity is not known or attached to the physical token in any way, but the voter is now in possession of a token that represents their right to vote in the election.

The voter then presents themselves at a booth where a computer interface (e.g. touchscreen display) is provided and provides the terminal with the unique code provided by their physical token. The computer checks that the code represents an unspent ballot paper and presents the user with a voting process in accordance with the local rules of the electorate. This could be by being shown on-screen, or could include other communication means e.g. audio means for use by blind users.

A further embodiment may provide the user with a printed record of their vote to place into a ballot box as a backup to the electronic process, and a further embodiment may use the unique physical token as the print media. Once the user’s vote is concluded, the computer interface spends the ballot paper into a group transaction which is held in a timelocked payment channel that closes when the ballot is finished. If the user retains a record of their unique ballot paper they can verify that their vote was correctly recorded once the transaction is finalized.

This process is illustrated in Figure 22 which comprises the following steps:

1. The issuer creates a Root Node to establish the token ledger that records the election’s votes and outcome

2. The issuer uses the authority from the root node to generate enough ballot papers for the election process to take place using a minting transaction

3. A knowledge proof needed to spend each ballot paper is produced as a physical token with a secure device that a voter must break into through an irreversible process in order to reveal (e.g. tearable perforated sheet/scratch panel)

4. Ballot papers are randomized and delivered to voting locations where they are distributed to voters who have presented adequate identification to participate in the election process.

5. Voters reveal their ballot paper’s knowledge proof by conducting the irreversible process needed to access it and present the information to a secure voting terminal. The terminal checks that the knowledge proof represents a valid token and presents the voter with a set of guided voting options.

6. The voter goes through the voting process using the secure terminal and once finished, indicates through an action that they have completed selecting their options. The terminal generates a new UTXO which it uses to transcribe the voter’ s selection and uses the knowledge proof to sign the digital ballot paper using SIGHASH_SINGLE | SIGHASH_ANYONECANPAY. At the end of the voting process, the signed ballot papers are all spent together in one transaction to finalise the voting process. A user who retains access to their ballot paper can easily check that their vote was recorded correctly.

Example Use case 5: State Machines

In one embodiment of the disclosure, a token can be created that is intended to pass through a state machine with a linear processing framework. In this way, a token can be created, and pass through numerous transfer operations, changing state each time. Some tokens may be processed back into standard blockchain UTXOs at the finalization of a state transition. In this way, the disclosure can be used to implement DFAs and automated systems which can be used in a wide range of scenarios and for many different purposes.

For example, consider a scenario in which a user purchases an airline ticket on a particular flight. The first state is a ticket booking which includes data such as flight and date. Prior to the flight, the user may change the booking which would involve a transition into a different booking state. The user may also add other services such as meals and a specific seat selection to their booking, each of which modifies the state of the ticket. When the user checks into their flight, they are assigned their final seating and the ticket changes state into a boarding pass. If the flight is cancelled, the ticket’s state may be changed back into a booking. Once the passenger has arrived at their destination, all of the underlying cryptocurrency that held the tickets that were used by all of the passengers on that flight can be processed back into a Bitcoin UTXO which the airline can then recycle into new tickets.

Peer-To-Peer Electronic Token Transfer

In some ways, the creation and use of tokens as disclosed herein can be thought of analgous to the use of fiat currency bank notes or coins which are issued as tokens by a national reserve. A £5 bank note is a promissory note issued by the Bank of England, having a serial number, watermark and/or other identifiying features (eg artwork) that enable them to be verified as being issued by an authorised issuer. A £5 bank note is fungible and may be exchanged directly between users Alice and Bob without an intermediary (i.e. a peer-to-peer cash transfer as per Satoshi Nakamoto’s 2008 whitepaper title) simply by Alice handing Bob a £5 note or five £1 coins. Alternatively, Alice may pay Bob via the issuing hank or another intermediary. Suppose that Alice wishes to pay Bob £5 via her bank. The £5 that Bob subsequently withdraws from his hank’s ATM is unlikely to (although theoretically may) be the same £5 note that Alice paid into her bank. If he withdraws it in person from a bank teller he may be given five individual £1 coins. In either case, Bob’s concern is that he receives his £5 worth of Bank of England tokens into his wallet.

Although it is unlikely that they would wish to do so, Alice or Bob may also destroy their £5 note or five £1 coins if they so wish. They may burn their hank note or melt their coins. Alternatively, the Bank of England may withdraw a hank note or coin from circulation so it can no longer be transferred between users. Simlarly, tokens minted in accordance with the present disclosure can be destroyed by users or withdrawn/cancelled from ongoing use by an issuer.

Also in common with tokens of the present disclosure, a bank note or coin retains its token value regardless of the number of times that it is transacted - a £5 note is always worth five pounds Stirling, whether it is used once or 10,000 times.

Moreover, a banknote cannot be split or recombined. If a £5 note is cut into 5 individual pieces of paper/plastic, or a £1 coin is melted down into smaller pieces of metal they will retain some (probably very small) instrinsic value relating to the resale of the paper and/or metals, but the (probably larger) token value is lost. In the same way, if a token minted in accordance with the present disclosure is used in a manner that is incompatible with the protocol, the underlying cryptocurrency may still provide some value to the owner but the usage as a particular type of token may be rendered ineffective. However, while banknotes and coins are a simple, quick, and private means of transferring a tokenised resource between users, they are inefficient in that their printing medium is physical. By providing a digital version of a token, some use cases of the present disclosure may provide a peer-to-peer elecontric cash solution as per Satoshi Nakamoto’s original white paper which offers the advantages of cash but provides a cryptographically secured and enforced alternative, that reduces the opportunity for exploitation by unauthorised parties (eg counterfeiters and fraudsters) and removes the wastage, expense and inefficiency of physical print media.

In some ways, therefore, embodiments of the disclosure provide simple, efficient and yet powerful blockchain-implemented solutions which are fully aligned with Satoshi Nakamoto’s original, ground breaking design. However, the benefits of such solution extend well beyond the use of blockchain trechnology for simply digital cash or currency in the same way that the Internet’s benefits extend well beyond the simple provision of an electronic message or web page. Embodiments provide potential for solutions which have not yet been explored on the blockchain. Any type of resource can be tokenised using the disclosed embodiments, giving rise to a versatile and advantageous blockchain-implemented data transfer mechanism.

In some respects, the recognition and conception of the present disclosure has been obfuscated to date by current blockchain rules which restrict the size of transaction outputs to “dust” levels, and which have resulted in efforts being focussed on a combine-and-split paradigm at the transaction and token levels. Embodiments of the disclosure, however, are able to exploit and harness the benefits of existing functionalities within blockchain protocols, such as Bitcoin’s SIGHASH flags and flags with the same or similar functionalities in alternative protocols. Instead of following conventional tokenisation approaches which break up tokens and recombine them into different token amounts during the transfer process, embodiments disclosed herein comprise the use of unqiue, fixed-value, denominated tokens which can be quickly and efficeintly verified and enable the creation of systems for uses beyond the capabilities of known approaches. Thus, improved blockchain networks and solutions are provided.

Moreover, once the tokens disclosed herein are issued, there is no requirement for the token Issuer to build or maintain additional infrastructure for token exchange/transfer/verification, providing a highly efficient and secure improvement over known technqiues. The capacilities and benefits of the blockchain network are leveraged by simply specifying the way in which the transactions are built in script. All token transfers are conducted on-chain and so the cryptographic enforcement, consensus mechanisms and security of the blockchain network are harnessed, plus the immutable, inspectable, timestamped record of events is secured on-chain. There is no requirement for a user to insert data into a script, while having the ability to lock tokens using scripts that are suited to their individual requirements without changing the value of the token. As there is no additional overhead in terms of scripting, this again gives rise to efficiency benefits in terms of ledger use.

With regard to digital wallets, the disclosure avoids or at least alleviates the problem of complex wallet integration so that development resources such as time, effort, computing power and costs are minimised. Wallets do not need to interface with the blockchain network other than to obtain block headers for validating SPV proofs for tokens that they receive. Wallets are simplified in that in some embodiments they do not need to build transactions, they can simply receive, sign and send the tokens in the usual way. Thus, embodiments of the disclosure provide the ability to construct hitherto unknown tokenisation systems and tools which store and transfer tokens using the simplest possible blockchain transaction outputs.

Further still, embodiments of the disclosure do not require the Issuer to be party to each transfer transaction on the blockchain. This addresses problems faced by exsiting solutions with regard to privacy and scalability, as their resource and cost requirements can escalate relative to the number of users.

Thus, the present disclosure provides technical solutions to a variety of technical problems, including, but not limited to, those mentioned above.

Enumerated Clauses:

Some illustrative embodiments of the present disclosure are provided in the following enumerated clauses.

1. A blockchain-implemented token generation, transfer and/or verification method comprising: using, processing and/or generating a blockchain transaction (MTx) having: i) one or more token-related outputs (T-UTXOs), each of which represents a respective token (T) issued by a Token Issuer (TI) and specifies a quantity of a) token units (TU) and b) token-related cryptocurrency (TRC) associated with the respective token (T); and ii) at least one Issuer-related output (I-UTXO) comprising issuance data (IData) associated with the Token Issuer (TI).

The TRC may be a variable amount of cryptocurrency in that the quantity of units e.g. may change.

2. A method according to clause 1, wherein the transaction (MTx) further comprises: i) at least one input comprising a quantity of cryptocurrency (C); and/or ii) at least one input comprising the issuance data (IData). Preferably, the Issuance data is provided in the same or a different input that comprises the quantity of cryptocurrency (C).

3. A method according to clause lor 2 wherein: the issuance data (IData) comprises, or references, a digital signature controlled by and/or associated with the Token Issuer (TI).

4. A method according to any preceding clause wherein: at least one of the one or more token-related outputs (T-UTXO) comprises a unique token identifier (tokenID) associated with the token represented by the token-related output (T-UTXO).

5. A method according to any preceding clause wherein the blockchain transaction (MTx) further comprises: at least one input and/or output comprising token generation data (MR) relating to the one or more Token- related outputs (T-UTXOs).

6. A method according to any preceding clause and further comprising the step of: using a token transfer transaction (TTTX) to transfer control, to a recipient, of a particular token represented by one of the one or more token-related outputs (T-UTXOs).

7. A method according to clause 6 and further comprising the step of: using at least one further token transfer transaction (TTTXi) to transfer control of the particular token (T) to the same or a further recipient

8. A method according to clause 6 or clause 7 and further comprising the step of: providing a solution in an unlocking script of an input in the token transfer transaction (TTTx) or at least one further token transfer transaction (TTTXi) to a locking script of the token-related output (T-UTXO) that represents the particular token.

9. A method according to any preceding clause and further comprising the step of: providing a physical representation of at least one of the respective tokens represented by the one or more token-related outputs (T-UTXOs); preferably wherein the physical representation comprises means for identifying the at least one respective token.

10. A method according to any preceding clause and further comprising the step of destroying the token by: removing it from a computer-based storage resources such as a token register; publishing data relating to the destruction of the token; and/or spending an unspent transaction output (UTXO) that comprises token generation data (MR) relating to the one or more Token-related outputs (T-UTXOs).

11. A method according to any preceding clause and further comprising the step of: submitting the blockchain transaction (MTx) to a blockchain network.

12. A blockchain-implemented token transfer and/or verification method comprising the step of using and/or generating a blockchain transaction (TokenTx) comprising an input which includes a token (T) and which: i) is linked in a linear transaction history on the blockchain to a token-issuing blockchain transaction (MTx) which comprises at least one Issuer-related output (I-UTXO) associated with issuance data (IData) relating to a Token Issuer (TI) that Issued the token (T); and ii) comprises a quantity of: a) token units (TU) specified in a token-related output (T-UTXO) of the token issuing blockchain transaction (MTx); and b) token-related cryptocurrency (TRC).

13. A method according to clause 12 wherein: the blockchain transaction (TokenTx) is used and/or generated by a computing resource that is arranged to implement a tier-2 blockchain tokenisation protocol.

14. A method according to clause 12 or 13 wherein the quantity of token units (TU) is fixed such that it remains the same upon spending the input to an output (UTXO).

15. A method according to any of clauses 12 to 14 and further comprising the step of transferring the token (T) from a Sender (S) to a receiver (R) by: spending the output (UTXO) of the blockchain transaction (TokenTx) to an input (I) in a receiving blockchain transaction (RTx), wherein an index or other identifier associated with the output (UTXO) corresponds to an index or other identifier associated with the Input. 16. A digital wallet arranged and configured to use or process the method of any preceding clause. The wallet may be operative to communicate with a blockchain network. It may be operative to provide blockchain transactions to the network. The wallet is arranged to operate on a computing device such as, for example, a laptop or mobile device.

17. A computer implemented method comprising the step of: generating, storing, processing and/or maintaining a computer-based resource (R) of a plurality of token- related blockchain transaction outputs (T-UTXOs), wherein each of the outputs (T-UTXOs): i) provides a respective token (T) issued by a Token Issuer (TI) and specifies a quantity of a) token units (TU) and b) token-related cryptocurrency (TRC) associated with the respective token (T); and ii) has a linear transaction history to a blockchain transaction (MTx) that comprises at least one Issuer- related output (I-UTXO) which includes issuance data (IData) associated with the Token Issuer (TI).

18. A method according to clause 17 wherein the computer-based resource (R) is generated, stored, processed and/or maintained off-chain.

19. A method according to clause 17 or 18 wherein each token-related blockchain transaction output (T- UTXO) is generated and/or spent by a computing component arranged to implement a tier-2 blockchain tokenisation protocol and comprises at least one partially signed locking script.

20. A method according to clauses 9 to 11 and further comprising the step of: receiving, at the computer-based resource (R) from a sending device (S), a token (T) provided by one of the plurality of token-related blockchain transaction outputs (T-UTXOs); storing at least one Token (T), received from a sending device, in the computer-based resource (R); and/or sending at least one Token (T) to a receiving device, wherein the token is provided by an output (T-UTXO) selected from the resource (R) of token-related blockchain transaction outputs (T-UTXOs)

21. A computer network comprising a plurality of nodes, wherein each node in the blockchain network comprises: a processor; and memory including executable instructions that, as a result of execution by the processor, causes the system to perform the computer-implemented method of any preceding clause. The network may be, or comprise, a blockchain network.

22. A non-transitory computer-readable storage medium having stored thereon executable instructions that, as a result of being executed by a processor of a computer system, cause the computer system to perform the computer-implemented method of any one of clauses 1 to 20.

Another aspect of the disclosure may provide a computer-implemented selection/voting method and corresponding system. The method/system may comprise steps and/or devices as recited in any of the preceding clauses.

It should be noted that the above-mentioned embodiments illustrate rather than limit the disclosure, and that those skilled in the art will be capable of designing many alternative embodiments without departing from the scope of the disclosure as defined by the appended claims. In the claims, any reference signs placed in parentheses shall not be construed as limiting the claims. The word "comprising" and "comprises", and the like, does not exclude the presence of elements or steps other than those listed in any claim or the specification as a whole. In the present specification, “comprises” means “includes or consists of’ and “comprising” means “including or consisting of’. Throughout this specification the word "comprise", or variations such as “includes”, "comprises" or "comprising", will be understood to imply the inclusion of a stated element, integer or step, or group of elements, integers or steps, but not the exclusion of any other element, integer or step, or group of elements, integers or steps. The singular reference of an element does not exclude the plural reference of such elements and vice-versa. The disclosure may be implemented by means of hardware comprising several distinct elements, and by means of a suitably programmed computer. In a device claim enumerating several means, several of these means may be embodied by one and the same item of hardware. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage.

In this document we use the term ‘blockchain’ to include all forms of electronic, computer-based, distributed ledgers. These include consensus-based blockchain and transaction-chain technologies, permissioned and un-permissioned ledgers, shared ledgers, public and private blockchains, and variations thereof. As the Bitcoin ledger is the most widely known application of blockchain technology it will be used herein for ease of reference, although it should be noted that the term “Bitcoin” is intended herein to refer to any version or variation that derives from, or is based on, the Bitcoin protocol. Moreover, other non-Bitcoin blockchain implementations have been proposed and developed and alternative blockchain implementations and protocols fall within the scope of the present disclosure.

The term “user” may refer herein to a human or a processor-based resource. The skilled person will readily understand that in the art it is usual to refer to spending of cryptocurrency in terms of sending coins from one address/owner to another. However, in reality, no actual “coins” are transferred. Instead, control of ownership is transferred from one script to another. As used herein, phrases “quantity/amount/portion of cryptocurrency”, “non-negative quantity etc of cryptocurrency” and the like are intended to mean zero or more units of a cryptocurrency e.g. >= 0 Satoshi in relation to Bitcoin.

Claims

CLAIMS:

1. A blockchain-implemented token generation, transfer and/or verification method comprising: using, processing and/or generating a blockchain transaction (MTx) having: i) one or more token-related outputs (T-UTXOs), each of which represents a respective token (T) issued by a Token Issuer (TI) and specifies a quantity of a) token units (TU) and b) token- related cryptocurrency (TRC) associated with the respective token (T); and ii) at least one Issuer-related output (I-UTXO) comprising issuance data (IData) associated with the Token Issuer (TI).

2. A method according to claim 1, wherein the transaction (MTx) further comprises: i) at least one input comprising a quantity of cryptocurrency (C); and/or ii) at least one input comprising the issuance data (IData); preferably wherein the Issuance data is provided in the same or a different input that comprises the quantity of cryptocurrency (C).

3. A method according to claim lor 2 wherein: the issuance data (IData) comprises, or references, a digital signature controlled by and/or associated with the Token Issuer (TI).

4. A method according to any preceding claim wherein: at least one of the one or more token-related outputs (T-UTXO) comprises a unique token identifier (tokenID) associated with the token represented by the token-related output (T-UTXO).

5. A method according to any preceding claim wherein the blockchain transaction (MTx) further comprises: at least one input and/or output comprising token generation data (MR) relating to the one or more Token-related outputs (T-UTXOs).

6. A method according to any preceding claim and further comprising the step of: using a token transfer transaction (TTTX) to transfer control, to a recipient, of a particular token represented by one of the one or more token-related outputs (T-UTXOs).

7. A method according to claim 6 and further comprising the step of: using at least one further token transfer transaction (TTTXi) to transfer control of the particular token (T) to the same or a further recipient

8. A method according to claim 6 or claim 7 and further comprising the step of: providing a solution in an unlocking script of an input in the token transfer transaction (TTTx) or at least one further token transfer transaction (TTTXi) to a locking script of the token-related output (T- UTXO) that represents the particular token.

9. A method according to any preceding claim and further comprising the step of: providing a physical representation of at least one of the respective tokens represented by the one or more token-related outputs (T-UTXOs); preferably wherein the physical representation comprises means for identifying the at least one respective token.

10. A method according to any preceding claim and further comprising the step of: submitting the blockchain transaction (MTx) to a blockchain network.

11. A blockchain-implemented token transfer and/or verification method comprising the step of using and/or generating a blockchain transaction (TokenTx) comprising an input which includes a token (T) and which: i) is linked in a linear transaction history on the blockchain to a token-issuing blockchain transaction (MTx) which comprises at least one Issuer-related output (I-UTXO) associated with issuance data (IData) relating to a Token Issuer (TI) that Issued the token (T); and ii) comprises a quantity of: a) token units (TU) specified in a token-related output (T-UTXO) of the token issuing blockchain transaction (MTx); and b) token-related cryptocurrency (TRC).

12. A method according to claim 13 wherein: the blockchain transaction (TokenTx) is used and/or generated by a computing resource that is arranged to implement a tier-2 blockchain tokenisation protocol.

13. A method according to claims 11 or 12 wherein the quantity of token units (TU) is fixed such that it remains the same upon spending the input to an output (UTXO).

14. A method according to any of claims 11 to 13 and further comprising the step of transferring the token (T) from a Sender (S) to a receiver (R) by: spending the output (UTXO) of the blockchain transaction (TokenTx) to an input (I) in a receiving blockchain transaction (RTx), wherein an index or other identifier associated with the output (UTXO) corresponds to an index or other identifier associated with the Input.

15. A digital wallet arranged and configured to use or process the method of any preceding claim.

16. A computer implemented method comprising the step of: generating, storing, processing and/or maintaining a computer-based resource (R) of a plurality of token- related blockchain transaction outputs (T-UTXOs), wherein each of the outputs (T-UTXOs): i) provides a respective token (T) issued by a Token Issuer (TI) and specifies a quantity of a) token units (TU) and b) token-related cryptocurrency (TRC) associated with the respective token (T); and ii) has a linear transaction history to a blockchain transaction (MTx) that comprises at least one Issuer- related output (I-UTXO) which includes issuance data (IData) associated with the Token Issuer (TI).

17. A method according to claim 16 wherein the computer-based resource (R) is generated, stored, processed and/or maintained off-chain.

18. A method according to claim 16 or 17 wherein each token-related blockchain transaction output (T- UTXO) is generated and/or spent by a computing component arranged to implement a tier-2 blockchain tokenisation protocol and comprises at least one partially signed locking script.

19. A method according to claim 9 or 10 and further comprising the step of: receiving, at the computer-based resource (R) from a sending device (S), a token (T) provided by one of the plurality of token-related blockchain transaction outputs (T-UTXOs); storing at least one Token (T), received from a sending device, in the computer-based resource (R); and/or sending at least one Token (T) to a receiving device, wherein the token is provided by an output (T-UTXO) selected from the resource (R) of token-related blockchain transaction outputs (T-UTXOs)

20. A computer network comprising a plurality of nodes, wherein each node in the computer network comprises: a processor; and memory including executable instructions that, as a result of execution by the processor, causes the system to perform the method of any preceding claim.

21. A non-transitory computer-readable storage medium having stored thereon executable instructions that, as a result of being executed by a processor of a computer system, cause the computer system to perform the computer-implemented method of any one of claims 1 to 20.