Implementing blockchain-based token attribution and yield distribution with reduced computational complexity

Abstract

Implementations of blockchain-based token attribution and yield distribution with reduced computational complexity are described. For example, a method can include maintaining a set of age data associated with token circulation within a blockchain of a blockchain system, detecting an age update event to cause an update to the set of age data items maintained on the blockchain, and causing the set of age data maintained on the blockchain to be updated. The set of age data includes an age of an attribution property for a token assigned to a token issuer of the blockchain system. The age of the attribution property is determined based on a circulation of tokens having the attribution property and an elapsed amount of time. The method further includes using the set of age data items to perform yield distribution to distribute yield to at least the token issuer.

Description

IMPLEMENTING BLOCKCHAIN-BASED TOKEN ATTRIBUTION AND YIELD DISTRIBUTION WITH REDUCED COMPUTATIONAL COMPLEXITYTECHNICAL FIELD

[0001] The disclosure is generally related to blockchains and other distributed ledgers, and more particularly, to implementing blockchain-based token attribution and yield distribution with reduced computational complexity.BACKGROUND

[0002] A network can include a decentralized network of nodes (i.e., computing devices), each of which maintains a copy of a distributed ledger, or blockchain, for tracking and managing transactions occurring within the network. More particularly, a blockchain can be a chain of cryptographically linked blocks of data (“blocks”), where each block of the blockchain maintains a record of one or more completed transactions. A transaction can reflect an update to data maintained by one or more accounts of the network. One example of a transaction is a transfer of a digital asset from one entity to another entity. Another example of a transaction is an exchange of digital assets. An exchange can involve the transfer of a digital asset from a source network having a source blockchain to a destination network having a destination blockchain. The nodes are responsible for managing (e.g., verifying) the transactions before appending them to the blockchain. At the core of the blockchain concept are the three pillars of decentralization, transparency, and immutability. No single node within a network can control a blockchain, and actions on the blockchain are verifiable and irreversible.

[0003] A block can include one or more transaction records and a cryptographic digest (“digest”) of the previous block representing the previous batch of transactions. A digest can be generated by a one-way function that produces the same output data for a given input. A one-way function is a function that, from a computational complexity perspective, is “easy” to obtain an output for a given input, but “hard” to invert the output to identify the given input. For example, the digest can be a hash value, which is an output string of data generated by employing a hashing method to an input string of data. Although the input string can be arbitrarily large, the output hash value can be set to a fixed size in accordance with the hashing method used. Digests provide a secure way to maintain integrity of the blockchain. For example, any attempted change of an earlier block will result in the modified digest ofthe block, which would require modifications to all subsequent blocks in the blockchain (i.e., tamper-proofing).

[0004] An asset generally refers to an object or property that is owned or controlled by an entity (e.g., an individual or a group of individuals), and can have a distinct usage right. For example, a physical asset refers to a tangible asset. As another example, a digital asset refers to an electronic asset (e.g., intangible asset). A digital asset can be represented by a cryptographic token (“token”). One example of a token is a fungible token, in which the token is replaceable with other tokens of the same type and / or value. For example, a fungible token can represent a unit of value of a cryptocurrency (e.g., digital coin). Fungibility means that each unit of an asset, such as a token, is essentially identical and can be exchanged on a one-to-one basis with any other unit of the asset. Their fungible nature enables fungible tokens to be easily exchanged, traded and / or used within blockchain systems. Another example of a token is a non-fungible token (NFT). In contrast to fungible tokens, an NFT represents a unique asset that is not interchangeable with another asset. An NFT can have distinct characteristics or properties that differ from other NFTs that define the uniqueness. For example, NFTs can represent things like digital art, digital collectibles, etc. Yet another example of a token is a semi-fungible token (SFT), which is a token that combines properties of both a fungible token and a non-fungible token. Each token within a set of SFTs can have unique properties or attributes, distinguishing it from other tokens in the set of SFTs.However, tokens within the same set of SFTs are still considered interchangeable and can be exchanged on a one-to-one basis. Accordingly, SFTs introduce a level of variability among tokens that are otherwise fungible in nature.BRIEF DESCRIPTION OF THE DRAWINGS

[0005] The disclosure is illustrated by way of examples, and not by way of limitation, and may be more fully understood with references to the following detailed description when considered in connection with the figures, in which:

[0006] FIGS. 1A-1F are diagrams of example computer systems for implementing blockchain-based token attribution and yield distribution with reduced computational complexity, in accordance with some implementations.

[0007] FIGS. 2A-2B are diagrams of an example computer system including an omnichain interoperability protocol platform, in accordance with some implementations.

[0008] FIG. 3 is a diagram of an example layout of an endpoint packet, in accordance with some implementations.

[0009] FIGS. 4-5D are flow diagrams of example methods for implementing omnichain interoperability protocol platforms, in accordance with some implementations.

[0010] FIGS. 6A-6G are flow diagrams of example methods for implementing blockchain-based token attribution and yield distribution with reduced computational complexity, in accordance with some implementations.

[0011] FIG. 7 is a diagram of an example graph illustrating age as a function of time, in accordance with some implementations.

[0012] FIG. 8 is a diagram of an example system implementing checkpoint root storage optimization, in accordance with some implementations.

[0013] FIG. 9 is a block diagram of an illustrative computing device operating in accordance with the examples of the disclosure.DETAILED DESCRIPTION

[0014] Described herein are systems and methods for implementing blockchain-based token attribution and yield distribution with reduced computational complexity. FIG. 1A shows a system 100 corresponding to a blockchain network, in accordance with some implementations. System 100 includes a token transaction management system to manage token transactions that occur within system 100. As will be described in further detail, examples of token transactions that can occur within system 100 include minting, redemption and token transfers.

[0015] For example, the token transaction management system can include vault 101. Vault 101 is a service (e.g., hardware and / or software component) that can support a set of functions that enables user accounts to mint and / or redeem tokens within the blockchain network, as will be described in further detail below. Vault 101 can implement a user interface that can receive inputs from a user account for executing one or more functions of the set of functions. Thus, the user interface can make token creation and / or management more accessible by reducing the amount of technical knowledge and / or programming skills needed to create and / or manage tokens. Vault 101 can be created by an administrator of system 100. In some implementations, vault 101 uses at least one smart contract to implement the set of functions. In some implementations, vault 101 is a smart contract of system 100. Generally, a smart contract is a sequence of executable instructions stored on a blockchain network that enables at least one function. The sequence of executable instructions can specify one or more conditions to be verified and one or more actions to be performed should the conditions be successfully validated. A smart contract can be stored on a blockchainnetwork. When a smart contract is deployed, it becomes part of the blockchain and is replicated and stored on all participating nodes within the blockchain network.

[0016] System 100 can include a set of user accounts. For example, each user account of the set of user accounts can have an associated digital wallet linked to system 100. For example, as shown, the set of user accounts can include at least one token issuer 102. Token issuer 102 is the user account of an entity that has minted at least one token 103 within the blockchain network. Generally, minting refers to the process of creating a token (e.g., token 103) within system 100, which brings the token into circulation within circulation space 108.

[0017] In some implementations, token 103 is a fungible token. Fungible tokens can be used to enable a variety of utility functions within a system, such as electronic transactions, electronic payments, electronic voting, etc. For example, some decentralized applications (DApps) (e.g., decentralized finance (DeFi) applications) can use fungible tokens to provide an easy-to-use, reliable and trustworthy electronic payment mechanism. In some implementations, token 103 is a stablecoin. A stablecoin refers to a token (e.g., fungible token) that is designed to maintain an approximately stable value to minimize price fluctuations and to provide a more reliable store of value and medium of exchange within a network. For example, a stablecoin can be a fiat-backed stablecoin backed by fiat currency and pegged to the value of the underlying fiat currency. As another example, a stablecoin can be a commodity-backed stablecoin backed by a commodity and pegged to the value of the underlying commodity. As yet another example, a stablecoin can be a crypto-backed stablecoin backed by another digital asset, such as another fungible token. To do so, a user can deposit an amount of the other digital asset as collateral and stablecoins can be issued against this collateral. As yet another example, a stablecoin can be an algorithmic stablecoin that uses a stablecoin supply control mechanism that modifies stablecoin supply in response to market conditions to maintain price stability. The stablecoin supply control mechanism can use a smart contract to automatically modify stablecoin supply.

[0018] As shown in FIG. 1A, in response to vault 101 receiving mint request 104-1 from token issuer 102 to mint at least one token 103, vault 101 can create and deliver at least one token 103 to token issuer 102, as indicated by arrow 150-2. For example, mint request 104-1 can trigger (e.g., call) a mint function of the set of functions of vault 101, and vault 101 can execute the mint function to satisfy mint request 104-1. A mint function can be defined by a token standard supported by the blockchain network. For example, a set of arguments of a mint function (e.g., received as part of mint request 104-1) can include an address of the token issuer who has triggered the mint function, and a number of tokens to be minted. Likeany other blockchain-based transaction, a consensus protocol can be used by the nodes of the blockchain network to verify a mint transaction before the corresponding transaction record can be added to the blockchain. In some implementations, token issuer 102 is a stablecoin issuer and token 103 is a stablecoin. As a stablecoin issuer, token issuer 102 can mint token 103 in exchange for some amount of external assets received from an external user account owned by token issuer 102 (e.g., fiat-backed stablecoins, commodity-backed stablecoins or crypto-backed stablecoins).

[0019] The set of user accounts can include one or more additional user accounts that are not token issuers. For example, as shown, system 100 can include user accounts 105-1 and 105-2. Token issuer 1022 can transfer tokens to one or more additional user accounts (e.g., to one or more digital wallet addresses of the one or more additional user accounts). For example, as shown, at least one token 106-1 has been transferred from token issuer 102 to user account 105-1, and at least one attributed token 106-2 has been transferred from token issuer 102 to user account 105-2. Additionally, tokens can be transferred between user accounts 105-1 and 105-2. Further details regarding token transfers will be described herein below with reference to FIG. IB.

[0020] To maintain value stability, system 100 can offer a promise or expectation that a token (e.g., stablecoin) owned by a user via a user account (e.g., user account 105-1 or user account 105-2) can be redeemed by the user at par value upon request. Generally, redemption refers to the process of exchanging a token within system 100 (e.g., within circulation space 108) for the underlying external asset equal to the par value. The underlying external asset can be electronically transferred to an external account owned by the user (e.g., an external bank account). As shown in FIG. 1A, in response to vault 101 receiving redemption request 107 from user account 105-1 to redeem at least one token 106-1, vault 101 can redeem at least one token 106-1. For example, redemption request 107 can trigger (e.g., call) a redemption function of the set of functions of vault 101, and vault 101 can execute the redemption function to satisfy redemption request 107. Generally, a redemption function can be defined by a token standard supported by the blockchain network. For example, a set of arguments of a redemption function can include an address of the token redeemer who has triggered the redemption function (e.g., an address of user account 105-1), and a number of tokens to be redeemed. Like any other blockchain-based transaction, a consensus protocol can be used by the nodes of a blockchain network to verify a redemption transaction before the corresponding transaction record can be added to the blockchain.

[0021] Since a blockchain of a blockchain network is an immutable digital ledger, a token cannot be deleted from existence from the blockchain network as part of the redemption process. Instead, redeeming a token can include burning a token to remove the token from circulation within the blockchain network (e.g., removed from circulation space 108). Burning a token can include transferring the token from the user account of the token redeemer (e.g., user account 105-1) to a special purpose account (e.g., digital wallet) having a special purpose address, from which the digital asset cannot be transferred by future transactions. For example, the special purpose address can be the null address for the blockchain network. Thus, although a burned token (e.g., token transferred to the special purpose address) still exists within the blockchain network, the burned token is made inaccessible to other user accounts within the blockchain network. Burning a digital asset can involve payment of transaction fees. For example, a token can be burned by executing a set of executable instructions (e.g., a set of executable instructions of a smart contract). The set of executable instructions can include an instruction that, when executed, can determine whether there are sufficient funds in the digital wallet connected to the digital asset issuer. The set of executable instructions can further include an instruction that, when executed after determining that there are sufficient funds in the user account of the token redeemer, can transfer the at least one token to be burned to the special purpose account.

[0022] The token transaction management system can further include token contract 109. In this example, token contract 109 is separate from vault 101 (e.g., vault 101 implements a different smart contract than token contract 109). In some implementations, token contract 109 is included in vault 101, or vice versa (e.g., vault 101 and token contract 109 implement the same smart contract). Token contract 109 can be created by an administrator of system 100. In some implementations, token contract 109 includes a transfer function to enable transfer of tokens between user accounts (e.g., between digital wallet addresses). An example of token contract enabling transfer of tokens between user accounts will be described in further detail below with reference to FIG. IB.

[0023] In some implementations, token contract 109 stores token balances for each user account (e.g., digital wallet) of the set of user accounts of system 100. For example, token contract 109 can maintain mappings of user account addresses (e.g., digital wallet addresses) to respective token balances within the blockchain network. Possession of tokens by user accounts (e.g., associated with digital wallets) may be tracked and / or modified by token contract 109. In some implementations, minting at least one token 103 can include token contract 109 updating the token balance of token issuer 102 by incrementing the tokenbalance of token issuer 102 by at least one token. In some implementations, redeeming at least one token 106-1 can include token contract 109 updating the token balance of user account 105-1 by decrementing the token balance of user account 105-1 by at least one token. In some implementations, transferring at least one token from a sender to a receiver includes updating the token balances of the sender and the receiver by decrementing the token balance of the sender by at least one token and incrementing the token balance of the receiver by at least one token. Accordingly, instead of having the tokens being held in the user accounts (e.g., digital wallets) directly, the tokens of all user accounts can be held within token contract 109, where the token balances are mapped to respective user accounts via respective user account addresses (e.g., digital wallet addresses). Further details regarding the token transaction management system, including vault 101 and token contract 109, will be described herein below.

[0024] In some implementations, the token transaction management system implements a token attribution method to keep track of the total number of tokens (e.g., stablecoins) that have been minted by at least one token issuer 102. For example, vault 101 can assign token issuer 102 with an attribution property as an identifier (ID) that uniquely reflects token issuer 102. For example, the attribution property can be defined as token metadata (e.g., a metadata tag). In some implementations, an attribution property is referred to as a token color (“color”). As part of the minting process, the mint function can include a token assignment function that assigns (e.g., links), to each token that is minted by token issuer 102, the attribution property identifying token issuer 102 (e.g., one-to-one mapping function). One example of a token assignment function is an incremental identifier mapping function, in which tokens minted by a first token issuer are assigned a first attribution property, tokens minted by a second token issuer are assigned a second attribution property, etc. However, any suitable token assignment function can be used in accordance with implementations described herein. Accordingly, each token minted within system 100 will have an assigned attribution property. Token balances of user accounts (e.g., digital wallets), which can be tracked by token contract 109, can be represented as a tuple of token attribution and quantity. For example, if a user account holds N tokens having attribution property A, then the token balance can be represented by the tuple A|A.

[0025] One type of token attribution method that can be implemented by the token transaction management system is a lossless token attribution method. The lossless token attribution method can be implemented by the token transaction management system (e.g.,token contract 109) maintaining a per-mint token attribution with respect to tokens owned across all user accounts.

