Integrated platform for digital asset registration, tracking and verification

Abstract

The invention provides a loan or loan processing platform based on a block chain. The platform comprises a block chain entering system comprising a smart contract execution environment (CEE). The blockchain entry system is configured to: (1) automatically process loan data from a loan initiation system (LOS) to virtually execute one or more loan contracts within a CEE, and the loan data including a plurality of loan-related facts; (2) encrypting the loan-related facts to generate a plurality of encrypted facts associated with the one or more loan assets; and (3) generate a plurality of hashes for the cryptographic facts. The hashes are recorded on the blockchain, and a combination of each encryption fact and its respective hash is stored in an encryption object store (EOS) separate from the blockchain. The platform also includes a digital asset registration tool (DART) to track control, transfer, transfer, and / or ownership of the controllable electronic records substantially in real time.

Description

[0001] Cross-references

[0002] This application claims priority to U.S. Provisional Application Serial No. 63 / 323,665, filed on March 25, 2022, which is incorporated herein by reference in its entirety. Background Art

[0003] Blockchain systems are increasingly used to record digital assets and / or transaction data via distributed computing devices. Blockchains beneficially allow secure, distributed storage of event and transaction data that is verifiable and prevents unauthorized use. However, existing systems for transacting with others via blockchains or otherwise may not provide sufficient information about one or more counterparties. Additionally, current blockchain-based systems may not be suitable for supporting traditional financial services industries that require private data integrity. For example, current platforms may not be suitable for enabling participating parties (e.g., financial institutions) to use private data with public blockchains. Summary of the invention

[0004] There is a need for platforms and systems that allow off-chain client protocols to be used in conjunction with on-chain data and contracts. The present disclosure relates to systems and methods for blockchain-based financial transactions. In particular, the platforms and systems of the present disclosure can be used to remove confidential data from a blockchain while still achieving data integrity (e.g., distributed, immutable, trustless) using the blockchain.

[0005] The present disclosure provides a platform for digital asset verification, tracking and registration. In some embodiments, the platform can be a loan or loan processing platform based on blockchain. The platform may include a blockchain entry system that allows loan originators to integrate their loan origination systems (LOS), custody and services into blockchain. For example, digital assets can be stationed in the blockchain by executing a client contract written by the initiator to consume the initiation data whose integrity is verified by the platform, and the output data may include the fact of records in the encrypted object storage (EOS) privately owned and hosted by the initiator.

[0006] The blockchain on-boarding system may include a smart contract execution environment (CEE) that records hash representations of documents, data, transactions, and client contracts to the blockchain. Modification or updating of data is performed only by further executing contracts on a unique predefined data structure (e.g., scope), and the input hash of the data from the object storage is checked according to the blockchain to ensure that no external data modification has occurred. In this way, the authenticity of the data can be verified without trusting the data storage of a single initiator. The systems and methods disclosed herein can beneficially provide portfolio-level credit, performance, and related statistics, as well as the ability to drill down into a single loan package, view exception reports, payment history, and the like. The blockchain on-boarding system beneficially allows the use of off-chain client protocols in conjunction with on-chain data and contracts. In particular, the systems and methods herein can advantageously enable participating financial institutions to use private data with public blockchains.

[0007] In one aspect, a blockchain-based lending or loan processing platform is provided. The platform may include: a blockchain on-boarding system including a smart contract execution environment (CEE). The blockchain on-boarding system is configured to: (1) automatically process loan data from a loan origination system (LOS) to virtually execute one or more loan contracts within the CEE, and the loan data includes multiple loan-related facts; (2) encrypt the loan-related facts to generate multiple encrypted facts associated with one or more loan assets; and (3) generate multiple hashes for the encrypted facts. The hashes are recorded on the blockchain, and the combination of each encrypted fact and its corresponding hash is stored in an encrypted object storage (EOS) separate from the blockchain.

[0008] In some embodiments, each fact corresponds to a single or discrete piece of data, the hash of which is recorded on the blockchain. In some embodiments, the CEE is configured to remove confidential data associated with one or more loan assets from the blockchain while maintaining the ability to use the blockchain to ensure data integrity. In some cases, a hash of the encrypted fact is recorded on the blockchain, and wherein the encrypted fact is not recorded on the blockchain. In some cases, EOS is local to the CEE, or EOS is part of the CEE.

[0009] In some embodiments, the plurality of loan-related facts include a credit score, borrower information or profile, an electronic copy of a signed security instrument, a copy of an electronic promissory note (eNote), a third party review (TPR) due diligence result, and / or loan terms. In some embodiments, the loan data is initiated by an originating party, and wherein the platform is configured to enable the originating party to create a unique wallet with a root key pair, the root key pair comprising a public key and a private key. In some cases, the loan-related facts are encrypted using the public key of the originating party. In some cases, a hash of the encrypted facts is recorded on the blockchain together with the public key and a timestamp of the originating party. In some cases. The private key may be used by the originating party or another party with the permission of the originating party to decrypt the encrypted facts stored in EOS.

[0010] In some embodiments, the blockchain contains records of all transactions, including loan settlement and loan asset transfer. In some embodiments, a collection of loan-related facts together constitutes a token. In some cases, the token includes a non-fungible token (NFT). In some cases, each token is assigned a unique identifier. In some cases, the platform is configured to specify ownership at the token level. In some cases, the platform is configured to fork the ownership of the token between the data owner and the value owner. For example, the platform identifies the value owner as an entity that is entitled to the monetary value of the loan asset containing the token, and allows the value owner to transfer the value right to other parties. For example, the platform identifies the data owner as an entity that controls the facts contained in the token. In some cases, the platform is configured to only allow the data owner to affect the facts in the token by adding one or more facts, changing one or more facts, or deleting one or more facts. For example, the platform is configured to allow data owners to freely share ownership, so that there can be multiple data owners, and wherein after the token has been settled in the blockchain, each data owner among the multiple data owners needs to sign any subsequent changes to the token data separately. In some cases, the platform is configured to allow the data owner to grant read-only access to the token data to one or more other non-owner parties. For example, the platform is configured to enable one or more other non-owner parties to decrypt the token and view / access facts within the token without allowing the non-owner parties to make any changes to the token data on the blockchain. In some cases, any attempted changes made by a non-owner party with only read-only access will not be accepted or verified for recording on the blockchain.

[0011] In some cases, the platform identifies the initiating party as an entity that creates and settles tokens through CEE, and wherein the initiating party defaults to being the data owner and value owner of the token initially. In some cases, the platform is configured to assign a unique public key-private key pair to the initiating party. In some examples, the public key can be used by the initiating party to create a digital signature on the token. For example, the platform allows the digital signature to be verified and validated by a private key connected to the public key and associated with the initiating party. In some cases, the token is encrypted, and the private key can be used to decrypt and view / access the facts within the token. In some cases, the public key and any subsequent authorized modifications or changes to the token are included in the token. In some cases, any authorized transfer of ownership of the token is tracked or traced by an integrated digital asset registration tool (DART). In some cases, the platform is configured to allow only entities whose digital signatures match the digital signatures of the current data owners of the tokens to make authorized subsequent modifications or changes to the tokens. In some cases, the platform is configured to reject modifications or changes proposed by any entity whose digital signatures do not match the digital signatures of the current data owners of the tokens.

[0012] In some embodiments, the platform also includes a digital asset registration tool (DART) connected to the platform. DART is an integrated registry that is configured to track control, transfer, assignment and / or ownership of controllable electronic records (such as promissory notes (eNote) associated with loan contracts) in real time. In some cases, DART is designed to eliminate the need for paper transfer, sales bills or other security agreement transfer documents or physical document delivery. In some cases, DART is designed to eliminate the need to manually register eNote and loans to any additional intermediary system. In some cases, DART is configured to realize the transfer of all-digital, tokenized mortgage assets from the transferor to the transferee based on the intra-party blockchain, and provide verification that the transferee has been granted a perfect super priority control authority. In some cases, EOS is configured to share encrypted facts and metadata with the loan market module, and wherein DART is used to record the loan transactions occurring via the loan market module in real time.

[0013] Additional aspects and advantages of the present disclosure will become apparent to those skilled in the art from the following detailed description, wherein only exemplary embodiments of the present disclosure are shown and described. As will be appreciated, the present disclosure is capable of other and different embodiments, and its several details are capable of modification in various apparent aspects, all without departing from the disclosure. Therefore, the drawings and descriptions are to be regarded as exemplary in nature, and are not to be regarded as limiting.

[0014] Incorporation by reference

[0015] All publications, patents, and patent applications mentioned in this specification are herein incorporated by reference to the same extent as if each individual publication, patent, or patent application was specifically and individually indicated to be incorporated by reference. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] The novel features of the present disclosure are set forth in detail in the appended claims. A better understanding of the features and advantages of the present disclosure will be obtained by referring to the following detailed description of exemplary embodiments and the accompanying drawings (also referred to herein as "Figures"), in which:

[0017] Figure 1 An example of a blockchain-based lending or loan processing platform according to some embodiments of the present disclosure is shown.

[0018] Figure 2 Shows examples of scopes proposed / generated by the Contract Execution Environment (CEE) and processed and recorded on the blockchain.

[0019] Figure 3 A contract execution environment (CEE) according to an embodiment of the present disclosure is schematically shown.

[0020] Figure 4 A loan onboarding architecture for onboarding loan assets to a blockchain is schematically illustrated.

[0021] Figure 5 The application architecture of the platform according to an embodiment of the present disclosure is schematically shown.

[0022] Figure 6 An example of a platform including a Digital Asset Registration Tool (DART) according to an embodiment of the present disclosure is shown.

[0023] Figure 7 An example of a user interface (UI) provided by a portfolio manager is shown.

[0024] Fig. 8A Schematically illustrated is a platform with blockchain-based loan verification and integrated eNote registration according to an embodiment of the present disclosure.

[0025] Figure 8B The data sharing mechanism in the platform according to the embodiment of the present disclosure is schematically illustrated.

[0026] Fig. 9 An exemplary computer system is schematically illustrated that is programmed or otherwise configured to implement one or more of the methods provided herein. DETAILED DESCRIPTION

