Improvements in or relating to digital asset management in distributed ledger systems

Abstract

A system for recording and transferring digital assets featuring: (a) generate, for each transaction, output receipt identifiers (Receipt IDs), each Receipt ID being uniquely derived from transaction data and blockchain state parameters; (b) maintain a receipt state structure comprising an unspent list, a spent list, and an in-progress list; (c) upon a transfer transaction, identify one or more input Receipt IDs and temporarily classify the input Receipt IDs as in-progress; (d) determine whether: (i) each input Receipt ID is valid and unspent; (ii) a digital signature associated with the transaction is valid; and (iii) a total quantity represented by the input Receipt IDs equals a total quantity represented by the output Receipt IDs; (e) upon satisfying validation criteria, atomically: (i) classify each input Receipt ID as spent; (ii) record each output Receipt ID as unspent; and (iii) update a blockchain ledger with a transaction record referencing the output Receipt ID.

Description

IMPROVEMENTS IN OR RELATING TO DIGITAL ASSET MANAGEMENT IN DISTRIBUTED LEDGER SYSTEMSTechnical field

[0001] The present invention relates generally to distributed ledger technologies and computer-implemented systems for recording, validating, and transferring digital assets. More particularly, the invention concerns blockchain architectures and associated software modules for generating and managing provenance-encoded digital asset identifiers, validating digital asset transfers using hybrid on-chain and off-chain state mechanisms, and performing consensus operations supplemented by external-data or anomaly-detection processes.

[0002] The invention further relates to systems and methods for executing cross-chain digital asset transfers, enforcing deterministic receipt lifecycle management, and improving the security, auditability, and operational efficiency of blockchain-based transaction platforms.Background

[0003] Distributed ledger technologies such as blockchains provide mechanisms for recording sequences of transactions in an immutable and tamper-evident manner using peer-to-peer networks. These systems enable participants to maintain a shared ledger without reliance on a central authority, and are well suited to applications requiring transparent, verifiable transaction histories.

