Field

This disclosure relates generally to methods and systems for electronic exchange between parties. Examples 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. More specifically, the invention generally resides in: a blockchain-implemented token generation, transfer and/or verification method that uses, processes and/or generates a blockchain transaction. In particular, the invention resides in configuring and/or grading the token origin e.g. cryptocurrency for use in atoken ledger. The invention also resides in 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 using configured and/or graded tokens.

Background

The Bitcoin blockchain ledger as introduced in 2008 by Satoshi Nakamoto’s whitepaper (https://bitcoin.org/bitcoin.pdf) is the most widely known blockchain and associated network/platform in use today. Therefore, Bitcoin is referred to in the examples used herein. Examples of the disclosure are not limited in this regard and alternative blockchain protocols and implementations fall within the scope of the present disclosure. 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. One example includes 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 digital or otherwise. Blockchain tokenisation technologies provide numerous technical advantages such as improved security, efficiency, ease of use and enhanced network privacy. A blockchain tokenisation solution is known from WO2021/250022 which is incorporated by reference herein in its entirety. In particular, Figures 9a and 9b and the associated description illustrate and describe schematic diagrams of a token ledger and subledger.

However, known tokenisation approaches also face numerous technical challenges, including: enabling an efficient determination of the origins of a token, which can be via a linear transaction history; determining the origin of the token ledger and/or the origin of the underlying UTXO; maintaining privacy while inhibiting anonymity; and improving transparency. UTXO origins in a cryptocurrency ledger are traceable back to the coinbase transaction that created it. A token ledger operates in parallel to the cryptocurrency ledger, and when a recipient of a token verifies its authenticity it can do so by referring back to its own creation. This efficiency can be achieved because the token has a linear transaction history i.e. the token transaction history from the latest transaction to the issuing transaction involves no forks or loops. Summary

The invention generally resides in a method of creating a token ledger, the method comprising: receiving a compiled transaction output, said output including script that defines a set of transactions that define a token ledger; and (i) compiling a block on a public blockchain, said block including the script in the reward transaction coinbase transaction, or (ii) applying the script to the output of the reward transaction. Bitcoin’s scripting language is referred to a Script. Transactions are written in script, thus script can be said to define or determine a transaction. Script defines, describes or determines a set or sequence of executable instructions - typically in the form of one or more transaction outputs. Script can be used to at least one of lock and unlock bitcoin, build applications and run programs. Script can be used to determine complex transaction setups, such as creating multisig addresses, managing smart contracts and creating and managing token ledgers.

Overall, the script is used to create token ledgers and the associated cryptocurrency supporting the tokens, wherein the script allocates cryptocurrency from a reward transaction to said token ledger. In this way, the token ledgers and the tokens therein can be described as having determinable and unimpeachable provenance, e.g. directly derivable from the subsidy of a reward transaction e.g. a coinbase transaction and associated cryptocurrency.

In one aspect there resides a computer-implemented method comprising: compiling a block for a cryptocurrency blockchain, wherein the block includes a reward transaction configured to output a quantity of cryptocurrency for completing a block that is accepted as a block in the blockchain; and configuring an output of the reward transaction using and/or including a script wherein the script defines, at least in part, a set of transactions that defines a token ledger comprising blockchain- implemented tokens, said tokens using the quantity of cryptocurrency. To be clear, while all the cryptocurrency of the reward transaction can be assigned for use in the token ledger, the invention is not so limited - hence the use of the term “a” quantity, to refer to at least one unit of cryptocurrency and using “the” to refer to said at least one unit of cryptocurrency. The block can then be transmitted for addition to the blockchain of the cryptocurrency blockchain network. Transmission can be by the compiler of the block, or other party. The method can further include receiving, using, processing and/or generating the script that defines the set of transactions for blockchain-implemented token generation. The set of transactions can be configured can be included in the script in at least one transaction output. The set of transactions can be configured to determine a plurality of token ledgers. The set of transactions can be configured in the script of a plurality of transaction outputs. The set of transactions can be configured in the script to determine one token ledger per transaction output.

By incorporating the script in the reward transaction e.g. Coinbase transaction (CBTx) or applying the script to the output, or otherwise including the script in the output of the reward transaction then unused cryptocurrency is used by the token ledger. In other words, the script defining at lest one output is embedded in the coinbase transaction. This provides tokens whose performance is improved e.g. efficiency of processing that subsequently reduces the computational cost of managing a token ledger established using unused cryptocurrency. Unused cryptocurrency derived from the coinbase transaction can be described as the amount of cryptocurrency that has not been processed e.g. subjected to a transaction on the blockchain outside of the coinbase transaction.

By generating and/or initiating a token ledger in the coinbase transaction it is established with zero history and/or providence. Such a token ledger can be accepted and validated in advance of subsequent acts of determining its origin and/or its acceptance by subsequent blocks.

The script can be configured to inhibit the definition, creation, generation or initiation, or otherwise, of the token ledger unless the source of the proof-of-work e.g. the hash-machine meets predetermined criteria e.g. its source of power was from a renewable energy source or that the hashmachine was located in a predetermined safe-list of locations. The token ledger can label the token with the source of origin of the hash-machine that determined the proof-of-work that was required by the blockchain node that produced the coinbase transaction that defined, created, generated or otherwise initiated the token ledger.

The set of transactions represents at least one of: a root node holding a digital identity; a digital signature; and a certificate of the issuer and/or authority responsible for tokens on the token ledger. In this way these parameters are embedded in the creation of the token ledger. A ‘node’ in this sense is a transaction e.g. a root transaction. A viewer of the set of transactions can inspect the blockchain history, wherein the set of transactions can be processed to determine a definition of the token ledger and/or the tokens to be minted. In this sense, the term ‘represents’ means that the or each transaction includes script that when executed or analysed enables the determination of such information and/or parameters.

The parameters defined in the set of transactions can be at least one of the features, operations requirements, ownership details of the token ledger that can be inspected either directly from the blockchain or via a link to an off-chain resource. By way of non-limiting example, parameters can include a token transaction output defining at least one of: creation of the database format and/or a master token, wherein the database format and/or parameters includes at least one of the database name, ownership rights and wrapper; an administration writechain, including an administration token, wherein the parameters and/or output of the token define access rights and/or authorisation levels; a modification of access rights of any token derived therefrom on the writechain; creation of a further writechain, including a further token, said token assignable to a person and/or a process; creation of an entity of the database, wherein the entity is assigned a name and/or reference; an update to an entity of the database, wherein a new parameter is added to the database and/or an existing parameter is updated; a termination output indicating that any further transaction from said token is null and void, thus indicating the end of the writechain.

Parameters can be referenced during subsequent operation of the token ledger. A transaction can include a header followed by a set of parameters. The parameters can include instructions that enable a user to operate and/or engage with a token ledger. The method can further comprise: compiling a subsequent block for the cryptocurrency blockchain, wherein the subsequent block includes a subsequent reward transaction configured to output a quantity of cryptocurrency; processing a second script, which includes a record of activity of the token ledger, the record comprising at least one of: a token ledger transaction; a batch of token ledger transactions; and/or encoded content thereof; and configuring an output of the subsequent reward transaction to include the second script, wherein the second script includes the record; and transmitting the block for addition to the cryptocurrency blockchain network. Not only can a record of the creation of the token ledger be included in the reward transaction but a record of token ledger transactions can also be included on the output of the reward transaction e.g. with an OP RETURN. This supports the token ledger operation off-chain, while records of token ledger transactions can be recorded on-chain e.g. in the output of a coinbase transaction.

In another aspect, there resides a computer-implemented method comprising: using, processing and/or generating a script that defines a set of transactions for blockchain-implemented token generation; providing the script to a block creator for compilation into a block of a cryptocurrency blockchain, wherein the block includes a reward transaction configured to output a quantity of cryptocurrency for completing a block that is accepted as a block in the blockchain, and wherein an output of the reward transaction includes the script wherein the script defines, at least in part, a token ledger for blockchain-implemented tokens, said tokens using the quantity of cryptocurrency; and using, processing and/or generating the server-based token ledger upon a computer-based resource, such as a server. The teaching herein can be applied to a computer-based resource e.g. a server, such as a serverbased token ledger supporting a private token ledger. Such a resource can prepare the script for a node for inclusion in the reward transaction and receive the tokenised cryptocurrency. The ‘node’ is the miner or node operator that solved the proof of work and established the block that allocated cryptocurrency for use in the token ledger.

The computer-based resource can receive, use and/or process tokens derived from the script. The genesis block of the server-based token ledger can be created after the block that generated the token ledger, or part thereof, comprising tokens, is confirmed and/or accepted by the blockchain network.

The token ledger can have one or more token-related outputs, each of which represents a respective token issued by a Token Issuer and specifies a quantity of a) token units and b) token-related cryptocurrency, derived from said reward transaction, associated with the respective token.

