Upgradeable Securities Tokens

Abstract

To provide a network node configured to be within a plurality of network nodes communicatively coupled in a peer-to-peer network of network nodes implementing a distributed ledger.SOLUTION: A network node is communicatively coupled to at least one remotely located computing device via at least one network interface. At least one processor develops a child smart contract, a subsequent version of a parent smart contract, in a distributed ledger and sets an upgraded address field in the parent smart contract so as to point to the address of the child smart contract. The parent smart contract remains developed after the child smart contract is developed.SELECTED DRAWING: Figure 6

Description

[Technical Field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application was filed on August 10, 2018, and is entitled "SELF-ENFORCING U.S. Provisional Patent Application No. 62 / 717,575 (Attorney Docket No. 270.023USPR) entitled "SECURITY TOKEN IMPLEMENTING SMART-CONTRACT-BASED COMPLIANCE RULES CONSULTING SMART-CONTRACT-BASED GLOBAL REGISTRY OF INVESTORS," filed on July 8, 2019, U.S. Provisional Patent Application No. 62 / 871,543 (Attorney Docket No. 270.032USPR) entitled "SPLITTABLE SECURITY TOKEN," and U.S. Provisional Patent Application No. 62 / 871,543 (Attorney Docket No. 270.032USPR) entitled "UPGRADABLE SECURITY TOKEN," filed on July 31, 2019, This application claims the benefit of U.S. Provisional Patent Application No. 62 / 881,121 (Attorney Docket No. 270.033 USPR), entitled "Upgradable Security Token (SMT)," all of which are incorporated herein by reference.

[0002]

[0002] This application is related to the following co-pending US patent applications, which are incorporated herein by reference:

[0003] No. ____________, filed on even date, entitled "SELF-ENFORCING SECURITY TOKEN IMPLEMENTING SMART-CONTRACT-BASED COMPLIANCE RULES CONSULTING SMART-CONTRACT-BASED GLOBAL REGISTRY OF INVESTORS," which is incorporated herein by reference.

[0003]

[0004] No. ____________ (Attorney Docket No. 270.032US01), filed on even date, entitled "SPLITTABLE SECURITY TOKEN," which is incorporated herein by reference. [Background technology]

[0004]

[0005] Cryptographic tokens are used in connection with various aspects of blockchains. For example, smart contracts implemented on the Ethereum blockchain allow for the creation and issuance of tokens with complex behavior attached. Ethereum Request for Comments 20 (ERC20) is a technical standard used for smart contracts (on the Ethereum blockchain) that implement tokens. The ERC20 standard is incorporated by reference in its entirety. Additionally, other methods may be implemented to satisfy Title 8 of the Delaware General Corporation Law. Summary of the Invention [Means for solving the problem]

[0005]

[0006] A network node including at least one processor, at least one memory, and at least one network interface, the network node configured to be among a plurality of network nodes communicatively coupled in a peer-to-peer network of network nodes that implement a distributed ledger. , is communicatively coupled to at least one remotely located computing device via at least one network interface. The at least one processor is configured to deploy a child smart contract, which is a successor version of the parent smart contract, in the distributed ledger. The at least one processor is also configured to set an upgraded address field in the parent smart contract to point to the address of the child smart contract. The parent smart contract remains deployed after the child smart contract is deployed.

[0006]

[0007] Exemplary embodiments will be described with additional specificity and detail through the use of the accompanying drawings, with the understanding that the drawings depict only exemplary embodiments and therefore should not be considered limiting in scope. [Brief explanation of the drawings]

[0007] [Figure 1]

[0008] FIG. 1 is a block diagram of an exemplary system using upgradeable smart contract-based security tokens. [Figure 2A]

[0009] FIG. 2 is a block diagram illustrating data structures used in the system shown in FIG. 1. [Figure 2B]

[0010] FIG. 2 is a block diagram illustrating the hierarchy of entities in the system shown in FIG. 1. [Figure 3]

[0011] FIG. 1 is a block diagram illustrating three different versions of an upgradeable smart contract. [Figure 4]

[0012] Figure 4A is a block diagram illustrating different stages of token migration to a subsequent version of a smart contract; Figure 4B is a block diagram illustrating different stages of token migration to a subsequent version of a smart contract; Figure 4C is a block diagram illustrating different stages of token migration to a subsequent version of a smart contract; and Figure 4D is a block diagram illustrating different stages of token migration to a subsequent version of a smart contract. [Figure 5]

[0013] FIG. 1 is a flow diagram illustrating a method for deploying a child smart contract. [Figure 6]

[0014] FIG. 10 is a flow diagram illustrating a method for transferring outstanding tokens in a parent smart contract to a child smart contract. [Figure 7]

[0015] FIG. 1 is a block diagram illustrating an exemplary computer system in which embodiments of the present disclosure may be utilized. [Figure 8]

[0016] FIG. 1 is a block diagram illustrating another exemplary computing device in which embodiments of the present disclosure may be utilized. DETAILED DESCRIPTION OF THE INVENTION

[0008]

[0017] In accordance with common practice, the various features illustrated are not drawn to scale, but are drawn to emphasize particular features relevant to exemplary embodiments.

[0018] In the following detailed description, reference is made to the accompanying drawings which form a part hereof, and in which are shown by way of illustration specific exemplary embodiments. It is to be understood, however, that other embodiments may be utilized and that logical, mechanical, and electrical changes may be made. Furthermore, the methods presented in the drawings and the specification should not be construed as limiting the order in which individual steps may be performed. Accordingly, the following detailed description is not to be construed in a limiting sense.

[0009]

[0019] The term "smart contract" (or simply "contract") refers to a set of conditional logic that may be implemented in software, e.g., one or more sequential steps that are executed in response to one or more associated conditions being met. A smart contract may be stored at an address on a distributed ledger. A smart contract may be invoked using the address of the smart contract. In an example, the smart contract may be programmed in the Solidity programming language. The smart contract may be executed by a processor on a network node that implements the distributed ledger, e.g., a network node running a virtual machine such as the Ethereum Virtual Machine (EVM).

[0010]

[0020] One particular example of a smart contract is a security token. In other words, a security token may be a type of smart contract, e.g., a cryptographic token that represents a security. A security token may be implemented as a smart contract (e.g., stored) in a distributed ledger (e.g., a blockchain). Various aspects of a given security token (e.g., issuance, transfer, etc.) may be regulated by the Securities and Exchange Commission (SEC) or other regulatory bodies.

[0011]

[0021] Security tokens may maintain state indicating existing token holders, token balances in addresses, total supply of tokens, etc. Thus, in addition to referring to smart contracts, the terms "security token" or "token" may refer to the state of security tokens that represent securities, e.g., shares of stock. Generally, but without limitation, the term "security token" is used to refer to smart contracts, while the term "token" is used to refer to the state of security tokens, e.g., representing shares of stock.

[0012]

[0022] A security can be a fungible, negotiable financial instrument that holds some monetary value. A security can be represented by an option. As used herein, ownership status, creditor relationships, or rights of ownership Examples of securities include, but are not limited to, real estate, at least one commodity, personal assets, at least one bond, at least one derivative, at least one futures, at least one fund, at least one currency fund, at least one exchange-traded fund, at least one mutual fund, at least one index fund, at least one bond fund, at least one commodity fund, and / or at least one real estate fund.

[0013]

[0023] A further description of security tokens, including their issuance, transfer, and associated regulations, can be found in U.S. Provisional Patent Application No. 62 / 717,575 (Attorney Docket No. 270.023 USPR), filed August 10, 2018, and entitled "SELF-ENFORCING SECURITY TOKEN IMPLEMENTING SMART-CONTRACT-BASED COMPLIANCE RULES CONSULTING SMART-CONTRACT-BASED GLOBAL REGISTRY OF INVESTORS," the entire contents of which are incorporated herein by reference.

[0014]

[0024] A common difficulty when developing smart contracts (e.g., in Ethereum / Solidity) is how to upgrade them, fix bugs, or otherwise ensure code changes within the smart contract. Traditional attempts at upgrading smart contracts focus on preserving the original address of the contract. The present system and method focuses on preserving the original code rather than preserving the contract address when changing the code, with the ability to link old code to new code while maintaining a full logical audit of the contract. While this approach can be applied to any type of smart contract, one particularly useful configuration involves upgrade paths for security tokens, including, for example, state.

[0015]

[0025] Two of the most important features of distributed ledger technology (DLT) and blockchain technology are delegation and auditability. Both of these features can be affected by another all-too-often overlooked (and / or missing) feature: maintainability. If a contract is not maintainable, it will quickly lose credibility if problems arise, features are missing, or, in the worst case, fraud and / or abuse occurs. One of the most notorious issues is the well-known decentralized autonomous organization (DAO) attack, which has raised concerns throughout the DLT community. This caused confusion for outside observers.

[0016]

[0026] No matter how well designed or tested they are, smart contracts are not immune to subversion, abuse, and / or misuse. Because immutability is a new concept to many developers accustomed to redeployment, hotfixes / patches, and / or code versioning, this lack of maintainability often goes unchecked. By designing upgrade paths into smart contracts (and particularly smart contracts that implement security tokens), the present systems and methods allow issuers to make changes to the smart contract's underlying code with less impact to users of the system.

[0017]

[0027] By allowing for the need to update a smart contract, upgradability can be designed in advance. As noted above, it is desirable for smart contracts to be auditable. Thus, the upgradeable security tokens described herein allow for chronological traversal of different versions of a security token (similar to a linked list). This allows for a clear ability to perform audits, while also providing an easy way to navigate the latest implementation when only knowing that a replacement contract exists.

[0018]

[0028] Additionally, it is desirable to transition state from an old contract to a new one by allowing holders of old tokens in a parent contract to move their holdings to new tokens in a descendant contract. This provides several features for the upgrade path. First, the old contract's token holdings are sent to the descendant's address. This essentially locks / burns / removes these tokens from circulation, preserving state information from the old contract while providing an audit trail of when holders moved their holdings. This can reveal whether a given contract is up-to-date or where it is in the upgrade path. Second, it identifies who decided to transition holdings and who did not, giving users control over whether to opt in or accept the upgraded changes. Instead of "parent" and "child" smart contracts, the terms "first" and "second" or "predecessor" and "successor" can also be used.

[0019]

[0029] One important change with upgradeable security tokens herein compared to traditional solutions is that assets / security tokens can potentially have multiple addresses. As long as there is an easy ability to follow the security token history and find active assets / security tokens, there is no impediment to implementing using multiple addresses.

[0020]

[0030] Since immutability is both a key concept within the blockchain space and an obstacle to integrity, there have been many attempts at upgradeable smart contracts within the Ethereum ecosystem. One concept shared by many solutions is the use of fixed, immutable contract addresses (as opposed to the present system and method). It is.

[0021]

[0031] Specifically, the "proxy pattern" emerges as a common solution to the inherent obstacles that immutability provides, but implementations also tend to use some form of persistent storage, hub-and-spoke, or other means to persist stored data. The proxy pattern is a single proxy contract whose sole purpose is to hold the address of the current implementation of the contract. The proxy contract can be invoked using low-level Solidity opcodes (delegate calls). In this case, the proxy contract passes the initiator's address to the actual implementation of the contract. In this way, the proxy contract's address remains unchanged between upgrades. Instead, to upgrade the contract, new code is deployed and the address field held within the proxy contract is updated to point to the newly deployed version containing the changes. This is useful for maintenance until bugs or other issues are discovered within the proxy contract implementation. If a vulnerability is discovered in the proxy contract, this could hinder adoption.

[0022]

[0032] A second potential problem arises with delegating proxy contracts. Pointers within proxy contracts can be changed at any time, essentially circumventing the immutable nature of blockchains while obscuring transparency. The present system and method addresses these shortcomings by maintaining a complete upgrade history, while preventing the functionality of a given address from being changed from its initial state.

[0023]

[0033] The examples described herein may be compatible with a custodial model, where a custodian holds tokens on behalf of investors and / or brokerage dealers. However, the system herein is also compatible with a non-custodial model, where, for example, investors and / or brokerage dealers hold tokens directly with little or no intermediaries.

[0024]

[0034] Various method names may be used herein as examples. It should be recognized that the method names are for illustrative purposes and not limiting. Additionally, optional devices and method steps are shown in dashed lines in the figures.

[0025]

[0035] 1 is a block diagram of an example system 100 that uses an upgradeable smart contract-based security token 102. The system 100 may include one or more security tokens 102, a system owner 112, an issuer 114, and at least one network node 140 that implements a distributed ledger 122. The system 100 may also include various optional entities and / or devices, as described below.

[0026]

[0036] In an example, each token in a security token 102 / smart contract may represent a single share of a company. The security token 102 may be implemented (e.g., stored) on a distributed ledger 122 (e.g., a blockchain). The security token 102 may be implemented using one or more smart contracts. The security token 102 may store an indication of its state, for example, how many tokens have been issued, which addresses hold how many tokens, etc.

[0027]

[0037] An investor 120 may be an individual or entity that previously holds, is considering, is receiving, or is transferring tokens. In an example, an investor 120 may be a customer of a broker dealer 118 (or of a custodian 116 directly), and the investor 120 may submit an order to the broker dealer 118 (or to the custodian 116 directly) for the purchase and / or sale of one or more tokens. Alternatively, the investor 120 may be a customer of a broker dealer 118 (or of a custodian 116 directly), and the investor 120 may submit an order to the broker dealer 118 (or to the custodian 116 directly) for the purchase and / or sale of one or more tokens. A third-party investor may be an “external investor” that does not need to be connected to a dealer 118 or custodian 116. Instead, the external investor may invoke related methods described herein to initiate a token transaction, such as, for example, the methods in the token 102 / smart contract itself and / or the global registry 108 described below.

[0028]

[0038] A “token transaction” or similar term refers to any movement of security tokens 102 and may be used to describe an issuance, offering, gift, purchase, sale, and / or employee compensation performed by the movement of tokens. A token 102 transaction may move a large amount of tokens from one or more input addresses (belonging to one or more investors 120, broker dealers 118, and / or custodians 116) to at least one output address (belonging to one or more investors 120, broker dealers 118, and / or custodians 116). As used herein, the terms “buyer” and “seller” refer to investors 120 moving and receiving tokens, respectively. A token transaction may be performed on-exchange or off-exchange.

[0029]

[0039] A broker dealer 118 in system 100 may be an individual or entity that buys or sells tokens for its own account and / or on behalf of its customers. During onboarding, the broker dealer 118 may create an account for a new customer, including collecting information; for example, the broker dealer 118 may onboard an investor 120 as a new customer. This may include performing anti-money laundering (AML) / know-your-customer (KYC) checks on the customer, provided, for example, by an identity service provider 126.

[0030]

[0040] An issuer 114 may be a person or entity that instructs an owner 112 to issue tokens, i.e., an owner 112 may own one or more originating smart contracts 113 that deploy / issue security tokens 102. The system 100 may optionally include many issuers 114. In an example, an issuer 114 may be a company, and each token in the security token 102 represents a share in the company.

[0031]

[0041] A brokerage dealer 118 may have an account with a custodian 116, i.e., a person or entity that holds custody, possession, and / or ownership of tokens for one or more brokerage dealers 118. A custodian 116 may be a person or entity that holds custody, possession, and / or ownership of tokens on behalf of many brokerage dealers 118 (who may have many investors 120 as their clients). System 100 may include many custodians 116 and / or many brokerage dealers 118.

[0032]

[0042] An owner 112 may be an individual or entity that owns, deploys, redeploys, and / or moves smart contracts in system 100. In an example, an owner 112 may deploy / issue security tokens 102 using method calls (e.g., executed by a virtual machine) to an originating smart contract 113. An owner 112 may be referred to as an administrator of system 100. System 100 may have only one or more owners 112. Optionally, an owner 112 may provide a data service describing the "market" for a token based on token transactions executed in system 100, e.g., a feed showing the volume of token transactions, transaction prices of the most recent token transactions, etc.

[0033]

[0043] As explained above, the terms owner 112, issuer 114, custodian 116, broker dealer 118, and investor 120 may refer to individuals or entities that perform various roles in system 100. Alternatively, these terms may refer to computing devices used by owner 112, issuer 114, custodian 116, broker dealer 118, and investor 120, respectively. When referring to computing devices, each of owner 112, issuer 114, custodian 116, broker dealer 118, and investor 120 may be implemented with one or more processors that execute instructions in memory on the respective computing device. Each respective computing device may be a mobile device, such as a cell phone or tablet, a personal computer, or a server configured to send and receive instructions and / or other data to and from other computing devices over a network 138, such as the Internet, for example.

[0034]

[0044] The security token exchange 124 may be a marketplace where security tokens 102, commodities, derivatives, and / or other financial instruments are traded, or an entity operating a marketplace (or one or more computing devices operated by the security token exchange 124). In an example, the security token exchange 124 may record successfully executed transactions in the distributed ledger 122. The security token exchange 124 is a custodian, i.e., where the custodian 116 holds and transacts tokens on behalf of broker dealers 118 and / or investors 120.

[0035]

[0045] A network node 140 may be a computing device implemented using one or more processors that execute instructions stored in memory to perform the functions described herein. In an example, a network node 140 may run a virtual machine (e.g., an Ethereum Virtual Machine) that executes any of the smart contracts described herein.

[0036]

[0046] The term "distributed ledger" refers to a system distributed across multiple interconnected network nodes 140 (i.e., computing devices that execute instructions stored in memory), where two or more of the network nodes 140 store a copy of the distributed ledger 122. In an example, one or more network nodes 140 in a peer-to-peer network may implement the distributed ledger 122.

[0037]

[0047] The distributed ledger 122 may implement one or more blockchains to validate the data stored within the distributed ledger 122. A blockchain is a verifiable, permanent ledger built one block at a time, with a proof-of-work seal (e.g., a hash) affixed to each block that validates that block. In a blockchain, the hash of the previous block is included in the current block, so through recursion, the current hash validates all previous blocks back to the original block of origin. Insertion of a hash into the blockchain permanently records that hash and serves as a notarization that verifies the time-stamped proof of existence of the hash data at the time the block was added to the chain. Future blocks provide additional assurance that changes cannot be made to earlier blocks in the chain, adding a layer of protection from manipulation of data stored in the chain or chain reorganization. A blockchain is an implementation of a distributed ledger 122 and can be public (e.g., viewable by anyone) or private (e.g., viewable only by authorized users or entities). Exemplary blockchains include the Bitcoin blockchain, the Ethereum blockchain, BigchainDB, Billon, Chain, Corda, Credits, Elements, Monax, Fabric, HydraChain, Hyperledger, Multichain, and Openchain. , Quorum, Ravencoin, Sawtooth, and Stellar. Preferably, the distributed ledger 122 is the public Ethereum blockchain, however, other implementations are possible. If a private blockchain is used, hashes of the public blockchain may be periodically committed (i.e., recorded) to a public blockchain, such as the Ethereum blockchain or the Bitcoin blockchain.

[0038]

[0048] Additionally or alternatively, the distributed ledger 122 may be a directed acyclic graph (DAG) that uses a gossip protocol, such as IOTA or Hashgra, to share information among the network nodes 140 of the system 100. Additionally, consensus can be reached in the distributed ledger 122 without proof of work; proof of stake can be used instead. Additionally, any Merkle tree (or hash tree), which uses cryptographic hashes to connect different sets of data, can be implemented by the distributed ledger 122.

[0039]

[0049] The term “wallet” refers to a software program, digital file, and / or memory used to store and / or manage digital assets, such as tokens. While the present systems and methods are described herein using tokens, they are compatible with any type of digital asset. In an example, a wallet may be defined by one or more private keys, one or more public keys derived from the one or more private keys, and / or one or more addresses derived from the one or more private keys and / or one or more public keys. In an example, a wallet may be defined by one or more private account keys (and, optionally, corresponding public account keys), each of which may have one or more child and / or grandchild transaction keys. The term “account” may be used to refer to an address in the distributed ledger 122, e.g., an Ethereum address in a hierarchical deterministic (HD) wallet.

[0040]

[0050] Ethereum Request for Comments 20 (ERC20) is a standard that defines a set of methods. To be ERC20 compliant, a cryptographic token (e.g., a utility, cryptocurrency, or security) must implement these methods, but security token 102 holders can implement the methods in their own ways. One advantage of ERC20 is that each application, wallet, exchange, or interface does not need to be tailored to each specific security token 102. Rather, if a project supports the ERC20 standard, the project can support many different ERC20 security tokens 102.

[0041]

[0051] To comply with ERC20, the security token 102 may include token logic and / or parameters 104 that implement six required methods, including totalSupply(), balanceOf(), transfer(), transferFrom(), approve(), and allowance(). These required methods describe how tokens can be transferred and how token-related data can be accessed. The token logic / parameters 104 may also implement various events, e.g., Transfer() and Approval(), to comply with ERC20. These events describe formatting guidelines for transfers and approvals.

[0042]

[0052] The transfer() method / function 109 may be invoked when a token transaction is requested, and the transfer() method 109 may optionally invoke methods in one or more other smart contracts, for example, in the token logic / parameters 104 and / or the global registry 108. The transfer() method 109 transfers tokens from an input address to at least one output address. Navigating to an address may be implemented in any suitable manner.

[0043]

[0053] The token logic / parameters 104 may also implement one or more optional methods for ERC20 compliance, such as name(), symbol(), and / or decimals(). These optional methods may be used to assign names and symbols to the security tokens 102 and to define the number of decimals that each security token 102 uses. These methods and events may be executed by a virtual machine (e.g., an Ethereum Virtual Machine) on the network node 140 and are further described in the ERC20 standard.

[0044]

[0054] The token logic and / or parameters 104 may also include data indicating the name of the security token 102, how many tokens of the same type have been deployed or issued, and / or the symbol of the security token 102. In an example, the symbol of the security token 102 may be a multi-character (e.g., four or five) identifier of the security token 102, similar to a stock ticker symbol. The symbol of the security token 102 may be registered with the Financial Industry Regulatory Authority (FINRA). A security token 102 symbol issued by a company may preferably be an expanded version of the company's ticker symbol, for example, with a particular letter (e.g., Q, X, or Z) concatenated to the end of the company's ticker symbol.

[0045]

[0055] The security token 102 may also include a balance table 105 stored, for example, in the distributed ledger 122. The balance table 105 may show the balances of all holders of the token; for example, the balance table 105 may show which addresses (e.g., Ethereum addresses) hold how many tokens. Alternatively, instead of being indexed by the addresses of the investors 120 (or custodians 116 or broker dealers 118), the balance table 105 may be indexed in other ways, such as by a hash of the investors' names. The balance table 105 of the security token 102 may be public, semi-public, or private, and may be anonymous so that the balance of tokens held by a particular investor 120, custodian 116, or broker dealer 118 cannot be derived purely from publicly available information.

[0046]

[0056] The balance table 105 may account for all tokens deployed or issued. As token movements occur (i.e., changes in balance), the balance table 105 may be updated and distributed to each copy of the security token 102 stored at the different network nodes 140. In an example, a movement of tokens in the security token 102 may include updating the balance table 105 in the security token 102. Table 1 is an example of a balance table 105 that includes key / value pairs for each investor address.

[0047] [Table 1]

[0048] In some examples, the balance table 105 is a multi-object data structure (e.g., an array) indexed by address (shown in the left column in Table 1), where the value of each index is the token balance (shown in the right column in Table 1) associated with the address. and stored as

[0049]

[0057] In some configurations, the security token 102 may include a token supply parameter 115, for example, stored in the distributed ledger 122. The token supply parameter 115 may indicate a total number of outstanding tokens. For example, the token supply parameter 115 may be the sum of the token balances of all addresses in the balance table 105 of the security token 102.

[0050]

[0058] However, security tokens 102 (unlike other types of tokens) may be regulated in the United States by the Securities and Exchange Commission (SEC). Accordingly, it may be desirable to comply with Title 8 of the Delaware Code, which relates to general corporate law, which is important because many publicly traded companies are incorporated in Delaware. Additional methods for complying with Title 8 are referred to herein as Title 8 methods, and may be implemented in a variety of ways, for example, with or without Ethereum Request for Comments 884 (ERC884). Specifically, Title 8 methods allow for the creation of tokens where each token represents a single share issued by a Delaware corporation; that is, such tokens may be designed to represent equity issued by a Delaware corporation, whether private or public.

[0051]

[0059] Thus, the token logic and / or parameters 104 may implement one or more Title 8 methods (beyond the six required by ERC20), including addVerified(), removeVerified(), updateVerified(), cancelAndReissue(), isVerified(), isHolder(), holderCount(), holderAt(), hasHash(), isSuperseded(), and / or getCurrentFor(). The token logic / parameters 104 may also implement one or more events (beyond the six required for ERC20 compatibility), such as, for example, verifiedAddressAdded(), VerifiedAddressRemoved(), VerifiedAddressUpdate(), and / or VerifiedAddressSuperseded(). These Title 8 methods and events may be executed by a virtual machine on the network node 140.

[0052]

[0060] However, SEC regulations impose additional requirements on security tokens 102 that are not required or enforced by ERC20 and / or Title VIII methods. To self-enforce compliance with SEC regulations, system 100 may implement functions beyond Title VIII methods. Specifically, one or more compliance rules 106A-106B may ensure that any transactions involving security tokens 102 comply with relevant SEC regulations. In an example, compliance rules 106 may (1) verify that buyers and / or sellers of tokens are eligible under at least one of SEC Regulations A, D, and S; (2) verify that AML and / or KYC services have been performed for buyers and / or sellers; (3) verify that no freezes (described below) have been established that prevent the movement of tokens; and / or (4) verify that a particular security token 102 is not subject to a blackout period, i.e., a restriction that prevents a seller from selling the token for a specified period (e.g., one year) after acquisition of the token.

[0053]

[0061] In some configurations, the compliance rules 106A may be stored in the security token (e.g., in the distributed ledger 122). Alternatively, the security token 102 may include at least one compliance rule pointer 107, each of which points to the address of at least one external compliance rule 106B (implemented using one or more smart contracts). In this type of configuration, at least At least one compliance rule pointer 107 may be updated to point to an updated external compliance rule 106B as needed.

[0054]

[0062] At least one of the compliance rules 106 may reference a global registry 108 (external to the security token 102), i.e., at least one of the compliance rules 106 accesses information stored in a data storage smart contract 128. By storing the compliance rules 106 external to the security token 102, for example, if there is a change in SEC regulation and the at least one compliance rule 106 needs to be updated, the at least one compliance rule 106 may be updated without modifying the security token 102 itself. Alternatively, the at least one compliance rule 106 may be included in the security token 102 itself. In that case, modifying (e.g., revoking and redeploying) the at least one compliance rule 106 requires modifying the security token 102. Optionally, token transactions that do not use any compliance rules 106 are also possible; for example, the default behavior may be to approve all transactions regardless of any compliance rules 106.

[0055]

[0063] The global registry 108 may be a collection of smart contracts 128-134. The smart contracts 128-134 include a data storage smart contract 128 that stores data. The data stored in the data storage smart contract 128 may relate to compliance with SEC regulations (e.g., an indication of whether the investor 120 qualifies under an exemption from SEC regulations), personally identifiable information (PII) of the investor 120, an indication of whether AML / KYC has been performed for the investor 120, and / or whether a freeze has been placed on the security token 102, the custodian 116, the broker-dealer 118, and / or the investor 120.

[0056]

[0064] The data structure 110 in the data storage smart contract 128 may store at least one investor element, each having information about a particular investor 120. Additionally, each investor element may include the investor's brokerage dealer 118 address (e.g., Ethereum address) and / or various regulatory certification information (e.g., whether AML / KYC has been performed for the investor 120, the investor's 120 country of origin, the length of time a particular token has been owned by the investor 120, etc.). Attributes in an investor element may include other information about the investor 120, collected by the brokerage dealer 118, for example, during onboarding. Such information may include the client's name, taxpayer identification number (e.g., Social Security number), address, telephone number, email address, date of birth, information from a driver's license, passport information, or other government-issued identification document, employment status and occupation, whether the client is employed by a brokerage firm, annual income, net worth, account investment objectives, and / or any other data that can be used to distinguish an individual's identity.