[0004] However, blockchains in their conventional form exhibit significant performance limitations when compared with modern high-volume digital transaction systems such as those employed by payment networks (e.g., Visa, PayPal) or traditional database-backed financial infrastructures. As illustrated in Table 1, blockchains generally provide efficient sequential reads but suffer from reduced performance for random reads, queries, and validationdependent write operations. Furthermore, blockchains inherently lack support for update or delete operations due to their append-only design.Activity Databasetod {Sequential Fast Fast itod (Random) Fast SiowQuery Fast Very SiowWrite Fast Quick. Slow to ValidateDelete Fast CannotUpdate Fast Cannot

[0005] These limitations stem from the manner in which distributed consensus is achieved. In typical blockchain networks, each participating node independently executes and verifies incoming transactions, and the network as a whole must reach agreement, via consensus, on the validity and ordering of those transactions. Because the nodes do not aggregate or share processing capacity, overall throughput is constrained by the slowest or least performant validating participants. This consensus-driven architecture introduces latency, increases computational overhead, and restricts scalability.

[0006] By contrast, centralised databases have benefited from decades of optimisation and hardware acceleration. Their performance has scaled consistently with advances described by Moore’s Law, enabling extremely fast random access operations, efficient querying, and support for mutable operations such as updates and deletes. Accordingly, traditional databases continue to outperform blockchains in applications requiring high-frequency, low-latency transactional throughput.

[0007] Existing blockchain systems therefore tend to excel at maintaining a sequential, immutable record of events, but are less suited to real-time transactional processing, dynamic asset management, or applications requiring rapid verification of state transitions. This creates practical challenges for implementing secure, auditable, high-volume digital asset systems on blockchain infrastructures.

[0008] Furthermore, conventional blockchain platforms such as Bitcoin and various UTXO- based variants represent digital assets using unspent transaction outputs (UTXOs). In these systems, each transaction consumes one or more UTXOs and generates new UTXOs, which collectively define the spendable asset state. While UTXO architectures provide clear ownership semantics and reduce certain classes of double-spend risk, they also exhibitcharacteristics that can limit their suitability for high-volume or low-latency digital asset processing.

[0009] For example, UTXO-based systems typically lack a deterministic provenance structure, as each new UTXO is independently generated and does not inherently encode its origin, transaction context, or associated metadata. This can complicate downstream verification, auditability, and cross-chain interoperability. In many implementations, validating UTXO spending requires full traversal of cryptographic signatures and historical records, which increases computational overhead for nodes and contributes to latency.

[0010] Further, UTXO architectures generally do not provide an intermediate or “in-progress” transactional state. Once a UTXO is broadcast for spending, competing transactions may arise in the mempool, leading to race conditions, inconsistent wallet states, or increased rejection rates. The absence of a controlled, multi-phase state transition mechanism can make it difficult to support real-time merchant payments, concurrent transaction flows, or high-frequency updates. Additionally, UTXO models often rely entirely on on-chain validation. As transaction volumes increase, this can constrain throughput, since all nodes must independently verify signatures, asset quantities, and transaction correctness. UTXO systems also provide limited flexibility for incorporating off-chain verification signals, external data sources, or specialised validation nodes, as the model does not explicitly support hybrid validation architectures.

[0011] These and other constraints can reduce the scalability, extensibility, and practical applicability of traditional UTXO-based blockchains for applications requiring fast, verifiable, and interoperable digital asset transactions.

[0012] It is an object of the present invention to address at least some of the limitations associated with existing blockchain and distributed ledger technologies, or to provide the public with a useful alternative.Summary

[0013] According to a first aspect, the present disclosure may provide a computer- implemented system for recording and transferring digital assets, the system comprising at least one processor configured by executable instructions to:(a) generate, for each transfer transaction, one or more output receipt identifiers (Receipt IDs), each Receipt ID being uniquely derived from transaction data and one or more blockchain state parameters;(b) maintain a receipt state structure comprising an unspent list, a spent list, and an inprogress list, each list storing Receipt IDs and associated metadata;(c) upon receipt of a proposed transfer transaction, identify one or more input Receipt IDs and temporarily classify the input Receipt IDs as in-progress within the receipt state structure;(d) determine, for the proposed transfer transaction, whether:(i) each input Receipt ID is valid and unspent;(ii) a digital signature associated with the proposed transfer transaction is valid; and(iii) a total quantity represented by the input Receipt IDs equals a total quantity represented by the output Receipt IDs;(e) upon the proposed transfer transaction satisfying predetermined validation criteria, atomically:(i) classify each input Receipt ID as spent;(ii) record each output Receipt ID as unspent; and(iii) update a blockchain ledger to include a transaction record referencing the output Receipt IDs.

[0014] In an embodiment, each Receipt ID may comprise metadata including one or more of:(a) a timestamp of creation,(b) a chain identifier,(c) a block height, or(d) a hash of a corresponding transaction.

[0015] Each Receipt ID may be generated using a deterministically incremented sequence value maintained in persistent smart-contract state. The generation of each Receipt ID may comprise hashing transaction data together with a nonce selected by a submitting wallet. Classifying a Receipt ID as in-progress may prevent the Receipt ID from being reused in another proposed transfer transaction until validation completes.

[0016] In an embodiment, a failure of a proposed transfer transaction may cause the inprogress classification of each input Receipt ID to be reverted to an unspent classification. The receipt state structure may be stored at least in part in an off-chain database and crossvalidated against on-chain transaction records.

[0017] In an alternate embodiment, determining whether input and output amounts are equal may comprise summing values recorded in metadata associated with multiple input Receipt IDs. The validation step may include verifying that a hash associated with each input Receipt ID matches a hash stored in a corresponding blockchain record. Updating the blockchain ledger may comprise writing a transaction referencing each output Receipt ID to a block together with a timestamp and a block hash. Furthermore, the output Receipt IDs may include a field identifying an originating Receipt ID from which the output Receipt ID was derived.

[0018] According to another aspect, the present disclosure may provide a consensus system for validating digital asset transfer transactions recorded in a blockchain, the system comprising a plurality of validator nodes executing a consensus protocol, and at least one sentinel node, wherein the sentinel node is configured to:(a) access or maintain a receipt state structure comprising an unspent list, a spent list, and an in-progress list storing receipt identifiers (Receipt IDs) and associated metadata;(b) verify, for each proposed transfer transaction supplied to the consensus protocol:(i) whether each input Receipt ID is present in the unspent list and absent from the spent list;(ii) whether a digital signature associated with the proposed transaction is valid;(iii) whether the transaction satisfies predefined input-output balancing criteria; and(iv) whether the transaction metadata is consistent with one or more of: on- chain records, off-chain receipt state entries, external data sources, or an anomaly-detection result generated by a machine-learning model;(c) generate a consensus attestation indicative of validity or invalidity of the proposed transfer transaction; and(d) supply the consensus attestation to the validator nodes,wherein the consensus protocol is configured such that the validator nodes accept a block comprising the proposed transfer transaction only upon receiving a positive consensus attestation from the sentinel node.

[0019] According to yet another aspect, the present disclosure may provide a consensus system for validating digital asset transfer transactions, comprising a plurality of validator nodes and at least one sentinel node, wherein the validator nodes execute a consensus protocol for proposing, validating, and finalising candidate blocks, and wherein the sentinel node is configured to:(a) obtain, for each proposed transfer transaction included in a candidate block, transaction data comprising one or more input receipt identifiers (Receipt IDs) and associated metadata;(b) determine, using a receipt state structure comprising unspent, spent, and in-progress Receipt ID lists, whether each input Receipt ID is valid and unspent;(c) evaluate the proposed transfer transaction against predetermined validation criteria comprising at least:(i) verification of a digital signature associated with the transaction;(ii) correctness of the classification of each input Receipt ID within the receipt state structure; and(iii) input-output quantity balancing;(d) generate an attestation message indicative of validity or invalidity of the proposed transfer transaction; and(e) transmit the attestation message to the validator nodes via a communication channel used by the consensus protocol, wherein the validator nodes are further configured to:(f) verify, during block-validation processing, whether the attestation message indicates that all transfer transactions in the candidate block satisfy the predetermined validation criteria; and(g) reject the candidate block responsive to the attestation message indicating that at least one transfer transaction fails the predetermined validation criteria.

[0020] In an embodiment, the sentinel node may further be configured to obtain external data relevant to transaction validation, the external data comprising one or more of: regulatory information, risk-classification data, network telemetry, or market-event data. Evaluating theproposed transfer transaction may comprise applying an anomaly-detection model executed by the sentinel node.

[0021] The sentinel node may maintain a local cache of entries from the receipt state structure for real-time validation of candidate transactions. The sentinel node may further be configured to verify that each input Receipt ID is not present in the spent list and not concurrently classified as in-progress for another proposed transfer transaction.

[0022] In an embodiment, the receipt state structure may be synchronised between the sentinel node and one or more validator nodes using periodic state-update messages. The sentinel node may transmit a negative attestation message when detecting an inconsistency between the receipt state structure and blockchain records.

[0023] In an embodiment, the sentinel node may further be configured to generate an audit record referencing each proposed transfer transaction and its corresponding validation outcome. The validator nodes may include the sentinel’s audit record in a block header or block metadata for on-chain publication. Further, the sentinel node may initiate an additional verification procedure when detecting disagreement among validator nodes regarding the validity of a candidate block.

[0024] According to yet another aspect, the present disclosure may provide a computer- implemented method for transferring a digital asset represented by a receipt identifier (Receipt ID) from a first blockchain to a second blockchain, the method comprising:(a) on the first blockchain:(i) verifying that an input Receipt ID is valid and unspent according to a receipt state structure;(ii) classifying the input Receipt ID as locked or transfer-off-chain within the receipt state structure; and(iii) generating a proof of inclusion of the input Receipt ID in a state commitment recorded on the first blockchain;(b) transmitting, via a bridge service, transfer data comprising the input Receipt ID, the inclusion proof, and metadata indicative of an originating chain context;(c) on the second blockchain:(i) verifying the inclusion proof against a stored commitment corresponding to the first blockchain;(ii) generating a new Receipt ID uniquely derived from the transfer data and comprising metadata indicative of the originating Receipt ID and chain context; and(iii) recording the new Receipt ID as unspent in a receipt state structure of the second blockchain and writing a corresponding transaction to the second blockchain.

[0025] Classifying the input Receipt ID as locked may comprise updating the unspent list to indicate the Receipt ID is unavailable for further transfers, and generating the proof of inclusion may comprise computing a Merkle proof associated with a state commitment recorded on the first blockchain.

[0026] In an embodiment, the bridge service may comprise a message-queue or postbox service configured to forward transfer data between blockchain networks. The transfer data may further comprise a signature of a sentinel node attesting to correctness of the locked Receipt ID state.

[0027] In an embodiment, the metadata may be indicative of the originating context and comprises an originating chain identifier, originating block number, and originating transaction hash. Further, verifying the inclusion proof may comprise evaluating the proof against a stored Merkle root representing a state of the first blockchain. Generating the new Receipt ID may comprise hashing the transfer data with a newly generated nonce on the second blockchain.

[0028] According to yet another aspect, the present disclosure may provide a digital asset transfer platform comprising:(a) a receipt management subsystem configured to:(i) generate, for each transfer transaction, one or more Receipt IDs uniquely derived from transaction data and blockchain state parameters;(ii) maintain a receipt state structure comprising unspent, spent, and in-progress Receipt ID lists; and(iii) update the receipt state structure in response to validation of transfer transactions;(b) a consensus subsystem comprising a plurality of validator nodes and at least one sentinel node, the sentinel node being configured to verify correctness of receipt state transitions and to provide consensus attestations required for acceptance of blocks; and(c) a cross-chain transfer subsystem configured to:(i) lock Receipt IDs on a first blockchain;(ii) generate proofs of inclusion of the locked Receipt IDs;(iii) transmit transfer data to a second blockchain; and(iv) generate and record new Receipt IDs on the second blockchain corresponding to the locked Receipt IDs.

[0029] The receipt management subsystem may be configured to revert in-progress Receipt IDs to unspent status upon rejection of a block by the consensus subsystem, and he consensus subsystem may be configured to record sentinel -generated audit metadata in the blockchain alongside validated transactions.

[0030] In an embodiment, the cross-chain transfer subsystem may be configured to prevent issuance of more than one new Receipt ID corresponding to a single originating Receipt ID.

[0031] According to yet another aspect, the present disclosure may provide a computer- implemented system for managing digital asset transfer transactions, comprising: one or more processors configured to maintain a receipt state structure including at least an unspent state, an in-progress state, and a spent state, and to:(a) classify one or more input receipt identifiers (Receipt IDs) of a proposed transfer transaction as in-progress upon receipt of the proposed transfer transaction;(b) prevent reuse of any in-progress Receipt ID in another proposed transfer transaction;(c) validate the proposed transfer transaction by determining whether the in-progress Receipt IDs satisfy predetermined criteria including validity and ownership;(d) upon successful validation, atomically reclassify the in-progress Receipt IDs as spent and record one or more corresponding output Receipt IDs as unspent; and(e) revert each in-progress Receipt ID to an unspent state upon failure of the proposed transfer transaction.

[0032] According to yet another aspect, the present disclosure may provide a digital asset validation system comprising:(a) a blockchain storing records of confirmed transfer transactions;(b) an off-chain validation layer maintaining a real-time state representation of asset identifiers including at least a validity state; and(c) a validation processor configured to approve or reject proposed transfer transactions by:(i) verifying consistency of each input asset identifier with the off-chain state representation; and(ii) verifying consistency of the input asset identifier with one or more blockchain records; wherein a proposed transfer transaction is accepted only when validation results from both the off-chain validation layer and the blockchain records indicate that each input asset identifier is valid.

[0033] In an embodiment, the deterministic function comprises a cryptographic hash function applied to a concatenation of the transaction data and the one or more blockchain state parameters. The concatenation may comprise combining the transaction data and the one or more blockchain state parameters in a predetermined ordering for input to the cryptographic hash function. The blockchain state parameters may further comprise a previous-block hash, a transaction timestamp, or a chain identifier. Further, digital asset identifier further encodes a nonce generated by a submitting wallet.

[0034] In another embodiment, the digital asset identifier may encode provenance information comprising at least one of:(a) an originating chain context,(b) an originating block height, or(c) an originating transaction hash.

[0035] The digital asset identifier may be configured to uniquely represent a lineage of issuance for the corresponding digital asset.

[0036] In another embodiment, the method may further comprise generating a proof of inclusion of the digital asset identifier within a state commitment recorded on the blockchain,and Recording the digital asset identifier may comprise storing a hash of the digital asset identifier within a Merkle tree whose root is committed to the blockchain.

[0037] In an alternate embodiment, the method may further comprise generating a subsequent digital asset identifier for a transfer transaction by applying the deterministic function to updated transaction data and one or more updated blockchain state parameters.

[0038] The subsequent digital asset identifier may include metadata identifying the digital asset identifier generated in step (c) as an originating identifier. The deterministic function may be configured to produce distinct digital asset identifiers for different blockchain networks by incorporating a network identifier into the blockchain state parameters.

[0039] According to yet another aspect, the present disclosure may provide a computer- implemented system for recording and transferring digital assets in a blockchain environment, comprising: at least one processor configured to execute instructions that cause the at least one processor to implement: a transaction module, an input-output validation module, a hash calculation module, a consensus module, a ledger update module, and a cross-chain interface module, wherein the processor is further configured, via execution of said modules, to: generate, by the transaction processor, for each transfer transaction, at least one output Receipt Identifier (Receipt ID), each Receipt ID being generated in an incremental ascending sequence; identify, by the input-output validator, as input one or more previously created Receipt IDs or an original asset creation transaction. determine, by the input-output validator, whether the total asset quantity represented by the input Receipt IDs equals the total asset quantity represented by the output Receipt IDs; in response to the total asset quantity of outputs being less than the total asset quantity of inputs, generate an additional balancing output Receipt ID that transfers any remainder back to a sender address; compute, by the hash calculator, a hash total for each transfer transaction, the hash total including the hash of at least one preceding transfer transaction, such that each transfer transaction is cryptographically linked to a prior transfer transaction;determine, by the consensus module, whether each transfer transaction satisfies one or more criteria comprising verifying: i. a sender address and digital signature; ii. that each input Receipt ID is valid and unspent; and iii. that the hash total of each input Receipt ID matches the hash recorded in the blockchain; iv. To be prudent we may cheek receiver address at least valid in our system record, by the ledger updater, those transfer transactions determined to have satisfied said verifying criteria, wherein each new output Receipt ID and an associated block number are stored in the blockchain and / or a Receipt ID list verified by the consensus module; and execute, by the cross-chain interface, recording and verification of output Receipuut IDs across multiple blockchains to effect transfer of assets between the blockchain.

[0040] In an embodiment, the consensus module may comprise a plurality of validator nodes configured to participate in a consensus protocol, wherein the plurality of validator nodes comprises: i. at least one sentinel node configured to provide an attestation of transaction validity based on external information or an artificial intelligence-based analysis; and ii. one or more non-sentinel validator nodes configured to perform validation based on blockchain transaction data.

[0041] The external information may comprise one or more of financial market data, supplychain or logistics updates, weather or environmental conditions, network performance metrics, regulatory data feeds, or other real-world information relevant to a digital asset transaction.

[0042] The artificial intelligence-based analysis may comprise applying a machine learning model to at least one of: (a) detecting anomalous transaction patterns; (b) classifying transactions according to risk level; (c) correlating blockchain transaction data with external data feeds; or (d) verifying compliance with predetermined policy rules.

[0043] In an embodiment, the consensus module may instantiate a plurality of consensus groups operating in parallel, each consensus group including at the least one sentinel node. Theat least one sentinel node may apply the machine learning model to detect anomalous transaction patterns and provide supplemental verification to the consensus module.

[0044] The at least one sentinel node may apply the machine learning model to analyze one or more of transaction data, external information feeds, or system activity to provide supplemental verification to the consensus module.

[0045] In an embodiment, responsive to inconclusive consensus among the non-sentinel validator nodes, the at least one processor is further configured to cause the sentinel node to perform a supplemental verification procedure comprising: i. retrieving external data feeds; ii. applying an anomaly detection model; and iii. outputting a consensus attestation message.

[0046] Each output Receipt ID may further encode metadata comprising at least one of i. timestamp of creation ii. originating sender address; or iii. identifier of the blockchain in which the Receipt ID is first recorded.

[0047] The incremental ascending sequence of Receipt IDs may be maintained separately for each asset type, and the transaction processor may assign a unique cryptographic nonce to each Receipt ID in addition to the incremental sequence.

[0048] In an embodiment, the hash total may be computed using a Merkle tree structure combining the current transaction data with the hash of the preceding transaction.

[0049] In an alternate embodiment, the consensus module may further validate that the receiver address of any balancing Receipt ID corresponds to the sender address of the corresponding input. The consensus module may include at least one Sentinel node configured to provide external information or Al-based attestation of transaction validity. The consensus module may dynamically instantiate multiple consensus groups operating in parallel, each group including the at least one Sentinel node. The consensus-validated Receipt ID list may be maintained as a sidechain linked to the blockchain.

[0050] The ledger updater may record, for each output Receipt ID, the block number, timestamp, and cryptographic hash of the block in which the output Receipt ID is first included, and the cross-chain interface may be configured to lock assets in a first blockchain and issue a corresponding wrapped asset Receipt ID in a second blockchain.

[0051] The system of claim 1, wherein the cross-chain interface employs a Sentinel node to attest to asset transfer events occurring on an external blockchain, and wherein the transfer events are timestamped at sub-second resolution to permit immediate reuse of output Receipt IDs as inputs for subsequent transactions. Immediate reuse of output Receipt ID be invoked- / controlled close to the generation of the received IDs

[0052] The system may support simultaneous consensus events triggered whenever pending transactions exceed a predetermined threshold.

[0053] In another aspect, the present disclosure may provide a computer-implemented system for recording and transferring digital assets in a blockchain environment, comprising: one or more processors and memory storing instructions that, when executed, configure a plurality of participating nodes to validate and record asset transfer transactions in a distributed ledger; a consensus manager executed by at least one of said processors, the consensus manager being configured to instantiate multiple consensus groups from a pool of said participating nodes in response to transaction volume, wherein each consensus group: i. is assigned a distinct subset of pending transactions and operates in parallel with other consensus groups such that multiple blocks may be validated and written concurrently; ii. includes at least one sentinel node, the at least one sentinel node being configured to (i) provide external information or attestations from outside the blockchain network, and / or (ii) apply artificial intelligence-based analysis for verification of transaction conditions; iii. assigns validator nodes to each consensus group, including designation of the at least one Sentinel node per group; and wherein successful validation by a consensus group causes the corresponding transactions to be written into a new block in the distributed ledger.

[0054] In an embodiment, the at least one sentinel node may be configured to verify off-chain data sources with cryptographic attestations. The at least one sentinel nodes may implement a machine learning model to detect anomalies or policy violations in pending transactions.

[0055] Multiple consensus groups may be active simultaneously, each writing a separate block, thereby improving throughput as transaction volume increases. The system may further comprise a reward distribution mechanism that compensates participating nodes, including the at least one sentinel node, upon successful consensus participation.

[0056] The consensus groups may be instantiated on-demand, and disbanded after block completion, thereby enabling scalability. The Sentinel node may be configured to provide realtime inputs required for validation in fast-moving transfer scenarios, including immediate use of newly created output IDs.

[0057] Fine-grained timestamps may be applied to transactions validated by the at least one sentinel node to ensure auditability and prevent replay or ordering conflicts. Each consensus group may be identified by a group identifier recorded in the blockchain alongside the validated block.

[0058] In an embodiment, the consensus groups may periodically exchange synchronization messages to ensure global consistency of the distributed ledger state. The consensus manager may apply a deterministic ordering protocol to transactions within each consensus group. The consensus manager may resolve conflicts between outputs of different consensus groups using the deterministic ordering protocol.

[0059] The deterministic ordering protocol may comprise a rule-based procedure that assigns a fixed transaction order based on one or more of (i) transaction timestamp; (ii) cryptographic hash value; or (iii) node priority ranking.

[0060] In another aspect, the present disclosure may provide a computer-implemented method for recording and transferring digital assets in a blockchain environment, the method comprising:executing, by at least one processor configured by stored instructions, a transaction module to generate, for each transfer transaction, at least one output Receipt Identifier (Receipt ID), each Receipt ID being generated in an incremental ascending sequence; executing, by the at least one processor, an input-output validation module to identify as input one or more previously created Receipt IDs or an original asset creation transaction; determining, by the at least one processor executing the input-output validation module, whether a total asset quantity represented by the input Receipt IDs equals a total asset quantity represented by the output Receipt IDs; in response to the total asset quantity of outputs being less than the total asset quantity of inputs, generating, by the at least one processor, an additional balancing output Receipt ID that transfers any remainder back to a sender address; computing, by the at least one processor executing a hash calculation module, a hash total for each transfer transaction, the hash total including a hash of at least one preceding transfer transaction, such that each transfer transaction is cryptographically linked to a prior transfer transaction; determining, by the at least one processor executing a consensus module, whether each transfer transaction satisfies one or more criteria comprising verifying: i. a sender address and digital signature; ii. that each input Receipt ID is valid and unspent; and iii. that the hash total of each input Receipt ID matches a hash recorded in the blockchain; recording, by the at least one processor executing a ledger update module, those transfer transactions determined to have satisfied the verifying criteria, wherein each new output Receipt ID and an associated block number are stored in the blockchain and / or a Receipt ID list verified by the consensus module; and executing, by the at least one processor executing a cross-chain interface module, recording and verification of output Receipt IDs across multiple blockchains to effect transfer of assets between the blockchains.

[0061] In another aspect, the present disclosure may provide a computer-implemented method for recording and transferring digital assets in a blockchain environment, the method comprising:configuring, by one or more processors executing stored instructions, a plurality of participating nodes to validate and record asset transfer transactions in a distributed ledger; instantiating, by a consensus manager executed by at least one of the processors, multiple consensus groups from a pool of the participating nodes in response to transaction volume, wherein each consensus group: i. is assigned a distinct subset of pending transactions and operates in parallel with other consensus groups such that multiple blocks may be validated and written concurrently; ii. includes at least one sentinel node, the at least one sentinel node being configured to (a) provide external information or attestations from outside the blockchain network, and / or (b) apply artificial intelligence-based analysis for verification of transaction conditions; and iii. assigns validator nodes to the consensus group, including designation of the at least one sentinel node per group; and writing, by the one or more processors, the corresponding transactions into a new block in the distributed ledger upon successful validation by the consensus group.

[0062] Many applications would benefit having the features and performance of a database as well as the features of a blockchain.

[0063] In one aspect the invention may broadly be said to consist of a distributed ledger system configured to create, update and maintain at least one blockchain indicative of transactions performed by a network of users of the system, the system comprising: a network of computing devices including a network of user nodes in communication with one another to participate in transactions and subsequently write the transactions to an associated blockchain, each node being associated with at least one processor and at least one computer-readable medium having recorded thereon instructions to be executed by the processor(s) to carry out one or more blockchain-related tasks for creating, updating and / or maintaining at least one associated blockchain of the system based on the transactions; and wherein the network of computing devices is operable to enable at least one ephemeral user node to join the network of computing devices to carry out the blockchain-related tasks in association with at least one blockchain during an active session of the ephemeral user node.

[0064] In another aspect the invention may broadly be said to consist of a method for maintaining at least one blockchain stored in a distributed ledger system, the method comprising: enabling communication between a network of computing devices including a network of user nodes of the system, to enable execution of one or more transactions between multiple user nodes and to enable writing of the transaction(s) to an associated blockchain, providing an interface for the network of computing devices to access at least one computer- readable medium having recorded thereon instructions to carry out one or more blockchain-related tasks for creating, updating and / or maintaining at least one associated blockchain of the system based on the transactions, and to allow each computing device to execute the blockchain-related tasks; and enabling at least one ephemeral user node to join the network of computing devices and to access the at least on computer-readable medium to execute the blockchain-related tasks in association with at least one blockchain during an active session of the ephemeral user node.

[0065] In another aspect the invention may broadly be said to consist of a distributed computing system configured to enable a network of users of the system to participate in one more transactions: a network of user nodes in communication with one another, each node being associated with at least one processor and at least one computer readable medium for participating in the one or more transactions with other user nodes in the network; a distributed ledger system capable of creating, maintaining and updating at least one blockchain indicative of the one or more transactions via the network of user nodes; and one or more databases accessible by the network of nodes for recording and reading data relating to the one or more transactions between the user nodes.

[0066] In another aspect, the invention may broadly be said to consist of a distributed ledger system configured to create, update and maintain at least one blockchain indicative of transactions performed by a network of users of the system, the system comprising: a network of computing devices including a network of user nodes in communication with one another to participate in transactions and subsequently write the transactionsto an associated blockchain, each node being associated with at least one processor and at least one computer-readable medium having recorded thereon instructions to be executed by the processor(s) to carry out one or more blockchain-1related tasks for creating, updating and / or maintaining at least one associated blockchain of the system based on the transactions; and wherein the network of computing devices is operable to enable at least one ephemeral user node to join the network of computing devices to carry out the blockchain-related tasks in association with at least one blockchain during an active session of the ephemeral user node.

[0067] In an embodiment, the network of computing devices may be operable to enable at least one ephemeral user node to repeatedly join the network of computing devices to carry out the blockchain-related tasks in association with at least one blockchain during multiple active sessions.

[0068] In an embodiment, each node may be configured to obtain executable code from the associated computer-readable medium to perform the one or more blockchain-related tasks. At least one node may be configured to communicate with the network of computing devices to obtain the executable code using an address location within a blockchain of the system. The node may be configured to access and execute the blockchain-related tasks via a web instance operable using the processor(s) associated with the node. The web instance may be a webbrowser instance. The node may be configured to access and execute the blockchain-related tasks using a web Assembly container.

[0069] In an embodiment, the node may be an ephemeral node. Preferably the node may join the network of computing devices when the node is capable of communicating with the server to access and perform one or more blockchain related tasks. In an alternate embodiment, all nodes are ephemeral nodes.

[0070] In an embodiment, at least one node may be configured to obtain data indicative of a current iteration of a blockchain from corresponding peer nodes for enabling the execution of the blockchain-related task(s). The least one node may be configured to obtain data indicative of a most recent block or most recent blocks of a current iteration of a blockchain from the network of computing devices for enabling the execution of the blockchain-related task(s).

[0071] In an embodiment, each ephemeral node may be configured to obtain data indicative of a most recent block or most recent blocks of a current iteration of a blockchain when the node joins the network of computing devices for enabling the execution of the blockchain-related task(s).

[0072] In an embodiment, at least one ephemeral node may be configured to maintain a full copy of the blockchain. Multiple ephemeral nodes of the network may be configured to maintain a full copy of the blockchain

[0073] The network of ephemeral nodes may comprise at least one node operating as a fullnode, wherein the full-node is operable to execute a mining task of the blockchain related tasks for selecting a node within the network to write a next validated block to the blockchain. The mining task may be operative using a proof-of-stake method. The network of nodes may comprise at least one ephemeral node operating as a light node, wherein the light node is not operable to execute a mining task of the blockchain-related tasks. The network of nodes may be capable of communicating with one another via a peer-to-peer communications protocol.

[0074] In an embodiment, the peer-to-peer communication may be facilitated by webRTC. The network of computing devices may be configured to verify a predetermined user identity associated with a node prior to the node establishing communication with the remaining network of nodes for the purposes of carrying out one or more blockchain related tasks. Verifying the predetermined user identity may comprise a two-factor authentication process.

[0075] The two-factor authentication process may include a biometric identification stage wherein a predetermined biometric characteristic of a user associated with the user node is verified.

[0076] In an alternate embodiment, each node in the network of nodes may comprise a node address associated therewith for each blockchain the node is configured to participate in to enable communication with the node, and wherein the node address includes an indication of the associated blockchain.

[0077] In another aspect, the invention may broadly be said to consist of a method for enabling a network of users to participate in one more transactions, comprising the steps ofenabling a network of user nodes to communicate with one another and participate in one or more transactions amongst two or more nodes, each node being associated with at least one processor and at least one computer readable medium for executing the transaction(s); utilising one or more databases accessible by the network of nodes for creating, maintaining and updating the one or more transactions between the user nodes; and creating, maintaining and updating at least one blockchain indicative of the one or more transactions in a distributed ledger system via the network of user nodes.

[0078] In another aspect, the invention may broadly be said to consist of a computing platform for enabling the development of a distributed computing system application running on a user’s computing device including at least one processor and at least one computer readable medium, the platform comprising: one or more application interfaces for enabling the generation of a user node application executable on a user’s computing device, the user node application having the functionality of: communicating with other user node application(s) in a network of user nodes to perform one or more transactions with the other user node application(s), performing one or more blockchain-related tasks to create, maintain and / or update at least one blockchain indicative of the one or more transactions; and access and update one or more databases for recording and reading data relating to the one or more transactions between the user node and the other nodes.

[0079] Any combination of one or more of the features listed in the following embodiments or further aspects may be combined with any one of the abovementioned aspects of the invention.

[0080] In an embodiment, the data relating to the at least one blockchain comprises data indicative of the one or more transactions of the associated blockchain. In some embodiments wherein at least one of the databases is a NoSQL database. In some embodiments each user node is configured to access data relating to transactions associated with the user node. In an alternate embodiment, at least one blockchain storing one or more transactions using the distributed ledger system is substantially synchronised with associated copies of the one or more transactions in the at least one database.

[0081] In an embodiment, the non-SQL database may store data indicative of a status of one or more transactions between user nodes. The non-SQL database mat be utilised to record blockchain-related transactions between the user nodes.

[0082] In an embodiment, each user node may be configured to execute data access layer software for translating blockchain-related transaction data acquired from the at least one database to data suitable for use as a transaction in the distributed ledger system.

[0083] In an embodiment, each user node may be configured to execute data access layer software for translating blockchain-related transaction data acquired from the distributed ledger system to data suitable for use to store as a transaction in the at least one database. Each user node may be configured to execute database management software for enabling the node to create, read, update and / or delete one or more blockchain related transactions on the at least one database. Each user node may be configured to execute database management software for enabling the node to transmit one or more blockchain related transactions stored in the at least one database to the user node for use in distributed ledger system. Each user node may be configured to execute node software for performing the one or more blockchain related tasks.

[0084] In an embodiment, each computing device may be configured to execute address filtering software for identifying blockchain-related transactions originating from the node software or from the database management software for a particular user node, for one or more user nodes or databases.

[0085] Theat least one user node may be an ephemeral node configured to temporarily join the network of user nodes to carry out the blockchain-related tasks in association with at least one blockchain during an active session of the ephemeral user node. The network of user nodes may be operable to enable at least one ephemeral user node to repeatedly j oin the network of computing devices to carry out the blockchain-related tasks in association with at least one blockchain during multiple active sessions. The at least one user node may configured to access and execute the blockchain-related tasks via a web browser instance operable using the processor(s) associated with the node.

[0086] The at least one user node may be configured to access and execute the blockchain- related tasks using a web Assembly container. The at least one node may bem an ephemeralnode and the ephemeral node is configured to maintain a full copy of the blockchain or an ephoch of the blockchain.

[0087] In an embodiment, the network of nodes comprises at least one ephemeral node operating as a full- node, wherein the full-node is operable to execute a mining task of the blockchain-related tasks for selecting a node within the network to write a next validated block to the blockchain. In an embodiment, the mining task is operative using a proof-of-stake method. The network of nodes may be capable of communicating with one another via a peer- to-peer communications protocol. The peer-to-peer communication may be facilitated by webRTC.

[0088] In an embodiment, one or more transactions executed and stored via the distributed ledger system and / or via the database have associated therewith any one or more of the following identifiers: user identifier, blockchain identifier, hierarchy level identifiers associated with a hierarchy system for a group of the user nodes, and / or an entity identifier associated with a user node.

[0089] In another aspect the invention may broadly be said to consist of a distributed computing platform, providing general purpose computing coupled with a ledger comprising: a software construct or platform to process code and create and compile and deliver an application designed to run in a web browser, said application having a distributed ledger or blockchain and for each user a corresponding indexed database dedicated the user.

[0090] In an embodiment, the indexed Database may be capable of communicating database transactions to other software applications which translates or manipulates each database transaction into a form suitable to be received and processed as a blockchain or distributed ledger transaction by said blockchain node.

[0091] In an embodiment, each application created on the platform software may have a unique ledger identifier GUTD and is part of the Platform’s ecosystem, enabling communication between ledgers. The applications created on or by the platform may also run- on large-scale devices or Servers or cloud-provided scalable computing or traditionally in existing datacentres. In an embodiment, each application created on or by the platform mayrun using headless chrome, or similar environment, instead of a web browser. The platform may enable the development of a software application running in a web-browser in a user device to distribute database transactions to a corresponding node in said application in a form suitable for creation of a blockchain transaction and transmit said transactions securely across a peer-to-peer network as corresponding blockchain or distributed ledger transactions.

[0092] In an embodiment, each application instance runs a node, and the local database only holds transaction data that are relevant to the system, application or user.

[0093] The term “comprising” as used in the specification and claims means “consisting at least in part of.” When interpreting each statement in this specification that includes the term “comprising” features other than that or those prefaced by the term may also be present. Related terms “comprise” and “comprises” are to be interpreted in the same manner.

[0094] The reference in this specification to any prior publication (or information derived from it), or to any matter which is known, is not, and should not be taken as, an acknowledgement or admission or any form of suggestion that that prior publication (or information derived from it) or known matter forms part of the common general knowledge in the field of endeavour to which this specification relates.Brief Description of the Drawings

[0095] The following drawings illustrate embodiments of the invention and its associated system components, workflows, and functionalities:

[0096] Figure l is a schematic block diagram illustrating an overview of a digital asset management platform implemented using a distributed ledger system, including user devices, validator nodes, at least one sentinel node, an off-chain receipt state store, and a blockchain ledger.

[0097] Figure 2 is a schematic diagram illustrating an example transaction processing arrangement, showing a blockchain block containing a zero-knowledge proof layer, a hash layer, and transaction information including transaction number, timestamp, and hash values, together with a receipt identifier for the transaction.

[0098] Figure 3 is a schematic diagram illustrating generation of a hash total and a receipt identifier, showing example input parameters used to compute a hash value and the resulting receipt identifier for a transaction.

[0099] Figure 4 is a diagram illustrating a Receipt ID state machine, including transitions between unspent, in-progress, and spent states, in response to transaction submission, validation, acceptance, or rejection.

[0100] Figure 5 is a schematic diagram illustrating an example verification workflow, including a first rule for checking input transaction receipts, a second rule for checking output receipts, and a combined rule-based validation process applied during transaction verification.

[0100] Figure 6 is a sequence diagram illustrating interaction between validator nodes and a sentinel node during a block-validation cycle, including transmission of candidate blocks, requests for attestation, responses from the sentinel node, and acceptance or rejection of the candidate block.

[0101] Figure 7 is a block diagram illustrating instantiation of multiple consensus groups, each group comprising validator nodes and at least one sentinel node, and demonstrating parallel validation of distinct subsets of pending transactions.

[0102] Figure 8 is a diagram illustrating a cross-chain transfer mechanism, including locking of Receipt IDs on a source chain, generation of a Merkle proof, verification of the proof on a destination chain, and issuance of a corresponding wrapped Receipt ID.

[0103] Figure 9 is a diagram illustrating an example structure of a Receipt ID certificate, including transaction metadata, provenance data, chain identifier, block height, content hashes, state classification, and optional inclusion-proof elements.

[0104] Figure 10 is a diagram illustrating an example of a deterministic ordering protocol for resolving conflicts between transactions validated by multiple consensus groups, including ordering rules based on timestamps, hashes, or deterministic ranking.

[0105] Figures I la and 1 lb form a schematic block diagram of a general -purpose computer system upon which arrangements described can be practiced.Detailed description

[0106] The present disclosure relates to systems and methods for recording, validating, and transferring digital assets within a distributed ledger environment. In particular, the disclosure describes an improved blockchain architecture that employs cryptographically generated Receipt Identifiers (Receipt IDs), structured validation rules, sentinel-assisted consensus mechanisms, and optional cross-chain transfer processes to enable secure, auditable and high- volume digital asset operations.

[0107] Existing blockchain systems exhibit limitations in deterministic traceability, real-time validation, transaction throughput, and verifiable provenance of digital assets. Many rely on traditional UTXO models or account-based models which do not provide fine-grained state classification, intermediate transaction states, structured provenance metadata, or deterministic ordering based on blockchain state parameters. The present disclosure introduces a Receipt- ID-centric architecture that unifies these elements into a cohesive framework, enabling improved auditability, double-spend resistance, and computational efficiency across blockchain and cross-chain environments

[0108] The embodiments described herein include a plurality of cooperating components, such as a transaction generation module, Receipt ID creation logic, a rules-based validator, one or more sentinel nodes configured to provide additional attestation or external signal verification, a consensus subsystem capable of parallel block formation, and a cross-chain interface. These components interact to ensure that each transfer of a digital asset is recorded with an associated Receipt ID having deterministic provenance, cryptographically provable uniqueness, and linkability to underlying blockchain state parameters.

[0109] The following detailed description refers to various figures illustrating example embodiments of the invention. These embodiments are provided to facilitate an understanding of the disclosed subject matter and are not intended to limit the scope of the claims.Components shown in one figure may operate in conjunction with components shown in other figures, and alternative implementations may omit, rearrange, or expand the illustrated elements while still falling within the scope of the present disclosure.

[0110] For clarity of description and to assist in understanding the embodiments disclosed herein, the following terminology is used throughout this specification. These definitions are provided for convenience and are not intended to limit the scope of the claimed invention.[Oi l 1] As used herein, the term “blockchain” refers to a distributed data structure comprising a sequence of data blocks linked together via cryptographic hash pointers. While blockchains are commonly implemented using peer-to-peer communication protocols and a distributed consensus mechanism, the present disclosure is not limited to any particular blockchain protocol, network topology, or consensus algorithm. The term encompasses any distributed ledger or chained-data structure providing append-only, tamper-evident recording of transactions.

[0112] A “node” refers to a software program or computing entity that participates in some aspect of management, validation, communication, or maintenance of the blockchain. Nodes may perform one or more roles, including but not limited to block generation, transaction validation, block verification, epoch management, or wallet operations, and may change roles dynamically depending on system requirements.

[0113] A “wallet” refers to a software component that manages cryptographic keys, prepares and proposes transactions, communicates with one or more blockchain nodes, and receives new digital assets or Receipt Identifiers (Receipt IDs). Wallets may operate in user devices, servers, cloud environments, or browser-hosted environments using compiled Web Assembly modules.

[0114] Web Assembly (WASM) refers to a browser-hosted virtual machine technology enabling execution of compiled code from high-level languages such as C#, Rust, or C++. Embodiments of the present invention may utilize WASM to execute wallet logic, validation steps, compilation modules, or transaction generation routines within a lightweight browser context.

[0115] Blazor refers to an implementation framework allowing .NET code to execute on the Web Assembly runtime. Certain embodiments of the invention may utilize Blazor-based wallets, validator scripts, or user-interface components.

[0116] WebRTC refers to a peer-to-peer communication protocol enabling low-latency data exchange between browser-based clients, desktops, or nodes. In some embodiments, WebRTC may be used by nodes to exchange transaction data, propagate blocks, or participate in distributed validation cycles.

[0117] An example blockchain architecture suitable for implementing embodiments of the invention is now described. This example is non-limiting and provided to illustrate one context in which the disclosed Receipt ID and validation mechanisms may operate.

[0118] Nodes within this architecture may be ephemeral. A node may launch, participate in validation or communication, and terminate before acquiring a full cache of the active epoch or the historical blockchain state. This enables lightweight, disposable, and scalable node participation.

[0119] In one embodiment, each block in the blockchain includes the following fields:- Index: a unique, monotonically increasing block identifier.- Nonce: a randomized value generated by the previous block writer to assist in selection of the next block-writing node.- Previous Hash: a SHA-256 hash of the preceding block in the chain. Current Hash: a SHA-256 hash of the present block’s data.- Data[ ]: an array of one or more byte arrays encoding .NET Standard objects or transaction payloads.- Epoch: an identifier representing the current segment or operational period of the chain.

[0120] Participating nodes may request only the current epoch and are not required to download the entire blockchain. This reduces overhead and supports the use of short-lived or browser-based nodes.Peer-to-Peer Operation

[0121] In one embodiment, peer-to-peer communication between nodes is implemented using WebRTC channels. Example operational steps include: i. new transactions are broadcast to all participating nodes; ii. each node aggregates new transactions into a candidate block;iii. each node applies a proof-of-stake or similar selection mechanism; iv. a node satisfying the selection criteria broadcasts a proposed block; v. nodes accept a block only if all transactions within it are valid and unspent; vi. nodes build subsequent blocks on the most recently accepted block; and vii. in cases where multiple candidate blocks are proposed concurrently, nodes continue building on their received branch until the longest or otherwise valid chain is identified through consensus.

[0122] The above process ensures eventual convergence, block continuity, and tamper-evident ordering of transactions.Transaction Model

[0123] In one embodiment, transactions are implemented as .NET Standard partial classes derived from a base Go. Transaction class. The transaction payload is compiled into Microsoft Intermediate Language (MSIL) and stored directly on the blockchain as part of the block data. Nodes executing transactions utilize a Just-In-Time compiler within the Common Language Runtime (CLR) environment to transform MSIL into native executable instructions.

[0124] Example transaction types may include:- go. Transact! on. Pay(pay or, payee, amount, balance) for transferring digital assets;- go. Transact! on. Message(src, dst, msg) for encrypted messaging between accounts;- transactions introducing or minting digital assets (e.g., tokens or fiat-backed units) each associated with a unique asset identifier.

[0125] An example transaction workflow proceeds as follows: i. a transaction is generated by user software and submitted to a node; ii. the transaction is locally compiled to MSIL (client-side, server-side, or via a cloud service); iii. the receiving node executes unit tests to ensure correctness; iv. if valid, the transaction is added to a local pool of candidate transactions and propagated to peers; v. a block writer aggregates validated transactions and proposes the block to its peers; andvi. upon acceptance of the block, all nodes remove included transactions from their candidate pools.Node Roles

[0126] Nodes may adopt one or more roles within the Go:) (Go-Smile) blockchain environment, including:- full Node: maintains the complete blockchain or epoch and verifies all received blocks;- founder Node: responsible for writing blocks based on weighted votes or stake. epoch Node: manages the operational epoch and validates blocks applicable to that epoch.- wallet Node: facilitates user interaction, transaction creation, and private-key operations.