The set of transactions can represent at least one of: a root node holding a digital identity; a digital signature; and a certificate of the issuer and/or authority responsible for tokens on the token ledger. In other words, the set of transactions contain script that represents such information and/or parameters.

The set of transactions include at least one of: an inaugural transaction, which includes a digitally signed certificate of an authority of the token ledger; a token definition transaction that defines the format of the tokens to be created on the ledger; a token issuance transaction, wherein a token is transferred to a user; and a token refresh transaction, which functions as an authorized reference point on the ledger against which a linear transaction history is verifiable. The or each of the set of transactions can include a digitally signed certificate of an authority that will manage the token ledger.

The reward transaction can be a coinbase transaction and/or include an unspent transaction output (UTXO), preferably a new UTXO.

The aspects herein can use, process and/or generate a second script, which includes a record of activity of the token ledger, the record comprising at least one of: a token ledger transaction; a batch of token ledger transactions; and/or encoded content thereof; and provide the second script to a block creator for compilation into a subsequent block of a cryptocurrency blockchain, wherein the subsequent block includes a subsequent reward transaction configured to include the second script that includes the record of a quantity of token transactions on the server-based token ledger.

Each token and/or the token ledger has a tag, wherein said tag determines a function and/or permission(s) of the token. A tag can be used to indicate the authority of a token, its origin and/or determine its functionality. When processing the second script, or a subsequent script, token data can be parsed to identify the tag and compiling a subsequent block can be limited to include a record of activity of the token ledger only for those tokens having the tag. By way of example, the script can include an identification of the owner of the token or token ledger e.g. the tokens and its ledger is managed by the Bank of England and, therefore, the tag or identification can be used to manage transactions - and the Bank of England can exclude and/or inhibit token transfer unless a token includes a ‘tag’ indicating, for example, that the token originated from a coinbase transaction that created a token ledger for the Bank of England. In another example, the tag can identify that the underlying cryptocurrency was mined in a particular country e.g. USA, and transactions can be restricted to tokens having a particular tag e.g. the token was based upon cryptocurrency mined in the USA.