[0057]

[0065] Attributes in an investor element (e.g., values ​​of slots in an investor element) may be stored, for example, as comma-separated values, a hash table, a mapping, a dictionary, and / or key / value pairs, as shown in FIG. 2A . Each investor element may be created by the owner 112, the issuer 114, the brokerage dealer 118, the custodian 116, and / or the investor 120 (e.g., if the investor 120 is an external investor). Investor elements in the data storage smart contract 128 may be updated as needed. For example, when the investor 120 closes their account with the brokerage dealer 118, the corresponding investor element may be deleted from the data storage smart contract 128. Additionally or alternatively, the investor 120 may be responsible for creating, updating, and / or deleting attributes in the investor element 223 associated with them, for example, if the investor 120 is an external investor.

[0058]

[0066] The data storage smart contract 128 may include an investor element for each instance of the investor 120 for each broker dealer 118 with which the investor 120 has an account. That is, the data storage smart contract 128 may store multiple investor elements for investors 120 who have accounts with multiple broker dealers 118. In an example, the investor elements for an investor 120 may be created, updated, and / or deleted only by the broker dealer 118 with which the investor 120 is associated, although other configurations are possible. Thus, each broker dealer 118 may preferably create, modify, or delete investor elements associated with investors 120 who are clients of the respective broker dealer 118.