[0127] These roles may be assigned dynamically. In some embodiments, all node software derives from a common library and may transition between roles without restarting or reconfiguration.

[0128] Figure 1 illustrates an example system architecture 100 for recording, validating, and transferring digital assets using a distributed ledger platform enhanced with Receipt Identifiers (Receipt IDs), structured validation logic, and sentinel -assisted consensus verification. The architecture comprises a set of cooperating modules and networked components that collectively implement the Receipt ID life cycle, transaction verification rules, block formation, and optional cross-chain operations.

[0129] A plurality of user devices (101) are shown, each executing a wallet module (102). The wallet module maintains private keys, prepares transaction requests, generates preliminary transaction metadata, and submits proposed transactions to validator nodes. In some embodiments, the wallet module executes as a Web Assembly (WASM) component or a Blazor-based front-end, enabling lightweight operation in browser environments without requiring a full blockchain client.

[0130] When initiating a transfer of digital assets, the wallet module identifies one or more input Receipt IDs available to the user and constructs a corresponding transaction payload. The payload includes payer and payee addresses, asset type identifiers, amount, timestamp, the oneor more blockchain state parameters (e.g., previous block hash), and a nonce. This payload is forwarded to the validator layer for validation and block inclusion.

[0131] The architecture includes a plurality of validator nodes (110), each of which executes validation logic for proposed transactions and participates in the consensus mechanism. Validator nodes maintain partial or full views of the blockchain ledger, store or cache one or more recent epochs, and apply a predetermined set of validation rules to candidate transactions.

[0132] Each validator node comprises a Receipt ID validation module (111) that verifies digital signatures, evaluates correctness and completeness of transaction fields, and ensures that each referenced Receipt ID is structurally valid, cryptographically authentic, and in a valid state (e.g., unspent). Validator nodes consult both on-chain Receipt ID records and associated off-chain state to evaluate the transaction.

[0133] In an embodiment, the validation logic implemented by validator nodes includes verifying structural properties of Receipt Identifiers, ensuring correct association with blockchain state parameters, and enforcing input-output balance conditions for digital asset transfers, enabling reliable lifecycle management of Receipt IDs within the distributed system.

[0134] At least one sentinel node (120) is included in the system architecture. The sentinel node participates in each block-validation cycle and performs additional checks beyond those executed by validator nodes. These checks include:- verifying consistency of Receipt ID states maintained in the off-chain receipt-state store (130);- performing anomaly detection or pattern recognition using a machine-learning model; optionally consulting external data feeds such as compliance indicators, market data, or system health information; and- issuing an attestation indicating whether the transaction satisfies consensus preconditions.

[0135] The sentinel node may further act as a determinative attestation authority for proposed ledger updates, ensuring that state transitions for Receipt Identifiers, block-level metadata, and associated provenance information satisfy system-level requirements for transactionacceptance. In some implementations, the sentinel node is configured to participate in every validation cycle, providing a mandatory verification pathway for block finalisation.

[0136] The sentinel node thus establishes an authoritative verification layer that prevents inconsistencies arising from distributed or delayed state propagation among validator nodes. If the sentinel node does not support the proposed block, the block fails consensus irrespective of other validator votes.

[0137] The system includes an off-chain receipt state store (130), which maintains time- critical classification of Receipt IDs into unspent, in-progress, and spent states. This state store is required because blockchain-based updates, while immutable, cannot always maintain instantaneous state transitions due to block timing and network latency.

[0138] Validator nodes and the sentinel node consult the off-chain store when determining whether one or more Receipt IDs used as inputs in a transaction remain unspent at the time of validation. Upon submission of a transaction, the corresponding Receipt IDs may temporarily transition into an in-progress state, ensuring that concurrent transactions cannot attempt to reuse the same Receipt ID.

[0139] A distributed blockchain ledger (140) stores all validated transactions, associated Receipt IDs, their provenance metadata, and linking hash values anchoring each transaction to prior ledger state. Each validator node may propose new blocks, but only blocks verified and attested by at least one sentinel node and accepted by validator nodes are appended to the chain. The Blocks contain:- the validated set of transactions;- the newly generated Receipt IDs created as transaction outputs;- block hashes, previous block hashes, and merkle roots; and- identifiers used for deterministic ordering or cross-chain traceability.

[0140] A cross-chain interface (150) enables Receipt IDs recorded on a first blockchain to be locked, verified using a merkle proof or comparable attestation mechanism, and reminted on a second blockchain while preserving provenance metadata. This module may interact with a bridge service, an off-chain relay, or a light-client verifier embedded in the target chain.

[0141] The cross-chain interface records:- the original Receipt ID; the originating chain identifier; block height; transaction hash; content hash or inclusion proof; and any restrictions relevant to reminted assets.

[0142] This ensures deterministic asset tracking and prevents duplication or fraudulent recreation of Receipt IDs across chains. The cross-chain interface thereby facilitates controlled reminting or reissuance of Receipt Identifiers in secondary ledgers while maintaining deterministic provenance. This structural support allows the digital asset transfer framework to operate consistently across heterogeneous distributed ledger environments.

[0143] The components in Figure 1 communicate through a peer-to-peer network layer. In an embodiment, wallet modules use encrypted client-node channels (e.g., gRPC, REST, or WebRTC). The validator nodes exchange transaction pools, block proposals, and consensus votes using P2P broadcasts and the sentinel nodes receive and return attestation requests through dedicated secure channels. Furthermore, all nodes synchronise blockchain epochs using lightweight gossip protocols.

[0144] Consequently, the system architecture 100 enables: deterministic generation of Receipt IDs with embedded provenance; structured rules-based validation of transactions; authoritative attestation by sentinel nodes; secure coordination of unspent, in-progress, and spent Receipt IDs;- robust block formation and consensus; and optional cross-chain mobility of assets while retaining auditability.

[0145] Together, these capabilities provide a digital asset transfer platform that improves over conventional UTXO systems and account-based models by ensuring deterministic traceability, preventing double-spending, and enabling parallelizable consensus operations.

[0146] It will be appreciated that the functional components illustrated in Figure 1 may be distributed, consolidated, or re-implemented using alternative computing frameworks, communication protocols, or ledger structures. Embodiments may omit certain modules, integrate multiple functions into a single component, or deploy additional auxiliary services while remaining consistent with the architectural principles shown in Figure 1.

[0147] In summary, Figure 1 presents an example architecture in which wallet modules, validator nodes, sentinel nodes, off-chain state stores, and distributed ledger components cooperate to manage the deterministic creation, validation, and lifecycle control of Receipt Identifiers. These components interact to ensure secure execution of digital asset transfers, robust prevention of double-spending, verifiable provenance of transaction outputs, and optional cross-ledger mobility of assets. The arrangement provides a flexible and extensible platform capable of supporting high-integrity validation workflows, parallel consensus operations, and reliable asset traceability across multiple blockchain environments.