The or each reward transaction or subsequent reward transaction can output a quantity of new cryptocurrency, and the token ledger uses the quantity of new cryptocurrency.

In another aspect, there resides 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, wherein each of the outputs: provides a respective token issued by a Token Issuer and specifies a quantity of a) token units and b) token-related cryptocurrency associated with the respective token, wherein token-related cryptocurrency was obtained from a reward transaction configured to output a quantity of cryptocurrency for completing a block that is accepted as a block in the blockchain, and wherein the token-related cryptocurrency is processed and/or generated by a script that defines a set of transactions for blockchain-implemented token generation, wherein the script defines, at least in part, a token ledger comprising blockchain-implemented tokens, said tokens using the quantity of cryptocurrency; and has a linear transaction history to said reward transaction. The computer-based resource (R) can be generated, stored, processed and/or maintained off- chain. Each token-related blockchain transaction output can be 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.

In another aspect there resides 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 methods taught herein.

In another aspect there resides 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 taught herein. The tokens and token ledgers configured according to the aspects of the invention improve the operating efficiency by reducing the computational cost associated with token management. This is achieved by creating a token and token ledger in a new way.

Brief Description of the Drawings

Aspects and examples 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 schematic representation of a cryptocurrency ledger including blocks, wherein said ledger and/or blocks are used to establish a token ledger;

Figure 2 is a schematic representation of a cryptocurrency ledger including blocks, wherein said ledger and/or blocks are mirrored in a private ledger supported upon a server, and the transactions are synchronously aligned; and

Figure 3 is analogous to Figure 1, except wherein transactions are asynchronously aligned;

Figure 4 is a schematic representation of transactions establishing graded ledgers;

Figure 5 is another schematic representation of transactions establishing graded ledgers;

Figure 6 is yet another schematic representation of transactions establishing graded ledgers;

Figure 7 is a schematic of a system including a computer-based resource configured to implement the methods taught herein.

Detailed Description - overview

Background

Examples of use cases are now provided for the purpose of illustration, without limitation. As explained above, for the sake of convenience only, “Bitcoin” is used herein as it is a well-known and widely used blockchain protocol. Examples of the disclosure may be implemented on the Bitcoin protocol, platform and cryptocurrency ledger, although this and the references to Bitcoin are not intended to be limiting and, therefore, the scope of examples of the present disclosure is not thus restricted. A cryptocurrency ledger can, for example, be maintained privately on a computer-based resource, such as a server. Such a privately maintained ledger, or record thereof, can be linked to the public blockchain ledger.

The following description relates to tokens, and in particular the creation of a token ledger and the tokens derived from said token ledger, which is used to manage and monitor the status of said tokens. Tokens can be created having different properties and their different types include: tokens created with a fixed value, which are referred to as static tokens; tokens created with an initial value that is changeable during a transaction, which are referred to as dynamic tokens; sub-tokens, which can be derived from a dynamic token during transactions that can reside in digital or physical form that can be spent into any compatible dynamic token during a transaction, these sub -tokens being configurable in a number of formats. Tokens with different properties are described in WO2021/250022, which is incorporated by reference herein in its entirety.