[0059]

[0067] Optionally, one or more other types of elements may be stored in the data storage smart contract 128, including attributes for various actors in the system 100. In an example, the other elements (i.e., other than the investor element) may include at least one custodian element, at least one broker dealer element, and / or at least one security token element. In an example, the broker dealer element for a broker dealer 118 may be created, updated, and / or deleted only by the custodian 116 with which the broker dealer 118 is associated, although other configurations are possible. Optionally, issuer elements and / or security token exchange elements may be stored for all issuers 114 and / or security token exchanges 124 in the system. Attributes of one of the other elements (e.g., values ​​of slots in the element) may be stored as comma-separated values, hash tables, mappings, dictionaries, key / value pairs, etc.

[0060]

[0068] As described above, each smart contract (e.g., security token 102) may be stored at an address that can be used to invoke methods implemented by the smart contract. Traditional solutions for upgrading smart contracts maintain the same address for the smart contract before and after the upgrade. For example, upgrading a smart contract via the proxy pattern involves deploying (1) a proxy contract at an address that remains unchanged, and (2) a non-proxy contract that the proxy contract points to. The non-proxy contract implements the substantial functionality of the contract, while the proxy contract simply points to the address of the non-proxy contract (which has little or no other functionality). During the upgrade, the address that the proxy contract points to is changed to the newly deployed non-proxy contract, but the proxy contract's address (the address at which the proxy contract is invoked) remains unchanged.

[0061]