[0148] Figure 2 illustrates an example transaction processing arrangement 200 implemented within the distributed ledger system 100 described in Figure 1. Depicted is the internal structure of a blockchain block (201) and the layered cryptographic elements used to authenticate, validate, and anchor digital asset transfer transactions implemented by the wallet module 102, validator nodes 110, and sentinel node 120.

[0149] The illustrated block 201 comprises a zero-knowledge proof layer (210), a hash layer (220), and a transaction information layer (230). Together these layers provide cryptographic integrity, data authenticity, and deterministic provenance for each transfer transaction written to the ledger. The block 201 may be generated by a validator node during a consensus cycle and is subsequently verified by validator nodes and the sentinel node as described with respect to Figure 1.

[0150] The zero-knowledge proof (ZKP) layer (210) provides a cryptographic proof that one or more conditions associated with the transaction are satisfied without exposing underlying confidential data. In some embodiments, the ZKP layer may encode proofs relating to balance preservation, asset type constraints, or correctness of Receipt ID construction. The presence of the ZKP layer allows validator nodes 110 and the sentinel node 120 to verify transaction integrity while minimizing disclosure of sensitive metadata encapsulated in the transaction information layer 230.

[0151] The ZKP layer thus serves as an attestation mechanism supporting certain embodiments in which the system employs additional verification steps or privacy -preserving validation routines. The integration of the ZKP layer with the validator pipeline illustrated inFigure 1 ensures that transactions may be validated even when executed by lightweight or ephemeral nodes that do not store full transactional context.

[0152] Located beneath the ZKP layer is a hash layer (220) comprising cryptographic hash values that bind the block to the preceding state of the blockchain ledger 140. The hash layer includes, for example, the current block hash, the previous block hash, and a transaction hash derived from the transaction payload. The validator nodes 110 recompute these hashes during block verification, while the sentinel node 120 cross-checks these values against its own view of block headers and epoch metadata to ensure consistency.

[0153] The hash layer (220) provides the cryptographic anchor upon which Receipt Identifiers are generated. In embodiments described earlier, the Receipt ID generator (executed by wallet module 102 or by validator nodes 110) uses blockchain state parameters including the previous block hash, timestamp, and transaction metadata to compute a deterministic, provenance- encoded Receipt ID. This anchoring ensures traceability, prevents tampering, and guarantees that each Receipt ID is cryptographically tied to a specific block and transaction.

[0154] In some embodiments, the hash layer forms part of the deterministic provenance structure used by the system to ensure that each generated Receipt Identifier reflects both the transaction content and the underlying ledger state. Such provenance structures may be utilised by the validation components in Figure 1 to enforce uniqueness, referential integrity, and input-output consistency during digital asset transfers.

[0155] The transaction information layer (230) encapsulates the structured metadata for a digital asset transfer. In the illustrated embodiment, this information includes:- transaction number (231);- timestamp (232) representing the time of transaction creation or block inclusion;- transaction hash (233); and optional content hash (234) that uniquely identifies the transaction payload or associated data structure.

[0156] This transaction metadata is produced by the wallet module 102 when the user initiates an asset transfer, and is subsequently validated by validator nodes 110 using the validation logic described in Figure 1. The metadata structure is also used by the sentinel node 120during its attestation process to evaluate compliance with system-wide rules, off-chain Receipt ID states maintained in the receipt-state store 130, and external verification criteria.

[0157] As shown in Figure 2, the block 201 further includes a Receipt Identifier (Receipt ID) 240, which is generated for the transaction and written into the block as part of the output. The Receipt ID is derived using a cryptographic hash function over a concatenation of selected transaction fields and blockchain state parameters, including any of:- payer and payee addresses; asset type identifier; transaction amount; timestamp; previous block hash; and a nonce generated by the wallet module or validator node.

[0158] The Receipt ID 240 uniquely represents the transaction output and serves as the input to subsequent transactions as illustrated in Figures 3 and 4. Validator nodes 110 ensure that the Receipt ID is well-formed and unused, while the sentinel node 120 ensures that the Receipt ID’s state (unspent, in-progress, or spent) aligns with the off-chain store 130 before the block is accepted.

[0159] The Receipt Identifier thereby functions as a verifiable output artifact that may be subsequently consumed as an input in later transactions, facilitating lifecycle control and enabling the system to implement sequential issuance, state classification, and balancepreservation rules across multiple transaction cycles.

[0160] The layered block structure shown in Figure 2 corresponds directly to the architectural components in Figure 1. The wallet module 102 constructs the transaction metadata displayed in the transaction information layer (230). Validator nodes 110 populate and verify the hash layer (220) as part of block formation and validation. The sentinel node 120 may verify the ZKP layer (210) and validate the Receipt ID (240) against off-chain state (130) before issuing an attestation supporting inclusion of the block into the blockchain ledger 140.

[0161] The arrangement illustrated in Figure 2 also supports embodiments in which attestation, provenance verification, and block acceptance depend on coordinated evaluation of transaction metadata, cryptographic commitments, and Receipt Identifier characteristics.

[0162] In an embodiment, the transaction information layer includes a block height and a transaction index identifying the position of the transaction within the block, enabling receipt ordering and audit reconstruction based on ledger structure.

[0163] Figure 2 illustrates a layered transaction structure in which zero-knowledge proofs, hash-anchored metadata, and Receipt Identifiers interact to establish a verifiable and tamper- evident record of digital asset transfers. When integrated with the architectural components of Figure 1, the layered arrangement enables robust validation workflows, deterministic provenance tracking, and reliable anchoring of transaction outputs within the distributed ledger.

[0164] Figure 3 illustrates, in schematic form, an example arrangement 300 for generating a hash total and corresponding Receipt Identifier (Receipt ID) for a digital asset transfer transaction. The arrangement 300 interacts with, and may be implemented by, the transaction processor, hash calculator, and validation components described with reference to Figure 1. It also extends the block-level structure illustrated in Figure 2 by showing how transactionspecific inputs are cryptographically transformed into immutable receipt artefacts.

[0165] The computation of the hash total and resulting Receipt Identifier shown in Figure 3 is performed within the same functional architecture illustrated in Figure 1, where the transaction processor, hash calculator, and validation modules cooperate to ensure deterministic Receipt ID formation. By incorporating transaction attributes such as the payer address, payee address, transaction timestamp, and the hash of a preceding transaction, the system establishes a cryptographically verifiable link between sequential transactions. The inclusion of a nonce enables uniqueness even when other fields may be duplicated, supporting the sequential issuance model enforced by the system’s transaction logic. This computed Receipt ID becomes the fundamental object used by the input-output validation module to determine the validity of a transaction, including checks for authenticity, unspent status, and state consistency across the distributed ledger.

[0166] In the embodiment shown, a transaction assembly module (301) receives a set of transaction parameters that collectively define the semantic content of the transfer. These include, in this illustrative example, a sender address (301a), a recipient or merchant address (301b), a transaction amount (301c), one or more input certificate or Receipt IDs (301 d), and atimestamp (301e). Additional parameters may include a chain identifier, block height, or any other ledger-state attributes required for deterministic transaction formation. The parameters 301a-301e may originate from the modules 102 and 104 of Figure 1, which ensure that the transaction is properly structured and cryptographically signed before processing.

[0167] A blockchain-state integration module (302) incorporates one or more ledger-state parameters into the hash calculation. These may include the previous block hash (302a), a block-level or transact! on -level nonce (302b), the current merkle root (302c), or other state commitments produced during block assembly as shown in Figure 2. This ensures that each receipt is anchored to a specific chain context, thereby preventing replay of a valid transaction into an unintended state or chain fork.

[0168] The transaction parameters and blockchain-state parameters are supplied to a concatenation and normalisation engine (303). In this example, a deterministic concatenation order is applied — such as lexicographic or schema-defined ordering — combined with canonical encoding of numeric, textual, and binary fields. The deterministic ordering enables independent validators to compute identical receipt hashes, while the inclusion of the nonce ensures that two syntactically identical transactions cannot generate the same Receipt ID. The deterministic concatenation process supports embodiments where the system maintains ascending-sequence identifiers or enforces collision resistance as part of validation workflows.

[0169] A cryptographic hash function (304), such as SHA-256 or an equivalent secure hash algorithm, is then executed over the concatenated byte sequence 303. The output of this hashing procedure generates a transaction hash total (304a). In various embodiments, the hash total may itself be incorporated into the block hash shown in Figure 2, or may be recorded in the validation structure maintained by the consensus module 108 of Figure 1. The hash total 304a provides a tamper-evident fingerprint of the transaction content, and may be used in dispute resolution, audit reconstruction, or inter-chain verification for cross-chain transfers.

[0170] The hash total produced in Figure 3 serves as one of the parameters examined during consensus validation. Validator nodes, including any designated sentinel nodes, recompute or verify the hash total from the presented transaction data to confirm that no tampering has occurred. This cross-verification mechanism ensures that Receipt IDs cannot be forged, duplicated, or replayed across forks or parallel branches of the ledger. The deterministiccomposition of the hash also enables rapid verification by lightweight or remote participants, supporting scalable validation in the consensus architecture described earlier.

[0171] A Receipt Identifier generator (305) transforms the hash total 304a into a Receipt ID 305a. The transformation may be direct (e.g., truncated hash, salted hash) or compound (e.g., combining hash total with sequential issuance metadata, chain ID, or internal counter values). In some embodiments, the Receipt ID 305a includes metadata comprising the originating address, timestamp, originating block number, or chain identifier, thereby enabling external verifiers to validate provenance and detect anomalous or conflicting transactions. The resulting Receipt ID 305a may be written into the ledger and, when applicable, into the Receipt ID list or sidechain structure referenced in Figure 1.

[0172] In some embodiments, the generation of the Receipt Identifier 305a also interacts with a sequencing component referenced in Figure 1, which maintains an incrementing receipt sequence value in persistent ledger state. The sequence value may be reserved or incremented when the transaction parameters are assembled, enabling validators to confirm that no gaps, replays, or duplicate identifiers arise during block formation. This mechanism supports consistent ordering of receipts and enables deterministic validation of input-output relationships during transaction execution.

[0173] A verification and classification module (306) optionally performs preliminary validation checks, such as ensuring the referenced input certificates exist, verifying that the sender address matches the signing credentials, or confirming that the calculated hash total 304a matches the hash derived from block-level records encoded in the layered structure illustrated in Figure 2. In embodiments with sequential issuance, the module 306 may also update the internal counter state ensuring gap-free ordering and referential integrity.

[0174] The verification and classification module 306 may additionally check that each input Receipt ID referenced in the transaction corresponds to a valid, unspent receipt entry maintained in the receipt-state structure described in Figure 1. The module may perform preliminary balance computations, ensuring that the aggregate input quantity is equal to or greater than the proposed output quantity, before passing the transaction to the consensus validation workflow. By linking the hashed transaction parameters to both spent and unspent classifications, the system ensures that the Receipt Identifier 305a becomes a traceable elementin the lifecycle of the asset, supporting deterministic transfer flows and preventing doublespend conditions.

[0175] The output of the arrangement 300 therefore consists of both (i) a cryptographic hash total 304a representing the transaction content and state, and (ii) a Receipt Identifier 305a that uniquely and irrevocably links the transaction into the chain’s historical record. As further illustrated in Figures 1 and 2, these artefacts become inputs to consensus validation, ledger finalisation, and downstream transfer operations, including cross-chain replication and verification.

[0176] The inclusion of the previous block hash 302a and other chain-state parameters ensures that the hash total 304a is cryptographically linked to a prior transaction or block, enabling later validators to verify that the corresponding Receipt Identifier is bound to a unique and immutable chain position. Such hash chaining supports replay protection, deterministic ordering, and the anchoring of receipts across intra-chain and cross-chain contexts.

[0177] It should be understood that the arrangement shown in Figure 3 represents one example of how transaction parameters and ledger-state parameters may be combined to form a hash total and Receipt Identifier. Equivalent implementations may vary in ordering, encoding, hashing method, or metadata structure, provided the resulting Receipt Identifier remains cryptographically derived, verifiable, and bound to its originating transaction.

[0178] In an implementation, the hash total 304a and Receipt Identifier 305a may be evaluated by one or more validator nodes, including nodes configured to apply external -data analysis or anomaly detection techniques. These nodes may confirm that the hash total corresponds to an authentic set of transaction parameters, that the referenced receipts have not been previously marked as spent, and that the chain-state parameters accurately reflect the current ledger state. This provides supplementary assurance prior to block acceptance and may assist in resolving ambiguous or conflicting transaction submissions.

[0179] In further embodiments, the Receipt Identifier 305a generated in Figure 3 may also form the basis for a cross-chain receipt artefact, where the originating receipt values are encapsulated, hashed, or reminted into a form suitable for a second blockchain. The hash total 304a may be incorporated into a merkle proof or bridge-verification structure that allowsanother chain to confirm that the receipt originated from a particular block, under a particular hash, without requiring full-chain synchronisation.

[0180] The generation of a Receipt ID as illustrated in Figure 3 also underpins the system’s input-output balancing logic, which forms a core rule for validating asset transfers. When a transaction references one or more Receipt IDs as inputs, the system computes the total quantity represented by those inputs and compares it against the total quantity associated with the newly generated output Receipt IDs. If the computed output amount is less than the aggregate input amount, the system automatically generates an additional balancing Receipt ID transferring the remainder back to the originating address. This behaviour ensures:- no inflation or creation of unbacked value;- no deflation beyond authorised spending; deterministic traceability of each unit of value; and accountability of unused or residual amounts.

[0181] The balancing logic is performed atomically during transaction processing and forms part of the verification steps applied by validator nodes (and by sentinel nodes, where applicable), ensuring that only transactions satisfying these constraints are eligible for block inclusion. The Receipt ID generated as part of this balancing operation retains the same cryptographic construction described in Figure 3, ensuring that the system maintains a continuous, auditable ledger of asset flow.

[0182] In an alternative embodiment, the system does not rely on a single monotonically incrementing sequence number maintained in smart-contract state or other shared storage to impose ordering among Receipt Identifiers. Instead, ordering information for each Receipt ID is derived directly from the structure of the blockchain ledger itself. In this embodiment, each block produced by the consensus process is associated with a unique block height that increases as new blocks are appended to the chain. Within each block, validated transactions are arranged in a deterministic order, such as according to a prescribed sorting rule, consensus- defined acceptance order, or other reproducible ordering criterion. For each transaction that generates one or more Receipt Identifiers, the system records the block height together with the transaction’s position or index within that block.

[0183] The combination of block height and transaction index provides a clear, reliable, and reproducible ordering of Receipt Identifiers across the ledger, without requiring a centralised or shared sequence counter. This ordering mechanism preserves the auditability, reconciliation, and verification properties of sequential issuance, while avoiding contention on contract-level state and enabling improved scalability under parallel transaction processing. In such embodiments, the Receipt Identifier generator, smart contract logic, or receipt-certificate construction process records the block height and transaction index as receipt metadata, and may incorporate these values into the receipt hash, certificate structure, or provenance fields, thereby cryptographically binding the Receipt ID to its ledger position. In an alternative embodiment, the system does not rely on a single monotonically incrementing sequence number maintained in smart-contract state or other shared storage to impose ordering among Receipt Identifiers. Instead, ordering information for each Receipt ID is derived directly from the structure of the blockchain ledger itself.

[0184] In this embodiment, each block produced by the consensus process is associated with a unique block height that increases as new blocks are appended to the chain. Within each block, validated transactions are arranged in a deterministic order, such as according to a prescribed sorting rule, consensus-defined acceptance order, or other reproducible ordering criterion. For each transaction that generates one or more Receipt Identifiers, the system records the block height together with the transaction’s position or index within that block.

[0185] The combination of block height and transaction index provides a clear, reliable, and reproducible ordering of Receipt Identifiers across the ledger, without requiring a centralised or shared sequence counter. This ordering mechanism preserves the auditability, reconciliation, and verification properties of sequential issuance, while avoiding contention on contract-level state and enabling improved scalability under parallel transaction processing. In such embodiments, the Receipt Identifier generator, smart contract logic, or receipt-certificate construction process records the block height and transaction index as receipt metadata, and may incorporate these values into the receipt hash, certificate structure, or provenance fields, thereby cryptographically binding the Receipt ID to its ledger position.

[0186] Figure 4 illustrates a Receipt Identifier (Receipt ID) state machine 400, which forms a core behavioural model for managing the lifecycle of digital asset certificates within the system 100. The state machine describes the permissible transitions of each Receipt IDbetween an unspent state, an in-progress state, and a spent state, based on events occurring during transaction submission, validation, block acceptance, or rejection. The Receipt ID state machine 400 interacts with the transaction processing workflow illustrated in Figure 2 and the hash / receipt generation process illustrated in Figure 3, and is maintained through components such as the input-output validation module 130, the consensus module 150, and the ledger update module 160 of Figure 1.

[0187] A newly generated Receipt ID enters the unspent state 401, representing its availability for use in a subsequent transfer transaction. As visualised in Figure 1, this state corresponds to a ledger entry recorded upon execution of a transfer transaction and block inclusion, with the Receipt ID and its associated metadata (e.g., receipt hash, block height, timestamp, content hash) stored in persistent ledger state 165 and synchronised to the unspent certificate list. In this state, the Receipt ID may be referenced as an input to a new transaction, and the system treats it as a valid, unencumbered certificate containing a deterministically trackable asset quantity.

[0188] Upon initiation of a transaction that references one or more unspent Receipt IDs as inputs, the system transitions the Receipt IDs to an in-progress state 402, as shown by transition arrow 411. This transition may occur when a transaction is submitted to the network and propagated for pre-validation, aligning with the transaction propagation step in Figure 2.

[0189] The in-progress state 402 prevents race conditions, duplicate spending attempts, or conflicting submissions by marking the affected Receipt IDs as temporarily locked pending completion of the validation process. Auxiliary systems or sentinel nodes may also maintain a mirrored live-state table of in-progress Receipt IDs to ensure low-latency coordination in merchant-payment or high-volume transaction scenarios.