Known tokens are referred to herein as “standard” tokens, which can be created using any random unit of cryptocurrency. Known tokens utilise existing cryptocurrency, and each unit of cryptocurrency can have its own unique history that can be traced back to its creation. By way of example, a token ledger can have 100 tokens, each of which has an associated unit of cryptocurrency e.g. 100 satoshis. Validating a unit of cryptocurrency can include a simplified payment verification (SPV) or the recipient holding a copy of the blockchain and tracing the transaction history to determine the authenticity of the unit of cryptocurrency. Prior to the mint of a new token, or the receipt of a new token, which is based on a unit of cryptocurrency, the authenticity and validity can be determined. Unfortunately, the required validation of each unit of cryptocurrency e.g. 100 units, requires processing a history of a myriad of transactions for the history of each unit, thus requiring significant processing cost. Moreover, while a transaction history can be established, the use of the cryptocurrency or the means by which it was obtained can be illegal or lack security. Validating a token, even after issue, can require tracing the history of each token, which involves a computational processing cost. Failure to validate a token or its source of cryptocurrency can lead to their value and/or their security being deemed worthless or ineffective if, for example, either were involved in illegal activity or obtained illegally.

In the examples taught herein, tokens can be created having different grades. The grade of a token can determine the efficiency at which the origin of the token can be determined, which can be via a linear transaction history. The grade can also determine the transparency of the origins of the token. As described above, known tokens are referred to as “standard” tokens, that are used in “standard” ledgers.

The tokens created in the examples herein include “non-standard” tokens and are referred to, by way of example, as either (i) “treasury”, wherein the tokens and token ledger grade can be described as having determinable and unimpeachable provenance, e.g. directly derivable from the subsidy of a reward transaction e.g. a coinbase transaction and (ii) “recycled” grade, wherein the tokens and token ledger grade can be described as having determinable provenance, e.g. directly derivable from the fees included in the transactions compiled in a block e.g. those fees in a coinbase transaction not attributable to a subsidy.

Creating tokens

Figure 1 illustrates the relationship between a cryptocurrency ledger and a token ledger, wherein the creation of the token ledger begins with a “mint” action for establishing tokens, wherein a set of transactions are used for a token ledger establishment. Establishing a token ledger and associated tokens includes obtaining and subsequently processing an amount of cryptocurrency, which can be subsequently allocated to tokens in a minting transaction having one or more token-related outputs, each of which represents a respective token issued by a Token Issuer.

In Figure 1, the set of transactions responsible for establishing a token ledger and minting tokens is shown distributed across three blocks i.e. N-l, N and N+l. The set includes: an inaugural transaction, which can function as a root node holding digital identities and/or digital signatures of the issuer and/or authority responsible for the tokens, which can also include additional signatures from, for example, a governmental or regulatory authority; an establishment or definition transaction, that determines the format of the token; and a minting transaction in which tokens are issued. The subsequent token ledgers for each denomination of token e.g. “Token X” and “Token Y” can have a direct relationship with the block in which the cryptocurrency ledger. It is to be noted that the set of transactions can be included in a single block.

Set-up