[0069] In contrast, according to the present system and method, upgrading a first smart contract may include (1) deploying a second smart contract and changing the address (in the upgraded address 111 field of the first smart contract) to point to the second smart contract, (2) issuing a new token 102 in the second smart contract to an intermediate address (e.g., the issuer's address), (3) migrating the old token 102 in the first smart contract (held in a set of token holder addresses) to an address in the second smart contract, and (4) moving the new token in the second smart contract from the intermediate address to the set of token holder addresses (that previously held the old token 102 in the first smart contract). Thus, the first smart contract remains deployed and, if necessary, auditable after the upgrade because both the first and second smart contracts are viewable / searchable.

[0062]

[0070] Optionally, a parent address 117 may be set in the second smart contract when it is deployed. The parent address 117 may point to the address of the first smart contract. The parent address 117 may allow for tracing the token history in reverse chronological order, if desired.

[0063]

[0071] Note that the address of a smart contract (e.g., security token 102) is different from the upgraded address 111 field in the smart contract. The address "of" the smart contract is the address where the smart contract is stored in the distributed ledger. The upgraded address 111 is a field in the smart contract whose value points to (the address of) a subsequent version of the smart contract.

[0064]

[0072] 2A is a block diagram illustrating a data structure 110 used in the system 100 shown in FIG. 1. One or more data structures 110 may be stored in a data storage smart contract 128. Each data structure 110 may include one or more elements 223A-223M, each element 223 corresponding to (i.e., containing information about) a particular custodian 116, broker-dealer 118, or investor 120. Optionally, security token elements 223 may also be stored in one or more data structures 110.

[0065]

[0073] In some configurations, all elements 223 within a particular data structure 110 correspond to the same type of entity, e.g., all elements 223 correspond to investors 120 in the system 100. In this configuration, the data storage smart contract 128 may include a first data structure 110 for all investors 120 in the system 100, a second data structure 110 for all custodians 116, a third data structure 110 for all brokerage dealers 118, and / or a fourth data structure for all security tokens 102. Alternatively, a particular data structure 110 may include elements 223 corresponding to different types of entities, i.e., investor elements 223, custodian elements 223, and brokerage dealer elements 223 may be included in a single data structure.

[0066]

[0074] In some configurations, each element 223 may include two storage slots 215A-215N, where each storage slot is a fixed number of bytes. For example, the storage slots may be 32 bytes long (or any suitable length), e.g., each storage slot 215 may be a slot in the Solidity programming language. Although each element 223 is shown in FIG. 2A as including two storage slots 215 (i.e., N=2M), an element 223 may include only a single storage slot 215 (i.e., N=M) or three or more storage slots 215 (i.e., N>2M).

[0067]

[0075] Each storage slot 215 may contain a key 219A-219N and a value 221A-221N, i.e., a key / value pair. Each key 219 may be a nested structure, with a first level indicating the type of entity (e.g., custodian 116, broker dealer 118, investor 120, etc.) to which the element 223 corresponds, and a second level indicating an address (e.g., an Ethereum address) owned by the particular entity. In this way, the key 215 may be encoded (by entity type). Instead of indexing by address, the second level of the key 219 may be indexed in other ways, such as by a hash of the entity / investor / security token name. Optionally, the key 219 may include more than two levels. If the element 223 contains two slots 215, the key 219 in the first storage slot 215 of the element 223 may be the same as or different from the key 219 in the second slot 215 of the element 223.

[0068]

[0076] The information included in value 221 may vary depending on the type of entity to which element 223 corresponds. Each value 221 in data structure 110 may be a nested structure, with a first level indicating the type of entity to which element 223 corresponds (e.g., custodian 116, broker dealer 118, investor 120, etc.), and one or more additional levels indicating additional information. In this manner, value 221 may be encoded (with the type of entity) so that a computing device (e.g., network node 140) knows how to interpret the data in value 221. In other words, the computing device (e.g., network node 140) interprets the data in value 221 differently based on the encoding, i.e., the type indicated in value 221. Multiple parameters may be bit-shifted (and / or concatenated) to fit into the same value 221.

[0069]

[0077] For example, the value 221 in the first storage slot 215 in a particular investor element 223 may include one or more bits indicating "investor" at a first level and a PII hash for the investor 120 at a second level. Additionally, the value 221 in the second storage slot 215 in the investor element 223 may include one or more bits indicating other attributes of the investor 120.

[0070]

[0078] Other examples of data structures 110 include a custodian element 223, a broker dealer element 223, and / or an optional security token element 223. Each custodian element 223 may include attributes related to a particular custodian 116. Optionally, a custodian element 223 may reference the addresses (e.g., Ethereum addresses) of one or more investor elements 223, broker dealer elements 223, and / or security token elements 223 with which the custodian element 223 is associated. For example, a custodian element 223 may include the addresses (e.g., Ethereum addresses) of one or more broker dealers 118 with which the custodian 116 is associated.

[0071]

[0079] Each broker dealer element 223 may include attributes related to a particular broker dealer 118. The value 221 in a particular broker dealer element 223 may include one or more bits indicating “broker dealer” at a first level and one or more bits indicating attributes related to the broker dealer 118 at a second level. Optionally, a broker dealer element 223 may reference the addresses (e.g., Ethereum addresses) of one or more investor elements 223, custodian elements 223, and / or security token elements 223 with which the broker dealer element 223 is associated. For example, a broker dealer element 223 may include the addresses (e.g., Ethereum addresses) of one or more custodians 116 with which the broker dealer 118 is associated.

[0072]

[0080] Each security token element 223 may include attributes related to a particular security token 102. The value 221 in the optional security token element 223 may include one or more bits indicating "security token" at a first level and one or more bits indicating attributes related to the security token 102 at a second level. Various types of information related to the security token 102 may be included in the value of the security token element 223.

[0073]

[0081] Each optional issuer element 223 may include attributes related to a particular issuer 114. The value 221 in a particular optional issuer element 223 may include one or more bits indicating "issuer" at a first level and one or more bits indicating attributes related to the issuer 114 at a second level. Optionally, the issuer element 223 may reference one or more investors 120, custodians 116, broker dealers 118, and / or addresses (e.g., Ethereum addresses) of the security token 102 with which the issuer 114 is associated.

[0074]

[0082] Figure 2B is a block diagram illustrating the hierarchy of entities in the system 100 shown in Figure 1. Specifically, Figure 2B illustrates the relationships between one or more investors 120, optional one or more broker-dealers 118, optional one or more custodians 116, and / or one or more owners 112 of the system 100.

[0075]

[0083] 2B may define data permissions in system 100. The hierarchy may be stored in any suitable format and / or may be implicit in the data stored in various elements 223.

[0076]

[0084] Data structure 110 may store multiple investor elements 223 for investors 120 who have accounts with multiple broker dealers 118. In an example, a first investor element 223A may describe a particular investor 120 according to data collected by a first broker dealer 118A, for example, during onboarding performed by the first broker dealer 118A. Similarly, a different investor element 223B may describe the same particular investor 120 according to data collected by a different broker dealer 118B, for example, during onboarding performed by the different broker dealer 118B. Additionally or alternatively, investor element 120I may be stored for an external investor who is not a client of a broker dealer 118 or custodian 116.

[0077]

[0085] Any smart contract implementing the global registry 108 may be executed by a virtual machine (e.g., an Ethereum Virtual Machine) running on a network node 140. Each entity in the system 100 may have different data permissions for the data storage smart contract 128. In an example, an owner 112 may add, remove, and / or modify elements of a custodian 116, a broker dealer 118, and / or an investor 120 in his hierarchy. A custodian 116 may add, remove, and / or modify elements of a broker dealer 118 and / or an investor 120 in his hierarchy. A broker dealer 118 may add, remove, and / or modify elements of an investor 120 in his hierarchy. An owner 112 may add, remove, and / or modify elements of a custodian 116, a broker dealer 118, and / or an investor 120 in his hierarchy. In some configurations, the investor 120 may have permission to invoke the transfer() method 109 to move funds and / or tokens between two addresses.

[0078]

[0086] Figure 3 is a block diagram illustrating three different versions 302A-302C of an upgradeable smart contract. In other words, Figure 3 shows a smart contract 302 that has been upgraded twice, resulting in a first version 302A of the smart contract, a second version 302B of the smart contract, and a third version 302C of the smart contract. In some configurations, the smart contract 302 shown in Figure 3 may implement the security token 102 described above. Although not shown in Figure 3, each smart contract 302 described herein may implement any or all of the same functions, methods, and / or parameters described for the security token 102 in Figure 1.

[0079]

[0087] Each smart contract 302 holds the address to its descendant subsequent contract. This address may be stored in each smart contract 302 in an upgraded address 111A-111C field, respectively. The upgraded address 111A in the first version of the smart contract 302A points to the address of the second version of the smart contract 302B, and the upgraded address 111B in the second version of the smart contract 302B points to the address of the second version of the smart contract 302B. It points to the address of the third version 302C of the smart contract. As such, the third version 302C is a child / descendant of the second version 302B, which is a child / descendant of the first version 302A.

[0080]

[0088] Assuming that the third version 302C of the smart contract is the current version, the upgraded address 111C of the third version 302C of the smart contract may be unset, e.g., set to all bits "0," all bits "1," or any other value that does not correspond to an address in the distributed ledger 122 on which the smart contract 302 is implemented. An unset upgraded address 111C means that the third version 302C of the smart contract is the currently active implementation of the smart contract 302, e.g., the most recently deployed version of the smart contract 302. In some configurations, the upgraded address 111 in the smart contract 302 may be initially set by the issuer 114 of the smart contract 302, e.g., by invoking a method implemented in the smart contract 302 in the distributed ledger 122.

[0081]

[0089] In some configurations, the upgraded address 111 field is not changed once it is set. Permanently setting the upgraded address 111 field in the smart contract 302 to point to the same subsequent version of the smart contract 302 ensures that the upgrade history of the smart contract 302 is auditable. To audit the upgrade path of the smart contract 302, the versions can be traced backward, for example, from the third version 302C to the second version 302B to the first version 302A. Beyond auditing, there is no need to trace backward during the lifetime of the smart contract 302, because the primary concern is whether the pointed-to address is the active version of the smart contract 302, and if not, how to trace back to the active version.

[0082]

[0090] Optionally, each smart contract 302 has an address to its parent contract. This address may be stored in the parent address 117A-117C fields. Assuming that the first version 302A of the smart contract is the oldest version, the optional parent address 117A in the first version 302A of the smart contract may be unset, may be set to, for example, all bits "0," all bits "1," or any other value that does not correspond to an address in the distributed ledger 122 on which the smart contract 302 is implemented. The optional parent address 117B in the second version 302B of the smart contract points to the address of the first version 302A of the smart contract, and the upgraded address 117C in the third version 302C of the smart contract points to the address of the second version 302B of the smart contract. Thus, the first version 302A is the parent of the second version 302B, which is the parent of the third version 302C.

[0083]

[0091] In a first example, an event is published when a contract is upgraded, e.g., when the upgraded address 111 and / or parent address 117 is set. In an example, a device (e.g., belonging to an investor 120, a broker dealer 118, a custodian, an issuer 114, an owner 112, or a network node 140) may intercept such an event. In an example, the event indicates the upgraded address 111 and / or the set parent address 117. The child smart contract 302 is directly invoked using the upgraded address 111 in the event. It is possible.

[0084]

[0092] In a second example, the calling device may optionally invoke the parent smart contract 302 to determine whether the upgraded address 111 and / or the parent address 117 are set in the parent smart contract 302. In the example, a getter function in the child smart contract 302 may call ) parent address 117, and a getter function in the parent smart contract 302 may return the upgraded address 111 (which points to its child). In an example, such a function may return a zero address when the upgraded address 111 and / or parent address 117 are not set.

[0085]

[0093] In examples where a smart contract 302 implements a security token 102, each version of the smart contract 302 may include a token supply parameter 115. The token supply parameter 115 may indicate the total number of tokens outstanding in the security token 102 / smart contract 302, e.g., the token supply parameter 115 may be the sum of the token balances of all addresses in the balance table 105 of the security token 102 / smart contract 302.

[0086]