[0190] While in the in-progress state 402, the referenced Receipt IDs are evaluated through the verification and classification functions of module 306 of Figure 3, including: confirming that the referenced Receipt IDs exist in the ledger,- verifying that associated cryptographic signatures are valid, checking that the hash totals embedded in the Receipt IDs correspond to the values recorded on-chain, ensuring input-output balance and correct sender-receiver relationships, andensuring sequential integrity where required.

[0191] If the transaction is rejected before block inclusion, due to an invalid signature, outdated chain state, hash mismatch, failed balance computation, or sentinel node veto, the Receipt IDs transition back to the unspent state 401, shown by transition arrow 412. This restores their availability for future use, preventing permanent lockout from temporary or invalid attempts.

[0192] If the transaction successfully satisfies the consensus validation procedures, including confirmation by any required sentinel node, the Receipt IDs referenced as inputs transition to the spent state 403, shown by transition arrow 413. This transition occurs atomically during block execution and ledger update operations described in Figure 1. At this point:- the Receipt IDs are recorded as consumed, no future transaction may reference them as inputs,- the ledger update module 160 writes updated receipt-state entries,- new output Receipt IDs generated for the transaction enter the unspent state 401.

[0193] The spent state 403 is irrevocable because the blockchain provides immutability and prohibits reallocation or reuse of spent receipts. Thus, each Receipt ID participates in at most one transfer transaction as an input, enabling deterministic audit trails and provable asset flow.

[0194] The state machine 400 operates in conjunction with the sequential issuance model described in Figure 3. The deterministic hash total and the incremental Receipt ID sequence are both validated before a state transition is finalised. As a result, the state machine supports both the logical correctness (preventing reuse or inconsistencies), and cryptographic correctness (ensuring each Receipt ID is validated against chain-state parameters and prior hash commitments). This structure improves auditability, enables decentralised double-spend prevention, and provides a unified abstraction for intra-chain and cross-chain transfer behaviours.

[0195] In an alternate embodiment, the state machine may include additional transient or extended states, such as: a quarantined state, where a sentinel identifies anomalous activity; a bridged / locked state, used in cross-chain transfer operations; ora provisional state, pending off-chain attestations or external-data verification inputs.

[0196] These optional states allow the system to accommodate compliance workflows, crossnetwork atomicity conditions, or Al-based anomaly detection functions without altering the fundamental three-state lifecycle illustrated in Figure 4.

[0197] Figure 5 illustrates a verification workflow 500 for processing transfer transactions within the system 100. The workflow depicts an ordered evaluation of digital asset transactions using a structured set of verification rules, including an input-receipt validation rule 510, an output-receipt validation rule 520, and a combined rule-based validation process 530 that determines whether a transaction is eligible for acceptance into the ledger. The verification workflow 500 operates in conjunction with the transaction processor, input-output validator, consensus module, and ledger update functions described in Figures 1-4.

[0198] In the first stage of the workflow, the system applies an input receipt verification rule 510, which is responsible for determining whether each input Receipt Identifier (Receipt ID) referenced by a transaction is valid, authentic, and currently available for use. This verification stage interacts with the Receipt ID state machine illustrated in Figure 4, particularly examining whether each referenced Receipt ID resides in the unspent state.

[0199] During this step, the system:- retrieves the on-chain metadata associated with each input Receipt ID,- verifies that the referenced transaction hash matches the stored hash total derived according to the hashing process shown in Figure 3, confirms that the digital signature of the sender corresponds to the public key recorded in the ledger, evaluates whether the Receipt ID has not been previously consumed or marked inprogress in concurrent transaction attempts, and- verifies that the Receipt ID is logically sequenced relative to the chain state and has not been invalidated by a chain reorganization or fork resolution.

[0200] The input verification rule 510 therefore ensures that only legitimate, unspent, cryptographically verifiable receipt certificates may serve as the foundation for constructing a new transaction.

[0201] The second stage of the verification workflow applies an output receipt verification rule 520, which evaluates the correctness and legitimacy of the newly proposed output Receipt IDs created by the transaction. In this step, the system:- recomputes the hash total for each proposed output using the deterministic process shown in Figure 3,- validates that each output Receipt ID corresponds to the declared asset amount and intended receiver address, ensures that no output Receipt ID collides with or duplicates any pre-existing ID, and confirms that the proposed outputs conform to the incremental or sequential issuance logic maintained by the system’s internal counter mechanism.

[0202] Where the transaction generates a balancing Receipt ID, consistent with the inputoutput balancing concepts described earlier, the system verifies that the balancing value corresponds exactly to the difference between total input value and the designated output amounts. The balancing Receipt ID is validated in the same manner as standard outputs and must satisfy all structural, cryptographic, and consistency rules. This stage ensures that the transaction forms a coherent and self-contained value transformation without creating, destroying, or manipulating asset quantities.

[0203] The verification workflow 500 operates through the coordinated execution of several system components, including the transaction module, the input-output validation module, the consensus module, and the ledger update module introduced in Figure 1. Each rule applied within workflow 500 corresponds to a specific evaluation step performed by one or more of these modules. For instance, the input receipt verification rule interacts directly with the inputoutput validation module to confirm the availability and authenticity of referenced Receipt IDs, while the combined rule-based validation relies on the consensus module to determine whether the transaction satisfies system-defined criteria and external validation requirements. This modular interaction ensures that the verification workflow is consistently integrated with the system’s broader operational framework.

[0204] The verification workflow proceeds to a combined validation step 530, where the results of rules 510 and 520 are aggregated and evaluated to determine overall transaction validity.

[0205] The combined rule-based process 530 performs the following operations: i. Reconciliation of Input and Output Totals

[0206] The system confirms that the sum of the input Receipt ID values equals the sum of the output Receipt ID values, including any balancing output. This prevents inflation or underflow conditions and enforces strict conservation of value. ii. Cross-Validation of Hash Integrity

[0207] Both input and output Receipt IDs must have cryptographically valid hash totals, ensuring end-to-end traceability. This step uses the hash calculator module described in Figure 1 and the hash generation mechanism described in Figure 3. iii. Chain-State Consistency Check

[0208] The transaction is evaluated against the current block height, the previous block hash, and the merkle-root snapshot to ensure that the transaction does not conflict with real-time chain evolution. Sentinel nodes may supply supplemental validation, including querying external state tables. iv. Signature and Address Authorization

[0209] The system confirms that the sender is authorized to spend the input Receipt IDs and that the signature is bound to the correct wallet or certificate authority. v. Application of Verification Policies

[0210] In an embodiment, the verification process incorporates additional rule sets, including anomaly detection rules, risk classification logic, or policy -based spending restrictions enforced by sentinel nodes. If all required checks within the combined verification stage pass successfully, the transaction is classified as valid and forwarded for consensus evaluation within the network, as illustrated in Figure 2. If any rule fails, the system rejects the transaction, returning any in-progress Receipt IDs to the unspent state shown in Figure 4.

[0211] As part of the output receipt verification rule 520, the system may further validate that the proposed output Receipt IDs adhere to the sequential issuance logic described previously. This includes confirming that the issuance counter has not been incremented out of order and that no parallel transaction has reserved the same sequence number. By incorporating this check into the verification workflow, the system ensures that the deterministic ordering of Receipt IDs remains intact across all transactions.

[0212] In some embodiments, one or more sentinel nodes participate in the rule-based verification workflow by applying supplemental validation criteria. Such nodes may access off-chain certificate-state tables, risk classifications, or external data feeds to detect anomalies or inconsistencies that would not be apparent from on-chain data alone. When a sentinel node identifies a discrepancy related to input-origin legitimacy, asset provenance, or cross-chain transfer status, it may flag the corresponding rule as unsatisfied. This supplemental validation enhances the robustness of the verification workflow and supports a broader set of operational and compliance requirements.

[0213] The input-output balancing logic is also performed during the combined rule-based verification stage. The validator determines whether the set of proposed outputs, including any balancing Receipt ID, accurately reflects the total asset quantity represented by the input receipts. This balancing behaviour prevents double-spending, enforces conservation of value, and ensures the traceability of residual amounts returned to the sender. If the balancing step produces an inconsistency, the rules within workflow 500 classify the transaction as invalid.

[0214] During execution of workflow 500, the system manages the lifecycle transitions of Receipt IDs, moving referenced inputs from the unspent state to the in-progress state upon transaction submission, and ultimately to the spent state upon successful verification and consensus acceptance. If any rule fails, the system reverts the Receipt IDs to the unspent state, ensuring that transient or erroneous transaction attempts do not permanently lock asset certificates. This behaviour reflects the state machine illustrated in Figure 5.

[0215] In an embodiment, the validation workflow illustrated in Figure 5 operates in combination with the receipt-generation functions previously illustrated in Figure 3 and the state-transition logic discussed in Figure 4. Each verification rule applied by the verification engine is configured to enforce a deterministic, machine-executable constraint on thetransaction data structure. These constraints ensure that: (i) each referenced receipt identifier corresponds to a cryptographically valid and unspent certificate, (ii) the quantity attributed to each input receipt identifier matches the ledger state committed by the consensus nodes, and (iii) the overall transaction satisfies an input-output conservation requirement that prevents creation or destruction of units. The verification workflow thereby provides a programmatic guarantee that only valid, authorised and balanced transactions are eligible for inclusion within a block.

[0216] Figure 6 illustrates an integrated workflow 600 that combines sequential receipt identifier issuance, multi-stage consensus validation including sentinel participation, and cross-chain asset transfer operations. The leftmost portion of Figure 6 depicts a receipt issuance subsystem 601, which provides deterministic and strictly ordered generation of receipt identifiers for new transactions. In an embodiment, a transaction constructor 602 receives transaction inputs including payor address, payee address, asset identifier, transfer quantity, timestamp, and one or more blockchain state parameters propagated from the system of Figure 1. A deterministic hashing unit 603 applies a cryptographic hash function, such as SHA-256-to a concatenation of these parameters together with a monotonically increasing counter value obtained from a receipt sequence manager 604. The resulting hash output, together with the sequence number, forms the composite Receipt ID 605, which uniquely identifies the transaction output and binds it to the chain state at the time of issuance. The output of the receipt issuance subsystem 601 feeds directly into the validation subsystem 610.

[0217] In this arrangement, the use of a monotonic sequence manager 604 ensures that each generated Receipt ID 605 is associated with a globally ordered position within the ledger, enabling deterministic reconstruction of transaction lineage and facilitating subsequent verification by validation modules and sentinel components. The concatenation and hashing performed by the deterministic hashing unit 603 provides a cryptographically verifiable binding between the transaction content, chain state, and receipt sequence, thereby enabling subsequent rule-based and state-machine operations to depend on immutable, tamper-evident identifiers.

[0218] The central portion of Figure 6 illustrates a multi-layer consensus validation pipeline 610. In the first stage, a validator set 611 comprises nodes configured to apply rule-based verifications as outlined in the verification structure of Figure 5. These verifications includeassessment of the validity of input Receipt IDs (including hash consistency, unspent status, and sufficiency of quantity), verification of the correctness of output Receipt IDs generated by the subsystem 601, cryptographic authentication of signatures associated with the transaction, and confirmation that the proposed transaction maintains input-output quantity balance consistent with the balancing principles described with reference to Figure 3. The validator set 611 also confirms compliance with deterministic execution rules associated with transaction code, where the system incorporates executable transaction modules.

[0219] In this embodiment, the validator set 611 performs evaluation steps that correspond to the structural and functional elements of the receipt-verification processes described earlier in relation to Figures 3 and 5. These include verifying that the Receipt ID content matches a deterministic transformation of transaction data and chain-state parameters, confirming that the receipt sequence number accords with the ordering constraints imposed by the receipt issuance subsystem 601, and enforcing input-output parity to ensure that transaction execution does not result in unauthorised creation or destruction of tokenised value.

[0220] Following validator-set evaluation, the transaction is passed to at least one sentinel node 612. The sentinel node 612 provides enhanced verification functions beyond rule-based validation. In an embodiment, the sentinel node 612 consumes externalised state data received from the chain-state propagation mechanisms introduced in Figure 1, including cross-chain lock states, external identity attestations, and system-level data required for policy -based validation. The sentinel node 612 may maintain a specialised record of authorised asset issuance limits, lists of compromised keys, or revocation data that is not necessarily stored on the public blockchain. The sentinel node 612 provides a binary accept / reject output signalling whether the transaction satisfies all extended validation requirements. If the sentinel node 612 issues a rejection, the transaction cannot progress to block formation irrespective of validatorset votes, ensuring that the sentinel forms a required participant in the consensus process. This arrangement reinforces tamper resistance and mitigates attack vectors targeting validator majorities.

[0221] Through this arrangement, the sentinel node 612 provides an additional enforcement layer distinct from the validator-set logic, allowing execution of policies that are not solely derivable from on-chain data. This supports embodiments where compliance metadata, jurisdiction-specific constraints, or key -revocation lists form part of the transaction validitycriteria. The sentinel thereby acts as a compulsory gatekeeper, ensuring that the state transitions depicted in Figure 4 can only proceed where both deterministic (node-level) and policy-based (sentinel-level) checks are satisfied.

[0222] The output of the combined validator set 611 and sentinel 612 forms a consensus decision 613. If the decision is affirmative, the transaction is included in a candidate block assembled by block-formation nodes (shown in Figure 1), and all Receipt IDs associated with the transaction advance along the state path illustrated in Figure 4. If rejected, the receipts remain or revert to the unspent state, or transition to an error state depending on the implementation.

[0223] The rightmost portion of Figure 6 illustrates a cross-chain asset transfer subsystem 620, allowing an output Receipt ID originating on a first blockchain (Chain A) to be represented and transacted on a second blockchain (Chain B) in a verifiable manner. A lock event 621 on Chain A marks one or more Receipt IDs as locked, preventing further spend operations on Chain A while a cross-chain transfer is pending. The lock event 621 is committed to Chain A’s block structure, and its inclusion is provable via a merkle proof generation module 622, which constructs a merkle branch 623 anchored to a block header on Chain A.

[0224] In an embodiment, the consensus decision 613 further ensures that a Receipt ID transitions from the “in-progress” state to either the “spent” or “rejected” branch of the state machine only when both deterministic and sentinel-verified validation paths have been completed. This coordinated enforcement ensures that no transaction is finalised without satisfaction of the multiple validation layers illustrated across Figures 4-6.

[0225] The merkle proof 623, together with metadata of the locked Receipt ID, is provided to a cross-chain bridging module 624. In an embodiment, the bridging module 624 includes or communicates with a sentinel node 612, enabling the sentinel to verify both (i) that the merkle proof corresponds to a valid lock event on Chain A, and (ii) that the lock event satisfies applicable system rules, including cross-chain policy constraints. Upon successful attestation, the bridging module 624 authorises creation of a corresponding mint event 625 on Chain B. The mint event 625 generates a new Receipt ID representing the transferred asset on Chain B, where the Receipt ID construction process mirrors the deterministic issuance steps performedby subsystem 601 but includes additional cross-chain metadata such as original chain identifier, original receipt identifier, and lock block height.

[0226] The lock event 621 interacts with the receipt-state model by transitioning the original Receipt ID into a locked state, distinct from the unspent, in-progress, and spent states of Figure 4 but governed by similar state-transition rules. This ensures that a single Receipt ID cannot be simultaneously spent on more than one chain, thereby preventing double-spend conditions in multi-chain environments.

[0227] Once minted on Chain B, the new Receipt ID 626 is recorded in Chain B’s ledger, where it is thereafter transactable according to the same receipt-state model depicted in Figure 4 and verifiable using the rule-based and sentinel -based mechanisms illustrated in Figure 5 and Figure 6. This ensures symmetry of validation processes across chains, prevents replay attacks, and maintains provenance continuity for the digitised asset.

[0228] The integrated workflow of Figure 6 therefore demonstrates how sequential receipt generation (601-605), consensus validation involving both standard validators and sentinel nodes (611-613), and cross-chain transfer logic (621-626) interact within a unified distributed-ledger computing environment. The arrangement supports scalable asset issuance, deterministic receipt identification, robust security through sentinel enforcement, and verifiable interoperability between heterogeneous blockchains.

[0229] The lock event 621 interacts with the receipt-state model by transitioning the original Receipt ID into a locked state, distinct from the unspent, in-progress, and spent states of Figure 4 but governed by similar state-transition rules. This ensures that a single Receipt ID cannot be simultaneously spent on more than one chain, thereby preventing double-spend conditions in multi-chain environments.

[0230] The mint event 625, informed by merkle proof 623 and sentinel attestation, generates a new Receipt ID 626 on Chain B whose deterministic construction incorporates cross-chain provenance metadata. This ensures that the new Receipt ID maintains a traceable linkage to the originating chain and transaction, enabling any verifier module operating in the Figure 5 structure to validate the authenticity and origin of the minted asset even in a heterogeneous multi-chain deployment.

[0231] In embodiments where receipt ordering is derived from block height and transaction index rather than from a pre-allocated sequence counter, definitive ordering attributes of a Receipt Identifier may be assigned during block construction or finalisation. In such cases, transactions may be validated in parallel by multiple validator nodes or smart-contract execution contexts, while the final receipt ordering is deterministically determined when validated transactions are assembled into a block. This approach is compatible with parallel smart-contract invocation, distributed validation across multiple nodes, and sentinel -assisted consensus, while avoiding reliance on shared mutable counters that could limit throughput or introduce contention in high-volume transaction environments.

[0232] Figure 7 illustrates an example consensus arrangement 700 in which multiple consensus groups are instantiated in parallel to validate and commit distinct subsets of pending transactions. The arrangement 700 builds upon the consensus functions and sentinel behaviour introduced in Figure 1, the verification workflow of Figure 5, and the integrated validation path depicted in Figure 6, and demonstrates how the system can scale throughput while retaining sentinel-based attestation for each block.