Compiling the block can include determining a proof of work (PoW) or proof of stake (PoS) or other such means. A node that successfully determines the next block in the chain is provided with a fee by way of recompense for establishing the block. The fee can be provided in a transaction that includes a quantity of cryptocurrency. The fee can be paid in a reward transaction. Using the BSV blockchain, by way of example, a node that transmits a block to the blockchain network is compensated by a reward transaction, which can include the fees e.g. gas associated with each of the transactions in said block and/or a block subsidy. The node, therefore, receives cryptocurrency via a reward transaction that includes: fees that have been validated and/or authenticated by said node; and new cryptocurrency allocated to the node in the form of a subsidy. In the case of a reward transaction of a block, the node allocates itself a quantity of cryptocurrency e.g. via a coinbase transaction (CBTx) that it adds to the transactions received from the network for recordal in a block. Coinbase transactions are well known (ht s : //wiki . bitcoin s . io/in d ex.php/Coinbase) and are representative of a reward transaction used by the invention, and coinbase transactions will be referred to herein by way as a non -limiting example. Alternative reward mechanisms can apply the teaching of the examples herein.

In Figure 1, a set of transactions has been compiled in a script. The script defines a set of transactions of a token ledger. The script can be created by a node or received by a node e.g. by a Token Issuer or Authority that compiled the script. The node compiles a block for transmission on the blockchain network for inclusion in the blockchain as the next block in the chain and includes the script in the output of the reward transaction e.g. the script is embedded in the coinbase transaction. When the block including the script is transmitted across the blockchain network and subsequently accepted as a valid block by the network the set of transactions defining the token ledger are recorded on -chain.

Figure 1 illustrates that different transactions within the set of transactions are recorded in different blocks e.g. each of the root, definition, and mint transactions of the set of transactions are included in respective outputs of the reward transactions for respective blocks. It is to be noted that the set of transactions does not need to be in sequential blocks. One of the set of transactions allocates a portion of the cryptocurrency in the reward transaction to the tokens of the token ledger being established by the script. In the examples below, the set of transactions e.g. each of the root, definition and mint transactions are included together in a script output in a reward transaction e.g. CBTx of a single block.

The method herein includes receiving, using, processing and/or generating a script that defines a set of transactions for blockchain-implemented token generation. The authority that manages the token ledger e.g. Token Issuer can prepare the script, or a node can receive a token ledger specification and compile the script for inclusion in a reward transaction. The node compiles a block for a cryptocurrency blockchain, wherein the block includes a reward transaction configured to output a quantity of cryptocurrency for completing a block that is accepted as a block in the blockchain. The reward transaction output is configured to include the script. The script defines, at least in part, a token ledger comprising blockchain-implemented tokens, said tokens using the quantity of cryptocurrency. The block is then transmitted for addition to the blockchain of the cryptocurrency blockchain network.

Overall, a miner can be provided with a template for a transaction that has at least one output that includes script that defines an inaugural transaction e.g. a root node of a token ledger, which uses cryptocurrency created and/or processed in the reward transaction.

Cryptocurrency normally acquired by the node from the reward transaction is attributed to the token ledger. For example, the block subsidy on the BSV platform is currently 6.25BSV, which is included in the reward transaction together with the fees e.g. 3.75 BSV gathered from the other transactions in the block - and the script is included on the output of the reward transaction. In this example, the script can allocate up to 10 BSV to the token ledger - in this way, the script can implement up to 1,000,000,000 tokens on the basis of one token per satoshi. The script cannot allocate more satoshis than there are available in the reward transaction

The cryptocurrency underpinning the token ledger established using the methods herein support efficient determination of the origins of a token and/or the associated cryptocurrency because the origin of the cryptocurrency and the creation of the token can be attributed to the reward transaction of a block. Determining the origin of the token ledger and/or the origin of the underlying cryptocurrency, therefore, can be achieved efficiently, while maintaining privacy, inhibiting anonymity and supporting transparency. The set of transactions can include or otherwise represent at least one of: a root node holding a digital identity; a digital signature; and a certificate of the issuer and/or authority responsible for tokens on the token ledger. The or each of these means of authentication is complimented by (i) the inclusion of the set of transactions on the output of the reward transactions token ledger, thus inherently including the authority of the node, and (ii) the use of cryptocurrency derived from the reward transaction e.g. new cryptocurrency e.g. virgin-satoshis.

While a token ledger can be maintained on the blockchain, it can additionally or alternatively be maintained on a separate private ledger. Figure 2 illustrates a public blockchain and a corresponding private ledger residing on a server, or other such computer-based resource.

In both Figures 1 and 2 it can be appreciated that the issue and/or use of tokens can occur after the token ledger and associated tokens have been established. This is because the use of the token ledger that was established on the output of a reward transaction, e.g. CBTx, is pending depending on the acceptability of the block containing the reward transaction by the blockchain network. An authority, such as a Token Issuer, managing the token ledger can wait until 6, 10 or even 100 blocks have been created before accepting that the token ledger has been sufficiently established on -chain. A genesis block of a server-based token ledger can be created after the block that generated the token ledger, or part thereof, comprising tokens, is confirmed and/or accepted by the blockchain network.

The private ledger can be maintained substantially simultaneously with the blockchain token ledger on the blockchain. Blocks in the private ledger can be maintained and be recorded on-chain to correspond to the blocks of the public blockchain. Alternatively, as shown in Figure 3, the private ledger can be maintained and be recorded on chain asynchronously from the blockchain ledger on the public blockchain. Figure 3 illustrates that transactions (pTx) can be recorded on the server and said records can be placed on-chain independently of the token transactions. The record on-chain can comprise at least one of: a token ledger transaction; a batch of token ledger transactions; and/or encoded content thereof e.g. a hash value record of a transaction or a batch of transactions.

A batch of transactions can be collated in a private ledger, with the history of the token transactions recorded asynchronously on the public blockchain. This means that each token transaction, or record thereof, is visible and accessible on the blockchain by searching each transaction and/or verifying the linear transaction history. In the example of Figure 3, a script has been provided to the node of Block N, and this has been included in the reward transaction to define tokens of the token ledger. To be clear, ‘node’ of Block N is the miner or node operator that solved the proof of work and established the block that allocated cryptocurrency for use in the token ledger.

Thereafter, the private ledger has collated token transactions and transmitted bundles of transactions, or their records, for broadcast on the blockchain network for inclusion in the next block that contains, for subsequent processing, said bundle of collated transactions. In Figure 3 those bundles have been included in Block N+100 and Block N+102. Alternatively, said bundle of collated transactions can be provided to a miner for inclusion in the output of their coinbase transaction. Collated transactions can be broadcast on the public blockchain network and/or recorded in the output of a coinbase transaction of a subsequent block on the public blockchain. Collated transactions can be encrypted prior to recordal on the public blockchain, which can maintain privacy.

Updating

Following the establishment of a token ledger on a blockchain, a node, or another node, can compile a subsequent block for the cryptocurrency blockchain, wherein the subsequent block includes a subsequent reward transaction configured to output a quantity of cryptocurrency. A second script can be generated or processed, which includes a record of activity of the token ledger. The record comprises at least one of: a token ledger transaction; a batch of token ledger transactions; and/or encoded content thereof. The node, or the another node, can configure an output of the subsequent reward transaction to include the second script, wherein the second script includes the record, and then transmit the block for addition to the cryptocurrency blockchain network. In this way, the token ledger can be maintained on the blockchain by recording the transaction history on the output of a reward transaction.

The authority responsible for the creation and subsequent management of the token ledger can be a node, or a group of nodes. Alternatively, the token ledger authority supports the token ledger independently, and cooperates with a node or group of nodes to establish the ledger and hold records.

In the case that a token ledger is established and/or managed independently, the token ledger authority can use, process and/or generate a script that defines a set of transactions for blockchain- implemented token generation, and provide the script to a block creator e.g. a node, for compilation into a block of a cryptocurrency blockchain. As described above, the block includes a reward transaction configured to output a quantity of cryptocurrency for completing a block that is accepted as a block in the blockchain. The output of the reward transaction includes the script wherein the script defines, at least in part, a token ledger for blockchain-implemented tokens, said tokens using the quantity of cryptocurrency. The server-based token ledger is subsequently used by, processed by, and/or generated upon a computer-based resource, such as a server. Once established, the published script in the reward transaction functions to enable the computer-based resource to receive, use and/or process tokens derived from the script.

Maintaining a record of a token ledger can include using, processing and/or generating a second script, which includes a record of activity of the token ledger, the record comprising at least one of: a token ledger transaction; a batch of token ledger transactions; and/or encoded content thereof; and providing the second script to a block creator for compilation into a subsequent block of a cryptocurrency blockchain, wherein the subsequent block includes a subsequent reward transaction configured to include the second script that includes the record of a quantity of token transactions on the server-based token ledger.

Token format

The token ledger can have one or more token-related outputs, each of which represents a respective token issued by a Token Issuer and specifies a quantity of a) token units and b) token-related cryptocurrency, derived from said reward transaction, associated with the respective token. The set of transactions can represent at least one of: a root node holding a digital identity; a digital signature; and a certificate of the issuer and/or authority responsible for tokens on the token ledger. The set of transactions includes e.g. contains script that determines at least one of: an inaugural transaction, which includes a digitally signed certificate of an authority of the token ledger; a token definition transaction that defines the format of the tokens to be created on the ledger; a token issuance transaction, wherein a token is transferred to a user; and a token refresh transaction, which functions as an authorized reference point on the ledger against which a linear transaction history is verifiable. The or each transaction of the set of transactions can include a digitally signed certificate of an authority that will manage the token ledger.