[0094] When a subsequent version of the smart contract 302 is deployed, the issuer 114 (or owner 112) sets the total supply parameter 115 (of the subsequent version of the smart contract 302) to match the total supply parameter 115 of the parent version. In the example of Figure 3, the total supply parameter 115B of the second version of the smart contract 302B may be set to be equal to the total supply parameter 115A of the first version of the smart contract 302A after deployment of the second version of the smart contract 302B. Similarly, the total supply parameter 115C of the third version of the smart contract 302C may be set to be equal to the total supply parameter 115B of the second version of the smart contract 302B after subsequent deployment of the third version of the smart contract 302C.

[0087]

[0095] In examples where the smart contract 302 implements a security token 102, each version 302 may also include balance tables 105A-105C that show the token balances and addresses of tokens issued in each version of the security token 102 / smart contract 302. The token balances and addresses in each balance table 105 may be considered part of the state of the smart contract 302. As illustrated in Figures 4A-4D, the state / balance tables 105 for both the parent and child versions of the smart contract may be updated to reflect the transition of tokens in the parent version to the child version.

[0088]

[0096] 4A-4D are block diagrams illustrating different stages in the migration of a token 102 to a subsequent version of a smart contract 302. In the example of FIGS. 4A-4D, the upgraded smart contract 302 implements a security token 102. Specifically, each of FIGS. 4A-4D shows two balance tables 105: the table 105A on the left is implemented for a (deprecated) parent smart contract 302 (and tracks tokens in the parent smart contract 302), and the table 105B on the right is implemented for a child smart contract 302 (and tracks tokens in the child smart contract 302), which is a subsequent version of the parent smart contract 302. Assume the address of the child smart contract 302 is address D. In other words, the child smart contract 302 is stored at address D in the distributed ledger 122.

[0089]

[0097] FIG. 4A shows the transition of tokens to a subsequent version of smart contract 302. 1 shows the first stage of the process. First, assume that the parent smart contract 302 (represented by the balance table 105A on the left) contains 450 outstanding tokens (the total supply parameter 115 is equal to 450). The outstanding tokens in the parent smart contract 302 can be distributed to three different addresses: 100 to address A, 150 to address B, and 200 to address C.

[0090]

[0098] After the child smart contract 302 is deployed, the issuer 114 (or owner 112) can allow or restrict tokens in the parent smart contract 302 from trading. Restricting transactions may force an upgrade by restricting all transactions from occurring within the parent smart contract 302 unless the recipient is an address that matches the address in the upgraded address 111 field (address D in this example). In other words, restricting transactions means that holders of tokens in the parent smart contract 302 can only move their holdings to the child smart contract 302. After the migration, the child smart contract 302 (at address D) becomes a holder in the parent smart contract 302. This provides pseudo-write functionality when holders migrate / move their tokens to the child smart contract 302's address (address D), while also providing a full audit trail of token transitions during the upgrade.

[0091]