[0233] In an embodiment, a consensus manager 701 is configured to monitor a global pool of pending transactions 702. The consensus manager 701 may receive transaction candidates from the transaction processing arrangement of Figure 2, where each candidate has already undergone preliminary validation as described with reference to Figures 3-5. When the transaction volume or latency thresholds exceed a predetermined level, the consensus manager 701 partitions the pending transactions 702 into multiple subsets 703a, 703b, 703c, each subset being assigned to a different consensus group for parallel processing.

[0234] In a embodiment, the consensus manager 701 interfaces with the transaction processing pipeline described in Figures 2-4, receiving transactions that have already been assigned Receipt IDs, verified against the input-output balancing logic, and associated with the transaction-specific hash values generated within the zero-knowledge and hashing layers of Figure 2. This ensures that the segmentation of transaction subsets 703a-703c reflects both structural validation outcomes and the ledger state maintained by the data structures of the system 100 shown in Figure 1.

[0235] The arrangement 700 includes a first consensus group 710, a second consensus group 720 and, in some embodiments, additional groups 730, 740, each group being instantiated dynamically by the consensus manager 701. Each consensus group comprises a plurality of validator nodes and at least one sentinel node. For example, the first consensus group 710 includes validator nodes 71 la-71 In and a sentinel node 712. The second consensus group 720 may include validator nodes 72 la-72 In and a sentinel node 722, and a similar pattern may be applied to further groups 730, 740. Each group is associated with a group identifier 715, 725 that can be recorded in the ledger to indicate which group validated a particular block.

[0236] Within each consensus group, validator nodes are configured to apply rule-based validation to the assigned subset of transactions, making use of the input-output verification logic outlined in Figure 5 and the receipt identifier construction and state-transition concepts described in Figures 3 and 4. The validators check, for example, that each referenced Receipt ID is unspent, that input and output quantities balance, that cryptographic signatures are valid, and that hash totals for receipts and transactions match those recorded in the chain state. These checks may be performed concurrently across multiple validators within the same group to further enhance throughput.

[0237] The validator nodes 71 la-71 In are configured to execute the rule sets introduced in Figures 5 and 6, including checks relating to the existence and status of Receipt IDs, the reproduction of transaction hash values, and evaluation of the zero-knowledge proof output associated with each transaction. The implementation of these rules across multiple consensus groups provides functional continuity with the transaction verification logic of Figure 5 while enabling parallelised evaluation across distinct subsets of transactions.

[0238] The sentinel node 712, 722 associated with each consensus group provides an additional layer of verification. In an embodiment, the sentinel node is configured to access externalised state or off-chain data sources, such as live spent / unspent lists, cross-chain lock records, compliance or policy metadata, or anomaly detection outputs. The sentinel node may execute one or more deterministic or machine learning-based checks to detect irregular or high-risk transaction patterns. A consensus decision 716, 726 for a given group is only considered successful when both: (i) a required quorum of validator nodes within that group has accepted the transaction subset, and (ii) the corresponding sentinel node has issued an attestation of validity for the same subset.

[0239] Once a consensus group has reached a positive decision 716, the group produces a candidate block 717 that encapsulates the validated transactions, associated Receipt IDs, and relevant metadata, including the group identifier and, in some embodiments, a sentinel attestation reference. These candidate blocks are forwarded to the consensus manager 701, which coordinates incorporation of the blocks into the distributed ledger. Multiple consensus groups can operate concurrently, so that candidate blocks 717, 727 from different groups may be produced in overlapping time intervals. The sentinel node functions as the specialised verification entity identified within the system architecture of Figure 1 and the verification workflow of Figure 6. In particular, the sentinel node 712 can incorporate additional validation rules, including cross-chain state checks, regulatory or compliance rule enforcement, or anomaly detection routines. These align with the system’s ability to reference externalised or higher-order state representations associated with the security layer and metadata structures described earlier. Each candidate block 717 includes not only the validated transactions but also a consolidated receipt-state mapping consistent with the ledger state transitions illustrated in Figures 3 and 4. In some embodiments, the candidate block also stores a consensus-group identifier referencing its originating group, enabling downstream auditing and deterministic ordering, as introduced conceptually in Figure 6.

[0240] In some embodiments, the consensus manager 701 applies a deterministic ordering protocol to the set of candidate blocks 717, 727 produced by the consensus groups. The ordering protocol may be based on parameters such as block timestamp, cryptographic hash values, or pre-assigned group priority, allowing the system to resolve contention where blocks touch overlapping regions of state (for example, transactions referencing the same Receipt ID). Blocks that cannot be reconciled without conflict may be rejected or re-queued for subsequent rounds of validation, whereas blocks that pass ordering and conflict-resolution checks are finalised and committed to the ledger as part of the blockchain maintained by the system 100. The deterministic ordering protocol is consistent with the principle of preventing double-spend or invalid state transitions as articulated through the receipt-status logic of Figures 4 and 5. Blocks touching overlapping Receipt IDs or producing mutually exclusive state transitions are detected and resolved before ledger commitment, ensuring coherence with the system’s global state representation in Figure 1.

[0241] The arrangement of Figure 7 therefore enables the system to scale transaction throughput by distributing the verification workload across multiple consensus groups, whilemaintaining the requirement that each validated block involves participation of at least one sentinel node. This structure strengthens the security model relative to systems that rely solely on homogeneous validator sets, because each group combines rule-based validation of transaction structure with sentinel-based attestation of external or higher-order conditions.

[0242] Figure 8 illustrates an example cross-chain transfer arrangement 800 for moving digitised assets represented by Receipt IDs from a source blockchain 810 to a destination blockchain 820. The arrangement 800 builds upon the system architecture of Figure 1, the transaction and receipt generation processes of Figures 2 and 3, the receipt state machine of Figure 4, the rule-based verification logic of Figure 5, and the consensus and sentinel arrangements of Figures 6 and 7.

[0243] In an embodiment, the source blockchain 810 comprises a ledger 811 that records transfer transactions, Receipt IDs and associated metadata as described previously. A crosschain lock contract or module 812 is deployed on the source chain 810 and is configured to receive a transfer request 801 from a user or application wishing to move a particular Receipt ID (or set of Receipt IDs) from the source chain 810 to the destination chain 820. The transfer request 801 may include, for example, a source Receipt ID, a target chain identifier, and a destination address on the destination chain 820.

[0244]

[0245] Upon receiving the transfer request 801, the lock contract 812 executes a lock operation 813. In this operation, the one or more input Receipt IDs are consumed and transitioned from the “unspent” state to a “locked” or “spent-for-bridge” state in the receipt state machine described in Figure 4. In some embodiments, the lock operation 813 results in a dedicated lock transaction 814 being written into a new block on the source chain 810. This lock transaction 814 is processed and validated by the verification engine and consensus modules as described in relation to Figures 5-7, ensuring that the lock operation is subject to the same structural and cryptographic checks as any other transaction.

[0246] Transactions containing lock operations 813 are incorporated into a Merkle tree 815 constructed over the set of receipts or events for a given block or epoch on the source chain 810. The Merkle tree 815 produces a Merkle root 816 that is committed on-chain within theheader or ancillary metadata of the corresponding block, thereby anchoring all leaf entries (including the lock event associated with the Receipt ID being transferred) to a single, verifiable root value. For each locked Receipt ID, a Merkle proof 817 is generated, comprising a sequence of sibling hashes and positional information sufficient to reconstruct the Merkle root 816 from the leaf corresponding to the lock event.

[0247] In an embodiment, the lock operation 813 leverages the same receipt-based asset model previously illustrated, such that each Receipt ID being transferred transitions from an unspent or active state to a locked state that prevents further spending on the source chain. This ensures that the cross-chain transfer respects the single-consumption semantics associated with the receipt model and maintains consistency with the state-transition behaviour outlined in Figure 4.

[0248] In an embodiment, the Merkle proof 817 and a compact description of the lock event (for example, the original receipt id, original chain id, original block height and original tx hash) are transmitted via a bridge service or cross-chain relay 830. The bridge 830 may be implemented as an off-chain service, a set of sentinel nodes with cross-chain visibility, a dedicated oracle contract, or a combination thereof. The bridge 830 is configured to observe the source chain 810, extract Merkle roots 816 and associated proofs 817, and forward verifiable proof packages 831 to the destination chain 820.

[0249] The Merkle proof 817 used in the cross-chain process constitutes an example of a verifiable cryptographic structure capable of proving inclusion of a receipt-related event without exposing the underlying transaction payload. The wrapped Receipt ID 828 generated on the destination chain may be derived using a deterministic algorithmic mapping that incorporates the original receipt identifier, thereby providing a verifiable association between the source-chain asset and its representation on the destination chain, and preventing unauthorised or duplicative minting.

[0250] On the destination chain 820, a corresponding bridge contract or cross-chain minting module 825 is deployed. The bridge contract 825 receives the proof package 831 and invokes a proof-verification component 826. The proof-verification component 826 reconstructs the Merkle root 816 from the supplied leaf data and Merkle proof 817 and confirms that the reconstructed root matches a Merkle root value previously registered or trusted for the sourcechain 810. In some embodiments, the trusted Merkle roots for the source chain 810 are themselves recorded or signed by a set of validators or sentinel nodes on the destination chain 820, for example using the consensus arrangements outlined in Figure 7.

[0251] When the Merkle proof 817 and associated metadata are successfully verified by the proof-verification component 826, the bridge contract 825 executes a minting operation 827 on the destination chain 820. In this operation, a wrapped Receipt ID 828 is created, representing the bridged asset on the destination chain 820. The wrapped Receipt ID 828 may be generated using a deterministic function that incorporates one or more of: the original receipt id on the source chain 810, the original chain id, the original block height, the original tx hash, and a destination chain id parameter. This ensures a cryptographic linkage between the wrapped Receipt ID 828 and the original Receipt ID on the source chain, while preventing untracked duplication.

[0252] The wrapped Receipt ID 828 is recorded in the ledger of the destination chain 820 as an unspent, spendable asset under the destination address provided in the transfer request 801. A mapping table or registry 829 may be maintained by the bridge contract 825 to associate each wrapped Receipt ID 828 with its originating Receipt ID and source chain metadata. This mapping prevents multiple wrapped receipts from being minted for the same locked source receipt and enables later reverse transfers (for example, burn-and-release) if the asset is to be moved back to the original chain.

[0253] In an embodiment, one or more sentinel nodes 840 participate in the cross-chain verification process. The sentinel nodes 840 may independently monitor both the source chain 810 and the destination chain 820, validate that the Receipt IDs being bridged are in the correct locked state on the source chain, and verify that no inconsistent or duplicate wrapped Receipt IDs are minted on the destination chain. The sentinel nodes 840 may also attest to the validity of Merkle roots 816 and may provide additional external or off-chain checks, such as rate limits, policy enforcement, or fraud-detection analytics, before allowing the bridge contract 825 to complete the minting operation 827. As with the validation workflows described in Figures 6 and 7, the destination-chain verification engine may incorporate sentinel nodes or analogous monitoring agents to ensure that only those proof packages that satisfy the required structural, cryptographic, and policy -based constraints are admitted for wrapped-assetissuance. This ensures that the cross-chain transfer process remains aligned with the rule-based and consensus-supported verification model.

[0254] The cross-chain arrangement 800 therefore integrates with the receipt-based transaction model of Figures 2-5, the state machine of Figure 4, and the consensus topology of Figure 7 to provide a mechanism for securely transferring assets between blockchains. By locking Receipt IDs on the source chain 810, proving inclusion of the lock transaction using Merkle proofs 817, and minting wrapped Receipt IDs 828 on the destination chain 820 only upon successful proof verification, the system ensures that asset movements are atomic from a logical perspective and auditable across chains. The minting of a wrapped Receipt ID 828 is performed only after confirming, via the proof-verification component 826, that the corresponding source-chain Receipt ID has been consumed in a lock transaction. This maintains the input-output balancing principle set forth earlier, ensuring that no additional asset units arise on the destination chain without a corresponding deduction on the source chain.

[0255] Figure 9 illustrates an example structure 900 of a Receipt ID certificate used within the system 100 to represent a unit of digital value and its associated audit trail. The certificate 900 provides a canonical data structure that can be persisted on-chain, cached off-chain, and exchanged via the verification APIs described in relation to Figures 1-8. In some implementations, each Receipt ID generated by the transaction processor 112 and hash calculator 114 (Figure 1) is materialised as an instance of the certificate 900, enabling deterministic reconstruction of transaction context, provenance, and state at any later point in time.

[0256] In the illustrated embodiment, the certificate 900 comprises a header portion 902 and a body portion 904. The header 902 includes a receipt identifier field 910, which stores the Receipt ID computed from transaction parameters as described in Figure 3, together with an optional sequence indicator or index 912 that reflects the global or per-asset issuance order. The header 902 may further include a certificate version field 914, enabling evolution of the certificate schema while preserving backwards compatibility in validation logic at nodes 140, consensus groups 610, and cross-chain components 802.

[0257] In an alternate embodiment, the receipt identifier 910 corresponds to the unique value generated by the receipt-generation logic of the system 100, enabling deterministic retrieval, verification, and lifecycle tracking of the transaction instance to which the certificate 900 relates.

[0258] The body 904 of the certificate 900 includes a transaction metadata section 920, which encapsulates information sufficient to describe the economic transfer represented by the Receipt ID. In an example implementation, the transaction metadata 920 includes a payer or sender address 922, a payee or recipient address 924, and an amount field 926 indicating the quantity of the relevant asset. An asset-type identifier 928 may be provided to distinguish between different token types, fiat representations, or other digitised assets maintained by the system 100. The transaction metadata 920 may further include a transaction timestamp 930 corresponding to the time at which the transaction was accepted into the ledger 150 (Figure 2) and optionally a user-facing reference 932 or merchant reference to facilitate reconciliation with external accounting systems. These transaction metadata fields may constitute the input parameters consumed by the transact! on -processing component of the system 100 and may also serve as the basis for downstream verification operations executed by verifiers, validator nodes, or sentinel nodes as introduced in relation to Figures 5-7.

[0259] In addition to transactional information, the certificate 900 includes a provenance section 940 that records how the Receipt ID was derived from prior system activity. The provenance section 940 may contain one or more input receipt references 942, each referencing the Receipt IDs used as inputs in the transaction that produced the present certificate. A creation-mode indicator 944 may distinguish between original issuance (for example, minting or asset onboarding), intra-chain transfer, cross-chain wrapped issuance (as in Figure 8), or reminting in a sidechain or layer-two environment. In some implementations, the provenance section 940 also includes an originator identifier 946 and an issuer or authority identifier 948, depending on whether the Receipt ID arose from end-user activity, an issuing institution, or an automated contract process.

[0260] The provenance section 940 provides structured information used by the statetransition logic to determine whether the Receipt ID can be consumed, transformed, or propagated, including determining eligibility for spending, locking, or cross-chain movement via the bridging mechanisms illustrated in Figure 8.

[0261] A chain context section 950 provides information that ties the certificate 900 to a particular blockchain instance and position within that chain. This section may include a chain identifier 952, a block height or block number 954, and a block hash 956 representing the hash of the block in which the corresponding transaction was first committed, as recorded in the distributed ledger 150 (Figure 2). In some embodiments, the chain context 950 also holds a previous block hash 958 and a transaction hash 960, enabling a verifier to reconstruct a complete linkage from the Receipt ID back to the underlying block header and transaction payload. These contextual fields allow light-client verifiers and external systems to confirm that the Receipt ID corresponds to a transaction that is immutably anchored in a particular chain and block. The inclusion of chain identifier 952, block height 954, and block hash 956 enables the certificate 900 to interact with the chain-anchoring and immutability-assurance mechanisms of the system 100, thereby allowing verifiers to confirm that the receipt corresponds to a transaction committed within a ledger maintained by a consensus group, such as those illustrated in Figure 7.

[0262] To support content integrity and off-chain storage scenarios, the certificate 900 further comprises a content and proof section 960 (illustrated as a separate logical block for clarity). This section can include a content hash 962 representing the cryptographic digest of the structured certificate payload, and optionally a content identifier 964 (for example, a CID or similar locator) referencing an off-chain record maintained in a content-addressable store. Where the system 100 employs Merkle-based aggregation as described in Figures 2 and 8, the certificate 900 may also include a Merkle root reference 966 and an inclusion proof 968 (such as a Merkle branch), enabling an external verifier to prove that the receipt-related transaction or lock event was included in a batch anchored on-chain under the corresponding merkle root value. These proof elements may be consumed directly by verification modules to perform deterministic validation without requiring full-node state, enabling light-client validation, sidechain reconciliation, and compact cross-chain verification in accordance with the proofbased validation pathways described in previous figures.

[0263] A state classification section 970 carries information about the current lifecycle state of the Receipt ID, as determined by the state machine 400 of Figure 4 and updated via the validation workflows of Figures 5 and 6. The state classification may include a primary state code 972 indicating whether the receipt is unspent, in-progress, spent, locked for cross-chain transfer, wrapped on a destination chain, or archived. In some implementations, sub-statefields 974 may store additional attributes such as a freeze reason, dispute flag, compliance hold indicator, or expiry status. A last-updated timestamp 976 and an associated update source identifier 978 (for example, a node identifier or sentinel group identifier) may also be recorded to provide a time-stamped audit trail of state transitions. The state code 972 and sub-state fields 974 may directly feed into the state-transition framework executed by the system 100 to determine whether a Receipt ID is in a valid consumable state, locked state, wrapped state, or any transitional state required for transaction execution, double-spend protection, or crosschain movement.