The reward transaction can be a coinbase transaction and/or includes an unspent transaction output (UTXO), preferably a new UTXO.

A subsequent reward transaction can have a deterministic relationship with at least one of: the block header; the block data, including the transaction data and/or the Merkle -tree of the transaction data; and a version identification of the block. In this context, the deterministic relationship is intended to mean that the block header, block data, and/or version identification of the block is determinable from the subsequent reward transactions, and/or vice-versa. In this way, a record of token transactions e.g. initially recorded and/or managed off-chain can be added to the output of a coinbase transaction, wherein the relationship is linked with at least one other coinbase transaction that created the token ledger and/or recorded transactions of the token ledger. The deterministic relationship enables quick and efficient computational validation of the token ledger and/or the tokens therefrom.

Tag I Grades

In addition to the methods herein teaching a new mechanism for generating tokens within a token ledger that improve efficiency and security, wherein said properties are derived from the use a script on the output of a reward transaction e.g. CBTx, the script can add a tag to at least one of: the cryptocurrency assigned to the token ledger; the tokens based on the cryptocurrency derived from the script; the root node; the token definition; issuance data; and minting transaction.

The tag is a set of data that indicates and/or determines at least one of the function, permission, authority and provenance of the token ledger and/or tokens of the token ledger. The tag can be included on an output with zero cryptocurrency value e.g. a false-output, such as an OP RETURN. Alternatively, it can be stored on a normal spendable output.