[0026] However, various practical constraints exist that can prevent the token transaction management system from using a lossless token attribution method to track token attribution. One example of a constraint is computational resource cost. For example, a lossless token attribution method can be computationally expensive to implement as the number of different token issuers increases within system 100, due at least in part to the space complexity required for the token transaction management system to maintain a per-minter token attribution for every user account (e.g., digital wallet). Space complexity refers to the amount of memory or storage space needed to solve a computational problem. For example, in a lossless token attribution method, the token transaction management system can store, for each user account (e.g., digital wallet), a token balance that reflects a token attribution for each token issuer. The space complexity needed to track token attribution using a lossless token attribution method can be approximately linear with respect to the number of token issuers. To illustrate, assume that a digital wallet has a single designated attribution property and has a total balance of 1,000 tokens. Further assume each of the 1,000 tokens can be minted by a different token issuer, such that only 1 token of the 1,000 tokens has the single designated attribution property. To keep track of token attribution using a lossless token attribution method in this illustrative example, the token transaction management system would need to store, for each of the 1,000 different attribution properties, a token balance of 1 token (e.g., linear space complexity). As another example, it is possible for a user account (e.g., digital wallet) with tokens from too many token issuers to be unable to transact due to running into a maximum gas limit (e.g., maximum cost per unit of computation that a user account can spend. To illustrate, if a user account needs to send 100,000 tokens each having a different token attribution from one user account to another user account, it may be impossible to do in one transaction. Accordingly, a lossless token attribution method may not be a computationally tractable token attribution solution as the number of different token issuers increases within system 100.

[0027] Aspects and implementations of the disclosure address the above and other deficiencies by providing technology that implements blockchain-based token attribution and yield distribution with reduced computational complexity. More specifically, the token transaction management system can use a lossy token attribution method that can achieve sub-linear computational complexity.

[0028] To implement the lossy token attribution method, at least one designated attribution property can be assigned to each user account (e.g., digital wallet address). A designated attribution property indicates the attribution property that each token maintained by the user account must have. A designated attribution property can be assigned to a user account using any suitable method. In some implementations, a designated attribution property assigned to a user account is selected by the user of the user account. In some implementations, the token transaction management system assigns a designated attribution property to a user account. For example, the token transaction management system can randomly assign a designated attribution property to a user account. The token transaction management system can maintain a record of designated attribution properties across user accounts.

[0029] If a receiver receives, from a sender, a token having an attribution property that is the same as the designated attribution property assigned to the receiver, then the token is a conforming token that can simply be transferred to the receiver and the corresponding token balances can be updated by the token transaction management system. However, it may be the case that at least one token being transferred from a sender to a receiver is a nonconforming token having an attribution property different from the designated attribution property assigned to the receiver.

[0030] To address this, the transfer function can cause token reattribution. Generally, reattributing a token from a first attribution property to a second attribution property can include causing a token having the first attribution property to be burned, and causing a token having the second attribution property to be minted. Token reattribution can occur either by reattributing the at least one token sent by the sender to the designated attribution property of the receiver, or by reattributing the token balance of the receiver to the attribution property of the at least one token sent by the sender. In some implementations, the sender is the receiver.

[0031] A lossy token attribution method described can reduce the computational complexity and / or space complexity to track token attribution within the system, as compared to a lossless token attribution method. For example, the space complexity to track token attribution using the lossy token attribution method can be sublinear with respect to the number of token issuers. In some implementations, the space complexity is constant. A constant space complexity means that the amount of computing resources (e.g., memory) used to store the token balance for a user account is the same regardless of the number of token issuers that have minted tokens within the system (i.e., the number of different token attributions). This is because only a single token balance of attributed tokens having thedesignated attribution property needs to be tracked for each user account. Accordingly, implementing a process of reattributing non-conforming tokens into conforming tokens during token transfers between senders and receivers can make tracking token attribution computationally feasible. An example of this process will be described below with reference to FIG. IB

[0032] In some implementations, token attribution is used to determine an amount of yield to provide to token issuer 102. “Yield” refers to a reward (e.g., additional tokens, interest or fees) earned by token issuer 102 based on the number of tokens minted by token issuer 102 that are in circulation within system 100 (e.g., within circulation space 108). For example, the yield can be distributed at a fixed interval (e.g., daily at a particular time) based on the number of tokens minted by token issuer that are in circulation within system 100. More specifically, token issuer 102 can be eligible to receive a proportionate amount of the total yield, where the proportionate amount of the total yield corresponds to the proportion of tokens minted by token issuer 102 to the total number of tokens that are in circulation within system 100. Illustratively, if it is determined that token issuer 102 has minted 100 tokens of 1,000 tokens that are in circulation within system 100 at the time of yield distribution, then system 100 can distribute 10% of the total yield to token issuer 102. Yield for a token may no longer be provided to token issuer 102 after the token is redeemed and removed from circulation within system 100. Accordingly, yield can function as an incentive to token issuer 102 to maximize token minting and circulation time within system 100.

[0033] FIG. IB is a diagram illustrating a single-chain token transfer within system 100, in accordance with some implementations. As shown, system 100 can include sender user account (“sender”) 110 that owns digital wallet 112 and receiver user account (“receiver”) 120 that owns digital wallet 122. Digital wallet 112 and digital wallet 122 can each be linked to the same local token contract 109 of a local blockchain. In some implementations, the source blockchain and the destination blockchain are the same. System 100 can further include token transfer platform 130. Token transaction platform 130 can be any node (e.g., server) of the system connected to the peer-to-peer (P2P) network of the underlying blockchain network to publish transactions. Token transaction platform 130 can implement a transfer function of token contract 109 to enable sender 110 to transfer tokens to receiver 120.

[0034] To initiate the transfer of tokens to receiver 120, sender 110 can send a transfer request to token transaction platform 130. The transfer request can designate a number of tokens to be sent from sender 110 to receiver 120 (i.e., a transfer amount) and an address of receiver 120 (e.g., the address of digital wallet 122). Each token sent from sender 110 isassumed to have a designated attribution property assigned to digital wallet 112, and at least one designated attribution property is assigned to receiver 120 (e.g., digital wallet 122).

[0035] Upon receiving the transfer request from sender 110, token transaction platform 130 can trigger (e.g., call) a transfer function of a token contract to cause a transaction payload equal to the number of tokens to be sent from digital wallet 112 to digital wallet 122 (e.g., debit digital wallet 112) and cause the transaction payload to be received by digital wallet 112 (e.g., credit digital wallet 122). In a single chain transfer, the operations of the transfer function can be combined in a single local transaction (e.g., atomic transaction).

[0036] The operation of the token transfer can change based on whether any nonconforming tokens are included in the transaction pay load. If the transaction pay load only includes conforming tokens, then the transfer function can simply send the transaction payload to digital wallet 122. However, if the transaction payload includes at least one nonconforming token, then the transfer function can cause reattribution of each non-conforming token into a conforming token (e.g., by burning the non-conforming token and minting the conforming token). In some implementations, the transfer function causes reattribution of at least one non-conforming token sent by sender 110 to the designated attribution property of receiver 120. In alternative implementations, the transfer function causes reattribution of the token balance of receiver 120 to the attribution property of the at least one non-conforming token sent by sender 110.

[0037] In some implementations, system 100 includes multiple blockchains (“multi-chain system”) forming a global blockchain network, and the token transfer is a cross-chain transfer from sender linked to a source blockchain and a receiver linked to a destination blockchain different from the source blockchain. An example of a multi-chain system will be described in further detail below with reference to FIG. 1C.

[0038] A multi-chain system can support single-chain (e.g., intrachain) transfers, such as that shown in FIG. IB. Additionally, a multi-chain system can support cross-chain (e.g., interchain) transfers. To perform a cross-chain transfer, the transfer function can implement a send transaction and a receive transaction. Generally, during the send transaction, the transfer function can cause a cross-chain message to be generated and sent to receiver 120. In some implementations, the cross-chain message includes a data packet (“packet”). Generating the cross-chain message can include moving the transfer amount of tokens from digital wallet 112 into the cross-chain message. That is, the cross-chain message includes a transaction payload that includes the transfer amount of tokens. Examples of generating and sending cross-chain messages will be described herein below with reference to FIGS. 2A-5B.Generally, during the receive transaction, the transfer function can cause the transaction payload to be moved from the cross-chain message to digital wallet 122. Additionally, any non-conforming tokens can be reattributed to respective conforming tokens.

[0039] However, cross-chain transfers can introduce messaging asynchrony between the debit of the transaction payload from the token balance of sender 110 and the credit of the transaction payload to the token balance of receiver 120. As will be described in further detail below with reference to FIGS. 1C-1F, implementations described herein can be used to reduce asynchrony in a computationally feasible way.

[0040] FIG. 1C is a diagram illustrating an example of system 100 as a multi-chain system, in accordance with some implementations. System 100 can include multiple blockchains, including one or more primary chains including primary chain 140A and one more secondary chains. Although two secondary blockchains 140B-1 and 140B-2 are described in this illustrative example, the number of secondary blockchains should not be considered limiting. In some implementations, primary chain 140A is a mainchain and each of secondary chains 140B-1 and 140B-2 is a sidechain.

[0041] Each local blockchain of system 100 can include a local token contract. Each local token contract of a local blockchain can track, for each attribution property, the local circulation of tokens having the attribution property circulating within the local blockchain. For example, as shown, primary chain 140 A includes local token contract 109 for tracking, for each attribution property, the local circulation of tokens having the attribution property circulating within primary chain 140A. As another example, as shown, secondary chain 140B-1 includes local token contract 109B-1 for tracking, for each attribution property, the local circulation of tokens having the attribution property circulating within secondary chain 140B-1. As yet another example, as shown, secondary chain 140B-2 includes local token contract 109B-2 for tracking, for each attribution property, the local circulation of tokens having the attribution property circulating within secondary chain 140B-2. The total local circulation for a local chain of system 100 refers to the sum of the local circulation for each attribution property.

[0042] As further shown, primary chain 140 A can include vault 101. For example, vault 101 can be deployed as part of the token contract of primary chain 140A. In some implementations, only primary chain 140A includes a vault. For example, in some implementations, the diagram shown in FIG. 1A can represent primary chain 140 A of system 100. In some implementations, each local blockchain includes a respective vault. For example, secondary chain 140B-1 and / or secondary chain 140B-2 can include its own vault.

[0043] After a token is minted at vault 101, it can be transferred to the user account (e.g., digital wallet) associated with the token issuer on primary chain 140A, from where it can be transferred to another user account and / or local blockchain. More specifically, system 100 can support intrachain or local token transfers between a sender and a receiver with respect to a local blockchain, and interchain or cross-chain token transfers between a sender associated with one local blockchain and a receiver associated with another local blockchain. For example, a cross-chain token transfer can occur between primary chain 140A and one of the secondary chains 140B-1 or 140B-2, between secondary chain 140B-1 and secondary chain 140B-2, etc.

[0044] In addition to handling mint and redemption functions for each local blockchain (e.g., primary chain 140A and secondary chains 140B-1 and 140B-2), vault 101 can be used to track, for each attribution property, the global circulation of tokens having the attribution property within system 100. More specifically, the global token circulation of tokens having a given attribution property can be equal to the sum of each local token circulation of tokens having the given attribution property. The global token circulation of tokens having the given attribution property can be used to determine the proportion of tokens having the given attribution property in circulation with respect to the total number of tokens in circulation, which can be used to determine the amount of yield due to the corresponding token issuer. The total global circulation for system 100 refers to the sum of the global circulation for each attribution property.

[0045] To enable the vault 101 to track the global token circulation of tokens for each attribution property (e.g., which can be used to determine yield to be provided to token issuers), vault 101 can receive updates to local token circulation information from secondary chains to prevent divergence between the secondary blockchain token contract state and the vault state. As described above with reference to FIG. IB, communication of a cross-chain transfer can be achieved using a cross-chain message (e.g., packet) that can send a set of data including the transfer payload from a source blockchain to a destination blockchain utilizing separate send and receive transactions.

[0046] However, it may be virtually impossible for vault 101 to track the global token attribution of the multi-chain system in a lossless way that is computationally efficient and scalable. This can be due at least in part to how computationally expensive it is to send crosschain messages from a secondary chain to primary chain 140A to synchronize the local token attribution data stored in the token contract of the secondary chain with the global token attribution stored on vault 101. Additionally, this can be due at least in part to the frequencyof token reattributions (e.g., the frequency of token transactions necessitating token reattributions). Accordingly, to make token reattribution with respect to cross-chain transfers scalable and practically usable, the number of synchronization messages sent to primary chain 140A to synchronize vault 101 should be reduced to reduce computational resource consumption.

[0047] However, decreasing the frequency of synchronization of vault 101 can lead to divergence between global token circulation(s) maintained by vault 101 of primary chain 140 A and local token circulation(s) maintained by respective token contract(s) of local blockchains. Divergence with respect to a local blockchain can grow as a function of time between consecutive synchronizations between the state of the token contract on the local blockchain and the state of vault 101. This divergence can be unsafe, as vault 101 cannot accurately track the total global token circulation. This can, for example, unfairly influence distribution of yield allocated to token issuers based on their respective token contributions to the global token circulation.

[0048] To address these and other drawbacks, system 100 can reduce computational resource consumption (e.g., reduce synchronizations using cross-chain messages) by separating token attribution and token distribution into separate layers. With respect to the token attribution layer, each local token contract (e.g., token contract 109, token contract 109B-1 and token contract 109B-2) can store, for each attribution property, an attribution property age (“age”) of the attribution property. The attribution age can be determined based on an amount of time that a quantity of tokens having the attribution property have been in circulation within a blockchain. The age of a given attribution property C is Agee, and the sum of ages across all attribution properties is Ages. For example, Agee and Ages can each be determined as local ages with respect to a local blockchain of system 100 (e.g., primary chain 140A, secondary chain 140B-1 and secondary chain 140B-2). As another example, Agee and Ages can each be determined across all local blockchains of system 100 (e.g., global ages). Age can be tracked for each attribution property in system 100, and for the total circulation of tokens within a local blockchain.

[0049] The age of an attribution property is defined as a product of a quantity of tokens having the attribution property in circulation within the local blockchain, and an elapsed amount of time that the quantity of tokens having the attribution property have been circulating within the local blockchain without a change in quantity. Any suitable units of time can be used to calculate age. Examples of suitable units of time include seconds (s), minutes, hours, etc. For example, in the case of seconds, if the quantity of tokens having anattribution property in circulation is 100, and the elapsed amount of time is 10 s, then the corresponding age is 1000. Age can be summed over time. For example, if the quantity of tokens having an attribution property in circulation is 100 for 10 s, and then the quantity of tokens having the attribution property in circulation changes to 200 for another 10 s, then total age for the attribution property is given to be 100 x 10 + 200 x 10 = 3000. Time can be determined using any suitable time source, such as local wall clock time or some other logical time construct.

[0050] Various age update events, also referred to herein as checkpoints, can cause an age update to the age of at least one attribution property with respect to at least one local blockchain. One type of age update event is a token transaction. One example of a token transaction that can cause an age update is token reattribution. For example, every time token reattribution is performed from a source attribution property to a destination attribution property, the age of the source attribution property and the age of destination attribution property can be updated. Other examples of token transactions that can be used as checkpoints include token transfers, token minting, and token burning. For example, every time a token having an attribution property is moved between blockchains, minted, or burned, the age of the attribution property for the attribution property and the total circulation on all blockchains involved can be updated.

[0051] Yet another type of age update event is yield distribution to distribute yield to respective token issuers across one or more local blockchains of system 100. Yield distribution can be periodically performed on epoch granularity, such that yield is distributed to token issuers at each epoch. “Epoch” refers to a time at which yield is distributed to token issuers. An epoch can occur at a regular (e.g., fixed) interval of time set by system 100. Further details regarding yield distribution will be described below with reference to FIGS. 1D-1F. Accordingly, yield distribution can be implemented as an automated checkpoint mechanism, performed at each epoch, to update attribution property ages across the one or more local blockchains of system 100.

[0052] Another type of age update event is an explicit age update event request, which is a request received from a computing device to trigger the age update (e.g., without having to perform a token transaction or yield distribution). An explicit age update event request can be made by an entity of system 100, such as a user, token issuer (e.g., minter), administrator, etc.

[0053] An illustrative example of updating ages of attribution properties over time will now be described. For example, assume at initial time to that the local circulation of tokens having attribution property B on a first local blockchain is 100 (100B) and the localcirculation of tokens having atribution property R on a second local blockchain is 50 (5 OR). In some implementations, the first local blockchain is different from the second local blockchain. In some implementations, the first local blockchain is the same as the second local blockchain.

[0054] At time t , 25 tokens having attribution property R are converted to atribution property B, such that the local circulation of tokens having atribution B is 125 (125B) and the local circulation of tokens having attribution property R is 25 (25R). Such token reatribution is an age update event at h that causes an update to the ages of B and R. More specifically, at fi, the age of attribution property B (Ages) is updated to 100(t1— t0), and the age of attribution property R (Ageu) is updated to 50(t1— t0). Additionally, the circulation of atribution property B (circulationB) can be updated to 125, the circulation of attribution property R (circulationR) can be updated to 25, the last timestamp for Ages (timestampB) can be updated to fi, and the last timestamp for AgeR (timestampR) can be updated to fi.

[0055] At time h, the remaining 25 tokens having atribution property R are converted to atribution property B, such that the local circulation of tokens having atribution B is 150 (150B) and the local circulation of tokens having atribution property R is 0 (OR). Such token reatribution is an age update event at h that causes an update to the ages of B and R. More specifically, at h, Ages is updated to 125(t2— ti), and AgeR is updated to 25(t2— ti). Additionally, circulationB can be updated to 150, circulationR can be updated to 0, and timestampB and timestampR can each be updated to t .

[0056] As mentioned above, yield distribution to token issuers across each local blockchain can occur at each epoch. Assume that yield distribution (e.g., epoch checkpoint) occurs at epoch d corresponding to time ta between h and tz (t < td< t2). If to reflects the beginning of time (e.g., to = 0), then Ages at ta can be equal to the sum of Ages at h and 125 (td— ti), and AgeR at time ta can be equal to the sum of AgeR at h and 25 (t3— t-^). If to does not reflect the beginning of time, then Ages and AgeR at ta can be offset by Ages and AgeR at the last yield distribution (e.g., epoch checkpoint) that occurred at epoch d-1 corresponding to time ta-i (td-i < td), respectively. For example, in this case, Ages at ta can be equal to the sum of Ages at h and 125 (td— t ). minus Ages at ta-i. AgeR at ta can be equal to the sum of AgeR at h and 25(td— tr), minus AgeR at ta-i. Accordingly, in this example, is irrelevant for the yield distribution that occurs during epoch d, while is relevant for the yield distribution that will occur during the subsequent epoch d+\ corresponding to time ta+i (td+1> td).

[0057] There are various ways to manage yield distribution at each epoch utilizing token attribution ages. In some implementations, yield distribution is managed by an on-chain entity. For example, as will be described in further detail below with reference to FIG. ID, at least one vault (e.g., vault 101) can centrally manage yield distribution by distributing, at each epoch, a respective token issuer yield share of a total amount of yield for the epoch to each token issuer (e.g., a digital wallet associated with a token issuer). As another example, as will be described in further detail below with reference to FIG. IE, at least one vault (e.g., vault 101) can distribute, at each epoch, a respective local blockchain yield share of a total amount of yield for the epoch to at least one local blockchain, and the at least one local blockchain can locally manage distribution of its respective local blockchain yield share to respective token issuers. In some implementations, yield distribution is managed by an off- chain entity. For example, as will be described in further detail below with reference to FIG. IF, at least one vault (e.g., vault 101) can send a total amount of yield for an epoch to an off- chain entity, and the off-chain entity can distribute, to each token issuer, a respective token issuer yield share of the total amount of yield for the epoch. In some implementations, yield distribution is managed by a combination of the at least one vault, the at least one local blockchain, and / or the off-chain entity. In some implementations, yield share of a token issuer is sent to a digital wallet directly managed by the token issuer. In some implementations, yield share of a token issuer is sent to a custodial wallet of a third party entity designated to be a receiver of the token issuer yield share.

[0058] FIG. ID is a diagram of an example system 100 illustrating centrally managed on- chain yield distribution, in accordance with some implementations. As shown, system 100 can include at least one including vault 101, as described above with reference to FIGS. 1A- 1C. In some implementations, vault 101 is included in a primary chain (e.g., primary chain 140A). In some implementations, vault 101 is included in at least one local blockchain. For example, vault 101 can be included in at least one of a primary chain or a secondary chain.

[0059] As further shown, system 100 can include a set of local blockchains including local blockchain 145-1. In some implementations, local blockchain 145-1 is a primary chain (e.g., primary chain 140A of FIG. 1C). In some implementations, local blockchain 145-1 is a secondary chain (e.g., secondary chain 140B-1 or secondary chain 140B-2 of FIG. 1C). Tokens present on local blockchain 145-1 can be minted by any number of token issuers, where each token issuer is assigned a respective attribution property, as described above. In this example, it is assumed that the token issuer(s) who have minted tokens present on local blockchain 145-1 include a token issuer assigned attribution property C. As further shown,system 100 can include a set of digital wallets including digital wallet 147. For example, digital wallet 147 can be similar to digital wallet 112 or digital wallet 122 of FIG. IB. Digital wallet 147 is assumed in this example to be owned by the token issuer assigned attribution property C.

[0060] At a current epoch, epoch T, vault 101 can receive, from at least one local blockchain, a respective set of age data items for epoch T (“Epoch age data”). For example, as shown, vault 101 can receive Epoch? age data 150D from local blockchain 145-1. In some implementations, Epoch? age data 150D includes the individual age of each attribution property on local blockchain 145-1, which includes the age of attribution property C (Agee), and a sum of the ages of all attribution properties (Ages) for local blockchain 145-E In some implementations, Epoch? age data 150D includes the individual age of each attribution property on local blockchain 145-1 (e.g., Agee), and vault 101 determines Ages for local blockchain 145-1 using the age of each attribution property on local blockchain 145-1.

[0061] Vault 101 can identify the total yield for local blockchain 145-1 at Epoch? (“Epoch? yield”) 160D. In some implementations, identifying Epoch? yield 160D includes determining Epoch? yield 160D. Epoch? yield 160D can be determined using any suitable yield determining logic. An administrator managing system 100 can arbitrarily distribute yields based on internal financial data.

[0062] Vault 101 can then determine, for each token issuer, a respective yield share of Epoch? yield 160D. For example, the yield share of Epoch? yield 160D for the token issuer assigned attribution property C is indicated by Epoch? yield share 170D.

[0063] In some implementations, Epoch? yield share 170D is a local epoch yield share for attribution property C with respect to local blockchain 145-1. For example, Epoch? yield share 170D can be determined as a proportional share of Epoch? yield 160D based on Agee for local blockchain 145-1 relative to Ages for local blockchain 145-1. In some implementations, Epoch? yield share 170D can be determined as Epoch? yield 160D multiplied by the ratio of Agee for local blockchain 145-1 to Ages for local blockchain 145-1. Vault 101 can then send Epoch? yield share 170D to digital wallet 147.

[0064] In some implementations, Epoch? yield share 170D is a global epoch yield share for attribution property C across all local blockchains (including local blockchain 145-1). For example, Epoch? yield share 170D can be determined as a proportional share of Epoch? yield 160D based on the sum of Agee across all local blockchains relative to the sum of Ages across all local blockchains. In some implementations, Epoch? yield share 170D can be determined as Epoch? yield 160D multiplied by the ratio of the sum of Agee across all localblockchains to the sum of Ages across all local blockchains. Vault 101 can then send Epoch yield share 170D to digital wallet 147.

[0065] FIG. IE is a diagram of an example system 100 illustrating locally managed on- chain yield distribution, in accordance with some implementations. As shown, system 100 can include vault 101, as described above with reference to FIGS. 1A-1C. In some implementations, vault 101 is included in a primary chain (e.g., primary chain 140A). In some implementations, vault 101 is included in at least one local blockchain. For example, vault 101 can be included in at least one of a primary chain or a secondary chain.

[0066] As further shown, system 100 can include a set of local blockchains including local blockchain 145-1 and local blockchain 145-2, In some implementations, at least one of local blockchain 145-1 or local blockchain 145-2 is a primary chain (e.g., primary chain 140A of FIG. 1C). In some implementations, at least one of local blockchain 145-1 or local blockchain 145-2 is a secondary chain (e.g., secondary chain 140B-1 or secondary chain 140B-2 of FIG. 1C).

[0067] At a current epoch, epoch / '. vault 101 can receive, from each local blockchain, a respective set of age data for epoch T (“Epoch? age data”). For example, as shown, vault 101 can receive Epoch? age data 150E-1 from local blockchain 145-1 and Epoch? age data 150E- 2 from local blockchain 145-2. In some implementations, Epoch? age data 150E-1 includes Ages for local blockchain 145-1 and Epoch? age data 150E-2 includes Ages for local blockchain 145-2.

[0068] In some implementations, Epoch? age data 150E-1 includes the individual age of each attribution property for local blockchain 145-1 (e.g., Agee for local blockchain 145-1), and Epoch? age data 150E-2 includes the individual age for each attribution property on local blockchain 145-2 (e.g., Agee for local blockchain 145-2). Vault 101 can determine Ages for local blockchain 145-1 as a sum of each individual age for local blockchain 145-1, and Ages for local blockchain 145-2 as a sum of each individual age for local blockchain 145-2.

[0069] Vault 101 can identify the total yield for local blockchain 145-1 at Epoch? (“Epoch? yield”) 160E. In some implementations, identifying Epoch? yield 160E includes determining Epoch? yield 160E. Epoch? yield 160E can be determined using any suitable yield determining logic. An administrator managing system 100 can arbitrarily distribute yields based on internal financial data.

[0070] Vault 101 can then determine, for each local blockchain, a respective yield share of Epoch? yield 160E, and can send the respective yield share of Epoch? yield 160E to the token contract of the local blockchain. For example, the yield share of Epoch? yield 160E forlocal blockchain 145-1 is indicated by Epoch yield share 170E-1 and is sent to token contract 109B-1, and the yield share of Epoch? yield 160E for local blockchain 145-2 is indicated by Epoch? yield share 170E-2 and is sent to token contract 109B-2.

[0071] In some implementations, vault 101 determines Epoch? yield share 170E-1 proportionally based on Ages of the local blockchain 145-1 divided by the global Ages (e.g., sum of Ages across all local blockchains), and Epoch? yield share 170E-2 proportionally based on Ages of the local blockchain 145-2 divided by the global Ages. Such a model only requires Ages data to be synchronized from each local blockchain to vault 101, thus resulting in messaging complexity scaling in proportion to the number of local blockchains of system 100 (rather than the number of token issuers). Therefore, locally managed on-chain yield distribution can reduce computational complexity and resource consumption, as compared to other yield distribution implementations, if the number of local blockchains is less than the number of token issuers.

[0072] After receiving Epoch? yield share 170E-1, local blockchain 145-1 can distribute, to the digital wallet of each token issuer, a respective yield based on the individual age of the assigned attribution property on local blockchain 145-1. This distribution or a subset of it can be permissionless and initiated by any party. For example, for the token issuer assigned attribution property C, the yield for attribution property C can be determined as a proportional share of Epoch? yield share 170E-1 based on Agee for local blockchain 145-1 relative to Ages for local blockchain 145-1. In some implementations, the yield for attribution property C can be determined as Epoch? yield share 170E-1 multiplied by the ratio of Agee for local blockchain 145-1 to Ages for local blockchain 145-1. Local blockchain 145-1 can then send the yield for attribution property C to the corresponding digital wallet (e.g., digital wallet 147 of FIG. ID).

[0073] Similarly after receiving Epoch? yield share 170E-2, local blockchain 145-2 can distribute, to the digital wallet of each token issuer, a respective yield based on the individual age of the assigned attribution property on local blockchain 145-2. For example, for the token issuer assigned attribution property C, the yield for attribution property C can be determined as a proportional share of Epoch? yield share 170E-2 based on Agee for local blockchain 145-2 relative to Ages for local blockchain 145-2. In some implementations, the yield for attribution property C can be determined as Epoch? yield share 170E-2 multiplied by the ratio of Agee for local blockchain 145-2 to Ages for local blockchain 145-2. Local blockchain 145-2 can then send the yield for attribution property C to the corresponding digital wallet (e.g., digital wallet 147 of FIG. ID).

[0074] FIG. IF is a diagram of an example system 100 illustrating off-chain-managed yield distribution, in accordance with some implementations. As shown, system 100 can include vault 101, as described above with reference to FIGS. 1A-1C. In some implementations, vault 101 is included in a primary chain (e.g., primary chain 140A). In some implementations, vault 101 is included in at least one local blockchain. For example, vault 101 can be included in at least one of a primary chain or a secondary chain.

[0075] As further shown, system 100 can include a set of local blockchains including local blockchain 145-1. In some implementations, local blockchain 145-1 is a primary chain (e.g., primary chain 140A of FIG. 1C). In some implementations, local blockchain 145-1 is a secondary chain (e.g., secondary chain 140B-1 or secondary chain 140B-2 of FIG. 1C). Tokens present on local blockchain 145-1 can be minted by any number of token issuers, where each token issuer is assigned a respective attribution property, as described above. In this example, it is assumed that the token issuer(s) who have minted tokens present on local blockchain 145-1 include a token issuer assigned attribution property C. As further shown, system 100 can include a set of digital wallets including digital wallet 147. For example, digital wallet 147 can be similar to digital wallet 112 or digital wallet 122 of FIG. IB. Digital wallet 147 is assumed in this example to be owned by the token issuer assigned attribution property C.

[0076] As further shown, system 100 can include off-chain entity 180. At a current epoch, epoch T, off-chain entity 180 can receive, from each local blockchain, a respective set of age data items for epoch T (“Epoch age data”). For example, as shown, off-chain entity 180 can receive Epoch? age data 150F from local blockchain 145-1. In some implementations, Epoch? age data 150F includes the individual age of each attribution property on local blockchain 145-1, which includes the age of attribution property C (Agee), and a sum of the ages of all attribution properties (Ages) for local blockchain 145-1. In some implementations, Epoch? age data 150F includes the individual age of each attribution property on local blockchain 145-1 (e.g., Agee), and vault 101 determines Ages for local blockchain 145-1 using the age of each attribution property on local blockchain 145-1.

[0077] Off-chain entity 180 can further receive, from vault 101, the total yield for local blockchain 145-1 at Epoch? (“Epoch? yield”) 160F. Epoch? yield 160F is similar to Epoch? yield 160D of FIG. ID.

[0078] Off-chain entity 180 can then determine, for each token issuer, a respective yield share of Epoch? yield 160F. For example, the yield share of Epoch? yield 160F for the token issuer assigned attribution property C is indicated by Epoch? yield share 170F.

[0079] In some implementations, Epoch yield share 170F is a local epoch yield share for atribution property C with respect to local blockchain 145-1. For example, Epoch? yield share 170F can be determined as a proportional share of Epoch? yield 160F based on Agee for local blockchain 145-1 relative to Ages for local blockchain 145-1. In some implementations, Epoch? yield share 170F can be determined as Epoch? yield 160F multiplied by the ratio of Agee for local blockchain 145-1 to Ages for local blockchain 145-1. Vault 101 can then send Epoch? yield share 170F to digital wallet 147.

[0080] In some implementations, Epoch? yield share 170F is a global epoch yield share for attribution property C across all local blockchains (including local blockchain 145-1). For example, Epoch? yield share 170F can be determined as a proportional share of Epoch? yield 160F based on the sum of Agee across all local blockchains relative to the sum of Ages across all local blockchains. In some implementations, Epoch? yield share 170F can be determined as Epoch? yield 160F multiplied by the ratio of the sum of Agee across all local blockchains to the sum of Ages across all local blockchains. Vault 101 can then send Epoch? yield share 170F to digital wallet 147.

[0081] Off-chain managed yield distribution can be the most computational-resource- efficient method of distributing yields, since it can be done without requiring any cross-chain messages. However, token issuers may need to place trust in the off-chain distribution infrastructure that they will receive the correct yield share for each epoch.

[0082] In some implementations, a combination of yield distribution methods can be used in conjunction or as mutually exclusive options. A subset of the yield can be distributed using a centralized yield distribution mechanism, a subset of the yield can be distributed using a local yield distribution mechanism, and a subset of the yield can be distributed using an off- chain yield distribution mechanism. These subsets may or may not be disjoint.

[0083] In some implementations, checkpoint roots (CPRs) of atributions properties are used for age tracking. A CPR for an atribution property refers to data that specifies the age at the current time. CPRs can be used to validate the authenticity of a sequence of ages of an atribution property. A CPR of an atribution property for a current time can be iteratively generated by combining the age of the atribution property at the current time with the previous CPR of the atribution property for the previous time. In some implementations, combining the age of the attribution property at the current time with the previous CPR of the atribution property for the previous time includes obtaining a digest (e.g., hash value) of an encoding of the previous CPR and the age. Further details regarding generating and storing CPRs will now be described below with reference to FIGS. 7-8.

[0084] FIG. 7 is a diagram 700 of an example graph 710 illustrating token attribution property age (“age”) as a function of time, in accordance with some implementations. Graph 710 includes x-axis 712 corresponding to time t and y-axis 714 corresponding to cumulative age as a function of time. More specifically, graph 710 is broken up into first epoch (Epocho) 720-1, second epoch (Epochi) 720-2 and third epoch (Epochs) 720-3. Epocho 720-1 has Epocho attribution 730-1, Epochi 720-2 has Epochi attribution 730-2, and Epochs 720-3 has Epoch2 attribution 730-3. First epoch age (Ao) 740-1 is defined as the cumulative age at the end of Epocho 720-1, second epoch age (Ai) 740-2 is defined as the cumulative age at the end of Epochi 720-2, and third epoch age (A2) 740-3 is defined as the cumulative age at the end of Epoch2 720-3. The time derivative of the function shown in graph 710 (e.g., slope) is equal to the circulation (e.g., instantaneous circulation) of the tokens having the attribution property. As described above with reference to FIG. 1C, Ao 740-1 is used to generate first CPR for the first epoch (CPRo) 750-1, Ai 740-2 and CPRo 750-1 are used to generate second CPR for the second epoch (CPRi) 750-2, and A2 740-3 and CPRi 750-2 are used to generate third CPR for the third epoch (CPR2) 750-3.

[0085] In some implementations, the CPR at a given time t, CPRi, can be determined as the digest (e.g., hash) of an encoding of the age at a certain point in time and the previous CPR, CP RM . This can create a chain-like structure where the current CPR (a compact hash or similar) can be used to validate the authenticity of a given sequence of ages. Any suitable digest function (e.g., hash function) can be used to determine CPRi. As an illustrative example, for time t E {0} U Z+(i.e., nonnegative integer), CPRi = keccak256(abi.encode(CPRf-i, Af)), where keccak256() is the SHA-3 cryptographic hash function, abi.encode() is an Application Binary Interface (ABI) encoding function, and CPR-i = 0. ABI encoding refers to a mechanism that can be used to convert data structures and / or function calls into bytes. ABI encoding can be used to ensure interoperability between different parts of a software system (e.g., where components are developed in different programming languages or executed on different hardware architectures). ABI encoding is an illustrative example of an encoding function that can be used in accordance with implementations described herein. However, any suitable encoding function that can uniquely identify a previous checkpoint root and an age of an attribution property can be used in accordance with implementations described herein.

[0086] In some implementations, CPR storage optimization is performed. More specifically, CPR storage optimization can be used to enable the verification of sequences of ages on a remote blockchain while only using one storage slot for CPR. Without this, for acurrent time T, it is noted that if CPR / .? was stored in a vault (e.g., vault 101 of FIGS. 1A- 1C), then the local blockchain would have to send CPR / . Ager-i, and Ager to verifiably recreate the chain all the way to CPRT. Accordingly, these implementations can reduce computation resource consumption (e.g., storage resource consumption). Further details regarding CPR storage optimization will now be described below with reference to FIG. 8.

[0087] FIG. 8 is a diagram of an example system 800 implementing CPR storage optimization, in accordance with some implementations. As shown, system 800 can include local blockchain 810 and vault 820. In some implementations, local blockchain 810 is a primary chain (e.g., primary chain 140A of FIG. 1C). In some implementations, local blockchain 810 is a secondary chain (e.g., secondary chain 140B-1 or secondary chain 140B- 2 of FIG. 1C). In some implementations, local blockchain functions as a primary chain and a secondary chain. In some implementations, vault 820 is included in a primary chain (e.g., primary chain 140A of FIG. 1C). In some implementations, vault 820 is included in a secondary chain (e.g., secondary chain 140B-1 or secondary chain 140B-2 of FIG. 1C).

[0088] Local blockchain 810 can include set of storage slots 812 storing a CPR for a current epoch at time t = T (CPRT) 814 and a set of epoch ages. As shown, the set of epoch ages can include an initial epoch age at time t = 0 (Ao) 816-1, ..., a previous epoch age at time t = T-l (AT-I) 816-(7-l) and a current epoch age at time t = T (AT) 816-7. Ao 816-1 is defined as the cumulative age at the end of an initial epoch at t = 0, AT-I 816-(7-l) is defined as the cumulative age at the end of a previous epoch at time t = T-l, and Ar 816-7 is defined as the cumulative age at the end of the current epoch t = T.

[0089] Vault 820 can include set of storage slots 822. In some implementations, set of storage slots 822 includes a single storage slot. In a previous vault state 830, set of storage slots 822 can store a CPR for a previous epoch, receive at least one age including AT 816-7 from local blockchain 810, use combiner 824 to obtain CPRT 844, and store CPRT 844 in set of storage slots 822 (e.g., overwriting CPRT-I 834). In some implementations, combiner 824 includes an encoder. In some implementations, correctness of received Ar 816-7 can be validated by comparing computed CPRT 844 to the value of CPRT observed on local blockchain 810.

[0090] In some implementations, the previous epoch is the epoch at time t = 7-1 (CPRr-i) 834. To enter current vault state 840, vault 820 can receive AySlO-T from local blockchain 810, and combine Ar 816-7 with CPR / ., 834 using combiner 824 to obtain CPRT 844 (e.g., as described above with reference to FIG. 7).

[0091] For example, the age of an attribution property can be defined as a tuple. The tuple can include data indicative of at least one of: the current circulation of tokens having the attribution property, the cumulative age of the attribution property, the time stamp of the last circulation or age update, the epoch number of the last updated circulation or age, or the CPR. An example tuple representing age of an attribution property is provided as follows:Age { circulation: u64, / / The current circulation age: u96 / / The cumulative age lastTimestamp: u32, / / The timestamp of the last circulation / age update lastCheckpointEpoch: ul6, / / The epoch number of the last updated circulation / age checkpointRoot: bytes32 / / The CPR) where u64 refers to a 64-bit unsigned integer, u96 refers to a 96-bit unsigned integer, ul6 refers to a 16-bit unsigned integer, and bytes32 refers to a fixed-length byte array of 32 bytes.

[0092] Implementations described herein can provide a number of technical advantages. For example, as described above, by implementing blockchain-based token attribution using a lossy token attribution method described herein instead of a more computationally complex lossless token attribution method, implementations described herein can reduce resource consumption (e.g., processor and / or memory resource consumption). Various aspects of the above referenced methods and systems are described in further detail herein below by way of examples, rather than by way of limitation.

[0093] In some implementations, system 100 is implemented by a decentralized exchange (DEX). A DEX, also known as a bridge, is a peer-to-peer (P2P) electronic platform that facilitates token transfers between digital wallets connected to different blockchains (i.e., cross-chain swaps). For example, some bridges can utilize smart contract-governed consensus protocols to facilitate the automatic minting of digital assets on a blockchain.

[0094] Some bridges can suffer from a variety of drawbacks. For example, some existing bridges can rely on intermediary chains and protocol-specific tokens, such as intermediary tokens or wrapped tokens, to facilitate transactions. Only a protocol-specific token is minted on the blockchain as opposed to the actual digital asset that the user wants. The user must then exchange the protocol-specific token for the actual digital asset in an additional transaction. These additional transactions and use of protocol-specific tokens andintermediary chains introduce overhead in what should be a single seamless transaction. As another example, some existing bridges can support only a small, limited network of blockchains.

[0095] To address at least the above deficiencies, cross-chain messaging of system 100 can be implemented using a set of cross-chain communication protocols (“communication protocols”) to support omnichain interoperability. A communication protocol can enable cross-chain communication of data items, such as messages or transactions, within a network. For example, a communication protocol described herein can support direct cross-chain messaging and / or cross-chain transactions. That is, a communication protocol described herein need not rely on any intermediary transactions, intermediary blockchains and / or intermediary tokens to facilitate the transmission of data items. A communication protocol described herein can be defined by a unified protocol, as opposed to an ad-hoc collection of messaging services, in order to serve diverse trust and security requirements of a wide variety of blockchain applications. A set of communication protocols described herein can provide a foundation to implement other network primitives, such as multicast (e.g., through iterated unicast) and / or publish / subscriber messaging.

[0096] Aspects and implementations of the set of communication protocols described herein can provide a number of technical advantages. For example, the set of communication protocols can enable the performance of direct cross-chain transactions. By using off-chain entities to retrieve and send transaction proofs and block headers, respectively, to a destination blockchain to determine whether a transaction originating from a source blockchain is stably committed on the source blockchain, the endpoints of the communication protocol located on the source blockchain and the destination blockchain can designed to be lightweight, and can run on computationally expensive blockchains without incurring prohibitive computational costs. Additionally, by enabling cross-chain digital asset transactions (e.g., transfers, swaps and / or exchanges), implementations described herein can maximize the utility of digital assets by enabling applications on every supported blockchain to use the digital asset, increase digital asset market liquidity, and digital asset utility. Further details regarding the set of communication protocols will now be described below with reference to FIGS. 2A-5D.

[0097] FIGS. 2A-2B are diagrams of an example computer system (“system”) 200 including an omnichain interoperability protocol platform, in accordance with some implementations. System 200 can implement a communication protocol to enable a crosschain bridge (“bridge”) that can be used to send a cross-chain data item (e.g., message ortransaction) from source blockchain 21 OA to destination blockchain 21 OB of a network. For example, blockchain 210A can correspond to sender 110 of FIG. 1A, and blockchain 21 OB can correspond to receiver 120 of FIG. 1A.

[0098] More specifically, the data item can be sent from a node maintaining blockchain 210A to a node maintaining blockchain 210B. A network can refer to a collection of blockchains that have functionality to support a protocol implemented by a platform. Each node of a network can be connected to other nodes of the network via a pair of unidirectional “connections,” over which data items (e.g., messages or native digital assets) can be transferred directly from the maintaining blockchain 210A to the node maintaining blockchain 210B. Each connection can be backed by liquidity assigned to blockchain 210B to facilitate withdrawals by the user as part of the communication protocol. Thus, the amount of available liquidity assigned to blockchain 210B can be viewed as the “bandwidth” of the connection between blockchain 210A and blockchain 210B. Allowing cross-chain transactions to flow freely provides opportunities for users to consolidate fragmented pockets of liquidity, while also making full use of applications on separate blockchains.

[0099] System 200 can enable a clean and minimal single-transaction cross-chain swap that does not utilize intermediary tokens. Generally, the transmission of a data item from blockchain 210A to blockchain 210B can be divided into multiple tasks, including an execution task and a validation task. A communication protocol described herein can separate these tasks into separate modules, which can then be unified through a flexible, customizable platform interface to support cross-chain data transfer protocols. For example, a platform interface can allow user applications associated with respective blockchains (e.g., located on the respective blockchains) to easily configure functionality, cost, and / or security. Accordingly, a communication protocol described herein can be generalized and modular to enable flexibility and customization depending on use case (e.g., a platform can define configuration space supporting a set of configurations).[000100] For example, blockchain 210A can include or otherwise be associated with user application 212A and endpoint 214, and blockchain 210B can include or otherwise be associated with user application 212B and endpoint 214B. Endpoint 214A and endpoint 214B can enable a user to send and / or receive a data item using the communication protocol. In some implementations, endpoint 214A and endpoint 214B are each implemented as a smart contract or a series of smart contracts.[000101] Endpoints 214A and 214B handle logic (e.g., high-level exchange logic) of the communication protocol for sending a data item from blockchain 210A to blockchain 210B.Endpoints, such as endpoint 214A and endpoint 214B, are lightweight clients that exist on their respective blockchains, and any blockchain with an endpoint can conduct cross-chain transactions involving any other blockchain with an endpoint using the platform. In some implementations, an endpoint is implemented as a series of smart contracts. Accordingly, the endpoints can create a fully-connected network in which every node of system 200 has a direct connection to every other node of system 200.[000102] Endpoints 214A and 214B can appear to user applications 212A and 212B, respectively, as ordered channels between blockchains 210A and 210B. User applications 212A and 212B can interact via endpoints 214A and 214B, respectively, to implement a communication protocol. For example, endpoint 214A can receive a data item (e.g., message or transaction) to be sent to blockchain 210B (e.g., a user application located on the destination blockchain), and send the data item to blockchain 210B in accordance with the communication protocol. As another example, endpoint 214B can receive a data item sent by blockchain 210A in accordance with the communication protocol.[000103] In some implementations, endpoint 214A includes set of communication protocol settings 211 A, communicator component 213A, validator component 215A and network component 217A. In some implementations, endpoint 214B includes set of communication protocol settings 21 IB, communicator component 213B, validator component 215B and network component 217B. This design can enable the addition of support for new blockchains without modifying components 213A through 217A and / or components 213B through 217B.[000104] Set of communication protocol settings 211 A and set of communication protocol settings 21 IB can each include a validation library selected from a set of validation libraries supported by system 200. A validation library is responsible for enabling validation of a data item being sent from a source blockchain to a destination blockchain. Blockchains 210A and 210B can be configured with the same validation library to support the transmission of a data item in accordance with the communication protocol. For example, a validation library can be implemented as an auxiliary smart contract that defines how cross-chain communication should be handled in accordance with the communication protocol. Each validation library can have an associated version number. For example, the set of validation libraries can include multiple versions of at least one validation library. The set of libraries can include one or more libraries that can handle message (e.g., packet) generation, encoding and / or decoding of smart contract address information, computation involved in validating the transaction proof, etc. For example, a library can handle Merkle-Patricia tree validation. Asanother example, a library can be a zero-nonce proof library. User applications 212A and 212B can specify any version of a validation library to enable data item transmission for a particular use case. System 200 can provide the ability to swap new validation libraries to achieve particular implementations of the communication protocol. For example, user applications 212A and 212B can specify any version of a validation library to enable data item transmission for a particular use case. In some implementations, the validation library is selected based on risk tolerance. Further details regarding validation libraries will be described below with reference to FIG. 2B.[000105] As another example, set of communication protocol settings 211 A and set of communication protocol settings 21 IB can further include a selection of a set of off-chain entities to facilitate data transfer between blockchain 210A and blockchain 210B based on the selected validation library (e.g., as defined by the selected validation library). For example, the selected validation library can indicate the set of off-chain entities. A set of off-chain entities can include at least two entities that are guaranteed not to collude to enable communication of a data item without the use of any intermediary chains, intermediary or wrapped tokens, etc. As shown, the set of off-chain entities includes trust entity 220, trust entity 230 and set of executors 240. In some implementations, the trust entity 220 and trust entity 230 are selected based on risk tolerance. More specifically, trust entity 220 and trust entity 230 are guaranteed not to collude, in order to enable communication of data between blockchain 210A and blockchain 210B without any intermediary chains, wrapped tokens, etc. Set of communication protocol settings 211 A and set of communication protocol settings 21 IB can be the same to implement the communication protocol between blockchain 210A and blockchain 210B (e.g., the same library). To ensure valid delivery of a data item (e.g., message) sent from blockchain 210A to blockchain 210B using the communication protocol, there must not be any collusion between trust entity 220 and trust entity 230. To prevent collusion between trust entity 220 and trust entity 230, trust entity 220 and trust entity 230 can be independent entities. For example, at least one of trust entity 220 or trust entity 230 can be a third-party entity that is not affiliated with the platform. Further details regarding executors and trust entities will be described below with reference to FIG. 2B.[000106] Endpoint 214A and endpoint 214B can initialize a communication protocol to communicate a data item during a cross-chain transaction. In some implementations, initializing the communication protocol includes configuring set of communication protocol settings 211 A and set of communication protocol settings 21 IB, respectively. In some implementations, configuring set of communication protocol settings 211A and set ofcommunication protocol setings 21 IB includes endpoint 214A receiving a customized setings configuration from user application 212A and endpoint 214B receiving the customized setings configuration from user 212B, and endpoint 214A and endpoint 214B configuring set of communication protocol settings 211 A and set of communication protocol settings 21 IB, respectively, in accordance with the customized settings configuration. In some implementations, configuring set of communication protocol setings 211 A and set of communication protocol setings 21 IB includes endpoint 214A and endpoint 214B each configuring set of communication protocol settings 211 A and set of communication protocol settings 21 IB, respectively, in accordance with a default configuration provided by the platform. For example, this can happen if user application 212A and user application 212B select the default configuration, or if endpoint 214A and endpoint 214B do not receive a customized setings configuration from user application 212A and user application 212B, respectively. Accordingly, during initialization of the communication protocol, a set of communication protocol setings can be selected from a range of communication protocol settings with different sets of characteristics depending on the user applications 212A and 212B.[000107] After the communication protocol is initialized, the data item to be sent in accordance with the set of communication protocol setings. To ensure valid delivery, a data item can be delivered if (e.g., if and only if) the transaction is determined to be valid (e.g., valid and committed). The set of communication protocol setings can be used to ensure that the transaction is valid. A description of the steps involved in the valid delivery of a data item using system 200 will now be described.[000108] In this illustrative example, trust entity 220 is a transaction proof entity and that trust entity 230 is a block header entity. A transaction proof entity is a service that provides a mechanism to independently produce a transaction proof for a specified transaction. In some implementations, a transaction proof entity is a third-party service. In some implementations, a transaction proof entity is provided by the platform itself. A block header entity is a service that provides a mechanism to produce a block header from one blockchain and send the block header to another blockchain. The block header is a component of the current block that includes information about the current block (i.e., block metadata). For example, the block header can include at least one of: a timestamp, a digest of the current block (e.g., hash of the current block), a digest of the header of the previous block (e.g., hash of the header of the previous block), a cryptographic nonce value, a Merkle tree root, etc. In some implementations, a block header entity is a third-party service not affiliated with the platform.However, such an example should not be considered limiting. User application 212A can execute a series of actions as part of a transaction T uniquely identified by transaction identifier t. The format of transaction identifier t can vary depending on the type of blockchain 210A. A step included in transaction T is the transmission of a data item over the communication protocol with a valid delivery condition on transaction T.[000109] More particularly, at step 1, user application 212A can send a request including a set of parameters to communicator component 213 A. In some implementations, the set of parameters includes transaction identifier t, a global identifier pointing to a smart contract on blockchain 210B (“dsf ’), and a user payload (e.g., any data that user application 212A wants to send to user application 212B). In some implementations, the set of parameters include a set of transaction proof entity arguments. The set of transaction proof entity arguments can include information (e.g., payment information) in the event that user application 212A wishes to use a reference transaction proof entity.[000110] At step 2, communicator component 213A generates a data item, and sends the data item along with auxiliary information to validator component 215A. In some implementations, the data item is a message. For example, the data item can be a packet. In some implementations, the data item generated by communicator component 213A includes dst and the user payload. For example, the data item generated by communicator component 213 can be represented as a packet Packet(dst, user payload). In some implementations, the auxiliary information includes transaction identifier t and the set of transaction proof entity arguments.[000111] At step 3, validator component 215A notifies network component 217A that the block header for the current block on blockchain 210A needs to be sent to blockchain 210B. For example, validator component 215A can send transaction identifier t and dst to network component 217A, and the receipt of transaction identifier t and dst is what notifies network component 217 A that the block header for the current block on blockchain 210A needs to be sent to blockchain 21 OB.[000112] At step 4, validator component 215 A notifies transaction proof entity 220 that the transaction proof for transaction T needs to be retrieved (e.g., fetched) and sent to blockchain 210B. For example, validator component 215A can forward the data item and the auxiliary information to transaction proof entity 220, and the receipt of the data item and the auxiliary information is what notifies transaction proof entity 220 that the transaction proof for transaction T needs to be retrieved and sent to blockchain 210B.[000113] At step 5, network component 217A notifies block header entity 230 to retrieve (e.g., fetch) the block header for the current block on blockchain 210A and send the block header to blockchain 210B. For example, network component 217A can sends dst and a block identifier (ID) of the current transaction to block header entity 230, and the receipt of dst and the block ID is what notifies block header entity 230 to retrieve the block header for the current block on blockchain 210A and send the block header to blockchain 210B.[000114] At step 6, block header entity 230 reads the block header of the current block from blockchain 210A. At step 7, transaction proof entity 220 reads the transaction proof associated with transaction T (proof(t)) from blockchain 210A. Transaction proof entity 220 can further store proof(t) off-chain. In some implementations, step 6 and step 7 are performed asynchronously.[000115] At step 8, block header entity 230 confirms that the current block of blockchain 210A is stably committed on blockchain 210A. The mechanism for confirming that the current block of blockchain 210A is stably committed on blockchain 210A varies per blockchain. In some implementations, confirming that the current block of blockchain 210A is stably committed on blockchain 210A includes determining that a number of block confirmations satisfies a threshold condition. For example, determining that a number of block confirmations satisfies a threshold condition can include determining that the number of block confirmations is greater than or equal to a threshold number of block confirmations. In some implementations, the threshold number of block confirmations is 15. After confirming that the current block of blockchain 210A is stably committed on blockchain 210A (e.g., determining that the number of block confirmations satisfies a threshold condition), block header entity 230 sends the blocker header to network component 217B. [000116] At step 9, network component 217B sends a digest of the block header to validator component 215B. For example, the digest of the block header can be a hash of the block header. At step 10, validator component 215B sends the digest of the block header to transaction proof entity 220.[000117] At step 11, upon receiving the digest of the block header, transaction proof entity 220 sends, to validator component 215B, a list of tuples that match the current block of blockchain 210A. More specifically, the list of tuples can be a list of any data item, transaction identifier t, proof(t) tuples that match the current block of blockchain 210A. In the event that multiple users simultaneously send data items between endpoints 214A and 214B, there may be multiple data items and associated transaction proofs within the same block.[000118] At step 12, validator component 215B determines whether transaction T is valid. In some implementations, determining whether transaction T is valid includes determining whether transaction T is valid and committed. For example, validator component 217 can determine whether transaction T is valid by determining whether the received transaction proof matches the block header stored by network component 217B (i.e., the transaction proof and the block header are determined to be in agreement). If the received transaction proof and the block header do not match, then transaction T is determined to be invalid and / or uncommitted and the data item is discarded.[000119] Otherwise, the data item (e.g., Packet(dst, user payload)) is sent to communicator component 213B. Since the transaction process matches the block header, the data item is sent with the guarantee that the transaction is stably committed on blockchain 210A. Then, at step 13, communicator component 213B sends the data item to user application 212B. Accordingly, due to the lack of collusion between the set of off-chain entities, the communication protocol can guarantee that a transaction with respect to blockchain 21 OB will be paired with a valid, committed transaction with respect to blockchain 21 OA without involving any indirect methods (e.g., intermediary chains and / or wrapped tokens).[000120] Executing smart contracts on blockchains (e.g., layer 1 blockchains) can be cost prohibitive, especially as the amount of stored data increases. To solve this problem, the task of retrieving transaction proofs is delegated transaction proof entity 220 and the task of retrieving block headers is delegated to block header entity 230. Transaction proof entity 220 and block header entity 230 are off-chain entities that do not collude. This results in endpoint 214A and endpoint 214B being lightweight and cost effective, even on expensive blockchains. An example of a packet that can be used to implement the communication protocol will now be described in detail below with reference to FIG. 3.[000121] Referring to FIG. 2B, system 200 can include a set of layers to support the sending and / or receiving of a data item in accordance with the communication protocol. For example, validation library 250 handles cybersecurity operations. To do so, validation library 250 can include set of validation libraries 252 to handle validating a data item to be sent by blockchain 210A, sending the data item to execution layer 260 and / or trust layer 270, validating the data item at blockchain 210B and / or transmitting the data item to blockchain 210B.[000122] Each validation library of set of validation libraries 252 can implement a data item validation mechanism having an associated trust characteristic and / or cost characteristic. For example, each validation library of set of validation libraries 252 can implement a data itemvalidation mechanism that conforms to an application programming interface (API) of the platform to establish a connection to an endpoint. This can allow the communication protocol to avoid the trap of validation lock-in. In some implementations, validation library 250 is append-only. In some implementations, set of validation libraries 252 is an append-only registry of validation libraries. In some implementations, each validation library of set of validation libraries 252 is immutable. Set of validation libraries 252 can include one or more validation libraries that can handle message (e.g., packet) generation, encoding and / or decoding of smart contract address information, computation involved in validating the transaction proof, etc. For example, a validation library can handle Merkle-Patricia tree validation. As another example, a validation library can handle zero-nonce proof validation. Each validation library of set of validation libraries 252 can be identifiable through a unique validation library identifier (ID). In some implementations, the validation library ID is paired with a version (e.g., semantic version) of the validation library.[000123] A validation library can be selected from set of validation libraries 252 to handle transmission of a data item (e.g., message) by blockchain 210A and / or receipt of the data item by blockchain 210B. For example, user application 212A and user application 212B can configure a validation library via endpoint 214A and endpoint 214B, respectively, as part of a set of configuration settings. The selection of the validation library can be based on a trust characteristic and / or a cost characteristic (e.g., based on much must trust and / or cost user application 212A and / or user application 212B is willing to tolerate for sending / receiving the data item). A data item can only be sent from blockchain 210A to blockchain 21 OB if blockchain 210A and the blockchain 210B each are configured with the same validation library (e.g., the same version of the same library). In some implementations, a validation library is accessed directly on-chain by address. User application 212A and user application 21B can each swap out a currently selected validation library for a new validation library.[000124] Execution layer 260 can include set of executors 262 including one or more executors that can be used to implement one or more non-validation tasks. A non-validation task refers to any task that does not directly pertain to validation. Set of executors 262 can minimize responsibilities of validation library 250 (e.g., responsibilities of set of validation libraries 252) by enabling the separation of non-validation tasks from validation tasks. The separation of non-validation tasks from validation tasks enables improved flexibility without compromising security. Set of executors 262 can be implemented and / or deployed by any entity, and can perform any non-validation task so long as the non-validation task does not interfere with a validation task that is implemented by a validation library. In someimplementations, set of executors 262 includes multiple executors that each implement one or more respective non-validation task. The operation and implementation of set of executors 262 can be democratized, allowing any entity to execute its own executor of set of executors 262, and by extension allowing any user application to add custom logic to be executed as part of the data item transaction. In some implementations, set of executors 262 implement a security mechanism to detect a malicious data item originating from blockchain 21 OA by inspecting data originating from blockchain 210A, filter the malicious data item and / or block the malicious data item from being sent to blockchain 21 OB. The security mechanism can be used to increase defense against potential security vulnerabilities (e.g., exploits) due to, e.g., protocol-level exploits and / or application-level exploits (e.g., due to a bug in an applicationlevel smart contract).[000125] Trust layer 270 can include trust entity 272-1 through trust entity 272-N. A set of trust entities can be selected among trust entity 272-1 through trust entity 272-N to handle transmission of a data item from blockchain 210A to blockchain 21 OB in accordance with a communication protocol. The set of trust entities and the executor(s) of set of executors 262 can collectively form a set of off-chain entities. For example, a user application can configure the set of off-chain entities via an endpoint as part of a set of configuration settings. The selection of the set of off-chain entities, such as the set of trust entities, can be based on a trust characteristic and / or a cost characteristic (e.g., based on much must trust and / or cost user application 212A and / or user application 212B is willing to tolerate for sending / receiving the data item). To ensure valid delivery of a data item sent from blockchain 210A to blockchain 210B using the communication protocol, there must not be any collusion between trust entities. To prevent collusion between trust entities, each trust entity of the set of trust entities can be an independent trust entity. For example, at least one trust entity of the set of trust entities can be a third-party entity that is not affiliated with the platform.[000126] A high-level description of the operation of system 200 will now be described. User application 212A can send a set of parameters for transmission of a data item to endpoint 214A. In some implementations, the data item is a message. For example, the data item can be a packet. In some implementations, sending the set of parameters includes generating a request by encoding the set of parameters into the request, and sending the request to endpoint 212A.[000127] In some implementations, the set of parameters includes a user payload and a set of auxiliary parameters. The user payload can include any data that user application 212A wants to send to user application 212B via the data item (e.g., message). The set of auxiliaryparameters can include at least one of: a validation library, a version of the validation library, a nonce value, a source blockchain ID of blockchain 21 OA, a source blockchain address of blockchain 210A, an address of user application 212A, a destination blockchain ID of blockchain 210B, a destination blockchain address of blockchain 210B, an address of user application 212B, an address of each off-chain entity that is being selected, a message offset, a set of executor arguments, etc. The set of executor arguments can specify which executor(s) of set of executors 262 to invoke and the arguments to pass during the invocation of the executor(s).[000128] Upon receiving the set of parameters from user application 212A, endpoint 214A can forward the set of parameters to validation library 250. Validation library 250 can select, based on the set of parameters, a validation library from set of validation libraries 252 to handle transmission of the data item. The validation library can then generate a data item based on the set of parameters. In some implementations, the validation library emits a data item that encodes parameters for the set of off-chain entities identified from the set of parameters (e.g., executor(s) of set of executors 262 and off-chain entities selected from trust entity 272-1 through 272-N).[000129] The validation library can send the data item to the set of off-chain entities identified from the set of parameters. The set of off-chain entities can cause the data item to be sent to blockchain 210B for validation using the corresponding validation library. Upon successful validation, the data item can be sent to endpoint 214B. Endpoint 214B can order data items received from the validation library located blockchain 210B, buffer data items that are received out-of-order, etc. The endpoint 214B can send, to user application 212B, the data item from the endpoint located on the destination blockchain. Additionally, set of executors 262 can execute any relevant actions based on the set of parameters, and send corresponding executor data items (e.g., executor messages) to user application 212B.[000130] FIG. 3 is a diagram of an example layout of an endpoint message 300, in accordance with some implementations. For example, endpoint message 300 can be a packet. The format of endpoint message 300 can vary depending on the source blockchain (e.g., blockchain 210A of FIG. 2) and the destination blockchain (e.g., blockchain 210B of FIG. 2). As shown, endpoint message 300 can include routing information 310, and user payload 320 including user argument 322 sent by a user application (e.g., user application 212A of FIG. 2). In some implementations, routing information 310 includes blockchain ID 312 and address 314. Blockchain ID 312 is a unique identifier for a blockchain in the communicationprotocol system. Address 314 is an address of the recipient smart contract on the destination blockchain. For example, address 314 can have a size of 20 bytes.[000131] A communication protocol described above with reference to FIGS. 1A-3 can be used to implement a cross-chain bridge that deals exclusively in native digital assets.Contrary to some bridge designs that issue wrapped tokens or go through intermediary sidechains, a bridge built using a communication protocol described herein to send data items between blockchains can have liquidity pools exist on both blockchains. A user can simply deposit a native digital asset in one liquidity pool and withdraw a native digital asset from another liquidity pool. The communication protocol can enable direct bridges (e.g., 1: 1 pricing), automated market making (e.g., ab = k pricing), etc. The guarantee of valid delivery that the communication protocol provides can enable a wide range of cross-chain applications.[000132] For example, a communication protocol described above with reference to FIGS. 1A-3 can be used to implement a multi-chain yield aggregator. Yield aggregators typically operate within the confines of single-chain ecosystems. One key weakness of these single chain yield aggregation systems is that they cannot take advantage of any yield opportunities outside of their current ecosystem, potentially missing out on many of the best yields. Implementing a multi-chain yield aggregator with the communication protocol described above can allow for strategies that tap into the best opportunities across all ecosystems, increasing access to high-yield opportunities and enabling users to take advantage of market inefficiencies. A multi-chain yield aggregator would be strictly better than a single-chain yield aggregator. For example, in the worst case, the strategy would degrade to taking advantage of opportunities on only one blockchain, and in the best case it would have exponentially more opportunities to choose from.[000133] As another example, a communication protocol described above with reference to FIGS. 1A-3 can be used to implement a multi-chain lending protocol. For example, the communication protocol can enable a lending protocol that would allow a user to keep an entire digital asset base in-place on one blockchain, lend out the digital asset base, and borrow directly from a different blockchain. This can eliminate intermediary costs such as bridge and swap fees.[000134] The ability to perform direct cross-chain transactions as described above with reference to FIGS. 1A-3 can enable the development and use of complex cross-chain or inter-chain applications without sacrificing trustlessness or introducing complex intermediary chains and / or smart contracts. Examples of such cross-chain applications include cross-chainbridges, multi-chain yield aggregators, and cross-chain lending protocols. For example, using a communication protocol described herein, users can freely move liquidity between blockchains, allowing for a single pool of liquidity to take part in multiple decentralized finance (DeFi) applications across different blockchains and ecosystems without having to go through third-party systems or intermediary tokens and / or chains.[000135] The configuration of the set of communication protocol settings, including the validation library and the set of off-chain entities, can be used to solve a variety of technical challenges. One technical challenge that can be solved is related to cybersecurity and trust in data item validation. A user application can require a level of trust for validating a data item that crosses through a set of off-chain entities. The level of trust can have an inherently reciprocal relation with the cost of validating the data item. For example, there may be a desire to pay a larger fee to minimize the level of trust required and, by extension the degree of risk, to transfer a large quantity of digital assets (e.g., tokens) from a source blockchain to a destination blockchain. To address this technical challenge, the set of communication protocol settings can enable trust-configurability for validating data items using the communication protocol. For example, the validation library and the set of off-chain can be selected to satisfy a trust characteristic and / or a cost characteristic for validating a data item being sent from a source blockchain to a destination blockchain for a user application.[000136] Another technical challenge that can be solved is extensibility. Generally, user applications should be updated to continue to meet ever-changing demands of users. It can be important to extend support to new blockchains that are added to the network, validation mechanisms, and messaging primitives. Moreover, the communication protocol should allow optimizations to existing code (e.g., debugging) in a manner that precludes the possibility of compromising the cost and / or performance of existing applications.[000137] To address extensibility, the modular design of the set of communication protocol settings including validation libraries can enable the communication protocol to be quickly and easily extended to include new blockchains of the network on demand. A validation library can be immutable when added to the set of validation libraries, which can be used to guarantee that user applications can use a given version of a given validation library without modifying and / or deprecating the underlying code. Moreover, an executor can be used to implement any non-validation tasks (e.g., a task that does not directly pertain to validation). For example, any non-validation task can be factored out of the validation library and handled by the executor, allowing for rapid development and deployment of features without going through rigorous auditing that may be required to introduce a new version of avalidation library. The executor can be implemented and / or deployed by any entity, and can perform any non-validation task so long as the non-validation task does not interfere with a validation task that is implemented by the validation library. Accordingly, the set of validation libraries can provide a high degree of freedom in adding and / or upgrade features, and the executor can be leveraged to minimize validation library responsibilities.[000138] Yet another technical challenge that can be solved is cybersecurity against protocol-level vulnerabilities and application-level vulnerabilities. A common theme in the blockchain ecosystem is that the security or trustworthiness of a smart contract is directly related to how long it has been in-use without being compromised. As such, it can be important for existing, well-established code to remain usable in an unmodified state indefinitely. In-place modification of existing code during updates can result in a loss of cybersecurity, which can be unacceptable for some user applications. To balance the need for backwards compatibility with the need to continually update and improve code, implementations described herein can enable validation libraries to be added or updated while also enabling user selection between a new improved validation library, or an older, well- established validation library. A validation library described herein can be append-only to protect user applications and / or associated users from silent modifications to the validation library. This append-only design of disallowing in-place updates for validation libraries is atypical of other communication protocols that support cross-chain data item transfers and, coupled with the application-specific validation library configuration, can enable improved cross-chain data transfer security. Moreover, the endpoints described herein can be immutable to prevent any entity, including the platform supporting the endpoints, from bypassing data item validation using validation libraries. While it may be theoretically possible for a user application to configure a malicious validation library, existing user applications that have already configured a specific validation library will be left unaffected by the malicious validation library. In addition, on-chain configuration changes can undergo a peer-review process and test period before they are deployed, reducing the likelihood that a user application can configure a malicious validation library in the first place. By allowing a high degree of configurability and democratizing the operation of the off-chain infrastructure, a platform described herein can provide improved cybersecurity and communicationprotocol-level configurability. In addition, users can execute their own off-chain entities for relaying data items to connect to existing validation libraries to further control the required level of trust for respective user applications. Further, a platform described herein canprovide an off-chain security mechanism to protect against application-level security vulnerabilities.[000139] FIG. 4 depicts a flow diagram of an example method 400 for implementing an omnichain interoperability protocol platform, in accordance with some implementations. For example, method 400 may be performed by endpoint 214A as shown in FIG. 2A. Method 400 may be performed by one or more processing devices that may comprise hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), executable code (such as is run on a general-purpose computer system or a dedicated machine), or a combination of both. For example, the one or more processing devices can perform individual functions, routines, subroutines, or operations to implement method 400.[000140] At operation 410, processing logic initiates a communication protocol for sending a data item from a source blockchain supported by a platform to a destination blockchain supported by the platform. For example, the data item can be sent from a source node maintaining the source blockchain to a destination node maintaining the destination blockchain. In some implementations, the data item is a message. For example, the data item can be a packet.[000141] Initializing the communication protocol can include configuring a set of communication protocol settings. In some implementations, the set of communication protocol settings includes a validation library selected from a set of validation libraries. For example, the set of validation libraries can include one or more validation libraries that are swappable (e.g., the validation library can be replaced with a new validation library). In some implementations, the set of communication protocol settings includes a set of off-chain entities selected to facilitate the sending of the data item. The set of off-chain entities can be selected in accordance with the validation library. For example, the set of off-chain entities can include a set of trust entities. A first trust entity of the set of trust entities does not collude with a second trust entity of the set of trust entities. The source blockchain and the destination blockchain are configured with at least some of the same set of communication protocol settings (e.g., the same validation library).[000142] In some implementations, initializing the communication protocol includes, at operation 412, configuring a set of communication protocol settings in accordance with customized settings configuration. For example, configuring the set of communication protocol settings in accordance with the customized settings configuration can include receiving a customized settings configuration from a user application, and configuring the set of settings in accordance with the customized settings configuration received from the userapplication. The user application can be associated with source blockchain or the destination blockchain. The customized settings configuration can be received as part of a set of parameters associated with a data item to be transmitted from the source blockchain to the destination blockchain.[000143] In some implementations, initializing the communication protocol includes, at operation 414, configuring the set of communication protocol settings in accordance with a default settings configuration. The default settings configuration can be provided by the platform. For example, this can happen if the user applications select the default configuration (e.g., as part of the set of parameters received from the user applications), or if the endpoints do not receive a customized settings configuration from the user applications. [000144] In some implementations, initializing the communication protocol includes obtaining, from the user application, a set of parameters. In some implementations, obtaining the set of parameters includes receiving a request from the user application. In some implementations, obtaining the set of parameters includes receiving a request from an entity that is delegated the authority to send requests on behalf of the user application. For example, the request can be generated by encoding the set of parameters. In some implementations, the set of parameters includes a user payload and a set of auxiliary parameters. The user payload can include any data that the user application wants to send to the user application associated with the destination blockchain via the data item. The set of auxiliary parameters can include at least one of: a validation library, a version of the validation library, a nonce value, a source blockchain ID, a source blockchain address, an address of the user application, a destination blockchain ID, a destination blockchain address, an address of the user application associated with the destination blockchain, an address of each off-chain entity that is being selected, a message offset, a set of executor arguments, etc. The set of executor arguments can specify the set of executors and the arguments to pass during the invocation the set of executors.[000145] At operation 420, processing logic causes the data item to be sent from the source blockchain to the destination blockchain in accordance with the communication protocol. For example, causing the data item to be sent in accordance with the communication protocol can include causing the data item to be sent in accordance with the set of communication protocol settings including the validation library and the set of off-chain entities. The set of trust entities of the set of off-chain entities can enable valid delivery of the data item. The set of executors of the set of off-chain entities can implement non-validation tasks, which can enable separation of validation tasks implemented by the validation library from the nonvalidation tasks.[000146] In some implementations, causing the data item to be sent from the source blockchain to the destination blockchain includes causing the validation library to be selected from a set of validation libraries. For example, causing the validation library to be selected from the set of validation libraries can include forwarding the set of parameters to a validation library. The validation library can then generate the data item based on the set of parameters. In some implementations, the validation library emits a data item that encodes parameters for the set of off-chain entities identified from the set of parameters (e.g., set of executors and set of trust entities). The validation library can send the data item to the set of off-chain entities identified from the set of parameters. The set of trust entities can cause the data item to be sent to the corresponding validation library located on the destination blockchain. The validation library located on the destination blockchain can then attempt to validate the data item. Upon successful validation, the data item can be sent to the endpoint located on the destination blockchain. The endpoint located on the destination blockchain can order data items received from the validation library located on the destination blockchain, buffer data items that are received out-of-order, etc. The endpoint located on the destination blockchain can send, to the user application associated with the destination blockchain, the data item from the endpoint located on the destination blockchain. Additionally, the set of executors can execute any relevant actions based on the set of parameters, and send corresponding executor data items (e.g., executor messages) to the user application associated with the destination blockchain. Further details regarding operations 410-420 are described above with reference to FIGS. 2A-3.[000147] An illustrative example of a method for implementing an omnichain interoperability protocol platform (e.g., causing a message to be sent in accordance with the communication protocol) will now be described in further detail below with reference to FIGS. 5A-5D.[000148] FIG. 5A depicts a flow diagram of an example method 500A for implementing an omnichain interoperability protocol platform, in accordance with some implementations. For example, method 500A may be performed by endpoint 214A as shown in FIG. 2. Method 500A may be performed by one or more processing devices that may comprise hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), executable code (such as is run on a general-purpose computer system or a dedicated machine), or a combination of both. For example, the one or more processing devices can perform individual functions, routines, subroutines, or operations to implement method 500 A.[000149] At operation 510A, processing logic receives, from a first user application associated with a source blockchain, a request associated with a transaction. The source blockchain is maintained by a set of nodes of a first blockchain network. For example, the first user application can execute a series of actions as part of the transaction. The request can include a set of parameters.[000150] In some implementations, the set of parameters includes a transaction identifier corresponding to the transaction, a global identifier corresponding to a destination blockchain, and a user pay load. The format of the transaction identifier can vary depending on the source blockchain type. In some implementations, the global identifier is indicative of a smart contract on the destination blockchain. For example, the global identifier can point to the smart contract on the destination blockchain. The user payload can include any data that the user application wants to send to a second user application associated with the destination blockchain. In some implementations, the set of parameters further includes a set of transaction proof entity arguments. The set of transaction proof entity arguments can include information in the event that the first user application wishes to use a reference transaction proof entity.[000151] At operation 520A, processing logic obtains a packet and auxiliary information. For example, obtaining the packet and auxiliary information can include generating the packet in response to receiving the request, and sending the packet with the auxiliary information for validation. In some implementations, the packet includes the global identifier and the user payload. In some implementations, the auxiliary information includes the transaction identifier and the set of transaction proof entity arguments.[000152] At operation 530A, processing logic determines that a block header for a current block on the source blockchain is to be sent to a destination blockchain. The destination blockchain is different from the source blockchain and is maintained on a set of nodes of a second blockchain network different from the first blockchain network. For example, determining that the block header is to be sent to the destination blockchain can include receiving a notification that the block header needs to be sent to the destination blockchain. In some implementations, receiving the notification that the block header needs to be sent to the destination blockchain includes receiving the transaction identifier and the global identifier. For example, the transaction identifier and the global identifier can be validated prior to receiving the notification that the block header needs to be sent to the destination blockchain. [000153] At operation 540A, processing logic causes a set of entities to obtain a set of data including the block header and a transaction proof for the transaction. For example,processing logic can cause the set of entities to obtain the set of data in response to determining that the block header is to be sent to the destination blockchain. In some implementations, the set of entities includes a transaction proof entity and a block header entity.[000154] For example, causing the set of entities to obtain the set of data include the block header and the transaction proof can include notifying the transaction proof entity that the transaction proof needs to be retrieved (e.g., fetched) and sent to the destination blockchain. In some implementations, notifying the transaction proof entity that the transaction proof needs to be retrieved and sent to the destination blockchain includes sending the packet and the auxiliary information to the transaction proof entity, and the receipt of the packet and the auxiliary information is what notifies the transaction proof entity that the transaction proof needs to be retrieved and sent to the destination blockchain. Further details regarding the transaction proof entity are described above with reference to FIGS. 2A-2B and will be described below with reference to FIG. 5B.[000155] As another example, causing the set of entities to obtain the set of data include the block header and the transaction proof can include notifying the block header entity that the block header needs to be retrieved (e.g., fetched) and sent to the destination blockchain. In some implementations, notifying the block header entity that the block header needs to be retrieved and sent to the destination blockchain includes sending the global identifier and a block ID to the block header entity, and the receipt of the global identifier and the block ID is what notifies the block header entity that the block header needs to be retrieved and sent to the destination blockchain. Further details regarding the block header entity are described above with reference to FIGS. 2A-2B and will be described below with reference to FIG.5C[000156] As described above with reference to FIGS. 2A-2B and as will be described in further detail below with reference to FIG. 5D, an endpoint on the destination blockchain can receive the set of data including the block header and the transaction proof, and use the set of data to determine whether the transaction is valid. Upon determining that the transaction is valid, the endpoint on the destination blockchain can send the packet to the second user application. Further details regarding operations 510A-540A are described above with reference to FIGS. 2A-3 and will be described in further detail below with reference to FIGS. 5B-5D.[000157] FIG. 5B depicts a flow diagram of an example method 500B for implementing an omnichain interoperability protocol platform, in accordance with some implementations. Forexample, method 500B may be performed by transaction proof entity 220 as shown in FIG. 2A. Method 500B may be performed by one or more processing devices that may comprise hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), executable code (such as is run on a general-purpose computer system or a dedicated machine), or a combination of both. For example, the one or more processing devices can perform individual functions, routines, subroutines, or operations to implement method 500B. [000158] At operation 51 OB, processing logic receives, from a first endpoint located on a source blockchain, a notification to obtain a transaction proof for a transaction associated with the source blockchain. In some implementations, receiving the notification to obtain the transaction proof includes receiving a packet and auxiliary information. In some implementations, the packet includes a global identifier corresponding to a destination blockchain and a user payload. In some implementations, the global identifier is indicative of a smart contract on the destination blockchain. For example, the global identifier can point to the smart contract on the destination blockchain. In some implementations, the user payload includes data that a first user application associated with the source blockchain wants to send to a second user application associated with the destination blockchain. In some implementations, the auxiliary information includes a transaction identifier of the transaction and a set of transaction proof entity arguments.[000159] At operation 520B, processing logic obtains the transaction proof from the source blockchain. For example, the transaction proof can be obtained from the source blockchain in response to receiving the notification to obtain the transaction proof. In some implementations, obtaining the transaction proof from the source blockchain includes reading the transaction proof from the source blockchain. In some implementations, obtaining the transaction proof from the source blockchain further includes storing the transaction proof off-chain.[000160] At operation 530B, processing logic receives, from a second endpoint located on a destination blockchain, data associated with a block header of a current block of the source blockchain. In some implementations, the data associated with the block header is a digest of the block header. For example, the data associated with the block header can be a hash of the block header.[000161] At operation 540B, processing logic sends, to the second endpoint, a list of tuples that match the current block of the source blockchain. For example, the list of tuples can be sent to the second endpoint in response to receiving the data associated with the block header.More specifically, the list of tuples can be a list of any packet, transaction identifier, and transaction proof tuples that match the current block of the source blockchain.[000162] As described above with reference to FIGS. 2A-2B and as will be described in further detail below with reference to FIG. 5D, the second endpoint can determine whether the transaction is valid based on the list of tuples. In response to determining that the transaction is valid, the second endpoint can send the packet to the second user application. Further details regarding operations 510B-540B are described above with reference to FIGS. 2A-5A and will be described in further detail below with reference to FIGS. 5C-5D.[000163] FIG. 5C depicts a flow diagram of an example method 500C for implementing an omnichain interoperability protocol platform, in accordance with some implementations. For example, method 500C may be performed by block header entity 230 as shown in FIG. 2A. Method 500C may be performed by one or more processing devices that may comprise hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), executable code (such as is run on a general-purpose computer system or a dedicated machine), or a combination of both. For example, the one or more processing devices can perform individual functions, routines, subroutines, or operations to implement method 500C.[000164] At operation 510C, processing logic receives, from a first endpoint located on a source blockchain, a notification to obtain a block header of a current block of the source blockchain. In some implementations, receiving the notification to obtain the block header includes receiving a global identifier corresponding to a destination blockchain and a block ID of the transaction. In some implementations, the global identifier is indicative of a smart contract on the destination blockchain. For example, the global identifier can point to the smart contract on the destination blockchain.[000165] At operation 520C, processing logic obtains the block header from the source blockchain. For example, the block header can be obtained from the source blockchain in response to receiving the notification to obtain the block header. In some implementations, obtaining the block header from the source blockchain includes reading the block header from the source blockchain. In some implementations, obtaining the block header from the source blockchain further includes storing the block header off-chain.[000166] At operation 530C, processing logic determines whether the current block is stably committed on the source blockchain. The mechanism for determining whether the current block is stably committed on the source blockchain varies per blockchain. In some implementations, determining whether the current block is stably committed on the source blockchain includes determining whether a number of block confirmations satisfies athreshold condition. For example, determining whether a number of block confirmations satisfies a threshold condition can include determining that the number of block confirmations is greater than or equal to a threshold number of block confirmations. In some implementations, the threshold number of block confirmations is 15.[000167] In response to determining that the current block is stably committed on the source blockchain, at operation 540C, processing logic sends the block header to a second endpoint located on the destination blockchain.[000168] As described above with reference to FIGS. 2A-2B and 5B and as will be described in further detail below with reference to FIG. 5D, the second endpoint can then generate data associated with the block header (e.g., a digest of the block header), and send the data associated with the block header to a transaction proof entity. The second endpoint can then receive, from the transaction proof entity, a list of tuples that match the current block of the source blockchain. The second endpoint can determine whether the transaction is valid based on the list of tuples. In response to determining that the transaction is valid, the second endpoint can send a packet to a user application associated with the destination blockchain. In some implementations, the packet includes the global identifier and a user payload. In some implementations, the user payload includes data that a user application associated with the source blockchain wants to send to the user application associated with the destination blockchain. Further details regarding operations 510C-540C are described above with reference to FIGS. 2A-5B and will be described in further detail below with reference toFIG. 5D[000169] FIG. 5D depicts a flow diagram of an example method 500D for implementing an omnichain interoperability protocol platform, in accordance with some implementations. For example, method 500D may be performed by endpoint 214B as shown in FIG. 2A. Method 500D may be performed by one or more processing devices that may comprise hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), executable code (such as is run on a general-purpose computer system or a dedicated machine), or a combination of both. For example, the one or more processing devices can perform individual functions, routines, subroutines, or operations to implement method 500D.[000170] At operation 510D, processing logic receives, from a block header entity, a block header of a current block of a source blockchain corresponding to a transaction. For example, as described above with reference to FIGS. 2 and 5C, the block header entity can obtain the block header from the source blockchain (e.g., read the block header from the source blockchain).[000171] At operation 520D, processing logic sends data associated with the block header to a transaction proof entity. To ensure valid delivery, it is assumed that the block header entity and the transaction proof entity are off-chain entities that do not collude. In some implementations, sending the data associated with the block header to the transaction proof entity includes generating the data associated with the block header in response to receiving the block header. In some implementations, the data associated with the block header includes a digest of the block header. For example, the data associated with the block header can include a hash of the block header.[000172] At operation 530D, processing logic receives, from the transaction proof entity, a list of tuples that match the current block. For example, the list of tuples can be sent by the transaction proof entity in response to receiving the data associated with the block header. In some implementations, the list of tuples includes at least one tuple of a packet, a transaction identifier corresponding to the transaction, and a transaction proof of the transaction, that matches the current block. In some implementations, a packet of a tuple is a packet including a global identifier corresponding to a destination blockchain and a user payload. In some implementations, the global identifier is indicative of a smart contract on the destination blockchain. For example, the global identifier can point to the smart contract on the destination blockchain. In some implementations, the user payload includes data that a user application associated with the source blockchain wants to send to the user application associated with the destination blockchain.[000173] In some implementations, the list of tuples includes zero tuples of a packet, a transaction identifier corresponding to the transaction, and a transaction proof of the transaction, that matches the current block. In this case, the transaction cannot be validated and the process would end.[000174] At operation 540D, processing logic determines whether the transaction is valid based on the list of tuples. In some implementations, determining whether the transaction is valid includes determining whether the transaction is valid and committed. In some implementations, determining whether the transaction is valid includes determining whether the block header and the transaction proof match. In response to determining that the transaction is invalid (e.g., in response to determining that the block header and the transaction proof do not match), the process terminates.[000175] In response to determining that the transaction is valid (e.g., in response to determining that the block header and the transaction proof match), at operation 550D, processing logic sends a packet to a user application associated with the destinationblockchain. In some implementations, the packet includes the global identifier and the user payload. Further details regarding operations 510D-550D are described above with reference to FIGS. 2A-5C.[000176] FIG. 6A depicts a flow diagram of an example method 600A implementing a mint function, in accordance with some implementations. For example, method 600A may be performed by vault 103 as shown in FIG. 1A. Method 600A may be performed by one or more processing devices that may comprise hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), executable code (such as is run on a general-purpose computer system or a dedicated machine), or a combination of both. For example, the one or more processing devices can perform individual functions, routines, subroutines, or operations to implement method 600 A.[000177] At operation 610A, processing logic receives, from a token issuer, a mint request to mint a set of tokens having an attribution property indicative of the token issuer and, at operation 620 A, processing logic executes the mint request to mint the set of tokens. Executing the mint request can include sending the set of tokens to the token issuer (e.g., updating a token balance of the token issuer maintained by a token contract of a blockchain linked to a digital wallet of the token issuer). For example, the mint request can define a number of tokens having the attribution property issuer, and mint the number of tokens defined by the mint request using the mint function in response to receiving the mint request. The token issuer can be required to provide minting collateral for the minting in order to execute the mint request. Further details regarding operations 610A-620A are described above with reference to FIG. 1A.[000178] FIG. 6B depicts a flow diagram of an example method 600B for implementing a redemption function, in accordance with some implementations. For example, method 600B may be performed by vault 103 as shown in FIG. 1A. Method 600B may be performed by one or more processing devices that may comprise hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), executable code (such as is run on a general-purpose computer system or a dedicated machine), or a combination of both. For example, the one or more processing devices can perform individual functions, routines, subroutines, or operations to implement method 600B.[000179] At operation 610B, processing logic receives a redemption request to redeem a set of tokens having an attribution property indicative of a token issuer and, at operation 620B, processing logic redeems the set of tokens. For example, a redemption request can be received from a user account associated with a source blockchain to redeem a set of tokens inpossession of the user account. Upon redemption of a token, the token is removed from circulation. Additionally, a token contract of the blockchain can be updated to reflect the removal of the token from circulation. Further details regarding operations 610B-620B are described above with reference to FIG. 1A.[000180] FIG. 6C depicts a flow diagram of an example method 600C to implement a transfer function, in accordance with some implementations. For example, method 600C may be performed by platform 130 as shown in FIG. IB. Method 600C may be performed by one or more processing devices that may comprise hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), executable code (such as is run on a general-purpose computer system or a dedicated machine), or a combination of both. For example, the one or more processing devices can perform individual functions, routines, subroutines, or operations to implement method 600C.[000181] At operation 610C, processing logic receives from a source user account associated with a source digital wallet of a source blockchain of a plurality of blockchains, a request to perform a cross-chain operation from the source blockchain to a destination blockchain of the plurality of local blockchains. The source blockchain can be associated with a source token contract. The attribution property of a token identifies a token issuer that minted the token. The vault stores a total number of tokens having the attribution property in circulation across the plurality of local blockchains. In some implementations, the token contract includes a smart contract. In some implementations, the vault includes a smart contract.[000182] At operation 620C, processing logic causes a cross-chain message including a transaction payload to be generated and, at operation 630C, processing logic causes the transaction payload to be applied to the destination blockchain.[000183] In some implementations, the source token contract further stores a source token balance of tokens, of the source digital wallet, having the attribution property within the source digital wallet. In some implementations, the cross-chain operation is a cross-chain transfer operation to transfer, from the source token balance to a destination digital wallet of the destination blockchain, a transfer amount of tokens having the attribution property. In some implementations, causing the cross-chain message to be generated further includes debiting, from the token balance of the source digital wallet, the transfer amount of tokens having the attribution property to obtain a debited amount of tokens, and adding the debited amount of tokens to the transaction pay load. In some implementations, causing the transaction payload to be applied to the destination blockchain further includes crediting thedebited amount of tokens to a destination token balance maintained by a destination token contract of the destination blockchain.[000184] In some implementations, the destination digital wallet is associated with a second attribution property different from the attribution property. In some implementations, the method further includes causing reattribution of: each token having the attribution property to the second attribution property, or each token having the second attribution property to the first attribution property.[000185] In some implementations, the space complexity to perform the cross-chain operation is sublinear with respect to a total number of token issuers. In some implementations, the space complexity to perform the cross-chain operation is constant with respect to a total number of token issuers. Further details regarding operations 610C-630C are described above with reference to FIGS. 1A-6B.[000186] FIG. 6D depicts a flow diagram of an example method 600D to implement an attribution layer of a blockchain system, in accordance with some implementations. For example, method 600D may be performed by one or more components of system 100 as shown in FIGS. 1A-1F. Method 600D may be performed by one or more processing devices that may comprise hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), executable code (such as is run on a general-purpose computer system or a dedicated machine), or a combination of both. For example, the one or more processing devices can perform individual functions, routines, subroutines, or operations to implement method 600D. [000187] At operation 610D, processing logic maintains, on at least one blockchain, a set of age data items associated with token circulation within the at least one blockchain. The set of age data items can include an age data item reflecting an age of an attribution property for a token assigned to a token issuer. The age of the attribution property can be determined based on an amount of time that a quantity of tokens having the attribution property have been in circulation within the at least one blockchain. The at least one blockchain can be included in a blockchain system including a primary blockchain and one or more secondary blockchains.[000188] At operation 620D, processing logic detects one or more age update events to update the set of age data items. At operation 630D, processing logic causes the set of age data items to be updated. For example, the set of age data items can be updated in response to detecting the one or more age update events.[000189] In some implementations, an age update event is a token transaction. Examples of token transactions that are age update events include token reattribution, token transfer, token minting, and token burning. In some implementations, an age update event is an explicit ageupdate request received from an entity. Examples of entities include a user, a token issuer (e.g., minter), an administrator of the blockchain system, etc.[000190] In some implementations, an age update event is yield distribution to distribute yield to respective token issuers across one or more local blockchains of the blockchain system. Yield distribution can be performed on epoch granularity, such that yield is distributed to token issuers at each epoch. An epoch can occur at a regular (e.g., fixed) interval of time set by the blockchain system. There are various ways to manage yield distribution at each epoch utilizing token attribution ages. In some implementations, yield distribution is managed by an on-chain entity. For example, at least one vault can centrally manage yield distribution by distributing, at each epoch, a respective token issuer yield share of a total amount of yield for the epoch to each token issuer (e.g., a digital wallet of a token issuer). As another example, at least one vault can distribute, at each epoch, a respective local blockchain yield share of a total amount of yield for the epoch to at least one local blockchain, and the at least one local blockchain can locally manage distribution of its respective local blockchain yield share to respective token issuers. In some implementations, yield distribution is managed by an off-chain entity. For example, at least one vault can send a total amount of yield for an epoch to an off-chain entity, and the off-chain entity can distribute, to each token issuer, a respective token issuer yield share of the total amount of yield for the epoch. In some implementations, yield distribution is managed by a combination of the at least one vault, the at least one local blockchain, and / or the off-chain entity.[000191] In some implementations, an age update event is an explicit age update request, which is a request received from a computing device to trigger the age update (e.g., without having to perform a token transaction or yield distribution). An explicit age update request can be made by an entity of system 100, such as a user, token issuer (e.g., minter), administrator, etc.[000192] The set of age data can include at least one age of at least one attribution property. An age of attribution property is defined as the product of the circulation of tokens having the attribution property within the local blockchain, and an elapsed amount of time. The age of a given attribution property C is Agee, and the sum of ages across all attribution properties is Ages. For example, Agee and Ages can each be determined with respect to a local blockchain of the blockchain system. As another example, Agee and Ages can each be determined across all local blockchains of the blockchain system (e.g., global ages). Age can be tracked for each attribution property in the blockchain system, and for the total circulation of tokens within a local blockchain of the blockchain system.[000193] At operation 640D, processing logic uses the set of age data items to perform yield distribution to distribute yield to at least the token issuer. Further details regarding operations 610D-640D are described above with reference to FIGS. 1A-1F and will now be described below with reference to FIGS. 6E-8.[000194] FIG. 6E depicts a flow diagram of an example method 600E to implement centrally managed on-chain yield distribution, in accordance with some implementations. For example, method 600E may be performed by vault 101 as shown in FIG. ID. Method 600E may be performed by one or more processing devices that may comprise hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), executable code (such as is run on a general-purpose computer system or a dedicated machine), or a combination of both. For example, the one or more processing devices can perform individual functions, routines, subroutines, or operations to implement method 600E.[000195] At operation 610E, processing logic identifies an epoch to initiate yield distribution to at least one token issuer of a blockchain system. An epoch can occur at a regular (e.g., fixed) interval of time set by the blockchain system (e.g. logical clock or wall clock).[000196] At operation 620E, processing logic receives, from at least one blockchain of the blockchain system, at least one set of age data items for the epoch associated with token circulation within the at least one blockchain. In some implementations, a set of age data items received from a blockchain includes the individual age of each attribution property on the blockchain (e.g. Agee for attribution property C), and a sum of the ages of all attribution properties (Ages) for the blockchain. In some implementations, a set of age data items received from a blockchain includes the individual age of each attribution property on the blockchain (e.g., Agee), and processing logic determines Ages for the blockchain using the age of each attribution property on the blockchain (e.g., Agee). In some implementations, a blockchain is a primary blockchain. In some implementations, a blockchain is a secondary blockchain.[000197] At operation 630E, processing logic determines, based on each set of age data items, at least one epoch yield share to be distributed to the at least one token issuer. An epoch yield share for a token issuer corresponds to the age of the attribution property assigned to the token issuer (e.g., Agee). An epoch yield share for a token issuer can be determined as a proportional share of a total epoch yield for the blockchain system.[000198] In some implementations, an epoch yield share for a token issuer is a local epoch yield share for an attribution property assigned to the token issuer with respect to a givenblockchain of the blockchain system. For example, the local epoch yield share can be a proportional share of the total epoch yield for the blockchain system determined based on the age of the attribution property assigned to the token issuer (e.g., Agee) for the given blockchain relative to the sum of the ages of all attribution properties (e.g., Ages) for the given blockchain. In some implementations, the local epoch yield share for a token issuer with respect to a given blockchain is determined as the total epoch yield for the blockchain system multiplied by the ratio of the age of the attribution property assigned to the token issuer (e.g., Agee) for the given blockchain, to the sum of the ages of all attribution properties (e.g., Ages) for the given blockchain.[000199] In some implementations, an epoch yield share for a token issuer is a global epoch yield share for an attribution property assigned to the token issuer across all blockchains of the blockchain system. For example, the global epoch yield share can be a proportional share of a total epoch yield for the blockchain system determined based on the sum of the ages of the attribution property assigned to the token issuer (e.g., Agee) across all blockchains relative to the sum of the ages of all attribution properties (e.g., Ages) across all blockchains. In some implementations, the global epoch yield share for a token issuer can be determined as the total epoch yield for the blockchain system multiplied by the ratio of the sum of the ages of the attribution property assigned to the token issuer (e.g., Agee) across all blockchains of the blockchain system, to the sum of the ages of all attribution properties (e.g., Ages) across all blockchains of the blockchain system.[000200] At operation 640E, processing logic causes the at least one epoch yield share to be distributed to the at least one token issuer. For example, causing an epoch yield share to be distributed to a token issuer can include causing the epoch yield share to be sent to an account (e.g., digital wallet) owned by the token issuer. Further details regarding operations 610E- 640E are described above with reference to FIG. ID.[000201] FIG. 6F depicts a flow diagram of an example method 600F to implement locally managed on-chain yield distribution, in accordance with some implementations. For example, method 600F may be performed by local blockchain 145-1 and / or local blockchain 145-2 as shown in FIG. IE. Method 600F may be performed by one or more processing devices that may comprise hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), executable code (such as is run on a general-purpose computer system or a dedicated machine), or a combination of both. For example, the one or more processing devices can perform individual functions, routines, subroutines, or operations to implement method 600E.[000202] At operation 61 OF, processing logic receives an epoch yield share allocated to a blockchain of a blockchain system. In some implementations, the blockchain is a primary blockchain. In some implementations, the blockchain is a secondary blockchain. In some implementations, a vault of the blockchain system determines the epoch yield share allocated to the blockchain, and sends, to the blockchain, the epoch yield share allocated to the blockchain. The vault can be included in a primary chain or a secondary chain. For example, the epoch yield share can be sent to a token contract of the blockchain. The vault can send the epoch yield share allocated to the blockchain in response to identifying an epoch to initiate yield distribution to at least one token issuer of the blockchain system (e.g., similar to operation 610E of FIG. 6E). Further details regarding the operations performed by the vault to determine the epoch yield share allocated to the blockchain are described above with reference to FIG. IE.[000203] At operation 620F, processing logic causes the epoch yield share allocated for the blockchain to be distributed to at least one token issuer. This distribution or a subset of it can be permissionless and initiated by any party. For example, causing the epoch yield share allocated for the blockchain to be distributed to the at least one token issuer can include determining a yield for an attribution property assigned to a token issuer (e.g., attribution property C), and causing the yield for the attribution property to be sent to an account (e.g., digital wallet) owned by the token issuer.[000204] The yield for an attribution property (e.g., attribution property C) can be determined based on the age of the attribution property (e.g., Agee) on the blockchain. More specifically, the yield for the attribution property can be determined as a proportional share of the epoch yield share allocated to the blockchain, based on the age of the attribution property (e.g., Agee) for the blockchain relative to the sum of the ages of all attribution properties (e.g., Ages) for the blockchain. In some implementations, the yield for the attribution property can be determined as the epoch yield share allocated to the blockchain, multiplied by the ratio of the age of the attribution property (e.g., Agee) for the blockchain to the sum of the ages of all attribution properties (e.g., Ages) for the blockchain. A similar process can be performed for each blockchain of the blockchain system. Further details regarding operations 610F-620F are described above with reference to FIG. IE.[000205] FIG. 6G depicts a flow diagram of an example method 600G to implement off- chain yield distribution, in accordance with some implementations. For example, method 600G may be performed by off-chain entity 180 as shown in FIG. IF. Method 600G may be performed by one or more processing devices that may comprise hardware (e.g., circuitry,dedicated logic, programmable logic, microcode, etc.), executable code (such as is run on a general -purpose computer system or a dedicated machine), or a combination of both. For example, the one or more processing devices can perform individual functions, routines, subroutines, or operations to implement method 600G.[000206] At operation 610G, processing logic identifies an epoch to initiate yield distribution to at least one token issuer of a blockchain system. For example, operation 610G can be similar to operation 610E of FIG. 6E.[000207] At operation 620G, processing logic receives a total epoch yield and at least one set of age data items associated with token circulation within at least one blockchain of the blockchain system. In some implementations, the total epoch yield is received from a vault of the blockchain system. In some implementations, a blockchain of the blockchain system is a primary chain. In some implementations, a blockchain of the blockchain system is a secondary chain. The vault can be included in a primary chain or a secondary chain.[000208] In some implementations, a set of age data items received from a blockchain includes the individual age of each attribution property on the blockchain (e.g. Agee for attribution property C), and a sum of the ages of all attribution properties (Ages) for the blockchain. In some implementations, a set of age data items received from a blockchain includes the individual age of each attribution property on the blockchain (e.g., Agee), and processing logic determines Ages for the blockchain using the age of each attribution property on the blockchain (e.g., Agee).[000209] At operation 630G, processing logic determines, based on the total epoch yield and the at least one set of age data items, at least one epoch yield share to be distributed to the at least one token issuer. In some implementations, an epoch yield share is a local epoch yield share for an attribution property assigned to a token issuer with respect to a blockchain of the blockchain system. In some implementations, an epoch yield share is a global epoch yield share for an attribution property assigned to a token issuer across all blockchains of the blockchain system. For example, operation 630G can be similar to operation 630E of FIG.6E[000210] At operation 640G, processing logic causes the at least one epoch yield share to be distributed to the at least one token issuer. For example, causing an epoch yield share to be distributed to a token issuer can include causing the epoch yield share to be sent to an account (e.g., digital wallet) owned by the token issuer. Further details regarding operations 610G- 640G are described above with reference to FIG. IF.[000211] FIG. 9 depicts a block diagram of a computer system 900 operating in accordance with one or more aspects of the disclosure. In various illustrative examples, computer system 900 may correspond to one or more components of systems 100, 200 and 800 of FIGS. 1-2B and 8. Computer system 900 may be included within a data center that supports virtualization. Virtualization within a data center can result in a physical system being virtualized using virtual machines to consolidate the data center infrastructure and increase operational efficiencies. A virtual machine (VM) may be a program-based emulation of computer hardware. For example, the VM may operate based on computer architecture and functions of computer hardware resources associated with hard disks or other such memory. The VM may emulate a physical computing environment, but requests for a hard disk or memory may be managed by a virtualization layer of a computing device to translate these requests to the underlying physical computing hardware resources. This type of virtualization results in multiple VMs sharing physical resources.[000212] In certain implementations, computer system 900 may be connected (e.g., via a network 964, such as a Local Area Network (LAN), an intranet, an extranet, or the Internet) to other computer systems. Computer system 900 may operate in the capacity of a server or a client computer in a client-server environment, or as a peer computer in a peer-to-peer or distributed network environment. Computer system 900 may be provided by a personal computer (PC), a tablet PC, a set-top box (STB), a Personal Digital Assistant (PDA), a cellular telephone, a web appliance, a server, a network router, switch or bridge, or any device capable of executing a set of executable instructions (sequential or otherwise) that specify actions to be taken by that device. Further, the term "computer" shall include any collection of computers that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methods described herein.[000213] In a further aspect, the computer system 900 may include a processing device 902, a volatile memory 904 (e.g., random access memory (RAM)), anon-volatile memory 906 (e.g., read-only memory (ROM) or electrically-erasable programmable ROM (EEPROM)), and a data storage device 916, which may communicate with each other via a bus 908.[000214] Processing device 902 may be provided by one or more processors such as a general purpose processor (such as, for example, a complex instruction set computing (CISC) microprocessor, a reduced instruction set computing (RISC) microprocessor, a very long instruction word (VLIW) microprocessor, a microprocessor implementing other types of instruction sets, or a microprocessor implementing a combination of types of instruction sets) or a specialized processor (such as, for example, an application specific integrated circuit(ASIC), a field programmable gate array (FPGA), a digital signal processor (DSP), or a network processor).[000215] Computer system 900 may further include a network interface device 922. Computer system 900 also may include a video display unit 910 (e.g., an LCD), an alphanumeric input device 912 (e.g., a keyboard), a cursor control device 914 (e.g., a mouse), and a signal generation device 920. Data storage device 916 may include a non-transitory computer-readable storage medium 924 on which may store instructions 926 encoding any one or more of the methods or functions described herein. Instructions 926 may also reside, completely or partially, within volatile memory 904 and / or within processing device 902 during execution thereof by computer system 900, hence, volatile memory 904 and processing device 902 may also constitute machine-readable storage media.[000216] While computer-readable storage medium 924 is shown in the illustrative examples as a single medium, the term "computer-readable storage medium" shall include a single medium or multiple media (e.g., a centralized or distributed database, and / or associated caches and servers) that store the one or more sets of executable instructions. The term "computer-readable storage medium" shall also include any tangible medium that is capable of storing or encoding a set of executable instructions for execution by a computer that causes the computer to perform any one or more of the methods described herein. The term "computer-readable storage medium" shall include, but not be limited to, solid-state memories, optical media, and magnetic media.[000217] Other computer system designs and configurations may also be suitable to implement the system and methods described herein. The following examples illustrate various implementations in accordance with one or more aspects of the present disclosure. [000218] Although the operations of the methods herein are shown and described in a particular order, the order of the operations of each method may be altered so that certain operations may be performed in an inverse order or so that certain operations may be performed, at least in part, concurrently with other operations. In certain implementations, instructions or sub-operations of distinct operations may be in an intermittent and / or alternating manner. In certain implementations, not all operations or sub-operations of the methods herein are required to be performed.[000219] It is to be understood that the above description is intended to be illustrative, and not restrictive. Many other implementations will be apparent to those of skill in the art upon reading and understanding the above description. The scope of the disclosure should,therefore, be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled.[000220] In the above description, numerous details are set forth. It will be apparent, however, to one skilled in the art, that aspects of the present disclosure may be practiced without these specific details. In some instances, well-known structures and devices are shown in block diagram form, rather than in detail, in order to avoid obscuring the present disclosure.[000221] Unless specifically stated otherwise, as apparent from the following discussion, it is appreciated that throughout the description, discussions utilizing terms such as “obtaining,” “receiving,” “causing,” “executing,” “sending,” “initiating,” or the like, refer to the action and processes of a computer system, or similar electronic computing device, that manipulates and transforms data represented as physical (electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage, transmission or display devices.[000222] The present disclosure also relates to an apparatus for performing the operations herein. This apparatus may be specially constructed for the specific purposes, or it may comprise a general purpose computer selectively activated or reconfigured by a computer program stored in the computer. Such a computer program may be stored in a computer readable storage medium, such as, but not limited to, any type of disk including floppy disks, optical disks, CD-ROMs, and magnetic-optical disks, read-only memories (ROMs), random access memories (RAMs), EPROMs, EEPROMs, magnetic or optical cards, or any type of media suitable for storing electronic instructions, each coupled to a computer system bus. [000223] Aspects of the disclosure presented herein are not inherently related to any particular computer or other apparatus. Various general purpose systems may be used with programs in accordance with the teachings herein, or it may prove convenient to construct more specialized apparatus to perform the specified method steps. The structure for a variety of these systems will appear as set forth in the description below. In addition, aspects of the present disclosure are not described with reference to any particular programming language. It will be appreciated that a variety of programming languages may be used to implement the teachings of the disclosure as described herein.[000224] Aspects of the present disclosure may be provided as a computer program product that may include a machine-readable medium having stored thereon instructions, which may be used to program a computer system (or other electronic devices) to perform a processaccording to the present disclosure. A machine-readable medium includes any mechanism for storing or transmitting information in a form readable by a machine (e.g., a computer). For example, a machine-readable (e.g., computer-readable) medium includes a machine (e.g., a computer) readable storage medium (e.g., read only memory (“ROM”), random access memory (“RAM”), magnetic disk storage media, optical storage media, flash memory devices, etc.).[000225] The words “example” or “exemplary” are used herein to mean serving as an example, instance, or illustration. Any aspect or design described herein as “example” or “exemplary” is not to be construed as preferred or advantageous over other aspects or designs. Rather, use of the words “example” or “exemplary” is intended to present concepts in a concrete fashion. As used in this application, the term “or” is intended to mean an inclusive “or” rather than an exclusive “or”. That is, unless specified otherwise, or clear from context, “X includes A or B” is intended to mean any of the natural inclusive permutations. That is, if X includes A; X includes B; or X includes both A and B, then “X includes A or B” is satisfied under any of the foregoing instances. In addition, the articles “a” and “an” as used in this application and the appended claims should generally be construed to mean “one or more” unless specified otherwise or clear from context to be directed to a singular form.Moreover, use of the term “an embodiment” or “one embodiment” or “an implementation” or “one implementation” throughout is not intended to mean the same embodiment or implementation unless described as such. Furthermore, the terms “first,” “second,” “third,” “fourth,” etc. as used herein are meant as labels to distinguish among different elements and may not have an ordinal meaning according to their numerical designation.

Claims

CLAIMSWhat is claimed is:

1. A method comprising: maintaining, by at least one processing device of a blockchain, a set of age data items associated with token circulation within the blockchain, wherein the set of age data items comprises an age data item reflecting an age of an attribution property for a token assigned to a token issuer, and wherein the age of the attribution property is determined based on an amount of time that a quantity of tokens having the attribution property have been in circulation within the blockchain; detecting, by the at least one processing device, an age update event to cause an update to the set of age data items maintained on the blockchain; causing, by the at least one processing device, the set of age data items maintained on the blockchain to be updated; and using, by the at least one processing device, the set of age data items to perform yield distribution to distribute yield to at least the token issuer.

2. The method of claim 1, wherein the age update event is represented by one of: token reattribution, token transfer, token minting, or token burning.

3. The method of claim 1, wherein the age update event corresponds to an explicit age update request received from an entity.

4. The method of claim 1, wherein the age update event is the yield distribution.

5. The method of claim 1, further comprising performing, by the at least one processing device, the yield distribution at an epoch to distribute yield to at least the token issuer, wherein the epoch corresponds to time at which yield is distributed to at least the token issuer.

6. The method of claim 5, wherein performing the yield distribution at the epoch further comprises: receiving, from the blockchain, the set of age data items;determining, based on the set of age data items, an epoch yield share for the epoch with respect to a total epoch yield of a blockchain system comprising the blockchain; and causing the epoch yield share to be distributed to the token issuer via a digital wallet associated with the token issuer.

7. The method of claim 5, wherein performing the yield distribution at the epoch further comprises: receiving, from a vault of a blockchain system comprising the blockchain, a first epoch yield share for the epoch allocated to the blockchain, wherein the first epoch yield share is a proportional amount of a total epoch yield of the blockchain system; and causing the first epoch yield share to be distributed to at least the token issuer, wherein the token issuer receives, via a digital wallet, a second epoch yield share allocated to the token issuer corresponding to a proportional amount of the first epoch yield share.

8. The method of claim 5, wherein performing the yield distribution at the epoch further comprises: receiving, from a vault of a blockchain system comprising the blockchain, a total epoch yield of the blockchain system for the epoch; receiving, from the blockchain, a set of age data for the epoch; determining, based on the total epoch yield and the set of age data for the epoch, an epoch yield share allocated to the token issuer for the epoch, wherein the epoch yield share is a proportional amount of the total epoch yield of the blockchain system; and causing the epoch yield share allocated to the token issuer for the epoch to be distributed to a digital wallet associated with the token issuer.

9. The method of claim 1, wherein: causing the set of age data to be updated further comprises causing a current checkpoint root of the attribution property to be stored on a storage slot of a vault of a blockchain system; the current checkpoint root corresponds to a current state of the vault; the current checkpoint root is determined based on a combination of a previous checkpoint root for the attribution property and the age of the attribution property; and the previous checkpoint root corresponds to a previous state of the vault.

10. The method of claim 9, wherein the current checkpoint root is a digest determined based on an Application Binary Interface (ABI) encoding of the previous checkpoint root and the age of the attribution property.

11. A system comprising: a memory; and a processing device, operatively coupled to the memory, to perform operations comprising: maintaining, on a blockchain, a set of age data items associated with token circulation within the blockchain, wherein the set of age data items comprises an age data item reflecting an age of an attribution property for a token assigned to a token issuer, and wherein the age of the attribution property is determined based on an amount of time that a quantity of tokens having the attribution property have been in circulation within the blockchain; detecting an age update event to cause an update to the set of age data items maintained on the blockchain; causing the set of age data items maintained on the blockchain to be updated; and using the set of age data items to perform yield distribution to distribute yield to at least the token issuer.

12. The system of claim 11, wherein the age update event is a token transaction event represented by one of: token reattribution, token transfer, token minting, or token burning.

13. The system of claim 11, wherein the age update event corresponds to an explicit age update request received from an entity of a blockchain system.

14. The system of claim 11, wherein the age update event is the yield distribution.

15. The system of claim 11, wherein the operations further comprise performing the yield distribution at an epoch to distribute yield to at least the token issuer, and wherein the epoch corresponds to time at which yield is distributed to at least the token issuer.

16. The system of claim 15, wherein performing the yield distribution at the epoch further comprises: receiving, from the blockchain, the set of age data items; determining, based on the set of age data items, an epoch yield share for the epoch with respect to a total epoch yield of a blockchain system comprising the blockchain; and causing the epoch yield share to be distributed to the token issuer via a digital wallet associated with the token issuer.

17. The system of claim 15, wherein performing the yield distribution at the epoch further comprises: receiving, from a vault of a blockchain system comprising the blockchain, a first epoch yield share for the epoch allocated to the blockchain, wherein the first epoch yield share is a proportional amount of a total epoch yield of the blockchain system; and causing the first epoch yield share to be distributed to at least the token issuer, wherein the token issuer receives, via a digital wallet, a second epoch yield share allocated to the token issuer corresponding to a proportional amount of the first epoch yield share.

18. The system of claim 15, wherein performing the yield distribution at the epoch further comprises: receiving, from a vault of a blockchain system comprising the blockchain, a total epoch yield of the blockchain system for the epoch; receiving, from the blockchain, a set of age data for the epoch; determining, based on the total epoch yield and the set of age data for the epoch, an epoch yield share allocated to the token issuer for the epoch, wherein the epoch yield share is a proportional amount of the total epoch yield of the blockchain system; and causing the epoch yield share allocated to the token issuer for the epoch to be distributed to a digital wallet associated with the token issuer.

19. The system of claim 11, wherein: causing the set of age data to be updated further comprises causing a current checkpoint root of the attribution property to be stored on a storage slot of a vault of a blockchain system; the current checkpoint root corresponds to a current state of the vault;the current checkpoint root is determined based on a combination of a previous checkpoint root for the attribution property and the age of the attribution property; and the previous checkpoint root corresponds to a previous state of the vault.

20. The system of claim 19, wherein the current checkpoint root is a digest determined based on an Application Binary Interface (ABI) encoding of the previous checkpoint root and the age of the attribution property.

Images