[0264] The certificate 900 may further include a signature and attestation section 980, which is used to provide cryptographic assurances regarding authenticity and policy compliance. In an embodiment, this section includes a holder signature 982 generated by the owner of the receipt using a private key corresponding to the sender or receiver address, and an issuer or platform signature 984 applied by an issuing authority, validator node, or consensus group 610. Where sentinel nodes 602 (Figure 6) or specialised policy engines perform anomaly detection or external data checks, an attestation field 986 may encode a machine-readable indication of that analysis, for example a risk score, a policy compliance code, or a signed statement that certain external conditions were met at the time of validation. These attestation elements can operate in conjunction with the deterministic validation logic to provide cryptographically verifiable assurances that the operations which produced or modified the certificate 900 were executed by authorised system components, such as validator groups or sentinel nodes assigned to anomaly-detection tasks.

[0265] To support interoperability and forward compatibility, the certificate 900 can include an extensions section 990, allowing additional metadata fields 992 to be attached without changing the core certificate schema. These fields may include, for example, regulatory- compliance identifiers (jurisdiction codes, KYC hashes), application-specific tags, arbitrary key-value annotations, or references to off-chain agreements. In some embodiments, the extensions section 990 is namespaced so that independent applications built on top of the receipt infrastructure can safely define and process their own extension fields without conflict. The extension mechanism allows the certificate 900 to interface with application-level or regulatory -level compliance features that rely on the underlying receipt model for auditability and traceability within the system 100.

[0266] In use, the certificate 900 may be serialised into a structured data representation, such as a JSON, CBOR, or protocol buffer document, and exposed via the receipt APIs of the verifier service 170, including endpoints such as / receipts / {receipt_id} and / receipts / {receipt_id} / verify. When a verifier retrieves a certificate 900, the verifier may apply the rule-based checks outlined in Figure 5, the state-machine logic of Figure 4, and the consensus-attestation semantics introduced in Figures 6 and 7, using the chain context 950 and content and proof section 960 to confirm that the certificate is cryptographically anchored and not subject to double-spend or replay across chains. During cross-chain workflows, as shown in Figure 8, the origin chain’s certificate instance and the destination chain’s wrapped certificate instance may share common provenance and content-hash values, allowing a deterministic linkage between representations.

[0267] Figure 10 illustrates an example deterministic ordering protocol 1000 for resolving conflicts between transactions validated by multiple consensus groups within the transactionprocessing environment of the system 100. In particular, the protocol 1000 operates on candidate sets of validated transactions produced by the parallel consensus groups shown in Figure 7, and produces a single canonical ordering suitable for block construction in the ledger 160 and for assigning definitive Receipt ID states as described in Figures 3-5 and the certificate structure of Figure 9.

[0268] In the illustrated embodiment, multiple consensus groups 710A-710N, instantiated as described in Figure 7, independently validate respective subsets of pending transactions and output group-specific candidate transaction lists 1002A-1002N. Each candidate list may include, for each transaction, the associated Receipt IDs (for example, input receipt identifiers and newly generated output receipt identifiers as described in Figure 3), local validation metadata such as group-specific timestamps and signatures, and a local sequence position or index assigned by the relevant consensus group. These candidate lists are delivered to a global ordering component 1010, which is responsible for reconciling overlaps, resolving conflicts, and producing a deterministic global transaction order 1018 for a given block or epoch.

[0269] The parallel output of candidate transaction lists from each consensus group reflects the distributed validation environment implemented by the system 100, in which each group processes a subset of pending transactions in accordance with group assignment logic previously described. This supports the broader system capability of validating transactions inparallel using multiple validator groups and sentinel oversight nodes, and ensures that the resulting transaction ordering protocol is compatible with the Receipt ID generation, lifecycle tracking, and rule-based verification processes introduced with reference to Figures 3-7.

[0270] The ordering component 1010 in the example of Figure 10 comprises a conflictdetection sub-module 1012, an ordering-rule engine 1014, and a commit-log generator 1016. The conflict-detection sub-module 1012 examines the candidate lists 1002A-1002N to identify one or more conflict sets, for example where two or more candidate transactions propose to consume the same input Receipt ID, or where the same logical transaction appears with differing local ordering or timestamps across consensus groups. To support this detection, the conflict-detection sub-module 1012 may access Receipt ID state information maintained by the sentinel node infrastructure described with reference to Figures 5-7, including centralised spent, unspent, and in-progress classifications.

[0271] Once conflict sets have been identified, the ordering-rule engine 1014 applies a deterministic ranking function to each conflicting transaction. In one embodiment, the ranking function is constructed using a lexicographically ordered tuple comprising: (i) a normalised transaction timestamp 1020, (ii) a cryptographic hash 1022 of the transaction or its Receipt ID (for example a SHA-256 digest as introduced in Figures 2 and 3), and (iii) a deterministic group identifier 1024 and local index 1026 representing, respectively, the originating consensus group and its local ordering within that group. Any node executing the same protocol 1000 over the same input candidate lists 1002A-1002N arrives at the same ranking order, thereby ensuring that the resolved transaction sequence is deterministic and globally reproducible without reliance on a single leader node.

[0272] In this regard, the deterministic ranking function operates cooperatively with the Receipt ID state-management logic and input-output balancing rules described earlier, ensuring that transactions associated with identical or overlapping input Receipt IDs are consistently prioritised, thereby preserving the single-spend property inherent to each unique Receipt ID. The cryptographic hash and metadata fields utilised by the ordering engine correspond to the structured transaction and Receipt ID certificate elements described in Figures 2, 3 and 9.

[0273] In the example shown, the ordering-rule engine 1014 first orders transactions by a canonical timestamp derived from transaction metadata (for example, a transaction creation time included in the transaction header, or a consensus-round timestamp provided by the group 710A-710N), optionally after normalisation to a common time reference. Where two or more transactions share the same canonical timestamp within a defined time resolution, the engine 1014 applies a secondary ordering based on the transaction hash 1022 or Receipt ID hash, treating the hash value as an unsigned integer or bit string and ordering transactions lexicographically. If a tie persists (for example, in extremely unlikely hash-collision scenarios or artificial test cases), a tertiary ordering may be applied using a deterministic ranking over the consensus group identifier 1024 and local index 1026.

[0274] The commit-log generator 1016 constructs a canonical transaction sequence 1018 from the ordered, conflict-resolved transaction set. For each conflict set, the highest-ranked transaction according to the ordering-rule engine 1014 is selected for inclusion in the sequence 1018, and any lower-ranked conflicting transactions are marked as rejected and may be recorded in a separate reject log 1030. In embodiments where a shared Receipt ID is consumed by multiple candidate transactions, the commit-log generator 1016 marks the input Receipt ID as spent in association with the selected transaction and ensures that subsequent conflicting candidates are recorded as invalid, so that the input-output balancing and double-spend protection mechanisms described in Figures 3-5 remain preserved at the global ledger level. This selection mechanism therefore supports the rule-based validation features implemented throughout the system, including the verification rules for checking the validity of input Receipt IDs, output Receipt IDs, and reconciliation of generated state transitions. The commitlog generator thereby ensures that, once the deterministic ordering is applied, the corresponding Receipt ID lifecycle transitions follow a consistent and reproducible pattern across all nodes participating in the ledger 160.

[0275] The canonical transaction sequence 1018 output by the commit-log generator 1016 is then provided to a block-construction component 1040 of the consensus engine 140. This component assembles a block payload, including transaction content, derived Receipt IDs, any associated zero-knowledge proof or Merkle proof information as described in Figures 2, 3 and 8, and an updated Merkle root representing the committed receipts for the block. The resulting block is then proposed to the underlying ledger 160 and, once accepted, becomes the authoritative source for both the transaction order and the Receipt ID lifecycle transitions. Insome implementations, the global ordering protocol 1000 may also determine the sequential numbering or index for a series of Receipt IDs, by assigning sequence numbers in the order that the transactions appear in the canonical sequence 1018.

[0276] In certain embodiments, the ordering-rule engine 1014 may additionally incorporate deterministic policies that prioritise specific transaction classes or sources. For example, the ranking tuple may be extended with one or more policy fields 1028 that encode transaction type, fee tier, or service-level class, such that, all else being equal, higher-priority transaction types are ordered ahead of lower-priority classes in a manner that is still deterministic across all nodes. The policy fields 1028 may be computed from data contained in the Receipt ID certificate structure of Figure 9 or inferred from the transaction metadata maintained by the system 100, thereby enabling service differentiation while retaining strict determinism. Policy fields incorporated into the ranking tuple may correspond to transaction-classification metadata or service-tier indicators embedded within or derived from the Receipt ID certificate structure. The use of such policy fields remains consistent with the system architecture, allowing enhanced prioritisation logic without deviating from deterministic ordering principles.

[0277] In an embodiment, when a cross-chain transfer is involved (as introduced with reference to Figure 8), the ordering protocol 1000 may incorporate the block height and Merkle-proof anchoring information associated with the cross-chain receipt into its ordering tuple. For example, transactions importing wrapped Receipt IDs from a sidechain or external ledger may include origin-chain block height and merkle root identifiers as additional ranking dimensions, ensuring that the ordering remains consistent with the finality assumptions and anchoring sequence of the source chain. This provides a deterministic mechanism for merging external and internal transaction flows into a single canonical ordering. Integration of crosschain receipt information into the ranking tuple also supports the interoperability mechanism introduced in Figure 8, ensuring that wrapped receipts, origin-chain identifiers, and Merkle proofs are consistently merged into a unified transaction-ordering framework. This allows the system to maintain the uniqueness, traceability and provability of Receipt IDs across multiple interoperating chain

[0278] The deterministic ordering protocol 1000 thereby forms a logical continuation of the multi-group validation architecture introduced in Figure 7 and the Receipt ID lifecyclehandling of Figures 3-6. By ensuring that any set of parallelly validated transactions can be collapsed into a single, reproducible transaction sequence that respects Receipt ID uniqueness, input-output balancing, and state-machine semantics, the protocol 1000 underpins scalable, high-throughput transaction processing without compromising the auditability and immutability properties of the distributed ledger maintained by the system 100.

[0279] In an embodiment, the deterministic ordering protocol resolves transaction order using ledger-derived positional attributes rather than a globally incremented sequence value. In this arrangement, transactions are ordered according to a deterministic tuple comprising the block height at which the transaction is committed and the transaction index assigned within that block. Because block height increases monotonically across the ledger and transaction indices are deterministically assigned within each block, this tuple establishes a total ordering across all transactions without reliance on a shared counter or central numbering mechanism. Any node executing the ordering protocol over the same validated transaction sets arrives at the same canonical ordering.

[0280] This ordering mechanism integrates with the Receipt Identifier lifecycle and statemanagement logic described earlier, ensuring that conflicting transactions referencing the same input Receipt IDs are resolved consistently, while preserving auditability, preventing double-spend conditions, and enabling scalable parallel validation across multiple consensus groups.

[0281] Figures I la and 1 lb depict a general-purpose computer system 1100, upon which the various arrangements described for the cardiovascular risk prediction system can be practiced.

[0282] As seen in Figure I la, the computer system 1100 includes: a computer module 1101; input devices such as a keyboard 1102, a mouse pointer device 1003, a scanner 1126, a camera 1127, and a microphone 1180; and output devices including a printer 1115, a display device 1114, and loudspeakers 1117. An external Modulator-Demodulator (Modem) transceiver device 1116 may be used by the computer module 1101 for communicating to and from a communications network 1120 via a connection 1121. The communications network 1120 may be a wide-area network (WAN), such as the Internet, a cellular telecommunications network, or a private WAN. Where the connection 1121 is a telephone line, the modem 1116 may be a traditional “dial-up” modem. Alternatively, where the connection 1121 is a high-capacity (e.g.,cable) connection, the modem 1116 may be a broadband modem. A wireless modem may also be used for wireless connection to the communications network 1120.

[0283] The computer module 1101 corresponds to components in the system architecture 100. The module 1101 typically includes at least one processor unit 1105, and a memory unit 1106. For example, the memory unit 1106 may have semiconductor random access memory (RAM) and semiconductor read-only memory (ROM). The computer module 1101 also includes several input / output (I / O) interfaces, including: an audio-video interface 1107 that couples to the video display 1114, loudspeakers 1117, and microphone 1080; an I / O interface 1113 that couples to the keyboard 1102, mouse 1103, scanner 1126, camera 1127, and optionally a joystick or other human interface device (not illustrated); and an interface 1108 for the external modem 1116 and printer 1115. In some implementations, the modem 1116 may be incorporated within the computer module 1101, for example within the interface 1108.

[0284] The computer module 1101 also has a local network interface 1111, which permits coupling of the computer system 1100 via a connection 1123 to a local-area communications network 1122, known as a Local Area Network (LAN). As illustrated in Figure I la, the local communications network 1122 may also couple to the wide network 1120 via a connection 1124, which would typically include a so-called “firewall” device or device of similar functionality. The local network interface 1111 may comprise an Ethernet circuit card, a Bluetooth® wireless arrangement, or an IEEE 802.11 wireless arrangement; however, numerous other types of interfaces may be practiced for the interface 1111.

[0285] The I / O interfaces 1108 and 1113 may afford either or both of serial and parallel connectivity, the former typically being implemented according to the Universal Serial Bus (USB) standards and having corresponding USB connectors (not illustrated). Storage devices 1109 are provided and typically include a hard disk drive (HDD) 1110. Other storage devices such as a floppy disk drive and a magnetic tape drive (not illustrated) may also be used. An optical disk drive 1112 is typically provided to act as a non-volatile source of data. Portable memory devices, such as optical disks (e.g., CD-ROM, DVD, Blu-ray DiscTM), USB-RAM, portable external hard drives, and floppy disks, for example, may be used as appropriate sources of data to the system 1100.

[0286] The components 1105 to 1113 of the computer module 1101 typically communicate via an interconnected bus 1104 and in a manner that results in a conventional mode of operation of the computer system 1100 known to those in the relevant art. For example, the processor 1005 is coupled to the system bus 1004 using a connection 1118. Likewise, the memory 1006 and optical disk drive 1112 are coupled to the system bus 1104 by connections 1119. Examples of computers on which the described arrangements can be practiced include IBM-PCs and compatibles, Sun Sparcstations, Apple MacTM, or like computer systems.

[0287] The method described herein may be implemented using the computer system 1100 wherein the processes of Figures 1 to 10, described above, may be implemented as one or more software application programs 1133 executable within the computer system 1100. In particular, the steps of the method of Figures 1 to 10 are effected by instructions 1131 (see Figure 1 lb) in the software 1133 that are carried out within the computer system 1100. The software instructions 1131 may be formed as one or more code modules, each for performing one or more particular tasks. The software may also be divided into two separate parts, in which a first part and the corresponding code modules perform the described methods and a second part and the corresponding code modules manage a user interface between the first part and the user.

[0288] The software may be stored in a computer-readable medium, including the storage devices described below, for example. The software is loaded into the computer system 1100 from the computer-readable medium and then executed by the computer system 1100. A computer-readable medium having such software or computer program recorded on the computer-readable medium is a computer program product. The use of the computer program product in the computer system 1100 preferably effects an advantageous apparatus for implementing the cardiovascular risk prediction system.

[0289] The software 1133 is typically stored in the HDD 1110 or the memory 1106. The software is loaded into the computer system 1000 from a computer-readable medium and executed by the computer system 1100. Thus, for example, the software 1133 may be stored on an optically readable disk storage medium (e.g., CD-ROM) 1025 that is read by the optical disk drive 1112. A computer-readable medium having such software or computer program recorded on it is a computer program product. The use of the computer program product in thecomputer system 1100 preferably effects an apparatus for performing the cardiovascular risk analysis processes.

[0290] In some instances, the application programs 1133 may be supplied to the user encoded on one or more CD-ROMs 1125 and read via the corresponding drive 1112, or alternatively may be read by the user from the networks 1120 or 1122. Still further, the software can also be loaded into the computer system 1100 from other computer-readable media. Computer- readable storage media refer to any non-transitory tangible storage medium that provides recorded instructions and / or data to the computer system 1100 for execution and / or processing. Examples of such storage media include floppy disks, magnetic tape, CD-ROM, DVD, Blu- ray TM Disc, a hard disk drive, a ROM or integrated circuit, USB memory, a magneto-optical disk, or a computer-readable card such as a PCMCIA card and the like, whether or not such devices are internal or external to the computer module 1101. Examples of transitory or nontangible computer readable transmission media that may also participate in the provision of software, application programs, instructions and / or data to the computer module 1101 include radio or infra-red transmission channels as well as a network connection to another computer or networked device, and the Internet or Intranets including e-mail transmissions and information recorded on Websites and the like.

[0291] The second part of the application programs 1133 and the corresponding code modules mentioned above may be executed to implement one or more graphical user interfaces (GUIs) to be rendered or otherwise represented upon the display 1114. Through manipulation of typically the keyboard 1102 and the mouse 1103, a user of the computer system 1100 and the application may manipulate the interface in a functionally adaptable manner to provide controlling commands and / or input to the applications associated with the GUI(s). Other forms of functionally adaptable user interfaces may also be implemented, such as an audio interface utilizing speech prompts output via the loudspeakers 1117 and user voice commands input via the microphone 1080.

[0292] Figure 1 lb is a detailed schematic block diagram of the processor 1105 and a "memory" 1134. The memory 1134 represents a logical aggregation of all the memory modules (including the HDD 1110 and semiconductor memory 1106) that can be accessed by the computer module 1101 in Figure I la.

[0293] When the computer module 1101 is initially powered up, a power-on self-test (POST) program 1150 executes. The POST program 1150 is typically stored in a ROM 1149 of the semiconductor memory 1106 of Figure 1 la. A hardware device such as the ROM 1149 storing software is sometimes referred to as firmware. The POST program 1150 examines hardware within the computer module 1101 to ensure proper functioning and typically checks the processor 1105, the memory 1134 (1109, 1106), and a basic input-output systems software (BIOS) module 1151, also typically stored in the ROM 1149, for correct operation. Once the POST program 1150 has run successfully, the BIOS 1011 activates the hard disk drive 1110 of Figure I la. Activation of the hard disk drive 1110 causes a bootstrap loader program 1152 that is resident on the hard disk drive 1010 to execute via the processor 1105. This loads an operating system 1013 into the RAM memory 1106, upon which the operating system 1053 commences operation. The operating system 1153 is a system-level application, executable by the processor 1105, to fulfill various high-level functions, including processor management, memory management, device management, storage management, software application interface, and generic user interface.