The tag can indicate the “grade” of a token ledger and the tokens therein. The tag can be included in the script and, for example, indicate (i) a “treasury” grade, wherein the tokens and token ledger grade can be described as having determinable and unimpeachable provenance, e.g. directly derivable from the subsidy of a reward transaction e.g. a coinbase transaction or (ii) a “recycled” grade, wherein the tokens and token ledger grade can be described as having determinable provenance, e.g. directly derivable from the fees included in the transactions compiled in a block e.g. those fees in a coinbase transaction not attributable to a subsidy.

Grades of tokens can be determined from tag data that includes, by way of non-limiting examples, (i) Miner identity, such as a valid Miner ID format, (ii) the location and/or jurisdiction of the ASICs that determine the proof of work (PoW), (iii) the entity that provided the Proof of Stake (POS), (iv) the energy source(s) used by the ASICs, (v) a breakdown of the cryptocurrency output from the reward transaction to the token ledger e.g. was the cryptocurrency part of the subsidy, or fees, and (vi) ownership and/or digital signature details of the token ledger, if known.

Tokens can be selectively processed based on the tag. For example, a node or a set of nodes will only process token transactions if the token and/or the underlying cryptocurrency has been tagged e.g. indicating the source of said cryptocurrency and/or token i.e. generated from a reward transaction. For example, when processing a second script, or a subsequent script, token data is parsed to identify the tag, and compiling a subsequent block to include a record of activity of the token ledger is restricted for those tokens having a valid tag.

Grade examples

Figures 4 and 5 illustrates an example in which a reward transaction has an input and an output in the form of a “coinbase” transaction e.g. the reward transaction, having a value of 10BSV. The output of the reward transaction is configured using predetermined script to create different outputs. It is well known that coinbase transactions do not have a cryptocurrency input and operate as a generation transaction. The term “input” in these figures, therefore, is used to represent the total value of cryptocurrency that is available as an input to the token ledger, said input value ’ s maximum value being sum of the miner subsidy and the mining fees paid by all other transactions included in the block.

In Figure 4, the three outputs, as shown, namely:

Tx Out 0, which has no cryptocurrency value and documents the creation of two pots of cryptocurrency for use in a token ledger. This output can be, for an example, a false-output, such as an OP RETURN. It is to be noted that Figure 4 describes “Ledger Bond Mint Data”, wherein the term “bond” has been used to describe the limitations placed on the satoshis allocated to the created token ledgers.

Tx Out 1, which has a value of 6.25 BSV (which is the current value of the BSV block subsidy awarded to successful nodes). Figure 4 describes the output as “Treasury Grade Ledger Bond” and indicating that 6.25 BSV has been assigned to this pot of tokenizable satoshi. The term ‘treasury’ has been used because those tokenised satoshis have characteristics that (i) enable efficient determination of the validity of said tokens, and (ii) said tokens and token ledger are immutable in their source of origin, because their source is not a myriad of blocks and their transaction history is not complicated - the underlying satoshis are assigned to the token ledger in their unused, or virgin state.

Tx Out 2, which has a value of 3.75 BSV (in this example this is the acquired fees from the other transactions in the blocks). Figure 4 describes the output as “Recycled Ledger Bond” and indicating that 3.75 BSV has been assigned to this pot of tokenizable satoshi. The term ‘recycled’ has been used because those tokenised satoshis have characteristics that enable efficient determination of the validity of said tokens because their source is not a myriad of blocks, and their transaction history is not complicated. While the satoshis allocated to the ‘recycled’ ledger bond have been used in previous transactions, their performance is greater than ‘standard’ tokenised satoshis, because their issue can be associated with the reward transaction e.g. CBTx of a single block.

Figure 5 illustrates that the output of the reward transaction e.g. CBTx is 10BSV can be allocated to a plurality of different token ledgers, provided the total of the outputs does not exceed the total of the inputs e.g. the total of the block reward, which includes the subsidy and the fees, for each grade of token ledger. By way of example, the 6.25 BSV available from the block subsidy is divided evenly between ‘TX Out 1’ and ‘TX Out 2’, each having a value of 3.125BSV. Similarly, the 3.75 BSV acquired from transaction fees is divided between ‘TX Out 3, having a value of 2 BSV and ‘TX Out 4’, having a value of 1.75 BSV.

As described above, a node can receive, use, process and/or generate a script that defines a set of transactions for blockchain-implemented token generation. The reward transaction can include the script directly. Additionally or alternatively, the reward transaction can transfer the cryptocurrency from the reward transaction to node operator, and the output of this reward transaction can use the script as described above. In each case the cryptocurrency, derived from the reward transaction and attributed to the node or transferred to the node, retains its unused or virgin status. To be clear, the script can be used “in” the reward transaction or “applied to” the reward transaction.