[0027] Although various embodiments have been shown and described herein, it will be apparent to those skilled in the art that such embodiments are provided by way of example only. Without departing from the scope of the present disclosure, those skilled in the art may conceive of many variations, changes and substitutions. It should be understood that various alternatives to the embodiments described herein may be employed.

[0028] The present disclosure provides a platform for digital asset verification, tracking and registration. In some cases, assets or items (such as financial assets (e.g., loans), ownership, artwork, etc.) can be represented on the blockchain as on-chain assets or digital consents (such as non-fungible tokens (NFTs)), where the blockchain records indicate the ownership of these different digital assets.

[0029] In some embodiments, the platform may be a blockchain-based lending or loan processing platform for financial assets. The platform may include a blockchain onboarding system that allows loan originators to integrate their loan origination systems (LOS), custody, and services into or on the blockchain. For example, digital assets may be onboarded to the blockchain by executing a client contract written by the originator to consume origination data whose integrity is verified by the platform, and the output data may include the fact of being recorded in an encrypted object storage (EOS) privately owned and hosted by the originator.

[0030] The blockchain on-boarding system may include a smart contract execution environment (CEE) that records hash representations of documents, data, transactions, and client contracts to the blockchain. Modification or updating of data is performed only by further executing contracts on data objects (e.g., scopes), and the input hash of data from object storage is checked against the blockchain to ensure that no external data modification has occurred. In this way, the authenticity of the data can be verified without trusting the data storage of a single initiator. The provided systems and methods can beneficially provide portfolio-level credit, performance, and related statistics, as well as the ability to drill down into individual loan packages, view exception reports, payment histories, and the like. The blockchain on-boarding system beneficially allows off-chain client protocols to be used in conjunction with on-chain data and contracts. In particular, the systems and methods herein can advantageously enable participating financial institutions to use private data with public blockchains.

[0031] Users of the platform may include customers, companies, organizations, investors, staked token holders, delegators, developers, researchers, maintainers, and various other participants. Participants may include individuals or entities that conduct transactions on the blockchain to register, custody, and trade assets. In some cases, participants may pay transaction fees when executing transactions on the blockchain. In some cases, the Customer Contract Execution Environment (CEE) may help facilitate private communications and processes between participants that are hashed before being included in the immutable record held by the verifier.

[0032] Participants may include validators and delegators who may be buyers, sellers, other financial services companies, or third-party validators that independently host blockchains. In some cases, any participant may become a validator or delegator. Participants who hold hashes (hash utility tokens used to pay for transactions (gas fees), staking, and delegation) may additionally participate by delegating their stake to validators in exchange for rewards. In some cases, any participant may directly buy or sell hashes by visiting any participating hash exchange.

[0033] A validator can be a validation node on a blockchain network. A validator can propose and validate transactions on a blockchain network. In some cases, a validator can stake hashes as part of the active validators on the network (e.g., the top 50 validator nodes by total stake in the network are selected as the active validator set), and is an essential element for hash holders who wish to delegate their stake and share in the rewards generated by the network fee allocation framework. Blockchains can provide benefits for incentivizing validation. For example, validators can participate in the security and control of the network, and can earn additional staking rewards through commissions collected, as well as bonuses for proposing transactions accepted by the network. In some cases, active validators can each take turns proposing blocks submitted using a round-robin allocation. Validators can choose the minimum gas price they will accept in order to process proposed transactions, which allows validators to organically modify the cost of using the network.

[0034] The term "stake" as used herein may generally refer to hashes that have been delegated to a validator to share the risks and rewards of participating in the consensus mechanism on a blockchain network. The term "delegation" as used herein may generally refer to staking hashes with a validator for that validator to use as voting power. For most holders of hash delegation, this is a simple and relatively secure way to share ownership and rewards of the network.

[0035] Participants may include asset creators or originators (e.g., loan originators) who place digital assets on the blockchain. Asset creators may register and custody digital assets on the blockchain by using a client contract or loan origination system. In some cases, the blockchain client contract may obtain encrypted data from the asset creator and convert that information into a predetermined object structure, and then encrypt the data in the creator's own private encrypted object storage (e.g., EOS) using the object hash recorded on the blockchain via a loan scope data module (e.g., loan scope or fact hash), as described later in this document. In addition to hosting digital assets, asset creators may also provide funding, financing, sales, and services for assets on the blockchain.

[0036] Participants may include entities that purchase or finance assets on the blockchain (e.g., banks, funds, etc.), entities that securitize assets, investors that purchase bonds, and various other entities (such as universal banks that provide a bridge between fiat currency and blockchain).

[0037] Blockchain entry system

[0038] In one aspect, a blockchain-based lending or loan processing platform is provided. The platform may include: a blockchain loan onboarding system including a smart contract execution environment (CEE). The blockchain onboarding system is configured to: (1) automatically process loan data from a loan origination system (LOS) to virtually execute one or more loan contracts within the CEE, and the loan data includes multiple loan-related facts; (2) encrypt the loan-related facts to generate multiple encrypted facts associated with one or more loan assets; and (3) generate multiple hashes for the encrypted facts. The hashes are recorded on the blockchain, and the combination of each encrypted fact and its corresponding hash is stored in an encrypted object storage (EOS) separate from the blockchain.

[0039] Figure 1An example of a blockchain-based lending or loan processing platform 100 according to some embodiments of the present disclosure is shown. The platform 100 may include a blockchain onboarding system 120 that allows loan originators to integrate their loan origination systems (LOS) 110, custody and services into or with a blockchain 140. In some embodiments, digital assets can be onboarded to the blockchain 140 by executing a client contract written by the originator to consume the origination data, verify its integrity, and output the data as a recorded fact 125 or a combination of an encrypted fact 125 and a fact hash 123 in an encrypted object store (EOS) 130. In some embodiments, EOS 130 can be privately owned and hosted by the loan originator, allowing for improved privacy. The data of the asset may contain sensitive and / or private information. Sensitive and / or private information may be stored off-chain in EOS. On-chain scope metadata may contain ownership information of the digital asset and may be pooled or tokenized using a tagging module described later herein.

[0040] Client contracts can be different from blockchain-based smart contracts. The client contract execution environment can be executed only in the contract execution environment of the parties participating in the contract and only operate on data stored in EOS. The record of contract execution is recorded to the blockchain using a blockchain data model (e.g., a scope data model), which in turn records the scope data object to the chain using a blockchain-based smart contract.

[0041] Client contracts can differ from smart contracts in that client contracts keep data private between parties off-chain and allow a structure to record agreed-upon state data to the blockchain. In contrast, smart contracts can run on the blockchain and require validators to access data, which can be problematic for consumer-based transactions due to data privacy issues.

[0042] The blockchain onboarding system described herein can be used to register new assets on a blockchain as on-chain digital assets. Digital assets can be represented using metadata modules and scoped data structures, as described later herein. The metadata module can be used to protect off-chain data privacy (e.g., personally identifiable information (PII)) while allowing the results of the asset data state (represented by a data hash) to be recorded on the blockchain. The blockchain onboarding system can be configured to automatically perform operations, thereby simplifying the registration process (e.g., the minting process) of new assets on the blockchain.

[0043] In some embodiments, the blockchain onboarding system 120 may include a contract execution environment (CEE) 121 that records fact hashes (e.g., hash representations of all documents, data, transactions, and client contracts) 123 to the blockchain 140. The blockchain onboarding system 120 may be configured to: (1) automatically process loan data 111 from a loan origination system (LOS) 110 to virtually execute one or more loan contracts within the CEE 121, wherein the loan data 111 includes a plurality of loan-related facts; (2) encrypt the loan-related facts to generate a plurality of encrypted facts 125 associated with one or more loan assets; and (3) generate a plurality of hashes 123 for the encrypted facts, wherein the hashes 123 are recorded on the blockchain. The combination of each encrypted fact 125 and its corresponding hash 123 may be stored in an encrypted object store (EOS) 130 separate from the blockchain 140.

[0044] In some embodiments, the digital asset may include a digital loan asset. Loan data 111 may be associated with one or more loan assets. The loan data may include a plurality of loan-related facts, including, for example, a credit score, borrower information or profile, an electronic copy of a signed security instrument, a copy of an electronic promissory note (eNote), third party review (TPR) due diligence results, loan terms and / or various other transactions (e.g., specific monthly payments), details (e.g., applicant credit score), documents or information related to the loan.

[0045] In some embodiments, the blockchain on-boarding system 120 may process the loan data 111 to virtually execute one or more loan contracts within the CEE 121, and the blockchain on-boarding system 120 may encrypt loan-related facts to generate a plurality of encrypted facts 125 associated with one or more loan assets.

[0046] In some embodiments, CEE 121 may convert loan data 111 into encrypted data for storage in an encrypted object store (EOS), and may record an object hash id (e.g., a fact hash in a scope object) on a blockchain. The hash id may be an encrypted hash of the content of a fact (e.g., a file, document, etc.) in an on-chain immutable transaction. In some cases, a hash value (e.g., a fact hash) of a fact (e.g., document content) may be used as a globally unique identifier (URI) or name (URN) for the content. In some cases, the encrypted data stored in EOS may be an encrypted fact-fact hash combination that includes actual fact data (e.g., a PDF of a guarantee document) 125 and a hash of the fact data (e.g., 489sdfkennwoeinv9) 123.

[0047] In some cases, CEE can store loan data in EOS in a predetermined data object structure. In some cases, the predetermined object structure can be defined by the loan data model. These unique object structures can be used to efficiently store state data in the data object store.