[0294] The operating system 1153 manages the memory 1134 (1109, 1106) to ensure that each process or application running on the computer module 1101 has sufficient memory in which to execute without colliding with memory allocated to another process. Furthermore, the different types of memory available in the system 1100 of Figure 1 la must be used properly so that each process can run effectively. Accordingly, the aggregated memory 1134 is not intended to illustrate how particular segments of memory are allocated (unless otherwise stated), but rather to provide a general view of the memory accessible by the computer system 1100 and how such is used.

[0295] As shown in Figure 1 lb, the processor 1105 includes a number of functional modules including a control unit 1139, an arithmetic logic unit (ALU) 1140, and a local or internal memory 1148, sometimes called a cache memory. The cache memory 1148 typically includes a number of storage registers 1144-1146 in a register section. One or more internal buses 1141 functionally interconnect these functional modules. The processor 1105 typically also has one or more interfaces 1142 for communicating with external devices via the system bus 1104, using a connection 1118. The memory 1134 is coupled to the bus 1104 using a connection 1119.

[0296] The application program 1133 includes a sequence of instructions 1131 that may include conditional branch and loop instructions. The program 1133 may also include data 1132 which is used in the execution of the program 1133. The instructions 1131 and the data 1132 are stored in memory locations 1128, 1129, 1130, and 1135, 1136, 1137, respectively. Depending upon the relative size of the instructions 1131 and the memory locations 1128— 1130, a particular instruction may be stored in a single memory location as depicted by the instruction shown in the memory location 1130. Alternately, an instruction may be segmented into a number of parts each of which is stored in a separate memory location, as depicted by the instruction segments shown in the memory locations 1128 and 1129.

[0297] In general, the processor 1105 is given a set of instructions which are executed therein. The processor 1105 waits for a subsequent input, to which the processor 1105 reacts to by executing another set of instructions. Each input may be provided from one or more of a number of sources, including data generated by one or more of the input devices 1102, 1103, data received from an external source across one of the networks 1120, 1122, data retrieved from one of the storage devices 1106, 1110, or data retrieved from a storage medium 1125 inserted into the corresponding reader 1112, all depicted in Figure I la. The execution of a set of the instructions may in some cases result in the output of data. Execution may also involve storing data or variables to the memory 1134.

[0298] The disclosed arrangements use input variables 1154, which are stored in the memory 1134 in corresponding memory locations 1155, 1156, 1157. The disclosed arrangements produce output variables 1061, which are stored in the memory 1134 in corresponding memory locations 1162, 1163, 1164. Intermediate variables 1158 may be stored in memory locations. Referring to the processor 1105 of Figure 1 lb, the registers 1144, 1145, 1146, the arithmetic logic unit (ALU) 1140, and the control unit 1139 work together to perform sequences of micro-operations needed to perform "fetch, decode, and execute" cycles for every instruction in the instruction set making up the program 1133. Each fetch, decode, and execute cycle comprises: a fetch operation, which fetches or reads an instruction 1131 from a memory location 1128, 1129, 1130; a decode operation in which the control unit 1139 determines which instruction has been fetched; andan execute operation in which the control unit 1139 and / or the ALU 1140 execute the instruction.

[0299] Thereafter, a further fetch, decode, and execute cycle for the next instruction may be executed. Similarly, a store cycle may be performed by which the control unit 1139 stores or writes a value to a memory location 1132.

[0300] Each step or sub-process in the processes of Figures 1 to 10 is associated with one or more segments of the program 1133 and is performed by the register section 1144, 1145, 1147, the ALU 1140, and the control unit 1139 in the processor 1105 working together to perform the fetch, decode, and execute cycles for every instruction in the instruction set for the noted segments of the program 1133.

[0301] The methods described may alternatively be implemented in dedicated hardware such as one or more integrated circuits performing the functions or sub-functions of the cardiovascular risk prediction system. Such dedicated hardware may include graphic processors, digital signal processors, or one or more microprocessors and associated memories.

[0302] In this document, the terms “computer program medium” and “computer usable medium” are used to generally refer to transitory or non-transitory media. Such media may be, e.g., storage medium, storage devices and channel. These and other various forms of computer program media or computer usable media may be involved in carrying one or more sequences of one or more instructions to a processing device for execution. Such instructions embodied on the medium, are generally referred to as “computer program code” or a “computer program product” (which may be grouped in the form of computer programs or other groupings). When executed, such instructions might enable the computing component (e.g. processor 104) to perform features or functions of the present application as discussed herein.

[0303] The terms “a” and “an,” as used herein, are defined as one or more than one. The term “plurality,” as used herein, is defined as two or more than two. The term “another,” as used herein, is defined as at least a second or more. The terms “including” and / or “having,” as used herein, are defined as comprising (i.e. open language). The phrase “at least one of . . . and . . . .” as used herein refers to and encompasses any and all possible combinations of one or moreof the associated listed items. As an example, the phrase “at least one of A, B, or C” includes A only, B only, C only, or any combination thereof (e.g. AB, AC, BC or ABC).

[0304] Although embodiments have been described with reference to a number of illustrative embodiments thereof, it will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the spirit and scope of the invention. Many modifications will be apparent to those skilled in the art without departing from the scope of the present invention as herein described with reference to the accompanying drawings.

Claims

CLAIMS1. A computer-implemented system for recording and transferring digital assets, the system comprising at least one processor configured by executable instructions to:(a) generate, for each transfer transaction, one or more output receipt identifiers (Receipt IDs), each Receipt ID being uniquely derived from transaction data and one or more blockchain state parameters;(b) maintain a receipt state structure comprising an unspent list, a spent list, and an inprogress list, each list storing Receipt IDs and associated metadata;(c) upon receipt of a proposed transfer transaction, identify one or more input Receipt IDs and temporarily classify the input Receipt IDs as in-progress within the receipt state structure;(d) determine, for the proposed transfer transaction, whether:(i) each input Receipt ID is valid and unspent;(ii) a digital signature associated with the proposed transfer transaction is valid; and(iii) a total quantity represented by the input Receipt IDs equals a total quantity represented by the output Receipt IDs;(e) upon the proposed transfer transaction satisfying predetermined validation criteria, atomically:(i) classify each input Receipt ID as spent;(ii) record each output Receipt ID as unspent; and(iii) update a blockchain ledger to include a transaction record referencing the output Receipt IDs.

2. The system of claim 1, wherein each Receipt ID comprises metadata including one or more of:(a) a timestamp of creation,(b) a chain identifier,(c) a block height, or(d) a hash of a corresponding transaction.

3. The system of claim 1 or claim 2, wherein each Receipt ID is generated using a deterministically incremented sequence value maintained in persistent smart-contract state.

4. The system of any of the preceding claims 1-3, wherein the generation of each Receipt ID comprises hashing transaction data together with a nonce selected by a submitting wallet.

5. The system of any of the preceding claims 1-4, wherein classifying a Receipt ID as inprogress prevents the Receipt ID from being reused in another proposed transfer transaction until validation completes.

6. The system of any one of preceding claims 1-5, wherein failure of a proposed transfer transaction causes the in-progress classification of each input Receipt ID to be reverted to an unspent classification.

7. The system of any one of preceding claims 1-6, wherein the receipt state structure is stored at least in part in an off-chain database and cross- validated against on-chain transaction records.

8. The system of any one of preceding claims 1-7, wherein determining whether input and output amounts are equal comprises summing values recorded in metadata associated with multiple input Receipt IDs.

9. The system of any one of preceding claims 1-8, wherein validation includes verifying that a hash associated with each input Receipt ID matches a hash stored in a corresponding blockchain record.

10. The system of claim 1, wherein updating the blockchain ledger comprises writing a transaction referencing each output Receipt ID to a block together with a timestamp and a block hash.

11. The system of claim 1, wherein output Receipt IDs include a field identifying an originating Receipt ID from which the output Receipt ID was derived.

12. A consensus system for validating digital asset transfer transactions recorded in a blockchain, the system comprising a plurality of validator nodes executing a consensus protocol, and at least one sentinel node, wherein the sentinel node is configured to:(a) access or maintain a receipt state structure comprising an unspent list, a spent list, and an in-progress list storing receipt identifiers (Receipt IDs) and associated metadata;(b) verify, for each proposed transfer transaction supplied to the consensus protocol:(i) whether each input Receipt ID is present in the unspent list and absent from the spent list;(ii) whether a digital signature associated with the proposed transaction is valid;(iii) whether the transaction satisfies predefined input-output balancing criteria; and(iv) whether the transaction metadata is consistent with one or more of: on- chain records, off-chain receipt state entries, external data sources, or an anomaly-detection result generated by a machine-learning model;(c) generate a consensus attestation indicative of validity or invalidity of the proposed transfer transaction; and(d) supply the consensus attestation to the validator nodes, wherein the consensus protocol is configured such that the validator nodes accept a block comprising the proposed transfer transaction only upon receiving a positive consensus attestation from the sentinel node.

13. A consensus system for validating digital asset transfer transactions, comprising a plurality of validator nodes and at least one sentinel node, wherein the validator nodes execute a consensus protocol for proposing, validating, and finalising candidate blocks, and wherein the sentinel node is configured to:(a) obtain, for each proposed transfer transaction included in a candidate block, transaction data comprising one or more input receipt identifiers (Receipt IDs) and associated metadata;(b) determine, using a receipt state structure comprising unspent, spent, and in-progress Receipt ID lists, whether each input Receipt ID is valid and unspent;(c) evaluate the proposed transfer transaction against predetermined validation criteria comprising at least:(i) verification of a digital signature associated with the transaction;(ii) correctness of the classification of each input Receipt ID within the receipt state structure; and(iii) input-output quantity balancing;(d) generate an attestation message indicative of validity or invalidity of the proposed transfer transaction; and(e) transmit the attestation message to the validator nodes via a communication channel used by the consensus protocol, wherein the validator nodes are further configured to:(f) verify, during block-validation processing, whether the attestation message indicates that all transfer transactions in the candidate block satisfy the predetermined validation criteria; and(g) reject the candidate block responsive to the attestation message indicating that at least one transfer transaction fails the predetermined validation criteria.

14. The system of claim 13, wherein the sentinel node is further configured to obtain external data relevant to transaction validation, the external data comprising one or more of: regulatory information, risk-classification data, network telemetry, or market-event data.

15. The system of claim 13 or claim 14, wherein evaluating the proposed transfer transaction comprises applying an anomaly-detection model executed by the sentinel node.

16. The system of any of the preceding claims 13-15, wherein the sentinel node maintains a local cache of entries from the receipt state structure for real-time validation of candidate transactions.

17. The system of any of the preceding claims 13-16, wherein the sentinel node is configured to verify that each input Receipt ID is not present in the spent list and not concurrently classified as in-progress for another proposed transfer transaction.

18. The system of claim 17, wherein the receipt state structure is synchronised between the sentinel node and one or more validator nodes using periodic state-update messages.

19. The system of any of the preceding claims 13-18, wherein the sentinel node transmits a negative attestation message when detecting an inconsistency between the receipt state structure and blockchain records.

20. The system of claim 13, wherein the sentinel node is further configured to generate an audit record referencing each proposed transfer transaction and its corresponding validation outcome.

21. The system of claim 13, wherein validator nodes include the sentinel’s audit record in a block header or block metadata for on-chain publication.

22. The system of claim 13, wherein the sentinel node initiates an additional verification procedure when detecting disagreement among validator nodes regarding the validity of a candidate block.

23. A computer-implemented method for transferring a digital asset represented by a receipt identifier (Receipt ID) from a first blockchain to a second blockchain, the method comprising:(a) on the first blockchain:(i) verifying that an input Receipt ID is valid and unspent according to a receipt state structure;(ii) classifying the input Receipt ID as locked or transfer-off-chain within the receipt state structure; and(iii) generating a proof of inclusion of the input Receipt ID in a state commitment recorded on the first blockchain;(b) transmitting, via a bridge service, transfer data comprising the input Receipt ID, the inclusion proof, and metadata indicative of an originating chain context;(c) on the second blockchain:(i) verifying the inclusion proof against a stored commitment corresponding to the first blockchain;(ii) generating a new Receipt ID uniquely derived from the transfer data and comprising metadata indicative of the originating Receipt ID and chain context; and(iii) recording the new Receipt ID as unspent in a receipt state structure of the second blockchain and writing a corresponding transaction to the second blockchain.

24. The method of claim 23, wherein classifying the input Receipt ID as locked comprises updating the unspent list to indicate the Receipt ID is unavailable for further transfers.

25. The method of claim 23 or claim 24, wherein generating the proof of inclusion comprises computing a Merkle proof associated with a state commitment recorded on the first blockchain.

26. The method of any of the preceding claims 23-25, wherein the bridge service comprises a message-queue or postbox service configured to forward transfer data between blockchain networks.

27. The method of any of the preceding claims 23-26, wherein the transfer data further comprises a signature of a sentinel node attesting to correctness of the locked Receipt ID state.

28. The method of any of the preceding claims 23-27, wherein the metadata indicative of the originating context comprises an originating chain identifier, originating block number, and originating transaction hash.

29. The method of any of the preceding claims 23-28, wherein verifying the inclusion proof comprises evaluating the proof against a stored Merkle root representing a state of the first blockchain.

30. The method of any of the preceding claims 23-29, wherein generating the new Receipt ID comprises hashing the transfer data with a newly generated nonce on the second blockchain.

31. A digital asset transfer platform comprising:(a) a receipt management subsystem configured to:(i) generate, for each transfer transaction, one or more Receipt IDs uniquely derived from transaction data and blockchain state parameters;(ii) maintain a receipt state structure comprising unspent, spent, and in-progress Receipt ID lists; and(iii) update the receipt state structure in response to validation of transfer transactions;(b) a consensus subsystem comprising a plurality of validator nodes and at least one sentinel node, the sentinel node being configured to verify correctness of receipt state transitions and to provide consensus attestations required for acceptance of blocks; and(c) a cross-chain transfer subsystem configured to:(i) lock Receipt IDs on a first blockchain;(ii) generate proofs of inclusion of the locked Receipt IDs;(iii) transmit transfer data to a second blockchain; and(iv) generate and record new Receipt IDs on the second blockchain corresponding to the locked Receipt IDs.

32. The platform of claim 31, wherein the receipt management subsystem is configured to revert in-progress Receipt IDs to unspent status upon rejection of a block by the consensus subsystem.

33. The platform of claim 31 or claim 32, wherein the consensus subsystem is configured to record sentinel-generated audit metadata in the blockchain alongside validated transactions.

34. The platform of any of the preceding claims 31-33, wherein the cross-chain transfer subsystem is configured to prevent issuance of more than one new Receipt ID corresponding to a single originating Receipt ID.

35. A computer-implemented system for managing digital asset transfer transactions, comprising: one or more processors configured to maintain a receipt state structure including at least an unspent state, an in-progress state, and a spent state, and to:(a) classify one or more input receipt identifiers (Receipt IDs) of a proposed transfer transaction as in-progress upon receipt of the proposed transfer transaction;(b) prevent reuse of any in-progress Receipt ID in another proposed transfer transaction;(c) validate the proposed transfer transaction by determining whether the in-progress Receipt IDs satisfy predetermined criteria including validity and ownership;(d) upon successful validation, atomically reclassify the in-progress Receipt IDs as spent and record one or more corresponding output Receipt IDs as unspent; and(e) revert each in-progress Receipt ID to an unspent state upon failure of the proposed transfer transaction.

36. A digital asset validation system comprising:(a) a blockchain storing records of confirmed transfer transactions;(b) an off-chain validation layer maintaining a real-time state representation of asset identifiers including at least a validity state; and(c) a validation processor configured to approve or reject proposed transfer transactions by:(iii) verifying consistency of each input asset identifier with the off-chain state representation; and(iv) verifying consistency of the input asset identifier with one or more blockchain records; wherein a proposed transfer transaction is accepted only when validation results from both the off-chain validation layer and the blockchain records indicate that each input asset identifier is valid.

37. The method of claim 36, wherein the deterministic function comprises a cryptographic hash function applied to a concatenation of the transaction data and the one or more blockchain state parameters.

38. The method of claim 37, wherein concatenation comprises combining the transaction data and the one or more blockchain state parameters in a predetermined ordering for input to the cryptographic hash function.

39. The method of any one of the preceding claims 36-38, wherein the blockchain state parameters further comprise a previous-block hash, a transaction timestamp, or a chain identifier.

40. The method of any one of the preceding claims 36-39, wherein the digital asset identifier further encodes a nonce generated by a submitting wallet.

41. The method of any one of the preceding claims 36-40, wherein the digital asset identifier encodes provenance information comprising at least one of:(a) an originating chain context,(b) an originating block height, or(c) an originating transaction hash.

42. The method of claim 41, wherein the digital asset identifier is configured to uniquely represent a lineage of issuance for the corresponding digital asset.

43. The method of claim 36, further comprising generating a proof of inclusion of the digital asset identifier within a state commitment recorded on the blockchain.

44. The method of claim 43, wherein recording the digital asset identifier comprises storing a hash of the digital asset identifier within a Merkle tree whose root is committed to the blockchain.

45. The method of claim 36, further comprising generating a subsequent digital asset identifier for a transfer transaction by applying the deterministic function to updated transaction data and one or more updated blockchain state parameters.

46. The method of claim 36, wherein the subsequent digital asset identifier includes metadata identifying the digital asset identifier generated in step (c) as an originating identifier.

47. The method of claim 36, wherein the deterministic function is configured to produce distinct digital asset identifiers for different blockchain networks by incorporating a network identifier into the blockchain state parameters.

Images