[0099] When the child smart contract 302 (represented by the balance table 105B on the right) is first deployed, it has no outstanding tokens (total supply parameter 115 equals 0) or token holders, so the balance table 105B is empty. Then, as part of the upgrade process, new tokens (a number equal to the parent smart contract's 302 total supply parameter 115: 450) are issued in the child smart contract, e.g., 450 new tokens are issued in the child smart contract 302 to issuer address 114. When the old tokens (in the parent smart contract 302) are migrated to address D, the corresponding new tokens (in the child smart contract 302) are moved from the issuer address to the token holder addresses.

[0092]

[0100] 4B-4D show the migration path of old tokens (in the parent smart contract 302) held at three addresses (A, B, and C) to the address of the child smart contract 302 (address D), and the corresponding movement of new tokens (in the child smart contract 302) from the issuer's address to the three addresses (A, B, and C). Note that instead of restricting the trading of tokens in the parent smart contract 302, the issuer 114 can allow the parent smart contract 302 to continue the trading. If the parent smart contract 302 continues the trading, the tokens in the parent smart contract 302 may be moved to an address other than the address of the child smart contract 302 (address D). For example, if the issuer 114 allows the parent smart contract 302 to continue the trading, a token holder associated with address A may move their 50 tokens to address B (instead of address D).

[0093]

[0101] Future upgrades follow the same flow as described in connection with Figures 4A-4D, with the issuer 114 allowing (or not allowing) tokens in the deprecated parent smart contract to actively trade. Enforcement (whether a token is allowed to continue trading in the parent smart contract 302) can occur in (1) compliance rules 106A implemented in the token 102 / smart contract 302 itself, and / or (2) compliance rules 106B implemented outside the token 102 / smart contract 302. In other words, in response to an upgrade being enforced, compliance rules in (or otherwise associated with) the parent / deprecated token 102 are enforced. This applies to all token transactions. The transaction requires that the transaction be sent to the address (Address D) of the child smart contract 302. In some configurations, the compliance rules 106 may determine whether the token in the parent smart contract 302 is allowed to continue trading by determining whether the upgraded address 111 field is set (indicating that trading is restricted) or not set (indicating that trading is permitted).

[0094]

[0102] 4B illustrates a second stage during a token 102 migration in which 100 tokens are moved from address A to address D. In other words, the holder (associated with address A) moves 100 old tokens in the parent smart contract 302 to address D of the child smart contract 302. This effectively writes these 100 old tokens to the parent smart contract 302, as they will never be moved from address D. In an example, the migration of old tokens (e.g., from address A, B, or C to address D) may involve invoking a move method implemented in the parent smart contract 302 in the distributed ledger 122. The move method may be invoked by the issuer 114, the owner 112, or a token holder associated with the transfer address.

[0095]

[0103] In addition to migrating the old tokens from the token holder address to address D in the parent smart contract 302, corresponding new tokens in the child smart contract 302 are moved from the issuer address to the token holder address. In the example, a sufficient number of new tokens are issued to the issuer address in the child smart contract 302 (during the upgrade process) to replace all of the old tokens in the parent smart contract 302. For example, 450 new tokens are issued to the issuer address in the child smart contract 302. In the example, all of the new tokens (in the child smart contract 302) are issued at once. Then, as the old tokens (in the parent smart contract 302) are migrated from the token holder address to the address (address D) of the child smart contract 302, a corresponding number of new tokens (in the child smart contract 302) are moved from the issuer address to the token holder address.

[0096]

[0104] Thus, after 100 old tokens (in the parent smart contract 302) are moved from address A to address D, 100 corresponding new tokens (in the child smart contract 302) may be moved from the issuer's address to address A. In the example, the address of the move method call that sends the old tokens to address D may be used as the output address for moving the new tokens from the issuer's address.

[0097]

[0105] 4C illustrates a third stage during the token 102 migration, during which 150 tokens are transferred from address B to address D. In other words, the holder (associated with address B) transfers 150 old tokens in the parent smart contract 302 to address D in the child smart contract 302, effectively writing these 150 old tokens. In the example, this transfer involves the issuer 114, owner 112, or token holder (associated with the transfer address) invoking a transfer method implemented in the parent smart contract 302 in the distributed ledger 122. After this transfer of the 150 old tokens, address D (in the parent smart contract 302) may hold 250 old tokens in the parent smart contract 302: 100 from address A and 150 from address B. Additionally, the corresponding 150 new tokens in the child smart contract 302 may be transferred from the issuer's address to address B. At that point, the issuer address will hold the remaining 200 (450 - 100 to Address A - 150 to Address B) new tokens.

[0098]

[0106] 4D illustrates a fourth stage during the token 102 migration, during which 200 tokens are transferred from address C to address D. In other words, the holder (associated with address C) transfers 200 old tokens in the parent smart contract 302 to address D in the child smart contract 302, effectively writing these 200 old tokens. In the example, this transfer involves the issuer 114, owner 112, or token holder (associated with the transfer address) invoking a transfer method implemented in the parent smart contract 302 in the distributed ledger 122. After this transfer of the 200 old tokens, the final state of the parent smart contract 302 has a single holder, address D (in the child smart contract 302), holding a total supply of 450 old tokens in the parent smart contract 302: 100 from address A, 150 from address B, and 200 from address C. This essentially locks / writes the old tokens in the parent smart contract 302 while proving that they have been migrated to the child smart contract 302.

[0099]

[0107] Additionally, the corresponding 200 new tokens in the child smart contract 302 may be moved from the issuer's address to address C. At that point, the issuer's address holds zero new tokens, and the issuer's address may optionally be removed from the balance table 105B.

[0100]

[0108] 5 is a flow diagram illustrating a method 500 for deploying a child smart contract 302. The method 500 may be performed by at least one processor executing a virtual machine in the system 100, e.g., at least one processor in a network node 140. The method 500 may include executing one or more methods embodied in the security token 102 / smart contract 302, e.g., stored in the distributed ledger 122. Additionally, the method 500 may utilize one or more parameters in the security token 102 / smart contract 302, e.g., stored in the distributed ledger 122.

[0101]

[0109] The method 500 begins at step 502, in which at least one processor deploys a child smart contract 302, which is a successor version (also referred to as a "child") of the parent smart contract 302, in the distributed ledger 122. Although not the currently implemented version, the parent smart contract 302 remains deployed after deployment of the child smart contract 302 to maintain auditability. In an example, the child smart contract 302 is deployed by storing the child smart contract 302 in the distributed ledger 122 and invoking, for example, an upgrade method implemented in the parent smart contract 302, which is also implemented in the distributed ledger 122. The upgrade method may be invoked by the owner 112 or issuer 114 of the parent smart contract 302.

[0102]

[0110] The method 500 proceeds to step 504, where at least one processor sets the upgraded address 111 field in the parent smart contract 302 to point to the address of the child smart contract 302. Each smart contract 302 may include an address to its child smart contract 302, if any. For a smart contract 302 without any child smart contracts 302 (i.e., the smart contract 302 is the currently active implementation of the smart contract 302), the upgraded address 111 field may be unset, for example, set to all bits "0," all bits "1," or any other value that does not correspond to an address in the distributed ledger 122 on which the smart contract 302 is implemented. The upgraded address 111 in the smart contract 302 is updated upon issuance of the smart contract 302, for example, by invoking a method implemented in the smart contract 302 in the distributed ledger 122. It can be set by the operator 114.

[0103]

[0111] In some configurations, the upgraded address 111 field is not changed once it is set. Permanently setting the upgraded address 111 field in the smart contract 302 to point to the same subsequent version of the smart contract 302 ensures that the upgrade history of the smart contract 302 is auditable.

[0104]

[0112] The method 500 proceeds to optional step 506, where the at least one processor initiates an event, e.g., an Ethereum event, indicating that the upgraded address 111 field (of the parent smart contract 302) has been set. In an example, the event may indicate the upgraded address 111 and, optionally, the address of the parent smart contract 302. In an example, these events are broadcast to a network of nodes 140 implementing the distributed ledger 122. In an example, a device (e.g., belonging to an investor 120, broker dealer 118, custodian, issuer 114, owner 112, or network node 140) may intercept such events.

[0105]

[0113] The method 500 proceeds to step 508, where the at least one processor sets the parent address 117 field in the child smart contract 302 to point to the address of the parent smart contract 302. Each smart contract 302 may include an address to its parent smart contract 302, if any. For a smart contract 302 without a parent smart contract 302 (i.e., if the smart contract 302 is the oldest version of the smart contract 302), the parent address 117 field may be unset and may be set, for example, to all bits "0," all bits "1," or any other value that does not correspond to an address in the distributed ledger 122 on which the smart contract 302 is implemented. The parent address 117 in a smart contract 302 may be set by the issuer 114 of the smart contract 302, for example, by invoking a method implemented in the smart contract 302 in the distributed ledger 122.

[0106]

[0114] The method 500 proceeds to optional step 510, where the at least one processor initiates an event, e.g., an Ethereum event, indicating that the parent address 117 field (of the child smart contract 302) has been set. In an example, the event may indicate the parent address 117 and, optionally, the address of the child smart contract 302. In an example, these events are broadcast to a network of nodes 140 implementing the distributed ledger 122. In an example, a device (e.g., belonging to an investor 120, broker dealer 118, custodian, issuer 114, owner 112, or network node 140) may intercept such events.

[0107]

[0115] The method 500 proceeds to optional step 512, where the at least one processor sets the token supply parameter 115 in the child smart contract 302 equal to the token supply parameter 115 in the parent smart contract 302. In examples, optional step 512 is performed only if the smart contract 302 implements a security token 102. In such a configuration, the token supply parameter 115 may indicate the total number of outstanding tokens in the smart contract 302; e.g., the token supply parameter 115 may be the sum of the token balances of all addresses in the balance table 105 of the smart contract 302. In contrast, if the smart contract 302 in method 500 does not implement a security token 102, optional step 512 is not performed.

[0108]

[0116] 6 is a flow diagram illustrating a method 600 for migrating outstanding tokens in a parent smart contract 302 to a child smart contract 302. The method 600 may be performed by at least one processor executing a virtual machine in the system 100, e.g., at least one processor in a network node 140. The method 600 may include executing one or more methods embodied in the security token 102 / smart contract 302, e.g., stored in the distributed ledger 122. Additionally, the method 600 may utilize one or more parameters in the security token 102 / smart contract 302, e.g., stored in the distributed ledger 122.

[0109]

[0117] The method 600 in Figure 6 is performed when the parent smart contract 302 and the child smart contract 302 each implement a respective security token 102. In some configurations, the method 600 in Figure 6 may be performed subsequent to the method 500 in Figure 5, for example, after the child smart contract 302 is deployed. Thus, the parent smart contract 302 and the child smart contract 302 in the method 600 in Figure 6 may be the same as the parent smart contract 302 and the child smart contract 302, respectively, described in the method 500 in Figure 5. In some configurations, the method 500 in Figure 5 and / or the method 600 in Figure 6 is initiated in response to the issuer 114 (of the parent smart contract 302) invoking an upgrade method implemented in the parent smart contract 302, e.g., also implemented in the distributed ledger 122.

[0110]

[0118] Method 600 begins at optional step 602, in which at least one processor determines whether old tokens in the parent smart contract 302 are restricted from trading after deployment of the child smart contract 302. In an example, the issuer 114 decides whether to allow, restrict, or allow further trading of the parent smart contract 302. If trading is restricted, all transactions of old tokens in the parent smart contract 302 must use the address of the child smart contract 302 as the output address of the transaction, such as address D in the example of FIGS. 4A-4D. In contrast, if the issuer 114 allows the parent smart contract 302 to continue trading, the old tokens in the parent smart contract 302 may be moved to an address other than the address of the child smart contract 302 (address D).

[0111]

[0119] Enforcement (whether an old token in the parent smart contract 302 is allowed to continue trading) can occur in (1) compliance rules 106A implemented in the security token 102 / smart contract 302 itself, and / or (2) compliance rules 106B implemented outside the security token 102 / smart contract 302. For example, the issuer 114 can invoke a method implemented in the parent smart contract 302 to indicate (e.g., in compliance rules 106) that trading of an old token in the parent smart contract 302 is restricted / upgrade is forced, and then at least one processor checks this indication when a movement / transaction of the old token in the parent smart contract 302 is initiated. In some configurations, the compliance rules 106 can determine whether a token in the parent smart contract 302 is allowed to continue trading by determining whether the upgraded address 111 field is set (indicating trading is restricted) or not set in the parent smart contract 302 (indicating trading is permitted). In some configurations, the remaining steps in method 600 may involve, for example, determining that an older token in the parent smart contract 302 is restricted from trading after deployment of the child smart contract 302. It is executed only based on (e.g., in response to)

[0112]

[0120] The method 600 proceeds to step 604, where the at least one processor issues new tokens in the child smart contract 302 to an intermediate address. In an example, the number of new tokens issued in the child smart contract is equal to the total supply parameter 115 of the parent smart contract 302. In an example, the intermediate address is the address of the issuer 114. In other words, new tokens may be issued in the child smart contract 302 that are initially held at the issuer's address.

[0113]

[0121] The method 600 proceeds to step 606, where the at least one processor migrates all old tokens in the parent smart contract 302 from token holder addresses to addresses of the child smart contract 302. The parent smart contract 302 may include a balance table 105 (in the distributed ledger 122) that shows the token balances of all addresses that hold old tokens in the parent smart contract 302; for example, the balance table 105 may show which addresses (e.g., Ethereum addresses) hold how many tokens in the parent smart contract 302. Similarly, the child smart contract 302 may include a balance table 105 (in the distributed ledger 122) that shows the token balances of all addresses that hold old tokens in the child smart contract 302.

[0114]

[0122] To perform the migration in step 606, the at least one processor may perform a move of the old tokens at the token holder address to the address of the child smart contract 302. This may include, for example, invoking a move method invoked by the issuer 114, owner 112, or token holder associated with the migration address and implemented in the parent smart contract 302 in the distributed ledger 122.

[0115]

[0123] The method 600 proceeds to step 608, where the at least one processor moves at least one new token in the child smart contract 302 from the intermediate address to the token holder address. For example, if in step 606, 100 old tokens (in the parent smart contract 302) were migrated from the token holder address, then in step 608, 100 new tokens (in the child smart contract 302) are moved from the intermediate address to the token holder address.

[0116]

[0124] The method 600 proceeds to optional step 610, where the at least one processor determines whether any old tokens in the remaining token holder addresses have not yet been migrated. If there are any old tokens that have not yet been migrated, the method proceeds to optional step 612, where the at least one processor selects a new token holder address and repeats steps 606 through 608 again for the new token holder address.

[0117]

[0125] After the final execution of step 608 for the parent smart contract 302, the final state of the parent smart contract 302 has a single address (the address of the child smart contract 302) that holds the total supply of old tokens in the parent smart contract 302. This essentially locks / writes the holdings of the parent smart contract 302, proving that the tokens have been transferred to the child smart contract 302. After the final execution of step 608, the issuer address typically does not hold any of the new tokens.

[0118]

[0126] In step 610, if there are no more old tokens to migrate (or If step 610 is not performed, method 600 may end at step 614. Figure 6 shows method 600 being performed iteratively for each address holding tokens in the parent smart contract 302. Alternatively, step 606 can be performed to transfer tokens for all token holder addresses holding tokens in the parent smart contract / security token 102, and step 608 can be performed to move new security tokens from the intermediate address to all token holder addresses without repeating the execution of steps 606-608 for each token holder address before moving to the next token holder address.

[0119]

[0127] After method 500 and / or method 600, the child smart contract 302 may be invoked. In a first example, an event is issued when the contract is upgraded, e.g., when the upgraded address 111 and / or the parent address 117 are set as in steps 504 and 508. In an example, a device (e.g., belonging to the investor 120, broker dealer 118, custodian, issuer 114, owner 112, or network node 140) may intercept such an event. In an example, the event indicates the upgraded address 111 and / or the set parent address 117. The child smart contract 302 may be directly invoked using the upgraded address 111 in the event. The calling device may invoke a method implemented in the child smart contract 302 using the upgraded address (the address of the child smart contract 302) in the event.

[0120]

[0128] Alternatively, the calling device may optionally invoke the parent smart contract 302 to determine whether the upgraded address 111 is set in the parent smart contract 302. In an example, a getter function in the parent smart contract 302 may return the upgraded address 111 (which points to its child smart contract 302). In an example, such a function may return a zero address when the upgraded address 111 and / or the parent address 117 are not set. Computer System Overview

[0129] Embodiments of the present disclosure include various steps and operations described above. These steps and operations may be performed by hardware components or may be embodied in machine-executable instructions that can be used to cause a general-purpose or special-purpose processor programmed to perform the steps. Alternatively, the steps may be performed by a combination of hardware, software, and / or firmware. Accordingly, FIG. 7 is a block diagram illustrating an exemplary computer system 700 in which embodiments of the present disclosure may be utilized. According to this example, computer system 700 includes an interconnect 702, at least one processor 704, at least one communication port 706, at least one main memory 708, at least one removable storage medium 710, at least one read-only memory 712, and at least one mass storage device 714.

[0121]

[0130] The at least one processor 704 can be any known processor. The at least one communication port 706 can be or include, for example, an RS-232 port for use with a modem-based dial-up connection, a 10 / 100 Ethernet port, or a Gigabit port using copper or fiber. The nature of the at least one communication port 706 can be selected depending on the network, such as a local area network (LAN), a wide area network (WAN), or any network to which the computer system 700 connects. The at least one main memory 708 can be a random access memory (RAM) or any other dynamic storage device commonly known in the art. The at least one read-only memory 712 stores static data, such as instructions for the at least one processor 704. The storage device may be any static storage device such as a programmable read-only memory (PROM) chip for storing functional information.

[0122]

[0131] At least one mass storage device 714 can be used to store information and instructions. In examples, hard disks (such as magnetic disk drives or solid-state drives using serial / parallel ATA or SCSI interfaces), optical disks, disk arrays such as RAID, or any other mass storage device may be used. The interconnect 702 can be or include one or more buses, bridges, controllers, adapters, and / or point-to-point connections. The interconnect 702 communicatively couples the at least one processor 704 with other memory, storage, and communication blocks. The interconnect 702 can be a PCI / PCI-X or SCSI-based system bus, depending on the storage device used. The at least one removable storage medium 710 can be any type of external hard drive, floppy drive, compact disc read-only memory (CD-ROM), compact disc re-writable (CD-RW), digital video disc read-only memory (DVD-ROM), Blu-ray disc read-only memory (BD-ROM), Blu-ray disc recordable (BD-R), Blu-ray disc recordable erasable (BD-RE).

[0123]

[0132] The components described above are intended to illustrate some types of possibilities. The foregoing examples should not limit the disclosure in any way, as they are merely exemplary embodiments.

[0124]

[0133] 8 is a block diagram illustrating another exemplary computing device 800 in which embodiments of the present disclosure may be utilized. The exemplary computing device 800 may be used to implement any of the global registry 108, the owner 112, the issuer 114, the custodian 116, the broker dealer 118, the investor 120, one of the network nodes 140 that stores a copy of the distributed ledger 122, the securities token exchange 124, and / or a virtual machine (e.g., the Ethereum Virtual Machine) that executes any of the smart contracts described herein. The computing device 800 includes at least one memory 802, at least one processor 804, optionally at least one network interface 806, an optional display device 808, an optional input device 810, and an optional power supply 812.

[0125]

[0134] In examples, the at least one memory 802 can be any device, mechanism, or entered data structure used to store information. In examples, the at least one memory 802 can be or include any type of volatile, non-volatile, and / or dynamic memory. In examples, the at least one memory 802 can be a random access memory, a memory storage device, an optical memory device, a magnetic medium, a floppy disk, a magnetic tape, a hard drive, an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), an optical medium (compact disc, DVD, Blu-ray disc, etc.), etc.

[0126]

[0135] According to some embodiments, the at least one memory 802 may include one or more disk drives, flash drives, one or more databases, one or more tables, one or more files, local cache memory, processor cache memory, relational databases, flat databases, etc. Additionally, those skilled in the art will recognize that at least one memory 802 may be used in conjunction with one or more other devices. , recognize many additional devices and techniques for storing information. At least one memory 802 may be used to store instructions for executing one or more applications or modules on at least one processor 804. In examples, at least one memory 802 may be used in one or more examples to accommodate all or a portion of the instructions necessary to perform the functions described herein, e.g., in FIGS. 3-4.

[0127]

[0136] The at least one processor 804 can be any known processor, such as a general-purpose processor (GPP) or special-purpose (such as a field-programmable gate array (FPGA), application-specific integrated circuit (ASIC) or other integrated circuit or circuit configuration), or any programmable logic device. In an example, any of the functionality disclosed herein (e.g., in FIGS. 3-4) may be performed by the at least one processor 804 and at least one memory 802.

[0128]

[0137] In an example, the at least one optional network interface 806 includes or is coupled to at least one optional antenna for communicating with a network (such as one of the at least one networks 112 of the system 100). In an example, the at least one optional network interface 806 includes at least one of an Ethernet interface, a cellular radio access technology (RAT) radio, a Wi-Fi radio, a Bluetooth radio, or a near field communication (NFC) radio. In an example, the at least one optional network interface 806 includes a cellular radio access technology radio configured to establish a sufficient speed cellular data connection (mobile internet) with a remote server using a local area network (LAN) or a wide area network (WAN). In an example, the cellular radio access technology includes at least one of Personal Communications Services (PCS), Special Mobile Radio (SMR) service, Enhanced Special Mobile Radio (ESMR) service, Advanced Wireless Services (AWS), Code Division Multiple Access (CDMA), Global System for Mobile Communications (GSM) service, Wideband Code Division Multiple Access (W-CDMA), Universal Mobile Telecommunications System (UMTS), Worldwide Interoperability for Microwave Access (WiMAX), 3rd Generation Partnership Project (3GPP) Long Term Evolution (LTE), High Speed ​​Packet Access (HSPA), Third Generation (3G), Fourth Generation (4G), Fifth Generation (5G), etc., or other suitable communication services or combinations thereof. In an example, the at least one optional network interface 806 includes a Wi-Fi (IEEE 802.11) radio configured to communicate with a wireless local area network that communicates with a remote server rather than a wide area network. In an example, at least one optional network interface 806 includes a near field communication device limited to close proximity communications, such as a passive near field communication (NFC) tag, an active near field communication (NFC) tag, a passive radio frequency identification (RFID) tag, an active radio frequency identification (RFID) tag, a proximity card, or other personal area network device.

[0129]

[0138] In an example, the optional at least one display device 808 includes at least one of a light emitting diode (LED), a liquid crystal display (LCD), a light emitting diode (LED) display, an organic light emitting diode (OLED) display, an e-ink display, a field emission display (FED), a surface conduction electron emitter display (SED), or a plasma display. In an example, the optional at least one input device 810 includes at least one of a touch screen (including capacitive and resistive touch screens), a touch pad, a capacitive button, a mechanical button, a switch, a dial, a keyboard, a mouse, a camera, a biometric sensor / scanner, a microphone, etc. In an example, the optional at least one display device 808 includes at least one of a touch screen (including capacitive and resistive touch screens), a touch pad, a capacitive button, a mechanical button, a switch, a dial, a keyboard, a mouse, a camera, a biometric sensor / scanner, a microphone, etc. For user interaction with the computing device 800, the optional at least one display device 808 may include at least one of a touch screen, a touch pad, a capacitive button, a mechanical button, a switch, a dial, a keyboard, a mouse, a camera, a biometric sensor / scanner, a microphone, etc. 8. In an example, at least one optional power supply 812 is used to power various components of the computing device 800. term

[0139] Below are brief definitions of terms, abbreviations, and phrases used throughout this application.

[0130]

[0140] The term "determining" may include calculating, computing, generating, processing, deriving, investigating, looking up (e.g., looking up in a table, database, or another data structure), ascertaining, and the like. "Determining" may also include receiving (e.g., receiving information), accessing (e.g., accessing data in a memory), and the like. "Determining" may also include resolving, selecting, choosing, establishing, and the like.

[0131]

[0141] The phrase "based on" does not mean "based only on," unless otherwise specified. In other words, the phrase "based on" describes both "based only on" and "based at least on." In addition, the phrase "based on" does not exclude intermediate steps; for example, A is based on C can mean that B is based on C, and A is based on B. In addition, the term "and / or" means "and" or "or." For example, "A and / or B" can mean "A," "B," or "A and B." In addition, "A, B, and / or C" can mean "A only," "B only," "C only," "A and B," "A and C," "B and C," or "A, B, and C."

[0132]

[0142] The terms "connected," "coupled," and "communicatively coupled," and related terms, are used in an operational sense and are not necessarily limited to a direct physical connection or coupling. Thus, in an example, two devices may be coupled directly or through one or more intermediary mediators or devices. As another example, devices may be coupled such that information can be passed between them without sharing a physical connection to each other. Based on the disclosure provided herein, one of ordinary skill in the art will recognize various ways in which a connection or coupling exists in accordance with the foregoing definitions.

[0133]

[0143] The phrases "in an exemplary embodiment," "in an exemplary embodiment," "in some embodiments," "according to some embodiments," "in illustrated embodiments," "in other embodiments," "embodiments," "in examples," "examples," "in some examples," "some examples," and the like generally mean that the particular feature, structure, or characteristic that follows the phrase is included in at least one embodiment of the present disclosure, and may be included in more than one embodiment of the present disclosure. Moreover, such phrases do not necessarily refer to the same or different embodiments.

[0134]

[0144] If the specification states that a component or feature "may include," "could include," "could have included," or "might include," or that a characteristic "may have," "could have," "could have," or "might have," that particular component or feature need not be included or have the characteristic.

[0135]

[0145] The term "in response" includes fully or partially responding.

[0146] The term "module" refers broadly to a software, hardware, or firmware (or any combination thereof) component. A module is typically a functional component that can use specified inputs to produce useful data or other output. A module may or may not be self-contained. An application program (also called an "application") may contain one or more modules, or a module may contain one or more application programs.

[0136]

[0147] The term "network" generally refers to a group of interconnected devices that can exchange information. A network can range in size from a few personal computers in a local area network (LAN) to the Internet, a worldwide network of computers. As used herein, "network" is intended to encompass any network that can transmit information from one entity to another. In some cases, a network may be made up of multiple networks, or even multiple heterogeneous networks, such as one or more border networks, voice networks, broadband networks, financial networks, service provider networks, Internet Service Provider (ISP) networks, and / or public switched telephone networks (PSTNs), interconnected via gateways operable to facilitate communication between the various networks.

[0137]

[0148] Also, for illustrative purposes, various embodiments of the present disclosure are described herein in the context of computer programs, physical components, and logical interactions within modern computer networks. Importantly, while these embodiments describe various embodiments of the present disclosure in the context of modern computer networks and programs, the methods and apparatus described herein are equally applicable to other systems, devices, and networks, as will be understood by those skilled in the art. Thus, the illustrated applications of embodiments of the present disclosure are not meant to be limiting but are examples. Other systems, devices, and networks to which embodiments of the present disclosure are applicable include, by way of example, other types of communication and computer devices and systems. More specifically, embodiments are applicable to communication systems, services, and devices such as cellular telephone networks and compatible devices. Additionally, embodiments are applicable to all levels of computing, from personal computers to mainframes and servers in large networks.

[0138]

[0149] In conclusion, the present disclosure provides novel systems, methods, and configurations for upgradeable security tokens. While a detailed description of one or more embodiments of the present disclosure has been set forth above, various alternatives, modifications, and equivalents will be apparent to those skilled in the art without departing from the spirit of the present disclosure. In examples, while the embodiments described above refer to particular features, the scope of the present disclosure also includes embodiments having different combinations of features and embodiments that do not include all of the described features. Accordingly, the scope of the present disclosure is intended to encompass all such alternatives, modifications, and variations as fall within the scope of the claims, together with all equivalents thereof. Therefore, the above description should not be deemed limiting. Example of an embodiment

[0150] Example 1 includes a network node comprising at least one processor, at least one memory communicatively coupled to the at least one processor, and at least one network interface communicatively coupled to the at least one processor, the network node being configured to be among a plurality of network nodes communicatively coupled in a peer-to-peer network of network nodes implementing a distributed ledger, the network node being communicatively coupled to at least one remotely located computing device via the at least one network interface, the at least one processor deploying a child smart contract in the distributed ledger that is a successor version of a parent smart contract, and updating an upgraded address field in the parent smart contract to point to an address of the child smart contract. So the parent smart contract remains deployed even after the child smart contract is deployed.

[0139]

[0151] Example 2 includes the network node of example 1, wherein the at least one processor is further configured to initiate an event indicating that the upgraded address field has been set.

[0140]

[0152] Example 3 includes the network node of any of Examples 1-2, wherein at least one processor is further configured to set a parent address field in the child smart contract to point to the address of the parent smart contract and initiate an event indicating that the upgraded address field has been set.

[0141]

[0153] Example 4 includes the network node of any of Examples 1-3, wherein the at least one processor is further configured to set a token supply parameter in the child smart contract equal to a token supply parameter in the parent smart contract.

[0142]

[0154] Example 5 includes the network node of any of Examples 1-4, wherein at least one processor is further configured to migrate all old tokens in the parent smart contract from token holder addresses to addresses of the child smart contract.

[0143]

[0155] Example 6 includes the network node of Example 5, wherein the at least one processor is further configured to issue at least one new token in the child smart contract to a token holder address.

[0144]

[0156] Example 7 includes the network node of Example 6, wherein the at least one processor is further configured to: determine whether an old token that needs to be migrated is at at least one other token holder address; issue a new token in the child smart contract to the intermediate address; select a new token holder address from the at least one other token holder address; migrate the old token in the parent smart contract from the new token holder address to an address of the child smart contract; and move at least one new token in the child smart contract from the intermediate address to the new token holder address.

[0145]

[0157] Example 8 includes the network node of any of Examples 6-7, wherein the at least one processor is further configured to, after deployment of the child smart contract, migrate all old tokens and move at least one new token based on a determination that the old tokens in the parent smart contract are restricted from trading.

[0146]

[0158] Example 9 includes the network node of any of Examples 6-8, wherein the at least one processor is further configured to determine that older tokens in the parent smart contract are restricted from trading based on whether the upgraded address field in the parent smart contract is set or unset.

[0147]

[0159] Example 10 includes the network node of any of Examples 1-9, wherein the old token and the new token are each cryptographic tokens representing an external tradable asset.

[0160] Example 11 includes the network node of any of Examples 1 to 10, where the parent smart contract and the child smart contract are implemented using their respective originating smart contracts.

[0148]

[0161] Example 12 includes a computerized method for upgrading a parent smart contract, the computerized method executed by a network node configured to be included within a plurality of network nodes in a peer-to-peer network of network nodes implementing a distributed ledger, the network node configured to be communicatively coupled to other network nodes in the peer-to-peer network, the computerized method comprising: deploying, in the distributed ledger, a child smart contract that is a successor version of the parent smart contract; and setting, in the parent smart contract, an upgraded address field to point to the address of the child smart contract, wherein the parent smart contract remains deployed after the child smart contract is deployed.

[0149]

[0162] Example 13 includes the computerized method of example 12, further comprising initiating an event indicating that the upgraded address field has been set.

[0163] Example 14 includes the computerized method of any of Examples 12-13, further comprising setting a parent address field in the child smart contract to point to the address of the parent smart contract and initiating an event indicating that the upgraded address field has been set.

[0150]

[0164] Example 15 includes the computerized method of any of Examples 12-14, further comprising setting a token supply parameter in the child smart contract to be equal to a token supply parameter in the parent smart contract.

[0151]

[0165] Example 16 includes the computerized method of any of Examples 12-15, further comprising migrating all old tokens in the parent smart contract from token holder addresses to addresses of the child smart contract.

[0152]

[0166] Example 17 includes the computerized method of Example 16, further comprising issuing at least one new token in the child smart contract to a token holder address.

[0153]

[0167] Example 18 includes the computerized method of Example 17, further comprising determining whether the old token that needs to be migrated is at at least one other token holder address; issuing the new token in the child smart contract to the intermediate address; selecting a new token holder address from the at least one other token holder address; migrating the old token in the parent smart contract from the new token holder address to an address of the child smart contract; and moving the at least one new token in the child smart contract from the intermediate address to the new token holder address.

[0154]

[0168] Example 19 includes the computerized method of any of Examples 17-18, further comprising, after deployment of the child smart contract, migrating all old tokens and moving at least one new token based on a determination that the old tokens in the parent smart contract are restricted from trading.

[0155]

[0169] Example 20 includes the computerized method of any of Examples 17-19, further comprising determining that the old token in the parent smart contract is restricted from trading based on whether the upgraded address field in the parent smart contract is set or unset.

[0156]

[0170] Example 21 includes the computerized method of any of Examples 12-20, wherein the old token and the new token are cryptographic tokens that each represent an external tradable asset.

[0157]

[0171] Example 22 includes the computerized method of any of Examples 12-21, wherein the parent smart contract and the child smart contract are implemented using their respective originating smart contracts.

[0158]

[0172] Example 23 includes a network node comprising at least one processor, at least one memory communicatively coupled to the at least one processor, and at least one network interface communicatively coupled to the at least one processor, the network node being configured to be among a plurality of network nodes communicatively coupled in a peer-to-peer network of network nodes implementing a distributed ledger, the network node being configured to be communicatively coupled to at least one remotely located computing device via the at least one network interface, and the at least one processor being configured to execute a child smart contract that is a successor version of a parent smart contract. The smart contract is configured to deploy the smart contract on a distributed ledger, set an upgraded address field in the parent smart contract to point to the address of the child smart contract, issue a new token in the child smart contract to the intermediate address, migrate all old tokens in the parent smart contract from the token holder's address to the child smart contract's address, and move at least one new token in the child smart contract from the intermediate address to the token holder's address, wherein the parent smart contract remains deployed after the child smart contract is deployed, and the old tokens and new tokens are cryptographic tokens each representing an external tradable asset.

[0159]

[0173] Example 24 includes the network node of Example 23, wherein the at least one processor is further configured to set a token supply parameter in the child smart contract equal to a token supply parameter in the parent smart contract.

[0160]

[0174] Example 25 includes the computerized method of any of Examples 23-24, wherein the at least one processor is further configured to, after deployment of the child smart contract, migrate all old tokens and move at least one new token based on a determination that the old tokens in the parent smart contract are restricted from trading.

[0161]

[0175] Example 26 includes the computerized method of any of Examples 23-25, wherein the at least one processor is further configured to determine that the old token in the parent smart contract is restricted from trading based on whether the upgraded address field in the parent smart contract is set or unset.

Claims

1. a network node, at least one processor; at least one memory communicatively coupled to the at least one processor; at least one network interface communicatively coupled to the at least one processor; the network node is configured to be among a plurality of network nodes communicatively coupled in a peer-to-peer network of network nodes implementing a distributed ledger; the network node is communicatively coupled to at least one remotely located computing device via the at least one network interface; The at least one processor deploying a second smart contract at a second address on the distributed ledger, the second smart contract having a second balance table; and a first smart contract at a first address on the distributed ledger, the first smart contract having a first balance table; An address field of the first smart contract is configured to reference the second address; issuing new tokens in the second smart contract to an address of an issuer that issued the new tokens; subtracting a specific number of tokens from each of the first values ​​indicating the number of tokens corresponding to each of the first token holder addresses in the first balance table; A network node configured to add the particular number of tokens to a second value indicating the number of tokens corresponding to the second address in the first balance table.

2. 2. The network node of claim 1, wherein the at least one processor is further configured to set a second address field of the first smart contract to reference a third address, wherein a third smart contract resides at the third address in the distributed ledger.

3. 2. The network node of claim 1, wherein the at least one processor is further configured to deploy a third smart contract at a third address on the distributed ledger.

4. 4. The network node of claim 3, wherein the at least one processor is further configured to set a second address field of the first smart contract to reference a third address.

5. The network node of claim 3 , wherein the third smart contract has a third balance table.

6. 6. The network node of claim 5, wherein the at least one processor is further configured to set a second address field of the first smart contract to reference the third address.

7. The at least one processor a second address field of the second smart contract is configured to reference the third address; subtracting a second specific number of tokens from each of third values ​​indicating the number of tokens corresponding to each of the second token holder addresses in the second balance table; and further configured to add the second specified number of tokens to a fourth value indicating the number of tokens corresponding to the third address in the second balance table. The network node of claim 3 .

8. 2. The network node of claim 1, wherein the at least one processor is further configured to set a second address field of the second smart contract to reference the first address of the first smart contract.

9. 2. The network node of claim 1, wherein the specific number of tokens subtracted from each of the first values ​​in the first balance table of the first smart contract is added to the second value indicating the number of tokens corresponding to the second address in the first balance table before being removed from token circulation.

10. 1. A method performed by a network node configured to be among a plurality of network nodes in a peer-to-peer network communicatively coupled to a network node implementing a distributed ledger, the method comprising: Deploying a second smart contract at a second address on the distributed ledger, the second smart contract having a second balance table, and a first smart contract at a first address on the distributed ledger, the first smart contract having a first balance table; Setting an address field of the first smart contract to reference the second address; issuing new tokens in the second smart contract to an address of an issuer that issued the new tokens; subtracting a specific number of tokens from each of first values ​​indicating the number of tokens corresponding to each of the first token holder addresses in the first balance table; adding the particular number of tokens to a second value indicating the number of tokens corresponding to the second address in the first balance table; A method comprising:

11. 11. The method of claim 10, further comprising: setting a second address field of the first smart contract to reference a third address, wherein a third smart contract resides at the third address in the distributed ledger.

12. 11. The method of claim 10, further comprising deploying a third smart contract to a third address on the distributed ledger.

13. 13. The method of claim 12, further comprising: setting a second address field of the first smart contract to reference the third address.

14. 13. The method of claim 12, wherein the third smart contract has a third balance table.

15. 15. The method of claim 14, further comprising: setting a second address field of the first smart contract to reference the third address.

16. Configuring a second address field of the second smart contract to reference the third address; subtracting a second specific number of tokens from each of third values ​​indicating the number of tokens corresponding to each of the second token holder addresses in the second balance table; adding the second specific number of tokens to a fourth value indicating the number of tokens corresponding to the third address in the second balance table; The method of claim 12 further comprising:

17. 11. The method of claim 10, further comprising: setting a second address field of the second smart contract to reference the first address of the first smart contract.

18. 11. The method of claim 10, wherein the specific number of tokens subtracted from each of the first values ​​in the first balance table of the first smart contract is added to the second value indicating the number of tokens corresponding to the second address in the first balance table before being removed from token circulation.

19. a network node, at least one processor; at least one memory communicatively coupled to the at least one processor; at least one network interface communicatively coupled to the at least one processor; the network node is configured to be among a plurality of network nodes communicatively coupled in a peer-to-peer network of network nodes implementing a distributed ledger; the network node is communicatively coupled to at least one remotely located computing device via the at least one network interface; The at least one processor deploying a second smart contract at a second address on the distributed ledger, the second smart contract having a second balance table; and a first smart contract at a first address on the distributed ledger, the first smart contract having a first balance table; deploying a third smart contract at a third address on the distributed ledger, the third smart contract having a third balance table; An address field of the first smart contract is configured to reference the second address; a second address field of the first smart contract is configured to reference the third address; issuing new tokens in the second smart contract to an address of an issuer that issued the new tokens; subtracting a specific number of tokens from each of the first values ​​indicating the number of tokens corresponding to each of the first token holder addresses in the first balance table; A network node configured to add the particular number of tokens to a second value indicating the number of tokens corresponding to the second address in the first balance table.

20. The at least one processor a third address field of the second smart contract is configured to reference the third address; subtracting a second specific number of tokens from each of third values ​​indicating the number of tokens corresponding to each of the second token holder addresses in the second balance table; and further configured to add the second specific number of tokens to a fourth value indicating the number of tokens corresponding to the third address in the second balance table.

20. A network node according to claim 19.

Images