Figure 6 illustrates how three reward transactions e.g. three coinbase transactions with each individual output having a value of 10 BSV can be used to create two outputs, namely: Tx Out 1-1, which has a value of 18.75 BSV (which is three-times the current value of the BSV block subsidy awarded to successful nodes); and Tx Out 1-2, which has a value of 11.25 BSV (in this example this is three-times the value of the acquired fees from the other transactions in the blocks).

Further details

The secure exchange of scripts and the subsequent token ledgers can be controlled to allow for the solutions to be exchanged securely and for the token ledgers to be used in the construction of on- chain artifacts. By way of example, upon redemption e.g. redemption of the transaction of the token ledger, a token ledger can release an R-puzzle allowing a reward transaction output or a single source derivative of reward transaction output to be used. Ownership can thus be traded by passing the k-value that corresponds to the R-Puzzle in the script to be used.

System

Overall, a computer-based resource (R), such as a server, can generate, store, process and/or maintain of a plurality of token -related blockchain transaction outputs, wherein each of the outputs: provide a respective token issued by a Token Issuer and specifies a quantity of a) token units and b) token-related cryptocurrency associated with the respective token, wherein token-related cryptocurrency was obtained from a reward transaction configured to output a quantity of cryptocurrency for completing a block that is accepted as a block in the blockchain, and wherein the token-related cryptocurrency is processed and/or generated by a script that defines a set of transactions for blockchain-implemented token generation, wherein the script defines, at least in part, a token ledger comprising blockchain-implemented tokens, said tokens using the quantity of cryptocurrency; and has a linear transaction history to said reward transaction.

The token ledger of the computer-based resource (R) can be generated, stored, processed and/or maintained off-chain. Each token-related blockchain transaction output (T-UTXO) can be 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.

In another example, a computer network comprises 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 described herein. In another example, there is 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 described herein.

An example of a computer-based resource, such as a device, is shown in Figure 7, wherein a device 100 can be scalable in size and across different locations to implement an aspect or method of the invention described herein. The device can also be representative of an input device such as a sensor or an output device such as an actuator. The device 100 includes a bus 102, at least one processor 104, at least one communication port 106, a main memory 108 and/or a removable storage media 110, a read only memory 112 and a random -access memory 114. The components of device 100 can be configured across two (2) or more devices, or the components can reside in a single device 10. The device can also include a battery 116. The port 106 can be complimented by input means 118 and output connection 120. The processor 104 can be any such device such as (but not limited to) an Intel(R), AMD(R) or ARM processor. The processor may be specifically dedicated to the device. The port 106 can be a wired connection, such as an RS-232 connection, or a Bluetooth connection or any such wireless connection. The port can be configured to communicate on a network such a Local Area Network (LAN), Wide Area Network (WAN), or any network to which the device 100 connects. The read only memory 112 can store instructions for the processor 104.

The bus 102 communicably couples the processor 104 with the other memory 110, 112, 114, 108 and port 106, as well as the input and output connections 118, 120. The bus can be a PCI /PCI-X or SCSI based system bus depending on the storage devices used, for example. Removable memory 110 can be any kind of external hard-drives, floppy drives, flash drives, for example. The device and components therein are provided by way of example and does not limit the scope of the invention. The processor 104 can implement the methods described herein. The processor 104 can be configured to retrieve and/or receive information from a remote server or other device. The device 100 can also support a collection of computer-based resources e.g. servers 122, with individual servers 124, 126, 128, 130, 132 assigned to separate private token ledgers.

Overview

The token ledger originates in a reward transaction e.g. CBTx and is defined and/or created therein to enable efficient verification of a token derived therefrom. Rather than that reviewing the transaction history for each unit of cryptocurrency and/or token i.e. from one unit to many transactions e.g. 100 different tokens each having an associated satoshi requires 100 different transaction histories to be validated, the methods herein enable many validations to reference a single transaction in a known block e.g. in Figure 1, the linear transaction history leads back to the coinbase transaction in Block N- 1. Moreover, the source of the script and/or any cryptocurrency attributed to said script is traceable back to the mining node that established the ledger in their coinbase transaction.

The additional transactions can be added to the output script of the coinbase transaction by the same miner or a different miner from the one that added the set of transactions to Block N- 1. The output e.g. UTXO of the subsequent token transaction can be compiled on the output of the coinbase transaction of the subsequent block.

Each and every token ledger transaction, or a derivation thereof, can be added to the output script of a coinbase transaction. For example, one or more miners can manage a token ledger and ensure that every transaction in a token ledger is recorded in the coinbase transaction output.

In practice, however, the frequency of token transactions can be different from the frequency at which blocks are established and, therefore, token transactions made in a private ledger can be recorded on the public blockchain (i) in the data block, amongst routine transactions and/or (ii) managed by a server and communicated to the public blockchain e.g. cryptocurrency ledger for recordal thereon.