[0048] In some embodiments, the object structure may include a scope object established in EOS, which may correspond to a set of facts about the loan data, i.e., a scope data set. For example, the loan data may be sorted and arranged into one or more scope data sets. A scope object in EOS may be a unit for storing loan data. For example, an initiation scope may be associated with initiation-related facts, such as all details, documents, and facts of the initiation process (e.g., a PDF copy of a wet signature document, an applicant's credit score, etc.). In another example, a service scope may include service-related facts, such as all details, documents, and facts of the service process (e.g., loan payments and documents). Depending on the nature of the digital asset, different digital assets may have different types (e.g., loans, ownership, artwork, funds, stock classes, etc.) and / or scope quantities. For example, a mortgage asset may include an eNote scope, which may include an electronic note record and related meta-linked data.

[0049] In some embodiments, a collection of loan-related facts may collectively constitute a scope object established on a blockchain. A blockchain scope object may be a non-fungible token (NFT) that includes a hash of a set of facts. For example, loan-related facts may be included in one or more scope data sets corresponding to one or more blockchain scope objects. Each fact in a scope data set may be hashed so that a set of fact hashes may be generated for the scope data sets included in the blockchain scope object. A blockchain scope object may record ownership, fact names, fact hashes, and various other states of facts or scopes. A blockchain scope object may not include the original loan-related facts. Instead, a scope object may include a fact hash 123. Fact hash 123 may be a hash of a subset of facts or a hash of a scope data set. A blockchain scope object may also be referred to as a token that may be used or explained interchangeably throughout the specification.

[0050] In some cases, a scope may be created with all facts at once (e.g., all origination information populated concurrently with an origination scope). Alternatively or additionally, facts may be added over time (e.g., new service information is added to an existing service scope).

[0051] In some embodiments, a single loan may have a single scope (e.g., each fact of a loan transaction in one scope). Alternatively, a single loan may have multiple scopes. For example, a dual-scope loan may include an origination scope and a service scope, and the eNote may be contained in the origination scope.

[0052] In some embodiments, CEE 121 may create one or more loan scopes 123 by hashing one or more scope data sets. In some cases, LOS 110 may sort and organize loan data 111 into one or more scope data sets and transmit the scope data sets to blockchain onboarding system 120. One or more loan scopes 123 may be proposed / generated by a CEE to be recorded on blockchain 140. The proposed loan scopes 123 may be processed by blockchain layer 140, such as by performing security validation checks on the proposed loan scopes, finalizing and recording the validated scopes on blockchain. In some cases, additional information, such as a block ID, may be included in the scope at the time of validation. Metadata or other information, such as a timestamp, may also be added when the scope is recorded on the blockchain.

[0053] A proposed scope or a documented scope may include a hash of facts instead of the raw facts or scope dataset. Figure 2 An example of a scope 200 proposed by CEE and a corresponding scope 210 processed and recorded on a blockchain is shown. As shown in the example, a loan scope may not include an original loan-related fact (e.g., a PDF document). The loan scope may include a fact name 203, which may be a name or identifier associated with the fact. For example, when the fact is a PDF guarantee instrument, the fact name of the fact may be "Signed Guarantee Instrument".

[0054] Scope 200 or 210 may include fact hash 204. A fact hash may be an algorithmically generated fingerprint of a piece of data (fact). A fingerprint is a string of characters that represents the data. A hash may be created using a hash algorithm (e.g., SHA-256), and the hash may be uniquely associated with the piece of data. In some cases, a change to a single character in a data set may result in a different hash value. For example, if the fact is a PDF collateral document, the fact hash is "adbkel838dfkjlbleisyuyf," which is a set of characters generated by a hash algorithm to uniquely represent a PDF collateral document.

[0055] Scopes 200 constructed by CEE may be assigned unique identifiers, such as scope IDs 201. In some embodiments, the loan data model may assign a universally unique identifier (UUID) to each scope. This may advantageously allow various applications (e.g., Figure 6 Joint contract execution and data sharing between the services and the portfolio manager application shown.

[0056] Scope 200 may contain information about ownership. The system herein may track ownership at the scope level by including entities that own digital assets (e.g., loan data) or scope data sets. Ownership of a scope may include data owners 202 and / or value owners 211. In some cases, the platform is configured to fork ownership of tokens between data owners and value owners.

[0057] The data owner 202 may refer to an entity that owns and controls a scope data set (e.g., a subset of facts contained in a scope). In some cases, the platform may be configured to only allow data owners to affect facts in a token, such as by adding one or more facts, changing one or more facts, or deleting one or more facts. In some cases, the platform may be configured to allow data owners to freely share ownership, such that there may be multiple data owners, and each of the multiple data owners may need to individually sign any subsequent changes to the scope data set after the scope has been recorded on the blockchain. In some cases, the platform may be configured to allow data owners to grant read-only access to token data (e.g., actual facts) to one or more other non-owner parties. In some cases, any changes attempted to be made by a non-owner party with only read-only access will not be accepted or verified for recording on the blockchain.

[0058] A value owner 211 may refer to an entity that is entitled to the monetary value of a digital asset (e.g., a loan asset) containing a scope or scope dataset. A value owner may be allowed to transfer value rights to other parties.

[0059] In some cases, the initiating party may be the default or initial data owner and value owner of the scope. The initiating party may refer to an entity that is created and settled in the scope through CEE. In some cases, the platform may allow both data ownership and value ownership to be freely transferred and shared. Variable ownership and licensing structures allow parties to flexibly adapt to all relationships involved in the life cycle of digital assets from initiation to securitization.

[0060] A value owner or data owner can control a scope. For example, for a single scope loan, the data owner can have control under ESIGN / UETA because that entity is the only one that can affect facts in the scope, including the transferable records therein.

[0061] The proposed scope 200 may include a digital signature identifying the data owner or proposing entity 202. In the proposed scope or recorded scope 210, the proposing entity may not be identified by name, thereby protecting the privacy or PII of the proposing entity. The proposing entity may be identified by a unique public key (e.g., alkdfjlkj23434ienfildf), which acts as a digital signature confirming the identity of the entity proposing the scope. The initiator or initiating party (e.g., the data owner) may digitally sign the proposed scope using the public key assigned to the initiating party. In some cases, each entity joining the blockchain network may be assigned a unique public-private key pair, and its private key may be kept secret. When preparing the scope, the initiator may use the private key to create a digital signature on the scope. The digital signature may be verified and validated by a public key connected to the private key and associated with the signing entity (i.e., the initiator). Including the initiator's or data owner's public key in the proposed scope (or modification thereof) can beneficially ensure that it is the initiator or data owner who proposed the scope (or modification).

[0062] In some cases, to meet the digital signature requirements, the data provider may need to provide the following information: 1) the entity's certificate, 2) the normalized raw data, and 3) the signature across the data. The entity's certificate allows any other third party to confirm that the information is signed using a private key specific to the data provider. For example, the entity will register its certificate with the blockchain certificate registry. The certificate may include any required chain of trust for the certificate authority. For example, the public key may be ASN1OID:prime256v1 and NIST CURVE:P-256. The normalized raw data may be the raw data packet sent in a standard canonical form. The signature across the data may be the result of the canonical raw data sent with a checksum (e.g., SHA256) and cryptographically signed with a private key.

[0063] An exemplary process for generating a signature may include: normalizing a message; running the normalized message through a SHA256 checksum; cryptographically signing the checksum using the certificate private key (e.g., the signature output may be in ASN.1DER format); encoding the signed checksum (e.g., via Base64); and inserting the encoded signature checksum into the signed response data header.

[0064] To verify this signature, the platform can view the original SHA256 checksum using the certificate's public key and run the checksum against the data used and compare the results. As long as the underlying data has not changed, the two checksums should be identical. The operation of viewing the checksum using the certificate's public key verifies the origin of the data, and the operation of comparing the checksum verifies that the data sent from the source was used to generate the financial asset.

[0065] The signature verification operation may be performed by the blockchain post-entry. In some cases, an invalid signature may not block the service flow. In some cases, when an invalid signature is determined, the signature verifier process may provide an alert and update the loan verification message.

[0066] In some cases, the platform may be configured to allow only entities whose digital signatures match the digital signatures of the current data owner of the scope to make authorized subsequent modifications or changes to the scope. In some cases, the platform may be configured to reject modifications or changes proposed by any entity whose digital signatures do not match the digital signatures of the current data owner of the scope. As described above, the blockchain layer may receive the proposed / generated scope 200 from the CEE and process the proposed scope, such as by performing a security validation check on the scope. For example, the blockchain layer may check and confirm that the validity of the digital signature of the data owner is included in the proposed scope. For example, for the initial creation of the scope, the initiator is the default data owner, so the initiator's public key is valid by default. When a modification is made to an existing scope, the blockchain layer may check and confirm that the digital signature of the proposing entity matches the public key of the current data owner of the modified scope. If the digital signature of the proposing entity does not match the public key of the current data owner, the blockchain layer may reject the proposed scope change because the proposing entity is not the data owner and has no right to modify the scope data.

[0067] After verification, the proposed scope may be finalized, timestamped, and recorded on the blockchain. In some cases, in addition to the data in the proposed scope 200, the finalized scope 210 may also include a value owner 211 identified by a public key assigned to the value owner, a block ID 212 identifying a specific location or block on the blockchain where the scope is recorded. The blockchain layer may transmit a copy of the recorded finalized scope to the CEE.

[0068] In some embodiments, scopes 200, 210 may also include a loan ID 205, which is an identifier uniquely associated with a loan asset. In some embodiments, scope 200 may include a history 206 of contract executions on the scope. Alternatively, the history may be recorded on the blockchain as a metadata scope. In some cases, history 206 may include data inputs and outputs of contracts executed on the scope, participants involved (e.g., participants identified by public keys), hashes of contract code, etc.

[0069] Return to reference Figure 1In some embodiments, one or more scope data sets for each resident contract may be created by a loan origination system (LOS) 110. The LOS may sort and organize the loan assets into one or more scope data sets. The originator may transmit (e.g., via a LOS-CEE connection) the relevant scope data sets, commands, and digital signatures to the CEE 121. The scope data set may include a set of facts, such as the borrower's personal information and a PDF of the security instrument.

[0070] In some embodiments, scope data may be transmitted to the CEE along with a scope command that identifies the proposed scope and action. For example, the command "onboard_new_loan" may be used to create a new loan-related scope. For example, when a contract is executed, a scope object may be created in EOS 130 that contains a complete record of the contract execution and a head state of the facts in the scope (data output by the contract), as well as a fact hash (e.g., a fact-fact hash combination 123, 125). The blockchain scope object may be created on the blockchain 140 at substantially the same time. The blockchain scope object may be created with Figure 2 The Originator can be designated as the value owner of the assets in the scope.

[0071] CEE 121 can be configured to keep confidential data related to one or more loan assets under the blockchain confidential while maintaining the ability to use blockchain to ensure data integrity. CEE 121 can build one or more loan scopes 123 based on one or more scope data sets as described above. For example, the CEE can generate a unique identifier for the scope. The CEE can be configured to generate a fact hash for each fact in the scope data set using a hash algorithm, and associate the fact hash with each fact. As described above, only the hash of the encrypted fact can be recorded on the blockchain, and the encrypted fact may not be recorded on the blockchain. The loan scope 123 may also include the public key of the initiating party. The CEE can then transmit the proposed loan scope 123 to the blockchain 140.

[0072] The blockchain 140 may receive the proposed loan scope 123 and process the loan scope by performing a security validation check on the proposed scope, finalizing and recording the validated scope on the blockchain. In some cases, the platform may be configured to allow only entities whose digital signatures match the digital signatures of the current data owner of the scope to make authorized subsequent modifications or changes to the scope. In some cases, the platform may be configured to reject modifications or changes proposed by any entity whose digital signatures do not match the digital signatures of the current data owner of the scope. For example, a hash of the cryptographic fact may be recorded on the blockchain along with the public key of the initiating party, a timestamp, a block ID, or other data as described above. The blockchain layer may check and confirm that the validity of the digital signature of the data owner is included in the proposed scope. For example, for the initial creation of a scope, the initiator is the default data owner, so the initiator's public key is valid by default. When a modification is made to an existing scope, the blockchain layer may check and confirm that the digital signature of the proposing entity matches the public key of the current data owner of the modified scope. If the digital signature of the proposing entity does not match the public key of the current data owner, the blockchain layer can reject the proposed scope change because the proposing entity is not the data owner and has no authority to modify the scope data.

[0073] After verification, the blockchain 140 may finalize the scope on the blockchain, timestamp the scope on the blockchain, and record the scope on the blockchain. In some cases, the blockchain 140 may add to the finalized scope a value owner identified by a public key assigned to the value owner, a block ID identifying a specific location or block on the blockchain where the scope is recorded. The blockchain 140 may transmit a copy of the recorded finalized scope to the CEE 121. In some cases, the value ownership of the scope may be recorded on the blockchain via a tag established on the chain. The tag module provides an ownership structure for managing tokenized value backed by assets or other tokenized value units denominated in monetary units. Tags may be tokenized, allowing for partial ownership of scopes.

[0074] The facts and related data to be stored in EOS may be encrypted. Encryption may be performed by CEE 121 or blockchain onboarding system 120 (e.g., blockchain software development kit (SDK)). For example, CEE may encrypt the fact-fact hash combination using the initiator's public key and then transmit the encrypted fact-fact hash combination to encrypted object storage (EOS) 130. CEE may use any suitable encryption method. For example, in some cases, elliptic curve integrated encryption scheme (ECIES) may be used to encrypt the asset before it is stored in EOS. ECIES is an integrated encryption scheme that uses the following functions: key agreement (a function for generating a shared secret by two parties); key derivation function (a mechanism for generating a set of keys based on key material and some optional parameters); encryption, such as symmetric encryption algorithms; message authentication code (data for authenticating messages); and hashing (e.g., SHA-256).

[0075] In some embodiments, the loan data may be originated by an originating party, and the platform may be configured to enable the originating party to create a unique wallet with a root key pair, the root key pair comprising a public key and a private key. The loan-related facts may be encrypted using the originating party's public key. The private key may be used by the originating party or another party with the originating party's permission to decrypt the encrypted facts stored in EOS.

[0076] In some cases, when the token / fact hash is encrypted, the private key can be used to decrypt the token and view / access the fact within the token. The public key can be included in the token or blockchain scope object and any subsequent authorized modifications or changes to the token. In some cases, subsequent transfers of rights to any authorization in the token are tracked or traced by an integrated Digital Asset Registry Tool (DART).

[0077] EOS 130 may receive encrypted loan fact 125 and fact hash 123. In some cases, encrypted loan fact 125 and fact hash 123 may be arranged as a fact-fact hash combination. The fact-fact hash combination may include actual fact data (e.g., a PDF of a security instrument) and a hash of the fact data (e.g., 489sdfkennwoeinv9). The fact-fact hash combination may be stored in EOS, which may be a secure vault or a safe depository. In some cases, only the originator may access the encrypted fact-fact hash combination by decrypting the encrypted fact-fact hash combination using the originator's private key.

[0078] In an example, the borrower signs the eNote in the lender's electronic settlement system or LOS 110. Loan data 111 including an eNate file (such as a secure XML file with an associated borrower signature and related metadata) and a scope command ("onboard_new_loan") and the lender's digital signature may be routed by the electronic settlement system or LOS 110 to CEE 121 to create an eNate scope.

[0079] CEE 121 may (i) create a hash of the eNote and transmit the encrypted fact-fact hash combination (e.g., the encrypted eNote file and the hash of the eNote file) to EOS Vault 130; and (ii) transmit the proposed eNote scope to blockchain layer 140.

[0080] It should be noted that although Figure 1 In the example, the loan scope including the fact hash is shown as being transmitted to both EOS 130 and blockchain 140, but the loan scope data transmitted to EOS may sometimes include the fact hash of the fact (e.g., the hash of the eNote file), while the loan scope data transmitted to and recorded on the blockchain may include other information, such as the data owner, the value owner (e.g., the lender is the default data owner and value owner), the block ID, and the fact name-hash combination described above. In some cases, the fact-fact hash combination stored in EOS and the loan scope recorded on the blockchain (e.g., the CEE scope database) may be associated by the fact name.

[0081] The blockchain layer 140 may verify, finalize, and record finalized eNote scopes on the blockchain. An authoritative or finalized scope recorded on the blockchain may include a scope ID, a data owner, a value owner, and a fact name-hash combination. The encrypted fact-fact hash combination (e.g., an encrypted eNote file and a hash of the eNote file) may be securely maintained in the lender's EOS vault 130 as an authoritative eNote file. The term "authoritative" may generally refer to a file, fact, data object, such as a verified and / or finalized scope object.

[0082] Authorized access or changes to encrypted scopes, facts, or fact-fact hash combinations can be controlled by distributing key pairs to entities. In some embodiments, the platform can be configured to enable the originating party of loan data to create a unique wallet with a root key pair, which includes a public key and a private key. Loan-related facts can be encrypted using the public key of the originating party. The private key can be used by the originating party or another party permitted by the originating party to decrypt the encrypted facts stored in EOS. In some cases, the platform can be configured to allow only entities whose digital signatures match the digital signatures of the current data owners of the scope to make authorized subsequent modifications or changes to the scope. In some cases, the platform can be configured to reject modifications or changes proposed by any entity whose digital signatures do not match the digital signatures of the current data owners of the scope.

[0083] In some cases, contract execution may operate on a single loan scope, consisting of key-value pairs, where value objects may be defined, for example, using protocol buffers (e.g., protobuf). In some cases, when token / fact hashes are encrypted, the private key may be used to decrypt the token and view / access the facts within the token. The public key may be included in the token or blockchain scope object, as well as any subsequent authorized modifications or changes to the token.

[0084] For example, an encrypted fact-fact hash combination may be securely stored in EOS 130. The data owner may access the facts in EOS (e.g., an XML eNote file) through a user interface hosted by CEE 121 or through another application. The fact-fact hash combination may be encrypted using a public key-private key encryption system as described elsewhere herein. The originator's public key may be used to initially encrypt the fact-fact hash combination, and the resulting encrypted fact-fact hash combination may be stored in EOS. In some cases, only the originator's private key may decrypt the cryptographic data and allow the originator to view the actual facts in the fact-fact hash combination (e.g., an XML eNote file).

[0085] In some cases, the data owner may be allowed to grant read-only access to other parties. For example, a CEE associated with EOS may copy the shared data into the EOS of that other party, and the other party may access the data and decrypt it with their private key. The other party then has read-only access because they can decrypt and view the data, but they may not have an authoritative influence on the data on the blockchain. As described above, the blockchain can check and verify signatures, and if the party's digital signature on the proposed modification of the relevant scope does not match the digital signature of the data owner, the proposed modification may not be verified to be recorded on the blockchain.

[0086] In some cases, the authoritative set of facts remains in the data owner's EOS, and only the data owner may have the authority to modify the scope that includes the authoritative fact name-fact hash combination associated with the set of facts.

[0087] Recorded or authoritative scopes may be changed. Changes may include: modifying facts associated with a scope (e.g., facts that are scope data sets), changing data owners and / or value owners of a scope. In some cases, changes to authoritative scope-related information (such as fact name-fact hash combinations, data owners, or value owners) may be implemented via the CEE or through a direct interface with the blockchain layer. For changes to be executed to completion, the proposing entity for the change may need to have appropriate ownership rights. For example, only the data owner may have the authority or right to modify facts in a scope data set or facts associated with a scope. Similar to the process of creating a scope described above, the data owner may submit the relevant scope data set (including the modified facts), the appropriate scope command, and the data owner's digital signature to the CEE. The CEE may then (i) encrypt the appropriate fact-fact hash combination and transmit the appropriate fact-fact hash combination to EOS, and (ii) build a proposed scope and transmit the proposed scope to the blockchain layer. Before recording the proposed (modified) scope, the blockchain layer may ensure that the digital signature of the proposing entity matches the digital signature of the current data owner of the proposed (modified) scope. If the proposing entity's digital signature does not match the current data owner's digital signature, the proposed scope may be rejected because the proposing entity is not the data owner and does not have permission to modify the scope data.

[0088] In some cases, recorded (revised) scopes may contain metadata about scope creation and modification. For example, metadata may include scope commands, inputs / outputs of contract execution, and previous versions of fact-fact hash combinations.

[0089] In some cases, the current data owner may have the power to change or modify which entity / individual should be designated as the data owner of a scope. In some cases, the current value owner may have the power to change which individual / entity should be designated as the value owner of a scope. In some cases, when the transaction is a more complex transaction, the value owner may use a "tag" to perform the change. A tag is a smart contract that can be programmed for various purposes, including specifying the value owner state of a scope. Tags are controlled by an "administrator" who can specify which entity is the value owner of the tagged asset.

[0090] In some cases, updates to scopes may be performed in a session, and the details persisted in the session. A session may contain a context for recording these records, which links a set of records to a common process or execution associated with specifications indicating allowed and required values. For example, a session may contain specifications detailing constraints on parties that need to sign, inputs, and outputs that can be recorded. Each scope may contain a list of allowed specifications that can be used. The blockchain onboarding system of this article may provide a service that makes it easy to reference confidential documents by their hash id, and encrypt and store these documents in a database where they are indexed by their hash id. The encryption key is specific to the owner or client of the document. When a contract requires the exchange of such a document, the service can re-encrypt the document with a key associated with the business partner receiving the document.

[0091] Figure 3 A contract execution environment (CEE) 300 according to an embodiment of the present disclosure is schematically shown. In some embodiments, the platform and / or blockchain onboarding system can be implemented in a virtual cloud environment. One or more components or modules can be provided as container applications. The CEE can assist in complex data hashing processes, maintenance of immutable objects, signature orchestration between multiple parties and various other services, processes described elsewhere herein. For example, a loan scope data set can be transmitted to the CEE 300 and stored and managed by the CEE 300. The CEE can be a data management system used by a branch (e.g., a lender) to onboard, update, access, and share data and facts in a scope via a direct interface with the CEE or via a connection between the CEE and another application (such as a LOS or SDK 311).

[0092] In some embodiments, CEE may include multiple components, including, for example, a client contract execution engine 303, a locally hosted encrypted object storage (EOS) 301, an index 305 of the encrypted object storage, and a communication exchange for coordinating the execution of multiple party contracts with other parties' own CEEs. In a cloud environment, index 305 may include a distributed search and analysis engine. CEE may include facilities that can easily reference documents by their hash ids, and encrypt and store these documents in an encrypted object storage (EOS). These encrypted documents are indexed by their hash ids and / or optionally by selected document attribute values. Document attribute values ​​can beneficially allow users to aggregate documents based on public attributes without revealing their sensitive content.

[0093] The Crypto Object Store (EOS) 301 can be a gateway for branches (e.g., lenders) directly to the blockchain layer. For example, EOS can be a vault for lenders' data, facts, and documents. The vault can be self-hosted by the lender or by a third-party data custodian. EOS can store actual, reproducible, encrypted facts (i.e., data and documents) (such as XML eNote records) in a secure vault.

[0094] In some embodiments, each CEE instance can communicate with a blockchain node to submit a transaction to the blockchain (contract execution hash record). Applications can use client CEE and object storage to protect the privacy and confidentiality of personally identifiable information (PII), sensitive data, and information related to non-fungible tokens. As described herein, the hash commitment of information and its state can be captured in a scope data model. CEE provides tools for structured data to be stored on the chain, and acts as a sidechain information workflow manager, where a database based on the scope data model is used as a state storage on the chain.

[0095] The blockchain communication exchange component 330 can manage secure communications between business partners to exchange information required to fulfill a contract. This communication can flow through an asynchronous mailbox system and event stream, where messages are authenticated and encrypted by the keys of both parties.

[0096] Entities and organizations can use the contract execution environment to execute contracts that create single or multiple party agreements. Entity identity and data encryption can use public-private key pairs. Entities can be known to each other and share data with each other through their public keys. Contract and asset data can be forwarded to all entities participating in the contract through public key identifiers. Entities can provide an implementation of an encrypted object storage (EOS) in which encrypted data associated with their public keys is stored. Contract execution can consume data from entity EOS, and the results of contract execution can be returned to the execution environment of the submitting entity. In some cases, the hash sum of the contract execution results (i.e., the cryptographic hash of its contents) can be submitted to the blockchain 320 (in the form of a scoped data object), where they are verified and submitted to the blockchain. The blockchain can issue an event to notify the entity that the contract has been submitted on the blockchain. The entity's local index 305 can be updated with new contract information. This information is later used to search and query data.

[0097] The blockchain layer 320 may include a blockchain, where scope objects (e.g., a proposed scope containing a fact hash) may be processed and authoritatively recorded by the blockchain. The blockchain is an immutable, publicly available source of truth for the existence, history, and time of any scope and fact therein.

[0098] A validator 340 may be a validating node on a blockchain network. A validator may propose and validate transactions on a blockchain network. In some cases, a validator may stake hashes as part of the active validators on the network (e.g., the top 50 validator nodes by total stake in the network are selected as the active validator set), and is an essential element for hash holders who wish to delegate their stake and share in the rewards generated by the network fee distribution framework.

[0099] Before using the data for contract execution, the branch 310 can use SDK 311 to encrypt the data before saving it to the encrypted object storage 301. The branch 310 can be a participant in the transaction and can call the contract. The branch can be any participant in the transaction.

[0100] In some cases, branch 310 may use SDK 311 to encrypt messages or loan data and / or create a set of audience passwords (ApubK[n] passwords) to share data and execute contracts. The audience password set is a list of participants who are granted permission to decrypt messages or loan data. The following is an exemplary process for encrypting messages using the EOS encryption scheme and processing encrypted messages in a client contract.

[0101] The audience secret can be submitted to the contract in the transient data space. The encrypted message and message metadata can be passed to permissioned participants and stored in their cryptographic object storage. The client contract running can use its NpubK to determine if it is in the ApubK[n] secret set. If the contract is not a valid ApubK[n] secret audience participant, the contract throws an exception and the transaction is rejected. The client contract extracts the Tag, EpubK, and encrypted DEK from its ApubK[n] secret into storage. An ECIES shared key can be generated to decrypt the encrypted DEK.

[0102] The same key agreement function (KA) used to encrypt this DEK is followed. During decryption, the KA function uses the EpubK from the cryptography and the NprivK of the contract to generate the Secret. The key derivation function (KDF) uses the Secret and EpubK encoded as byte array parameters to generate the message authentication code key (MAC key) and encryption key (ENC key). Using the MAC key, the encrypted DEK, and the UUID of the calling branch, a new tag is calculated and compared to the tag from the ApubK[n] cryptography. If the tags do not match, the contract throws an exception and the transaction is rejected. Using the ENC key, the encrypted DEK is decrypted into the plaintext DEK. The encrypted message from DIME (data instance with metadata and encrypted DIME) is decrypted using the DEK to obtain the plaintext message.

[0103] The client contract processes plaintext messages by: validating the message, altering the message, reading DIME message metadata (e.g., asset ID, information about the message such as key-value sets), and including or altering the message based on the metadata.

[0104] When the client contract has processed the plaintext message, it encrypts it using the DEK to obtain a new encrypted message. The DEK is destroyed from storage. The audience passwords are processed to obtain a set of audience passwords that only contain participants with privileged decryption messages. The client contract encapsulates the filtered set of passwords in the message audience DIME along with the message metadata. Finally, the client contract encapsulates the encrypted message and message metadata in DIME.

[0105] CEE 300 can be used to house loan data as described above. In some cases, CEE and its components can be used to house and manage any general file. In an exemplary process of housing a loan or document, branch 310 can submit a request to add a contract (e.g., a document) to vault 301. The submitter can be the owner and can include its public key in the document. CEE engine 303 generates a unique UUID and assigns it to the document. The unique ID can be used when a document is required to be checked out, checked in, or verified. System 300 can create a digitally altered copy of the document. The copy can be returned to the owner, where the owner can view and share the copy. CEE engine 303 can generate keys that can be used to encrypt the authoritative copy once an authoritative copy is generated. These keys can be retained by CEE 300 to ensure that only the system can decrypt the authoritative copy upon request by the owner. A digitally altered authoritative copy of the document is created and encrypted with a key. The copy can also be returned to the owner, but only the encrypted version can be returned. If the owner does not have a copy of the key, they may not be able to decrypt the authoritative copy without using system 300. The record of the document is recorded in the blockchain. For example, a recorded loan scope object may include the following fields: UUID, owner's public key, document status (checked in / checked out), hashed representation of original document, value owner, block ID, as described above. UUID, replicas, and encrypted authoritative copies may be returned to the owner.

[0106] During the check-out process, the owner of a document may submit a request to check the document out of the vault 301. In addition to the UUID and encrypted authoritative copy returned to them when the document was added to the vault, the owner includes their public key in the request. The encrypted authoritative copy may be hashed and compared to the hash from the blockchain to ensure that the document has not been altered. The state will also be checked to ensure that the document is currently checked in. The key used to originally encrypt the document may be retrieved from the vault. Using the key, the authoritative copy is decrypted. The checked-out state change is recorded to the blockchain. The decrypted authoritative copy is returned to the owner.

[0107] During the check-in process, the owner of the document submits a request to check the document back into the vault. In addition to the UUID and the decrypted authoritative copy, the owner also includes their public key again in the request. The authoritative copy is encrypted with the original key, hashed, and compared to the hash from the blockchain to ensure that the document has not been altered. The status is also checked to ensure that the document is currently checked out. A new digitally altered copy of the document is created. This copy is returned to the owner, where the owner can view and share it. New keys are generated, which, once generated, are used to encrypt the authoritative copy. These keys are retained by the system to ensure that only the system can decrypt the authoritative copy upon request by the owner. A digitally altered authoritative copy of the document is created and encrypted with the new key. This encrypted copy is again returned to the owner. A record of the updates to the document, including the updated check-in status, is recorded to the blockchain. The UUID, copy, and the encrypted authoritative copy are returned to the owner.

[0108] In some embodiments, the software development kit (SDK) 311 provided by the platform of this article can be a contract execution SDK, which consists of a collection of JVM-based libraries that help manage interactions with blockchain 320. For example, SDK 311 can process data and arrange it into a "scope" as defined above. In some cases, the SDK includes a docker-compose environment that allows a complete local stack to be run. In some cases, the SDK is responsible for executing a contract between one or more participants. After the contract is successfully executed, the result can be a collection of blockchain protobuf messages. All records can be encrypted and stored in EOS. At this stage, messages can be recorded to the blockchain with a blockchain HTTP or gRPC interface. Optionally, the blockchain event stream can be read to asynchronously detect changes made to previously submitted scopes. Blockchain 320 or CEE 300 can persist records in the system so that they are easy to search at a later point in time after execution. For example, a protobuf indexer can achieve this by converting protobuf to an optionally filtered key-value JSON structure. A custom protobuf descriptor is provided which supports hierarchical whitelisting / blacklisting of nested protobuf messages.

[0109] In some cases, the SDK 311 may encrypt all data sent to the encrypted object store (EOS) 301 using encryption schemes described elsewhere herein (e.g., ECIES and DIME formats). If all audience members for the request reside on the owner's EOS, the data may be stored and may not be replicated to any other branch's EOS. When there are audience members owned by remote EOSs, the data may be replicated to those other branch environments. The DIME standard defines an encryption scheme so that if the data falls into the wrong hands, it cannot be decrypted back to a plaintext version. The EOS itself may be a storage and replication mechanism for the data, and it may not have the keys required to decrypt the data.

[0110] Figure 4 A loan onboarding architecture 400 for onboarding loan assets to a blockchain is schematically shown. In some embodiments, the platform and / or blockchain onboarding system may be implemented in a virtual cloud environment.

[0111] In some cases, before the loan is placed on the blockchain, the loan originator may create a digital loan package and digital source documents (e.g., ownership, credit, income, etc.) for verification purposes. In some cases, the loan data or package may be digitally signed by the provider. The loan package may be created by a loan origination system 410 integrated with the blockchain 420. For example, the originator requires the borrower to sign a loan agreement, deliver required disclosures (Truth in Lending Act, etc.), and wait for the revocation period to end (if relevant). If the loan data is off-chain, the originator may define any schema for its loan data. In the case where the loan interacts with other blockchain-driven applications (e.g., a portfolio manager or a marketplace), the scoped data model described above may be used. For example, the loan data at the time of origination may be stored as a single scope in the encrypted object store 431, while the service data is recorded in a separate scope.

[0112] Digital assets can be populated on the blockchain by executing a client contract written by the initiator to consume the originating data, verify its integrity, and output the data as a recorded fact in an encrypted object storage privately and hosted by the initiator. The blockchain contract execution environment (CEE) 430 records hash representations of documents, data, transactions, and client contracts to the blockchain. Modification or updating of data can be achieved by further executing contracts on the scope, and performing a validation check on the input hash of the data from the object storage according to the blockchain to ensure that no external data modification has occurred. Various functions can be provided via the CEE API (application programming interface) 433. This beneficially allows the authenticity of the data to be verified without the need to trust the data storage of a single initiator. For example, the message payload submitted to the blockchain API has the following structure (e.g., in plain text as part of the metadata): sender, audience list, and basic identifier. The payload can be a ciphertext block containing member information and associated results from the execution of the smart contract.

[0113] The platform 400 may provide a variety of loan onboarding services. For example, the development of a client blockchain contract may require the participation of multiple parties, such as an initiator and an auditor. For example, an onboard-to-service provider contract may involve an initiator and a service provider, both of whom verify that the data is sufficiently complete for transfer to the service provider. All parties involved in the execution of the contract can read the data. Any party may refuse to execute the contract. If all parties agree, the resulting data facts are copied to each participant's encrypted data storage as part of the scope's header state.

[0114] Each onboarding contract may create a new scope in EOS 431 with the loan UUID as the scope UUID. The onboarding contract may also establish initial values ​​for facts in the scope. In some cases, not all facts will be established during the onboarding process. For example, the validation_results fact may only be populated after the initial run of the loan validation contract. Additionally, not all facts will be established for each loan type. For example, a HELOC loan scope may include a lien_property fact, but a personal loan may not include a lien_property fact.

[0115] A validation command (e.g., Service-Loan-ValidateService) may validate a loan as part of the onboarding process. In some cases, the loan validation process may examine the data for the loan in EOS 431 and perform a number of checks to ensure that the system underwriting guidelines are met. The validation results may be stored in the validation_results fact and may be displayed by the portfolio manager to the originator or interested investors. Performing validation checks in the client contract beneficially allows the originator to bypass traditional manual verification audits.

[0116] The "assign-to-servicer" service ensures that the requirements for servicing the loan are met. If the loan data is malformed in some way, the servicing application rejects the contract and the loan origination system 410 is responsible for correcting the problem.

[0117] Based on the needs of CEE, the encrypted object storage 431 can run in several different configurations. For example, in a "no external multi-party configuration", if CEE strictly handles single-party contracts or multi-party contracts where all parties are within the CEE execution environment, a single private addressable object storage node can be used. The replication function can be disabled. In an "external multi-party configuration", if the CEE execution environment needs to execute multi-party contracts with some parties that exist outside of EOS 431, the EOS and replication functions of the CEE execution environment are enabled. In some cases, EOS requires postgres to persist data. The CPU and memory requirements may depend largely on the amount of data that the EOS environment will support.

[0118] The blockchain 420 can be accessed via a blockchain node. The blockchain node provides a method for the CEE 433 to read events and send transactions to the distributed blockchain network.

[0119] Figure 5The application architecture 500 of the platform is schematically shown. The application layer 501 can provide a user interface for interacting with one or more blockchain-based applications. For example, a market and exchange application can be provided in which users can buy, sell, and trade valuable things. The valuable things can include, for example, asset-backed securities, cryptocurrencies, or tokenized assets.

[0120] The interface layer 501 may include a wallet application. An entity (e.g., an organization, system, or user) may need to have an account to conduct business on the blockchain. An account is represented by the public key portion of a public and private key pair. An account may contain a uniquely identified address, which may be a string value derived from the entity's public key (e.g., in Bech32 format), thereby providing a standard blockchain pseudonym. In the example of a hash transfer transaction, where user A is the hash holder and user B is the recipient. User A holds 100 hashes at address tp1kaczxflvhq4700r0ntdnqlxpu80xdp869seh9e (the address is derived from the public key portion of the key pair held by user A). User B also generates a key pair and address from the public key portion of the key pair tp18839rhfk0ql7mdqgn27eeaesmfr9ckpajssuc4. Before user A can send a transfer transaction request to the blockchain, she may need to sign the transfer transaction. User A signs the transaction using the private key portion of her key pair and submits the transaction to the blockchain. The blockchain verifies the transfer transaction signature against User A’s public key, verifying that she has an account on the blockchain and that the address holds enough hashes to pay the transaction fee and transfer to User B.

[0121] A wallet is where users (e.g., User A and User B) store their key pairs. Wallets are used to manage key pairs, addresses, and the token values ​​held by the addresses. In some cases, when using a blockchain wallet, an HD wallet can be used. An HD wallet allows an entity to create a root mnemonic seed and then derive subkeys from the root that can be used to hold value on the blockchain. For example, User A's address tp1kaczxflvhq4700r0ntdnqlxpu80xdp869seh9e is one of many keys in her HD wallet. An entity can import, export, or regenerate its wallet (and any subsequently exported addresses) using the root mnemonic seed. The root mnemonic seed is a secret value controlled by the entity and is never exposed to the blockchain system.

[0122] One or more applications may be executed on multiple devices. The multiple devices may include a personal computer (e.g., a portable PC), a notebook computer, or a tablet PC (e.g., iPad, Galaxy Tab), phones, smartphones (e.g. iPhone, Android-supported devices, ) or a personal digital assistant. The application may include a graphical user interface (GUI) for a user to access, manage, control various digital assets, conduct transactions, and other functions consistent with the functions described herein. The GUI may be presented on one or more devices.

[0123] The Contract Execution Environment layer 503 can be configured for the onboarding and management of private and sensitive information. The Contract Execution Environment (CEE) provides entities with the ability to exchange private data but still take advantage of the ownership, immutability, and value benefits provided by the blockchain. The CEE layer is the bridge between the blockchain and the financial services business logic. The CEE layer can connect directly to blockchain nodes to call transactions, query transactions, and listen to events.

[0124] The blockchain layer 500 is a blockchain network and provides a persistent, distributed, immutable and replicated deterministic state machine. The blockchain layer 500 may include a network (blockchain SDK 505) and a consensus layer 507 of the blockchain, which includes transaction ordering and consensus. The blockchain layer 500 may include middleware business applications (including coins, cryptocurrencies and tokenization) that utilize value and ownership tokens, allowing for exchange, trading and settlement of value tokens and bridges to legal currencies. The blockchain layer 500 uses smart contracts to provide bilateral exchange implementations and provides blockchain primitives such as account authorization, governance, staking, voting, gas and fee processing, telemetry and node configuration.

[0125] The blockchain 510 acts as a ledger, registry, and exchange for digital assets. The blockchain contains a record of all transactions, including loan entry and loan asset transfers. The blockchain used by the platform can be a proof-of-stake production blockchain. The blockchain combines the distributed, trustless, and immutable characteristics of the blockchain with the functionality of a ledger, registry, and exchange. In some embodiments, the blockchain can use a more flexible proof-of-stake consensus method 507 based on the SDK 505.

[0126] In some cases, the blockchain layer 510 may use many different proof-of-stake blockchains connected together to support diverse and scalable workloads. Each blockchain created with the SDK 505 can be completely independent and autonomous, while maintaining the ability to selectively connect to other chains through the use of IBC (Inter-Blockchain Communication). This additional flexibility means that a given application is allowed to establish its own dedicated blockchain network based on the requirements of its own application, thereby supporting the concept of aggregate use of many different blockchain instances if the application requires it to use as little as one computer / one node over a full public global network.

[0127] The blockchain layer 510 can support multiple types of integration, including application-based and smart contract-based integration, which provides opportunities for high performance or high flexibility depending on the requirements. In some cases, the SDK 505 can be developed using Protobuf, which has direct forwarding messaging and a state machine model that provides extension points.

[0128] The platform 500 may allow a blockchain to maintain its network sovereignty, facilitate interaction with other blockchains, and improve scalability. A flexible peer-to-peer network model may greatly simplify the operational aspects of a blockchain network while creating a more fault-tolerant network by using redundant network paths in a peer-to-peer architecture. The platform may include a WASM (network assembler) environment that allows the creation of smart contracts for deployment flexibility at the expense of performance and ease of development, thereby reducing the cost of maintaining and deploying blockchains and making it easier for third parties to integrate while maintaining sovereignty and control.

[0129] Digital Asset Registration Tool (DART)

[0130] Loan transfers have always been challenging. Conventional loan document management systems can be inefficient. For example, loan data, documents, or information can be maintained across disconnected systems (e.g., LOS, servicing systems, investor portfolio management systems, eVault, etc.). Additionally, manual tracking (such as using spreadsheets to capture portfolio details, purchase recommendations, wire transfer instructions / dates) can add additional friction. Conventional systems can require multiple updates to the Mortgage Electronic Registration System (MERS) database for each transfer, and quality control expenditures can be duplicated.

[0131] The present disclosure can address the above shortcomings by providing an integrated digital asset registry tool (DART). DART can be an integrated registry configured to track control, transfer, assignment and / or ownership of controllable electronic records (such as a promissory note (eNote) associated with a loan agreement) in substantially real time.

[0132] In some cases, DART can eliminate the need for paper transfers, bills of sale or other security agreements or other physical document transfers. In some cases, DART can eliminate the need to manually register eNotes and loans with intermediary systems including the Mortgage Electronic Registration System (MERS). In some cases, DART is configured to enable an intra-party blockchain-based transfer of fully digital, tokenized mortgage assets from a transferor to a transferee, and provide verification that perfect super-priority control rights have been granted to the transferee.

[0133] In some cases, EOS is configured to share cryptographic facts and metadata with the loan market module. DART is used to record loan transactions occurring via the loan market module in substantially real time.

[0134] Figure 6 An example of a platform 600 including a digital asset registration tool (DART) 610 is shown. The DART 610 can be used for electronic promissory note (eNote) registration. The DART can be configured to track control, transfer, assignment, and / or ownership of an eNote associated with a loan contract in substantially real time.

[0135] In some cases, DART can include eNote registration, tracking and recording of mortgagee services. DART can monitor transactions, eliminating the need to record market transfers in another system.

[0136] In some cases, blockchain onboarding system 620, blockchain 630, vault 640 (integrated or separate eVault), and integrated registry application 610 may constitute an ESIGN / UETA safe harbor compliance control system.

[0137] The platform may include a verification oracle 660, where verification results may be digitally signed by the source and added to the blockchain. For example, an electronic trust letter and due diligence results are stored in EOS immediately after the transaction is closed and are accessible on the loan market. In some cases, due diligence data such as a due diligence 15E certification may be transmitted from the originator to the verification oracle along with the loan asset (e.g., an eNote), thereby protecting the holder as well as the initial insured when appropriate. Verification may be attached to the asset as close to origination as possible and may travel with the asset through investors on the blockchain. In some cases, the finalized loan verification (including electronic RL, review results and reports, and indemnity policies) may become attributes of the loan asset on the blockchain. Due diligence results and origination data may be encrypted and stored in the encrypted object storage 640.

[0138] The platform manages and trades its loans on the Portfolio Manager and Marketplace 650. To allow these applications to read the loan data in the encrypted object store, the LOS can share the data by granting the public key of other applications. When a blockchain scope object is granted to another public key, the CEE 620 can copy the data to the encrypted object store of another application. Subsequent modifications or changes to the scope through contract execution can also be copied to the encrypted object store and may require a key to read the scope, as described above.

[0139] In some cases, the portfolio manager 650 may allow participants (e.g., investor A, investor B) to purchase loans via the loan marketplace (portfolio manager). For example, a seller (e.g., originator) may select loans to pool and pledge, sell, and select a counterparty. The counterparty may be notified, accept the transaction, and purchase the loan via the portfolio manager. The loan or eNote may be transferred to the investor at the time of purchase. Verification is attached to the asset as close to origination as possible and travels with the asset through the investors on the blockchain. Figure 7 An example of a user interface (UI) provided by a portfolio manager is shown. The UI can provide intuitive tracking or asset management, such as viewing real-time service data (service integration) and current loan data / documents from blockchain records, providing convenient access to trading partners, and providing near real-time asset / fund transfers.

[0140] Fig. 8A A platform 800 with blockchain-based loan validation and integrated eNote registry is schematically shown. The result can be a fully digital, tokenized asset that has the same velocity as the capital it is collateralized against. The DART or registry can beneficially provide an ESIGN / UETA safe harbor compliance control system, eliminating the need to certify a security agreement / bill of sale or submit a UCC financing statement. For example, once the transfer is complete, the new owner can have fully perfected "super priority" title. The platform can allow USDF consortium members to mint / destroy 100% fiat-backed digital tokens for real-time settlement of market transactions. The platform can also beneficially allow real-time markets for trading securities and provide data to inform pricing in primary and secondary markets.

[0141] Figure 8B The data sharing mechanism in the platform 800 is schematically shown. As described above, the loan scope model of the platform can be used by various parties. For example, the loan scope model (e.g., blockchain loan scope, encrypted loan data, etc.) can be used by service applications and portfolio managers, allowing joint contract execution and data sharing between these applications. For example, the loan scope constructed by the initiator CEE 810 can be assigned a unique identifier (e.g., scope ID), which can be a universal unique identifier (UUID) and stored in the initiator EOS 811. Each participant can have its own key pair and its own contract execution environment and instance of EOS. For example, the portfolio manager can have a key pair uniquely associated with it and have an instance of PM CEE 820 including PM EOS 821, and the service entity can have a key pair uniquely associated with it and have an instance of service provider CEE 830 including service provider EOS 831.

[0142] Data sharing can be achieved through key-based data sharing and replication and / or joint contract execution in CEE. In some cases, any of the data sharing methods can include copying to the EOS of another party (e.g., service provider EOS 831) and adding the other party as an audience member. Audiences can refer to other parties that can decrypt data but are not data owners. The data owner of the scope can allow other parties to have read-only access to the data. Audience members can decrypt the data using their own private keys. Encrypted data and audience and key information can be packaged into a single data structure, which is a data instance with metadata and encryption (DIME).

[0143] Data sharing mechanisms and audience information control can be supported through end-to-end encryption within the blockchain protocol as described above. Submitted data can exist in an unencrypted / visible state assigned to the specified audience in the submission, processing / verification and retrieval context.

[0144] The submission context can be assigned to the creator who submitted the information to the system. While the information can be transferred to another owner, it may not be possible to submit data to the system and not be marked as its owner. Changing the ownership of an asset can be the same as above, such as by the existing owner adding permissions to the new owner, and then the new owner retrieving the data and resubmitting it back to the system to complete the change of ownership.

[0145] Computer Systems

[0146] In another aspect, the present disclosure provides a computer system programmed or otherwise configured to implement the method of the present disclosure. Fig. 9 , computer system 901 may be programmed or otherwise configured to implement a method for providing a blockchain-based lending or loan processing platform. For example, computer system 901 may be configured to implement a blockchain-based on-boarding system, a smart contract execution environment (CEE), or other components of the platform. Computer system 901 may be a user's electronic device or a computer system remotely located relative to the electronic device. Computer system 901 may be a cloud server.

[0147] The computer system 901 may include a central processing unit (CPU, also referred to herein as a "processor" and "computer processor") 905, which may be a single-core or multi-core processor, or multiple processors for parallel processing. The computer system 901 also includes a memory or memory location 910 (e.g., random access memory, read-only memory, flash memory), an electronic storage unit 915 (e.g., a hard disk), a communication interface 920 (e.g., a network adapter) for communicating with one or more other systems, and peripheral devices 925 (such as cache, other memory, data storage, and / or an electronic display adapter). The memory 910, the storage unit 915, the interface 920, and the peripheral devices 925 communicate with the CPU 905 via a communication bus (solid line) such as a motherboard. The storage unit 915 may be a data storage unit (or data repository) for storing data. The computer system 901 may be operably coupled to a computer network ("network") 930 with the help of the communication interface 920. The network 930 may be the Internet, an internetwork, and / or an extranet, or an intranet and / or an extranet in communication with the Internet. In some cases, network 930 is a telecommunications and / or data network. Network 930 may include one or more computer servers that may implement distributed computing (such as cloud computing). In some cases, with the help of computer system 901, network 930 may implement a peer-to-peer network that may enable devices coupled to computer system 901 to act as clients or servers.

[0148] The CPU 905 may execute a sequence of machine-readable instructions that may be embodied in a program or software. The instructions may be stored in a memory location such as the memory 910. The instructions may be directed to the CPU 905, which may then program or otherwise configure the CPU 905 to implement the methods of the present disclosure. Examples of operations performed by the CPU 905 may include reading, decoding, executing, and writing back.

[0149] CPU 905 may be part of a circuit, such as an integrated circuit. One or more other components of system 901 may be included in the circuit. In some cases, the circuit is an application specific integrated circuit (ASIC).

[0150] The storage unit 915 may store files, such as drivers, libraries, and saved programs. The storage unit 915 may store user data, such as user preferences and user programs. In some cases, the computer system 901 may include one or more additional data storage units located external to the computer system 901 (e.g., located on a remote server that communicates with the computer system 901 via an intranet or the Internet).

[0151] Computer system 901 can communicate with one or more remote computer systems via network 930. For example, computer system 901 can communicate with a remote computer system of a user (e.g., a merchant or an end user). Examples of remote computer systems include personal computers (e.g., portable PCs), tablet computers or tablet PCs (e.g., iPad, Galaxy Tab), phones, smartphones (e.g. iPhone, Android-supported devices, ) or a personal digital assistant. A user can access the computer system 901 via a network 930.

[0152] The methods described herein may be implemented by machine (e.g., computer processor) executable code stored in an electronic storage location of the computer system 901 (e.g., such as stored in the memory 910 or electronic storage unit 915, for example). The machine executable or machine readable code may be provided in the form of software. During use, the code may be executed by the processor 905. In some cases, the code may be retrieved from the storage unit 915 and stored on the memory 910 for ready access by the processor 905. In some cases, the electronic storage unit 915 may be eliminated and the machine executable instructions may be stored on the memory 910.

[0153] The code may be precompiled and configured for use with a machine having a processor suitable for executing the code, or may be compiled at run time. The code may be provided in a programming language that may be selected to enable the code to be executed in a precompiled or as compiled manner.

[0154] Aspects of the systems and methods provided herein (such as computer system 901) can be embodied in programming. Various aspects of the technology can be considered as "products" or "articles", which are usually in the form of machine (or processor) executable code and / or associated data carried or embodied in a type of machine-readable medium. The machine executable code can be stored in an electronic storage unit (such as a memory (e.g., read-only memory, random access memory, flash memory) or a hard disk). "Storage" type media can include any or all tangible memories of a computer, processor, etc., or its associated modules (such as various semiconductor memories, tape drives, disk drives, etc.), which can provide non-temporary storage at any time for software programming. All or part of the software can communicate from time to time via the Internet or various other telecommunications networks. For example, such communications can load software from one computer or processor to another computer or processor, such as from a management server or host to a computer platform of an application server. Thus, another type of medium that can carry software elements includes optical waves, radio waves, and electromagnetic waves, such as those used across physical interfaces between local devices, through wired and optical landline networks, and through various air links. Physical elements that carry such waves (such as wired or wireless links, optical links, etc.) can also be considered as media that carry software. As used herein, unless limited to non-transitory, tangible "storage" media, terms such as computer or machine "readable media" refer to any medium that participates in providing instructions to a processor for execution.

[0155] Thus, machine-readable media (such as computer executable code) may take a variety of forms, including but not limited to tangible storage media, carrier media, or physical transmission media. Non-volatile storage media including, for example, optical or magnetic disks, or any storage device in any computer or the like may be used to implement the databases and the like shown in the accompanying drawings. Volatile storage media include dynamic memory, such as the main memory of such a computer platform. Tangible transmission media include coaxial cables; copper wire and optical fiber, including the wires that make up a bus within a computer system. Carrier transmission media may take the form of electrical or electromagnetic signals, or acoustic or light waves, such as those generated during radio frequency (RF) and infrared (IR) data communications. Thus, common forms of computer readable media include, for example, a floppy disk, a flexible disk, a hard disk, a magnetic tape, any other magnetic medium, a CD-ROM, a DVD or DVD-ROM, any other optical medium, a punched card tape, any other physical storage medium having a pattern of holes, a RAM, a ROM, a PROM and an EPROM, a FLASH-EPROM, any other memory chip or cartridge, a carrier wave that transmits data or instructions, a cable or link that transmits such a carrier wave, or any other medium from which a computer can read programming code and / or data. Many of these forms of computer readable media can participate in carrying one or more sequences of one or more instructions to a processor for execution.

[0156] The computer system 901 may include or communicate with an electronic display 935, which includes a user interface (UI) 940 for providing a portal for users to interact with, for example, a financial services platform. The portal may be provided through an application programming interface (API). A user or entity may also interact with various elements in the portal via the UI. Examples of UIs include, but are not limited to, graphical user interfaces (GUIs) and web-based user interfaces.

[0157] The methods and systems of the present disclosure may be implemented by one or more algorithms. The algorithms may be implemented by software when executed by the central processing unit 905. For example, the algorithms may be configured to generate a visual code that indicates or represents a transaction amount for a settlement between a first party and a second party.

[0158] Although preferred embodiments of the present invention have been shown and described herein, it will be apparent to those skilled in the art that such embodiments are provided by way of example only. Without departing from the present invention, those skilled in the art will now expect many variations, changes and substitutions. It should be understood that various alternatives to the embodiments of the present invention described herein may be adopted in practicing the present invention. The appended claims are intended to define the scope of the present invention, and thus encompass methods and structures and their equivalents within the scope of these claims.

Claims

1. A blockchain-based lending or loan processing platform, comprising: A blockchain on-boarding system including a smart contract execution environment (CEE), wherein the blockchain on-boarding system is configured to: (1) automatically processing loan data from a loan origination system (LOS) to virtually execute one or more loan contracts within the CEE, wherein the loan data includes a plurality of loan-related facts; (2) encrypting the loan-related facts to generate a plurality of encrypted facts associated with one or more loan assets; and (3) generating a plurality of hashes for the cryptographic facts, wherein the hashes are recorded on a blockchain, and wherein a combination of each cryptographic fact and its corresponding hash is stored in an encrypted object store (EOS) separate from the blockchain.

2. A platform according to claim 1, wherein each fact corresponds to a single or discrete piece of data, a hash of which is recorded on the blockchain.

3. The platform of claim 1, wherein the CEE is configured to remove confidential data associated with the one or more loan assets from the blockchain while maintaining the ability to use the blockchain to ensure data integrity.

4. The platform of claim 3, wherein the hash of the cryptographic fact is recorded on the blockchain, and wherein the cryptographic fact is not recorded on the blockchain.

5. The platform of claim 3, wherein the EOS is local to the CEE or the EOS is part of the CEE.

6. A platform according to claim 1, wherein the plurality of loan-related facts include a credit score, borrower information or profile, an electronic copy of a signed security instrument, a copy of an electronic promissory note (eNote), third party review (TPR) due diligence results, and / or loan terms.

7. The platform of claim 1, wherein the loan data is originated by an originating party, and wherein the platform is configured to enable the originating party to create a unique wallet having a root key pair, the root key pair comprising a public key and a private key.

8. The platform of claim 7, wherein the loan-related facts are encrypted using the public key of the originating party.

9. The platform of claim 8, wherein the hash of the cryptographic fact is recorded on the blockchain along with the initiating party's public key and a timestamp.

10. The platform of claim 7, wherein the private key is usable by the initiating party, or another party with permission from the initiating party, to decrypt the encrypted fact stored in the EOS.

11. The platform of claim 1, wherein the blockchain contains records of all transactions, including loan entry and loan asset transfers.

12. A platform according to claim 1, wherein a collection of loan-related facts together constitute a token recorded on the blockchain.

13. A platform according to claim 12, wherein the token comprises a non-fungible token (NFT).

14. The platform of claim 12, wherein a collection of tokens collectively constitute a loan asset.

15. The platform of claim 13, wherein each token is assigned a unique identifier.

16. A platform according to claim 12, 13 or 14, wherein the platform is configured to specify ownership at a token level.

17. The platform of claim 16, wherein the platform is configured to bifurcate ownership of tokens between data owners and value owners.

18. The platform of claim 17, wherein the platform identifies the value owner as an entity entitled to the monetary value of the loan asset comprising the token, and allows the value owner to transfer value rights to other parties.

19. The platform of claim 18, wherein the platform identifies the data owner as the entity that controls the facts contained in the token.

20. The platform of claim 19, wherein the platform is configured to only allow the data owner to affect the facts in the token by adding one or more facts, changing one or more facts, or deleting one or more facts.

21. A platform according to claim 20, wherein the platform is configured to allow the data owner to freely share ownership, enabling multiple data owners, and wherein after the token has been settled on the blockchain, each of the multiple data owners needs to individually sign any subsequent changes to the token.

22. The platform of claim 19, wherein the platform is configured to allow the data owner to grant read-only access to the token to one or more other non-owner parties.

23. A platform according to claim 22, wherein the platform is configured to enable the one or more other non-owner parties to decrypt the token and view / access the facts within the token without allowing the non-owner parties to make any changes to the token on the blockchain.

24. A platform according to claim 23, wherein any attempted changes made by the non-owner party with only read-only access will not be accepted or verified for recording on the blockchain.

25. The platform of claim 19, wherein the platform identifies a sponsoring party as an entity that creates and settles the token through the CEE, and wherein the sponsoring party is by default initially the data owner and the value owner of the token.

26. The platform of claim 25, wherein the platform is configured to assign a unique public-private key pair to the initiating party.

27. The platform of claim 26, wherein the public key is usable by the originating party to create a digital signature on the token.

28. The platform of claim 27, wherein the platform allows verification and validation of the digital signature through the private key connected to the public key and associated with the initiating party.

29. The platform of claim 27, wherein the token is encrypted and the private key can be used to decrypt and view / access the facts within the token.

30. The platform of claim 27, wherein the public key and any subsequent authorized modifications or changes to the token are included in the token.

31. A platform according to claim 30, wherein any authorized transfer of ownership of the token is tracked or traced by an integrated Digital Asset Registration Tool (DART).

32. A platform according to claim 30 or 31, wherein the platform is configured to allow authorized subsequent modifications or changes to the token only by entities whose digital signature matches the digital signature of the current data owner of the token.

33. A platform according to claim 32, wherein the platform is configured to reject modifications or changes proposed by any entity whose digital signature does not match the digital signature of the current data owner of the token.

34. The platform of claim 1 further comprises a Digital Asset Registry Tool (DART) connected to the platform, wherein the DART is an integrated registry configured to track control, transfer, assignment and / or ownership of controllable electronic records, such as a promissory note (eNote) associated with a loan agreement, substantially in real time.

35. The platform of claim 34, wherein the DART is designed to eliminate the need for paper assignments, bills of sale, or other security agreement transfer documents or physical document delivery.

36. The platform of claim 34, wherein said DART is designed to eliminate the need for manual registration of eNotes and loans with any additional intermediary systems.

37. A platform according to claim 34, wherein the DART is configured to effectuate an intra-party blockchain-based transfer of a fully digital, tokenized collateral asset from a transferor to a transferee, and to provide verification that full super-priority control rights have been granted to the transferee.

38. The platform of claim 34, wherein the EOS is configured to share the cryptographic facts and metadata with a loan market module, and wherein the DART is used to record loan transactions occurring via the loan market module in substantially real time.

Images