Systems and methods for compliant digitally represented assets - Patents.com

Abstract

A compliance system configured to manage transactions on a digital asset network in accordance with a compliance policy is provided. The digital asset network is configured to enforce rules governing recording of transactions on a public ledger. The compliance system is configured to determine that a requested transaction complies with the compliance policy, generate at least partially encrypted Compliance Related Aid Information (CRAI), where the CRAI includes information configured to facilitate independent verification of compliance, associate at least a portion of the CRAI with transaction information stored on the public ledger, and store the associated CRAI in a storage location accessible via the digital asset network.

Description

[Technical field]

[0001] The subject matter disclosed herein relates to systems for managing transactions on digital asset networks, and in particular to systems configured for enforcement of compliance policies for such networks. [Background technology]

[0002] Public cryptocurrency systems offer many of the advantages that have made these systems so successful and may enable them to replace part or all of the existing banking infrastructure in the future. At the same time, public cryptocurrency systems suffer from several limitations that reduce their usefulness.

[0003] Public ledgers such as Bitcoin and Ethereum do not fully protect transaction privacy, as all transactions are publicly visible. Instead, participants in these networks employ (possibly many) pseudonymous identifiers known as "addresses", which provide limited privacy. However, the privacy guarantees offered by pseudonymous identifiers are weak, and any party that can link a single address to a user's real identity will likely be able to recover the user's entire transaction history.

[0004] Public ledgers such as Bitcoin are "permissionless," i.e., any party can execute transactions on the system. As a result of this design, users do not need to comply with Know Your Customer (KYC) or Anti-Money Laundering (AML) rules, or any other banking regulations that enforce restrictions on the flow of currency. Currently, compliance with banking regulations is enforced only in limited locations within the cryptocurrency ecosystem, namely, exchanges and other Virtual Asset Service Providers (VASPs) that interface between cryptocurrencies and the traditional banking system. These providers then use the public nature of the cryptocurrency network to analyze the transaction patterns of the cryptocurrencies they process, e.g., to make determinations as to whether their customers are engaging in transactions that may be risky or illegal. This process involves a significant amount of guesswork and estimation from incomplete data. Nonetheless, multiple commercial products have been developed to perform this tracing and risk assessment function.

[0005] Techniques such as "zero-knowledge proofs" can improve the privacy properties of cryptocurrency systems. Such techniques have been deployed as part of some cryptocurrency systems, concealing the identities of participants and the amount of each transaction. However, improved privacy has implications for regulatory compliance. As privacy techniques improve, they tend to reduce the quality of on-chain transaction data, further reducing the accuracy of tracing and risk estimation data gleaned from public transaction data. Privacy improvements are likely to be deployed in the future and may pose a threat to the modern cryptocurrency ecosystem.

[0006] Several proposed solutions to this problem have been offered. One solution is to discard the existing decentralized cryptocurrency system and "wallet" software and replace it with a centralized system, e.g., operated by a traditional banking partner or a VASP, possibly simplifying regulatory compliance at the cost of radically removing the decentralized nature of cryptocurrency technology. Other proposals require users to voluntarily report on each transaction in a separate, centralized registry. This approach also requires new trusted parties, and is only effective if all parties on the network participate. Summary of the Invention

[0007] The subject matter disclosed herein is directed to a sealed asset platform (SAP) configured to provide a compliance layer and an architecture to facilitate regulatory compliance systems interoperating with existing cryptocurrency networks without sacrificing user or transaction privacy.

[0008] SAPs may be configured to augment cryptocurrency transactions and wallets with compliance relevant auxiliary information (hereinafter "CRAI") to facilitate enforcing compliance, and to use the CRAI to cryptographically ensure compliance with compliance policies in each relevant information interaction. SAPs generate sealed assets by explicitly or implicitly augmenting some or all transactions and / or wallets with the CRAI.

[0009] The CRAI may include user identification information (such as name, national identifier, etc.), account numbers and facility identifiers, authentication information issued by third parties (including, but not limited to, credit risk score and / or accredited investor status), information related to user behavior and / or payment patterns (including, but not limited to, transaction history, provenance of funds, source of funds, counterparty identity, and / or information related to the transaction and / or any other information deemed relevant for compliance. The CRAI may be mechanically recorded and / or inferred by ledger mechanisms (e.g., transaction history) or provided by an external party (e.g., KYC information, and information from asset-aware services described below).

[0010] While the CRAI is recorded on the cryptographic ledger, it is not provided in an explicit form that can be read by anyone with access to the ledger, as this would compromise privacy, rather this information is cryptographically protected and only permissible parties for each transaction, as determined by, for example, compliance policies, can see permissible inferences.

[0011] Cryptographic protection of the CRAI may be provided by any one or more suitable methods. Non-limiting examples of such methods may include the following: (1) Attach the CRAI in encrypted form so that decryption is possible only to authorized parties. This may include cryptographically ensuring, e.g., by zero-knowledge proofs, that decryption is possible and that the underlying data is correctly formed and authenticated. This method may allow other parties (e.g., validators or "miners" of the distributed ledger) to recognize valid transactions while lacking the ability to decrypt each CRAI. (2) Attaching the CRAI in a form that cannot be recovered (e.g., due to privacy concerns and / or data size constraints). For example, the CRAI may contain only inferences and attributes (e.g., the transaction sender's nationality, the transaction sender's total monthly transaction volume, etc.), and the correctness of the CRAI is cryptographically guaranteed, e.g., by a zero-knowledge proof. (3) Verifying and / or disclosing the CRAI using a cryptographic secure multiparty computation performed between a party holding the CRAI and a party wishing to verify properties of the CRAI.

[0012] As previously discussed, sealed assets can facilitate enforcement of jurisdiction-specific compliance policies (e.g., one or more rules), implemented, for example, as a computer program that determines, based on data from one or more sources of information, whether a given transaction should be allowed and what information must be disclosed to whom. Such information may include, but is not limited to, one or more selected from transaction details (e.g., amount, time, etc.), user (i.e., sender) identification information contained within the CRAI, recipient information (e.g., cryptographic identifiers such as public keys), public and / or personal information stored on a cryptocurrency ledger, etc.

[0013] Compliance policies may be established by relevant authorities in a jurisdiction, by one or more consortia (e.g., autonomous industry associations) that enforce their regulatory obligations, by the regulated entity, and / or by any other appropriate party. For example, compliance policies may be determined by an organization or individual to meet its unique requirements, such as preventing financial outflows above a certain rate, financial outflows outside a designated allow list of destinations, etc.

[0014] A compliance policy may specify, for example, what CRAI information must be attached to each transaction, who should be able to see the CRAI information, whether the CRAI information is conveyed explicitly or implicitly by cryptographically guaranteed inference, etc. For example, a policy may dictate that coarse-grained information is published and authenticated to transaction recipients, that detailed wallet owner identification information is attached in encrypted form that can be decrypted by authorized law enforcement under certain conditions, and that designated authorities can only see transactions that exceed a predefined value in real time. A compliance policy may further impose restrictions on which transactions are allowed to occur in virtual assets. For example, a compliance policy may specify restrictions on the amount of currency that a user can send in a single transaction, during a certain period of time, to a designated party or group of parties, etc., including a combination of one or more such restrictions.

[0015] The SAP may be configured to define one or more sealed wallets for a user, including, for example, a data structure configured to facilitate binding the sealed assets held by the user to the identity credentials of the user. In particular, the SAP may be configured to define the sealed wallets according to the policy of the jurisdiction with which the wallet is associated (e.g., the jurisdiction to which the wallet owner is subject). This may involve, for example, facilitating the implementation of KYC, AML, and / or CTF checks by regulated entities from a list prescribed by the policy, issuance of credentials by other authorized parties attesting to relevant attributes of the wallet owner, etc. These checks may be validated by a wallet identity provider (WIP), i.e., a party that maintains the ability to issue new sealed wallets. Individual assets may determine which identity providers are acceptable, for example, by specifying a policy to reject transactions by unauthorized WIPs.

[0016] The CRAI is generated or maintained by the user's wallet implementation and is not directly trusted by other users, and the SAP is configured to ensure that each transaction complies with the policy with which it is associated, and thus the SAP may provide a mechanical method for checking all transactions for such compliance so that non-compliant candidate transactions are automatically rejected.

[0017] The sealed asset may be an entirely new virtual asset, or the sealed asset may be obtained by extending an existing native (i.e., traditional) asset (e.g., an existing cryptocurrency such as Bitcoin) with an appropriate CRAI (e.g., creating a "sealed Bitcoin"). In the latter case, the SAP is configured to execute a sealing process in which units of the native asset are converted into units of the sealed asset. Requirements are defined by the policy and may consist, for example, of manual KYC / AML / CTF checks by regulated entities from a list prescribed by the policy.

[0018] After every sealed asset is created, it may be transacted within a conforming pool containing multiple sealed wallets and multiple sealed assets, each associated with the same and / or compatible compliance policies. A single sealed asset may be associated with multiple conforming pools because different wallets may be subject to different policies (e.g., depending on the jurisdiction in which the operating wallet's owner resides). Moving a sealed asset between conforming pools is subject to the policies of both the originating pool and the destination pool, which may allow unlimited moves, may impose constraints (e.g., in amounts or in required reporting), or may require the move to be approved by a designated gateway.

[0019] The SAP may be further configured to facilitate "breaking the seal" of a sealed asset, i.e., extracting the underlying native from the sealed asset, e.g., in the case of a sealed asset created by sealing a native asset as described above, by removing the CRAI associated with the sealed asset. This may be performed separately for any unit of the sealed asset, e.g., by the owner of the sealed asset. In such a case, the extracted native asset will no longer be in the conforming pool, and other parties may recognize the asset as an asset whose compliance is no longer assured by the SAP, and thus reject all transactions for the asset until it is resealed. In this case, the sealing may be performed by a process determined by the policy described above. According to some embodiments, the SAP may be configured to automatically reseal the asset if it has not yet been transferred to another user (and thus can be recognized as already associated with the removed CRAI). The ability to break the seal may thus provide a measure of security to facilitate protection against the avoidance of loss of funds, e.g., in the case of a system failure.

[0020] Thus, SAP is configured to allow transactions in conforming pools that correctly communicate and propagate the CRAI of the associated wallet and associated transaction (as defined by policy), which may include considering information regarding the transaction's counterparty, upstream transactions including the resulting funds being spent, and the CRAI associated with the transaction.

[0021] According to some embodiments, a SAP may facilitate one or more coordinated means for propagating the CRAI through multiple commingled systems, for example, by a custodian serving many customers, by a decentralized exchange and / or other decentralized financial system, or by a privacy enhancing system such as a mixnet. Thus, a SAP may be configured to accurately communicate the CRAI when funds are withdrawn from a commingled system.

[0022] SAP may be configured to provide default privacy guarantees and protection of all personal information unless and until jurisdictional policies dictate that privacy and personal information be made public. This may include default protection of users' personally identifiable information, such as KYC information and transaction history, which are not acceptable for disclosure except to duly authorized parties under policy specific conditions.

[0023] SAP may support sealed assets, carry CRAI, and enforce policies on any type of virtual asset. In this document, the terms "virtual asset", "digital asset", and "asset" are used interchangeably to refer to any asset whose ownership and transfer can be represented digitally on a computer system. This may include, but is not limited to, fungible assets (assets in which all units have equal value and do not contain inherently different identities, e.g., most cryptocurrencies, stable coins, fungible tokens, and bank-issued digital currencies), non-fungible tokens that represent ownership or control of different (physical or virtual) assets, assets made non-fungible by additional inferences on the provenance of the assets (e.g., "colored coins" or coins whose value is affected by provenance due to chain analysis), etc.

[0024] Such assets may be created on and primarily defined by a blockchain ledger (e.g., most cryptocurrencies, including stablecoins), and / or may represent ownership of other assets (e.g., digital tokens that represent ownership of financial instruments or assets, such as securities, financial derivatives, commodities, real estate, collectibles, etc.).

[0025] SAP may operate against a public blockchain-based ledger, against a private or permissioned blockchain-based ledger, and / or against any other suitable digital system capable of representing asset ownership and asset movement events using well-defined semantics, the digital system including a database configured to represent such information. Digital systems may include, but are not limited to, payment and / or clearing services that digitally convey movements of currency, securities, or other assets.

[0026] The SAP may be configured to maintain the CRAI and enforce compliance policies across transactions involving multiple types of sealed assets and / or multiple blockchain-based consensus systems (or other systems for representing virtual assets) to create a unified conforming pool. For example, the SAP may track the CRAI and enforce compliance across a transaction exchanging one sealed BTC coin tracked by the Bitcoin blockchain for 35 sealed ETH coins tracked by the Ethereum blockchain.

[0027] According to an aspect of the subject matter disclosed herein, there is provided a compliance system configured to manage transactions on a digital asset network in accordance with a compliance policy, the digital asset network being configured to enforce rules governing recording of transactions on a public ledger, the compliance system comprising: determining that the requested transaction complies with a compliance policy; generating at least partially encrypted Compliance Related Aided Information (CRAI), the CRAI including information configured to facilitate independent verification of compliance; and associating at least a portion of the CRAI with transaction information stored in the public ledger and storing the associated CRAI in a storage location accessible via the digital asset network.

[0028] It will be understood that, throughout this specification and the appended claims, unless otherwise clear from the context, terms such as "compliance," "compliance system," and the like are used with reference to internal policies (e.g., policies defined by a compliance policy) and not necessarily with reference to compliance with relevant regulations, laws, etc. Although there may be overlap between these two policies, i.e., a compliance policy may be defined to facilitate compliance with relevant regulations, laws, etc., the intent in the subject matter disclosed herein relates to system-defined policies, unless otherwise clear from the context.

[0029] The compliance policy is associating encrypted regulatory information with one or more of the user's transactions, the regulatory information being decodable by an associated regulatory agent; generating a report including information regarding the one or more transactions; and cryptographically storing the report including any associated regulatory information.

[0030] The compliance policy may define one or more conditions that constitute suspicious activity, and the compliance system is configured to determine that one or more transactions constitute the defined suspicious activity. The compliance system may be configured to cryptographically store the report, including the regulated information, such that knowledge of the existence of the report is encrypted. At least the user may not be able to use the information to decrypt the regulated information. A non-limiting example is described below as compliance policy example 5 (reporting suspicious activity).

[0031] Associating regulatory information and generating reports may be performed by a wallet associated with a user. A non-limiting example is described below as Compliance Policy Example 13 (Foreign Account Reporting).

[0032] The storage location may be a public ledger of a digital asset network. Associating the CRAI with a transaction may include attaching the CRAI to the transaction.

[0033] The storage location may be a publicly accessible server, and transaction information recorded on the digital asset network's public ledger references the storage location.

[0034] A policy may define one or more attributes of a prohibited transaction, and the compliance system is configured to prevent the execution of a transaction that is deemed prohibited by the compliance policy. A non-limiting example is described below as Compliance Policy Example 14 (Enforcement of Prevention and Sanctions).

[0035] A policy may define one or more attributes of a transaction that require inference, and a compliance policy is configured to identify when a transaction requires inference, calculate the amount of inference, and initiate a transaction to satisfy the required inference. A non-limiting example is described below as compliance policy example 11 (paying taxes).

[0036] The compliance system may be configured to utilize the capabilities of the digital asset network to check the validity of the CRAI attached to the transaction information, thereby verifying compliance with compliance policies.

[0037] The compliance system may include a number of sealed wallets defined by a compliance policy, where the sealed wallets are configured to infer against the CRAI to determine whether a requested transaction complies with the compliance policy.

[0038] At least a portion of the sealed wallet may be implemented as code stored in the digital asset network.

[0039] The compliance system may be further configured to reason against a CRAI associated with one or more transactions.

[0040] The CRAI may include attestation that the transaction complies with compliance policies.

[0041] The CRAI may include compliance information relevant to determining the compliance of the requested transaction with a compliance policy.

[0042] The compliance information may associate the identity of one or more participants with the transaction.

[0043] The compliance information may relate to the details of the transaction.

[0044] The compliance system may further comprise an identity provider configured to verify information corresponding to a user and, upon verification, issue an identity proof to the user.

[0045] The identity proof is A public component containing the user's identity, and / or It may include a private component that contains cryptographic keying material.

[0046] The identity proof may form at least a part of the CRAI.

[0047] The compliance system may be configured to extend native assets associated with the digital asset network by attaching a CRAI in accordance with a compliance policy, thereby generating a sealed asset.

[0048] The compliance system may be configured to separate the CRAI from the sealed assets, thereby extracting the native assets from the sealed assets.

[0049] The compliance system may be further configured to define conforming pools containing sealed wallets and sealed assets defined by compatible compliance policies.

[0050] A compliance policy may define which compliance policies are compatible.

[0051] Compliance policies may define the conditions under which sealed assets may leave the compliant pool.

[0052] The compliance system may be further configured to prevent transactions involving one or more parties.

[0053] The CRAI may include a regulatory escrow access field configured to facilitate third-party verification of each transaction.

[0054] The compliance system may be further configured to attach an encoded mathematical function associated with the transaction to the transaction.

[0055] The compliance system may be further configured to analyze one or more transactions for suspicious activity.

[0056] Encryption of at least a portion of the CRAI may facilitate verification of the CRAI without disclosing the contents of the CRAI.

[0057] This verification may involve a zero-knowledge proof.

[0058] The encryption of at least a portion of the CRAI may be unrecoverable.

[0059] The transaction information may include one or more selected from the group consisting of a cryptographic identifier of the sender of the transaction, a cryptographic identifier of the recipient of the transaction, and transaction details.

[0060] A transaction may involve transferring currency.

[0061] The currency may be a cryptocurrency.

[0062] The compliance system may be configured to manage transactions on the digital asset network in accordance with at least one compliance policy selected from the two or more compliance policies.

[0063] The compliance system may include one or more computer processors and memory storing executable instructions for directing the system to operate as configured.

[0064] For a better understanding of the subject matter disclosed herein, and to illustrate how the same may be carried out in practice, embodiments will now be described, by way of non-limiting example only, with reference to the accompanying drawings, in which: [Brief description of the drawings]

[0065] [Figure 1] FIG. 1 illustrates a compliance system and a digital asset network in which the compliance system is configured to manage transactions in accordance with the subject matter disclosed herein. [Diagram 2] FIG. 2 illustrates sealed assets defined by the compliance system shown in FIG. 1. [Diagram 3] 2 illustrates a gateway of the compliance system shown in FIG. 1 in communication with multiple conforming pools and native assets. [Figure 4] FIG. 2 illustrates an exchange asset recognition service of the compliance system shown in FIG. 1. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0066] As shown in Figure 1, a compliance system is provided that is configured to manage transactions on a digital asset network. The digital asset network is configured to enforce rules (not necessarily defined by the compliance system) that control the recording of transactions on a public ledger. The compliance system is configured to enforce one or more compliance policies on transactions that the compliance system manages. It will be understood that Figure 1 illustrates merely one example of how a compliance system may be implemented and is not intended to be limiting, either in the components illustrated or in the relationships between the components.

[0067] The compliance system may comprise a Sealed Asset Platform (SAP), which may comprise and / or be configured to operate with some or all of the following: (1) A wallet implementation configured to facilitate a user interacting with SAP. According to an embodiment, a wallet implementation is a software application configured to communicate with SAP to facilitate issuing, receiving, and communicating the status of one or more transactions. A wallet implementation may be configured to manage cryptographic identifiers that control the spending of currency, and record identity authentication information belonging to a user. A wallet implementation may be executed locally or remotely, and / or may be hardware-enhanced. (2) A consensus system configured to update a cryptocurrency ledger and enforce rules to control which transactions are allowed. The consensus system may comprise a single centralized machine, or the consensus system may comprise a network of independent decentralized systems. Example consensus systems include, but are not limited to, the Bitcoin and Ethereum technology platforms, which use blockchain technology to build ledgers in which transactions are constrained by a set of agreed-upon consensus rules. (3) In the sealed assets (described below), one or more compliance policies, each of which contains a set of rules that define, for each transaction, whether the transaction is considered compliant and therefore permitted, as well as what information the transaction must disclose and to whom. (4) Sealed assets, including virtual assets for which compliance policies can be enforced using SAP. As shown in FIG. 2, sealed assets may include native assets that include existing virtual assets, where the native assets have been extended by SAP with Compliance Related Ancillary Information (CRAI), thereby facilitating enforcement of compliance policies associated with the native assets. (5) A conforming pool containing the set of all transactions across one or more ledgers and one or more sealed assets that meet the relevant compliance policies. (6) An identity provider (IP) configured to issue identity credentials to users on the system. A SAP may include multiple IPs, each of which independently uses a different technique for verifying a user's identity. Once issued, an identity credential is a digital document asserting the correctness of the user's identity as well as necessary information about the user and the user's account. The IP may be further configured to verify the user's identity at any time after the user's identity credential has been issued. (7) A policy issuer configured to facilitate the creation of new conforming pools by determining compliance policies to apply to conforming pools. The compliance policies then determine which assets transactions may be performed within the pool and how these transactions should function. (8) A gateway configured to allow the movement of assets into and out of conforming pools, which may include the movement of assets between different conforming pools having different compliance policies (e.g., different policies between legal jurisdictions). The gateway may include a gateway that allows assets to enter conforming pools from external sources, such as traditional cryptocurrency assets. (9) One or more asset-aware services (AAS) configured to interact with the sealed assets while maintaining meaningful information about the CRAI of the assets. The asset-aware services may be internal and / or external to the consensus system. The asset-aware services may include centralized or decentralized exchanges, inter-blockchain communication systems, and / or other suitable applications.

[0068] Multiple of the above components may be co-located in a single machine and / or implemented as features of a single software program (e.g., an identity provider may issue assets and / or use a wallet implementation as an end user). Alternatively, a single component may be implemented in a distributed manner such that the component's roles are performed by multiple parties together.

[0069] Wallet Implementation and Sealed Wallets A wallet implementation may include software and / or hardware that communicates with the SAP, performs transactional actions on behalf of the user, and communicates the state of the SAP to the user.

[0070] A wallet implementation may be configured to manage cryptographic identifiers (i.e., keys) associated with each user and controlling the spending of assets owned by that user. A wallet implementation may store, process, and communicate CRAIs associated with each user and transactions involving the user. For example, a wallet implementation may be configured to record identification authentication information belonging to a user.

[0071] Different wallet implementations may communicate with a single instance of SAP (e.g., by adhering to a compatible protocol) and are therefore interoperable. A wallet implementation may, for example, be configured to serve multiple users, each with their own cryptographic identifier and authentication information.

[0072] An instance of a wallet implementation may constitute a sealed wallet with a cryptographic identifier and authentication information associated with a particular user.

[0073] Wallet implementations may utilize dedicated hardware for secure data storage or for accelerated performance. Wallets may run on a user's local device, such as a phone or personal computer, or wallets may run on a remote server accessed, for example, via the Internet (e.g., via Software as a Service (SaaS) or Infrastructure as a Service (IaaS), as part of some related third-party service, etc.). Wallet functionality may be split between local computers, remote servers, and hardware (e.g., private keys and authentication information may be stored on a local computer or hardware for security, user interaction may be handled by a local computer for responsiveness, and synchronization with the blockchain may be handled by a remote server for efficiency). All of these components are extended to communicate and act on the CRAI as required by the relevant policies.

[0074] A sealed wallet may be operated and controlled by the user who owns the assets. A sealed wallet may be operated and controlled by a separate party that constitutes a wallet service provider (WSP). Various combinations of the two are possible. For example: In a custodial wallet, the wallet implementation is fully operated and controlled by a WSP that is different from the asset owner (similar to a traditional bank deposit account). The WSP holds the associated cryptographic identifiers and authentication information, and therefore retains full technical control of the assets. Users exercise their ownership by instructing the WSP to perform actions on their behalf through some interface provided by the WSP (e.g., a website). A single WSP may serve many different users, may commingle assets owned by different users under a single cryptographic identifier within the WSP's own sealed wallet, and may not hold the full amount of a user's deposit in custody (i.e., fractional reserves). In a self-custodial wallet (also called a self-hosted or non-hosted wallet), the wallet implementation is operated and controlled entirely by the user who owns the assets (similar to a traditional cash wallet, for example). There is no dependency on an external party other than to interact with the blockchain ledger system (to receive updates and to submit transactions fully formed and ready to be broadcast). In particular, private cryptographic identifiers and authentication information belonging to the user are stored in software and hardware operated by this user (similar to having an ID card in a traditional wallet).

[0075] It will be appreciated that custodial and self-custodial wallets represent two extreme cases, and that various combinations combining aspects of each of these wallets are possible, mutatis mutandis, without departing from the scope of the subject matter disclosed herein. For example, a wallet implementation may start with a self-custodial wallet and be modified such that one or more of the following capabilities are delegated to the WSP: Spending authority, i.e., storage of a private cryptographic identifier that allows for the expenditure of funds together with the implementation of the prerequisite computation procedure. A credential authority, i.e., storage of credentials associated with a user and attesting to the user's identity, along with implementation of procedures for exposing the credentials. Monitoring rights, i.e. storage of private cryptographic identifiers or implementation of communication protocols that allow a WSP with which a user is trading to see transactions (partially or in whole, as receiver and / or sender, some or all transactions). Censorship power, i.e. turning the WSP into a bottleneck that can stop users from issuing transactions; and / or Acceleration and ledger tracking, i.e. delegation of technical components such as accelerating computational operations or synchronizing with the state of the distributed ledger that may be too slow or expensive to implement on a user’s own device.

[0076] If all capabilities are delegated by the user to the WSP, the resulting wallet implementation becomes a custodial wallet.

[0077] Wallet implementations and WSPs can play a vital role in processing the CRAI, i.e., generating and maintaining some kind of record of the CRAI (e.g., transaction history), performing inference based on the CRAI, generating cryptographic claims about the CRAI that are verified by others, checking the validity of the CRAI and cryptographic claims about the CRAI generated by others, and / or communicating the CRAI to and from users and integrated services.

[0078] A sealed wallet may include smart contracts, i.e., autonomous or semi-autonomous computer programs executed by a distributed ledger. Such smart contracts may own assets in the sense that the smart contract controls all movement and spending of these assets. For example, smart contracts may include multi-sig wallets, decentralized exchanges, automated market makers, and / or decentralized loan-making services. A smart contract may be designed as a sealed wallet by attaching a policy-enforced CRAI to the wallet and subjecting inbound and outbound transactions to policy enforcement, just as for any other sealed wallet. The policy may include rules specific to such a sealed wallet (e.g., a rule requiring that the CRAI associated with the wallet identify the party that initiated the smart contract).

[0079] Identity Provider (IP) An identity provider is configured to issue identity proofs to end users. In its most common form, the role of the IP is to (1) verify the identity corresponding to each user, and (2) issue a cryptographic proof, called an identity proof, to the user. The user then incorporates the resulting proof into a sealed wallet as a CRAI, and may subsequently present that CRAI (or a proof of the contents of the CRAI) in transactions as dictated by applicable compliance policies.

[0080] Identity providers may be identified by one or more public cryptographic identifiers, such as the public key of a digital signature algorithm. These identifiers are then cryptographically bound to identity proofs, which are authenticated cryptographic data structures that encapsulate information about a user's identity in a machine-readable form. An identity proof, in some instantiations, may consist of one or both of: (1) a public component (or a condensed cryptographic representation thereof) that embeds the user's identity; and (2) a secret (i.e., private) component that contains cryptographic keying material. Identity proofs function similarly to standard Public Key Infrastructure (PKI) certificates in that identity providers can authenticate the identities of other identity providers, which in turn can authenticate the identities of end users. Each certificate may embed a defined validity period and may include mechanisms that allow IPs to revoke certificates that have been misused or stolen.

[0081] The issuer of a sealed asset may select one or more IPs to provide identity services for a particular asset. This list can be explicitly specified at the time the asset is issued, or the list may be updated over time. To participate in making transactions in a conforming pool, a sealed wallet must be provisioned with at least a valid identity proof from one or more of the permitted IPs. For example, as described below, a compliance policy for a given asset is used to specify which IPs are required for transactions involving the given asset.

[0082] Identity proofs issued by an IP include attributes required or permitted by applicable compliance policies. For example, these attributes may include, but are not limited to, one or more selected from the following: (1) Basic “no-your-customer” information, such as the owner’s name, type of entity (individual / business), nationality, home address, date of birth, national identifier, passport number, tax identifying number, driver’s license number, and contact details. (2) Biometric information of the owner. (3) Information (e.g., as described above) about parties (which may be different from the owners) who are authorized to perform transactions in these wallets. (4) The identity of the wallet owner as a financial institution, virtual asset service provider, custodian service, etc. (5) The wallet owner's association with accounts or digital identities on other platforms, such as social network usernames, customer accounts at private companies (including financial institutions), employee databases, self-sovereign identity networks (based on blockchain or otherwise), ownership of internet domain names, etc. This association may be made directly or indirectly through an identity linking service such as Keybase; and / or (6) For example, an IP’s assessment of a wallet’s risk score based on the IP’s own KYC / AML risk-based policies.

[0083] It will be appreciated that some of these attributes may be of critical privacy importance and therefore should not be disclosed indiscriminately. The associated compliance policy may dictate which attributes are disclosed to whom, under what conditions. SAP may include cryptographic protocols configured to facilitate enforcement of this policy.

[0084] Identity proof may further include information obtained during the customer's due diligence process and / or extended due diligence process, including, for example, but not limited to: (1) Corroborating activity information that matches customer transaction profiles obtained through third-party providers or via public searches. (2) The customer’s IP address. (3) Information obtained through the use of blockchain analytics. (4) Details regarding the nature, end use or end user of the goods for which the transaction is being effected, and the purpose of the transaction. (5) Proof of ownership of funds and / or source of property or funds. (6) The identity and beneficial ownership of the counterparty. (7) Export control information and / or other licenses and / or certifications. (8) Any other identifying information relating to the originator or beneficiary of the transaction; and / or (9) Other customer information, transaction history, and additional transaction data obtained from the customer by the customer or its VASP counterparty.

[0085] In addition, proof of identity and other information forming part of the CRAI may be amended and updated from time to time by undergoing a review of existing records and matching the information with new data as it becomes available, for example in accordance with regulatory requirements, for purposes of identity verification and authentication, and / or for ongoing due diligence.

[0086] Identity proofs may facilitate VASPs to: (1) Allows VASPs to identify counterparty VASPs for the transfer of virtual assets. (2) Allowing for the submission of precise origin and required beneficiary information immediately when a transfer of virtual assets on a decentralized platform is effected. (3) Allows VASPs to submit sizable transactions to multiple destinations in a substantially stable manner. (4) To facilitate record-keeping using CRAI, it enables VASPs to transmit data securely, i.e., to protect the integrity and availability of required information. (5) In addition to protecting the use of such CRAI by the receiving VASP or other required entity, protect the CRAI from unauthorized disclosure, consistent with National privacy and data protection laws. (6) providing a communication channel to VASPs to further support follow-up with counterparty VASPs for purposes of counterparty due diligence; and / or (7) Facilitate the option to request information about specific transactions to determine whether the transactions involve high risk or are prohibited.

[0087] As described below, the compliance system may include an identity delivery system configured to facilitate IPs achieving some or all of the above.

[0088] Asset Awareness Service (AAS) A sealed asset typically exists in one of two states. The asset's normal state is that it resides in a compliant pool. While the asset is in a compliant pool, it can be transmitted between wallets as permitted by the asset's compliance policy. However, some applications require more complex financial transactions that cannot be fully encoded by a simple globally enforced policy.

[0089] An example of such an application is a service that receives and mixes assets from multiple users. Services with this characteristic include asset exchanges (whether centralized or decentralized), many decentralized finance applications, coin mixing networks, custody solutions, etc. For example, in an asset exchange, multiple users submit assets to a control exchange system, which may mix the assets of the multiple users in the same wallet, and then the users conduct transactions to obtain different assets (also held in mixed wallets), and finally withdraw the various assets from the exchange.

[0090] Thus, an asset-aware service (AAS) is configured to process (e.g., send, receive, and interact with) one or more sealed assets in a more complex manner than is permitted by the basic compliance policies of the assets. The AAS is also permitted to send, receive, or mix together currencies from different end users. The AAS is responsible for ensuring that the CRAI information is correctly reflected in all assets that exit the service and enter a conforming pool. The AAS may extend the CRAI of a transaction with additional information available to the AAS that may not otherwise be inferred from previous CRAIs and transaction history. Thus, if assets in an exchange belong to a user of the service, the CRAI of those assets may reflect this ownership state whenever those assets enter and leave the service, and whenever those assets are exchanged for other assets in the exchange. This reflection may require logic specific to the application supported by the service.

[0091] A sealed asset compliance policy may support an AAS in a variety of ways, all of which allow some AAS to perform transactions or communicate CRAI that may not otherwise be permitted by the compliance policy. For example, (1) Compliance policies may include an "allowed list" of AAS parties that are authorized and therefore trusted to track a user's CRAI with respect to funds flowing within and to communicate it in outbound transactions. (2) The compliance policy may permit a particular protocol (i.e., a distributed algorithm) to mechanically track the CRAI as it flows through the protocol. For example, a mixnet system may be extended to cryptographically convey the CRAI along with the mixed transaction in a manner that achieves the privacy goal of the mixnet as observed by the public, including unauthorized eavesdroppers, but allows for forensic investigation by authorized law enforcement. Specifically, when applied to a blockchain platform that supports smart contracts, this extension may be realized by creating a smart contract that implements the protocol (or a relevant portion of the protocol), performs tracking of the CRAI with respect to assets that flow through the smart contract, and is reviewed to ensure that the tracking of the CRAI is correct and sane. The address of the smart contract may then be added to the allow list of AAS in the policy. Similarly, "Layer 2" asset movement protocols for virtual assets, such as Bitcoin's Lightning Network, or Bolt Labs' zkChannels based on the Bolt Protocol, may also be extended at the protocol level to convey a CRAI that reflects the true ownership of the asset, rather than just a mechanism for moving assets via an underlying ("Layer 1") distributed ledger. Similarly, rollup systems may be extended to convey a CRAI, for example, as described below. (3) The aforementioned authorized list of AASs may be embedded directly in the policy and / or delegated to an external party, such as a regulatory body, using cryptographic means (e.g., digital signatures). For example, the policy may include a cryptographic identifier of some third-party service, which itself publishes a list of the public keys of the authorized AASs in a well-defined location. This allows the list of authorized AASs to change over time (this may be repeated; for example, the policy may cryptographically delegate authority to a party, which in turn is allowed to delegate authority to nominate AASs to one or more other parties. Similarly, such authority may be distributed among a group of multiple parties using well-understood techniques such as multi-sig or threshold cryptography). The same mechanism may allow the authority of an AAS to be revoked, for example, if a particular AAS is compromised or fails to generate a CRAI correctly. (4) An AAS may be permitted to operate within certain behavioral boundaries. For example, a compliance policy may embed a specific set of parameters that define the types of activities that may be supported by the AAS. These parameters may specify constraints on certain types of activities (e.g., constraints on permitted transaction addresses, total funds exchanged, and types of assets supported). As a specific example, an AAS may be permitted to act as a gateway service between some pools (e.g., compliant pools) but not between other pools.

[0092] Compliance policies may give the AAS the flexibility to disable the default CRAI propagation based on assets and wallets in the following ways: (1) Identify assets that are mixed within one wallet owned by the AAS operator as being stored on behalf of one or more other users' wallets, and accordingly propagate the CRAI corresponding to the real owner (e.g., the real owner's original wallet and transaction history). Thus, when assets are withdrawn from the mixed wallet, they simply have the CRAI of the real user's wallet, not the CRAI of the AAS operator that stored the assets. (2) Identifying a currency-denominated asset in one sealed asset as resulting from a trade or exchange of a prior different sealed asset, and accordingly propagating the CRAI corresponding to the prior asset (e.g., the prior asset's origin wallet and transaction history). (3) Extending the above to the fractional reserve case, in which a custodian's wallet may hold less funds than the total funds put into custody with the custodian by users. Thus, the custodian's AAS may receive deposits from one or more users into the custodian's own wallet, withdraw some of these assets for the custodian's own purposes (e.g., to lend interest-bearing loans), deposit some assets back into the custodian's wallet, and finally allow users to withdraw assets from the custodian's wallet. The AAS may be configured to filter out irrelevant assets at intermediate steps and include only economically relevant transactions (in this case, user deposits and withdrawals) in the CRAI.

[0093] The AAS may further be configured to add additional information to the CRAI of associated transactions and wallets, e.g., if permitted by compliance policies. For example, the exchange AAS may annotate transactions with information about exchange rates and market conditions during the transaction.

[0094] Data Platform Compliance-enabled cryptocurrency systems often require the collection and distribution of aggregate data or statistics regarding transactions occurring on the system. This data may include, for example, statistics regarding transaction volumes and flows of one or more sealed assets, exchange price information for assets (if such information is available), and other data that may be generated by the AAS (e.g., exchange transaction volumes). Statistics may be specific to a particular user's wallet activity (e.g., calculation of a "risk score" based on that user's activity). These statistics may be further categorized by policy-dictated wallet attributes, allowing for statistics such as "total funds held in wallets marked as owned by the bank" or "total daily flow of funds from wallets tagged as self-custodial to wallets tagged as owned by the exchange."

[0095] Collection of this aggregate data serves two purposes. First, it may facilitate SAP providing customers and / or regulators with aggregate information regarding the current state of the system while simultaneously protecting the privacy of individual traders to the greatest extent possible. This information may enable customers and / or regulators to detect and respond to trends.

[0096] Second, it can facilitate informing compliance policies that require such aggregate data. For example, a compliance policy may require issuing Suspicious Activity Reports (SARs) based on contextual information such as the overall transaction volume in that asset (as larger transactions compared to the total volume may be an indicator of market manipulation). To enable such policies, the data platform can expose the necessary data in an authenticated form to participants on the network via “data oracles”. These are specialized systems that enable the publication (on-ledger or off-ledger) of such data. Data values ​​exposed via these data oracles can be used as inputs to certain compliance policies.

[0097] It will be understood that the term SAR, as used herein, may include all forms of implemented reporting in various jurisdictions and organizations, including, for example, regulated reporting in the United States (e.g., "Cash Transaction Reports" (CTR) requirements, etc.).

[0098] A data platform may include the following components: (1) a privacy-preserving data collection architecture consisting of one or more nodes (whether distributed or centralized servers) responsible for collecting and aggregating statistics about transactions occurring on the network, (2) an application programming interface (API) through which participants can obtain statistical data and make inquiries about the state of the network, (3) a set of data "oracles" that expose data for use by participants in the network, and (4) a data dashboard that communicates human-readable summaries to authorized parties.

[0099] The data platform will be designed to collect information from individual traders using privacy-preserving technology.

[0100] The data platform may include data access control mechanisms that limit visibility of data to particular parties (e.g., organizations, departments, or roles within an organization). Access policies may be specified by compliance policies and / or by policies within an organization. For example, a compliance policy may specify that a regulatory body has access to wallet owner identifying information in a particular transaction, and a policy within the regulatory body may specify that a particular investigator can access this information only if the transaction owner's address is within a particular district or only with approval from the investigator's manager. This composite policy is enforced by the data platform.

[0101] gateway A gateway is configured to facilitate the movement of assets from one compliant pool to another, or to allow native assets to enter or leave a compliant pool. A gateway is similar to an AAS (indeed, a gateway may be considered a specialized AAS) in the sense that it represents a built-in "exception" to the restrictions imposed on assets by the compliance policies associated with a pool. For example, as shown in FIG. 3, a single gateway may allow assets to transition between multiple compliant pools and native assets.

[0102] The compliance policy associated with each matching pool may determine the identity of the allowed gateways. This may be done by identifying the exact cryptographic identity (e.g., public key) of each gateway provider in the policy, or by specifying more complex mechanisms in the compliance policy to allow new gateways without modifying the compliance policy.

[0103] Compliance Policy Each sealed asset is associated with one or more compliance policies. A compliance policy comprises a set of machine-readable rules that determine under what conditions transactions in a conforming pool are permitted. A compliance policy may enforce one or more selected from the following aspects of how transactions of sealed assets in conforming pools are carried out: Which assets may be allowed to execute transactions within a conforming pool? Which identity providers must issue identity proofs to users who perform transactions involving assets, and what conditions must be enforced against the user's identity. · Which asset awareness services and gateways are supported by the asset. · What information from the CRAI associated with all wallets and transactions will be disclosed, under what conditions, and to which parties? What aggregate information may be disclosed, under what conditions, and to which parties for all transactions, wallets, and each CRAI; and / or Any other restrictions that may be enforced on transactional data, identity data, private data, and public data that are published in well-defined locations.

[0104] The nature of the compliance policy A compliance policy includes a set of rules that can be evaluated by a computer system to determine if a transaction should be allowed. A compliance policy may specify a set of "side effects" to be caused by an attempted transaction, such as publishing a suspicious activity report (SAR) or generating statistical data for use by the data platform. In a standard embodiment, these rules are expressed in the form of a computer program or logic circuit that takes in various data related to the transaction, reasons on this data, and outputs a decision to approve or disallow the transaction as well as some output data that can be sent to the ledger.

[0105] The policy issuer selects the compliance policy (or policies) that will be used by default within each new sealed asset (it will be understood that a collection of policies may be implemented by specifying a single policy that combines multiple policies, and thus in this disclosure "policy" explicitly includes any such collection of policies and / or single policy). When multiple policies are used, the asset issuer must specify how the different policies interact, for example, whether all policies must be satisfied simultaneously, or whether only one or a subset must be satisfied.

[0106] Examples of policy issuers include, but are not limited to, autonomous trade associations, corporations, non-profit organizations and / or consortia of non-profit organizations, central banks, regulatory bodies, law enforcement agencies, regulated entities, and individuals. Policies may reflect requirements applicable globally, to specific jurisdictions, to specific organizations, to specific individuals, and / or to any grouping of these. SAPs may be configured to allow policies to be issued by specific parties, by some specified set of parties, or without authorization, i.e., by any party.

[0107] SAP may be configured to allow policies to be issued and modified by any of the above, by any designated party, or by any designated group of parties.

[0108] Multiple policies may be substantially concurrent for the same sealed asset. Different sealed assets may share the same compliance policy or portions of the compliance policy of different sealed assets. Assets may use unique policies that differ from other assets.

[0109] Entering a policy Compliance policies may reason against a large and diverse set of data sources made available by the system to reach a decision to allow or disallow a transaction. These inputs may be derived from one or more selected from the following data sources: Transaction inputs, i.e. information related to the transaction itself, such as the purpose of the transaction, the amount and currency in which the transaction is carried out, the addresses of the sender and receiver, and the time of the transaction. Data adjacent to the transaction, i.e. additional auxiliary data fields that are embedded in the transaction when it is represented in a form recognized by the consensus system. These data fields can include structured fields with meaning understood by the consensus system, in addition to unstructured data fields visible to participants on the network (such as memo fields that already exist in existing currencies). Data from one or more identity credentials provided in a sealed wallet (belonging to the sender or recipient) authorized by an identity provider. Various pieces of information from these identity credentials may be used as inputs to compliance policies. Public "oracle" data broadcast by trusted parties (known as "oracles"). This data may be published via a consensus system or some other channel and is typically cryptographically authenticated by the issuing party. Examples of this public data may include asset price data; and / or · Data from the consensus system, such as the time when a transaction was added to the ledger or the length of the ledger, or other information present in the ledger.

[0110] The above list is not exhaustive: in principle, compliance policies may be inferred over any data available at the time a transaction is created or added to the consensus system's ledger.

[0111] Policy and Data Privacy Two important conditions for the design of compliant sealed assets are privacy and soundness. The first condition requires that transactions should not leak sensitive information to unauthorized participants, even if that information is required to verify that compliance policies are met. This privacy requirement is particularly important in public consensus systems, where the task of validating the correctness of transactions on the ledger is often the responsibility of untrusted volunteers. Soundness means that participants in the consensus system and third parties must be confident that a transaction does in fact satisfy compliance policies, even if they cannot see all of the inputs to the policy evaluation.

[0112] An apparent contradiction in these requirements is resolved through the use of cryptography. In particular, this requires that the correct evaluation of compliance policies must be enforced using privacy-preserving techniques such as zero-knowledge proofs and multi-party computation.

[0113] Input / Output Privacy To achieve confidentiality, each compliance policy may include information about which inputs and outputs are sensitive, i.e., it may specify the inputs required to perform the transaction and the required side-effect outputs, and in addition employ a confidentiality labeling schema that indicates the confidentiality requirements associated with each of the input and output data. This labeling supports multiple classifications ranging from "fully confidential" (where no other parties can use the data regarding the inputs / outputs) to "fully public" (where the data is fully usable by any party observing the transaction on the ledger). Many intermediate classifications are also supported. For example, a policy may specify that only certain parties (e.g., regulators or banks) can see the inputs / outputs of a particular transaction. A policy may specify that the inputs / outputs of a particular transaction may be used to perform aggregate statistical data collection. A more complete description of the confidentiality labeling schema is given in a later section.

[0114] While most inputs to a transaction's policy are known by the wallet generating the transaction, there are exceptions to this rule: for example, a policy may contain a list of flagged addresses or conditions for generating a suspicious activity report.

[0115] Asset Awareness Service (AAS) As previously discussed, asset-aware services represent an exception to the compliance policy, in which designated external parties or designated protocols and smart contracts are given discretion to accurately communicate CRAI or enforce behavior. EXAMPLES

[0116] Compliance Policy Below, examples of compliance policies are presented. It will be understood that these examples are merely illustrative and that SAP is not limited thereby. It will be further understood that a single compliance policy may include elements of one or more of the examples given below, mutatis mutandis.

[0117] [Example 1] Regulatory closure According to some embodiments, a compliance policy simply ensures that all funds in a conforming pool remain associated with this pool when transitioning between wallets, and that funds cannot be moved to other pools (except as specifically permitted by the policy). Regulatory closure policies may be enforced by specifying a compliance policy that ensures multiple conditions: each transaction must cryptographically bind an identifier of a particular conforming pool to the contents of the transaction, and each sealed wallet must also bind a pool identifier to all funds stored in the wallet (a pool identifier may include a cryptographic hash of a policy program or an identifier that is uniquely bound to a particular policy by the network. Such an identifier may be included in the transaction as a plaintext field, or may be cryptographically bound to the transaction using various technical means described in later sections. A sealed wallet may be bound to multiple pool identifiers, provided that funds are segregated within the wallet to indicate which funds belong to each identifier).

[0118] The policy itself enforces the following conditions: (1) all transactions received by a sealed wallet must be associated with a specific pool identifier that is also contained in the wallet, (2) all funds held by the wallet must be associated with a pool identifier contained in the transaction in which those funds were received, and (3) all transactions sent by the wallet must embed in the wallet the pool identifier with which they are associated. A further extension of this idea is to only allow certain wallets to perform transactions in certain pools, which may be accomplished, for example, by tying one or more pool identifiers to the wallet's identity proofs and requiring that the appropriate proofs be present in the sending and / or receiving wallet.

[0119] Sometimes it may be necessary to allow funds in one conforming pool to be transferred to a different conforming pool, for example, when the funds are transferred between different regulatory jurisdictions. This transfer may be allowed by creating specific exceptions in the compliance policy to allow funds to be transferred between pools. However, such exceptions may not be known at the time the policy is developed and may be subject to specific restrictions that are context-dependent. These issues are addressed by allowing gateways to allow the movement of funds. In this case, the compliance policy may allow gateways in two different ways: (1) In a custodial solution, each policy may specify an "allowed list" of specific senders that are allowed to circumvent the policy restrictions and change the pool identifier associated with the outgoing funds. In this model, funds may be transferred between pools by first sending the funds to a gateway and then allowing the policy to send the funds onward to a different pool. Alternatively, (2) in a non-custodial solution, the policy program may require an additional policy input that contains a circumvention proof (i.e., a cryptographic message signed by the key of the gateway identified in the policy). A bypass proof can show that a particular permitted transaction may bypass a policy restriction. The advantage of the second solution is that the gateway does not gain custodial control over any of the funds.

[0120] [Example 2] Regulated Escrow A regulated escrow system stores additional information within each transaction recorded on the ledger, encoded in a form that can only be read by certain parties. This information may include details about the transaction that are not available in readable form on the ledger (e.g., as is common when the ledger provides privacy features) or other information that is not typically included in the transaction, such as KYC identifying information.

[0121] Supporting a regulated escrow system requires that each transaction contain a special data field called the Regulatory Escrow Access Field (REAF). In effect, the REAF is an encrypted container that can only be decrypted by a specific recipient or set of recipients, called the Regulatory Escrow Authority. Non-limiting examples of suitable escrow authorities include government regulatory agencies, third-party compliance firms, or banks.

[0122] For regulatory escrow to be meaningfully enforced, each transaction in the sealed pool must contain an attached or associated REAF that embeds the correct relevant information. The presence and correctness of the REAF is enforced by a compliance policy. More specifically, the compliance policy ensures that (1) each transaction must contain a correctly formatted REAF, (2) the REAF must represent a valid encryption according to the key of the regulatory escrow agent specified by the policy, and (3) the REAF must contain the appropriate set of information for this transaction. The REAF itself may be constructed using a public key cryptography scheme that encrypts the relevant transaction data according to the public key of the appropriate escrow party. The compliance policy may specify the plaintext embedded within the REAF ciphertext. This specification is supported by any compliance policy that meets the above criteria, i.e., the compliance policy can be inferred over information adjacent to the transaction (such as the REAF ciphertext attached to the transaction) and other transaction inputs. The contents and recipients of the REAF may be fixed by the policy, or the policy may dictate different information and recipients based on the nature of the particular transaction.

[0123] [Example 3] Sender and Recipient Block Lists In some cases, regulators and banks may identify certain accounts that should be prevented, either temporarily or permanently, from sending or receiving transactions. These accounts may be identified by specific cryptocurrency addresses or by specific transactor identities. In principle, this list may be fixed as part of a compliance policy, but more commonly it changes from time to time.

[0124] Supporting this functionality requires several prerequisites. First, one or more authorized parties must periodically determine a list of unauthorized accounts. Second, this list must be made public to transactors on the system, with some form of cryptographic authentication that includes assurance that all parties can verify the authenticity of the list, and that the list is "fresh", i.e., that a given version of the list is up-to-date. These properties can be achieved by publishing the list on a public ledger, or by publishing a cryptographic "digest" (hash) of the list on the ledger and transmitting the list itself via some separate channel.

[0125] Enforcement of the denial list is ensured by specifying a compliance policy that infers both the current version of the denial list and the inputs to a given transaction (e.g., sender and recipient account identities). If either the sender or recipient account is included in this list, the compliance policy will not allow the transaction.

[0126] In the above we assume that the complete contents of the reject list are available to the sender. In some cases, it may be undesirable to expose this information. A later section addresses how some input to the compliance policy may be exposed in a form that is sensitive to the sender.

[0127] [Example 4] Statistical Data Collection Several applications require the availability of aggregate statistical data about transactions created within a matching pool, which requires that transactions expose some data about each transaction such that useful information about individual transactions is not made available, yet aggregate statistics about many transactions can be derived by data aggregators authorized to compute data aggregations.

[0128] Data aggregation can be made possible using several underlying mathematical techniques, which are described in detail in later sections. These mathematical techniques can be briefly summarized as follows: (1) transaction statistics can be collected by using homomorphic encryption (encryption that allows mathematical operations to be performed on encrypted data), (2) transaction statistics can be collected by using noise-obfuscated summation techniques (such as randomized response techniques) where the statistical data is combined with statistical noise such that the aggregate data can be collected only by summing a large number of transactions and filtering out the noise, and (3) statistical data can be collected by encrypting relevant data according to a key controlled by a trusted hardware component (e.g., an Intel SGX enclave that performs the statistical aggregation without revealing the individual transaction data). These techniques can be combined in various ways, as described in later sections.

[0129] The data required to compute aggregate statistics may be published alongside each transaction in special fields called Statistical Aggregation Fields (SAFs). Compliance policies enforce the presence and correct structure of SAFs for each authorized transaction in a manner similar to how policies can enforce the presence of REAFs. Policies enforce that the SAFs encode some specific mathematical function of the relevant transaction data, the exact nature of this function depending on the mathematical technique used to perform the statistical aggregation. The inputs to the function and the nature of the function itself may be fixed for all transactions, or compliance policies may specify different structures (and different function inputs) for transactions with different characteristics. Advanced policies may also include program logic that allows a centralized party to change the structure of the function by periodically publishing new data to traders. This mechanism allows an operator's data platform to "tune" the quality and type of data collected.

[0130] After a SAF is attached to each transaction, the data aggregator may calculate aggregate statistics about transactions conducted over time by combining information from many SAFs issued over a period of time. The nature of this aggregation will depend on the mathematical techniques used to construct each SAF, and the accuracy of the statistical aggregation may depend on the techniques used and the number of transactions collected. This combined data may then be exposed to users via the data platform's APIs and / or to traders via data oracles.

[0131] [Example 5] Reporting Suspicious Activity Several regulatory frameworks require banks and financial institutions to analyze customer transactions and submit reports that identify possible criminal activity. These are often referred to as "suspicious activity reports" (SARs). In current banking practices (e.g., regulations in the United States), SARs may be built based on manual analysis of transactions, or SARs may be generated algorithmically by automated systems. The issuance of algorithmic SARs may be enforced by compliance policies.

[0132] Enforcing SARs through a compliance policy requires two prerequisites. First, the compliance policy must embed program logic that evaluates the inputs of a transaction, plus (optionally) information about the surrounding conditions (e.g., aggregate statistics published to the network by a data oracle). This logic must evaluate these inputs to determine whether a given transaction should result in a SAR, and if so, what content of the SAR should be resulted. Second, the compliance policy must enforce a means for reporting SARs to the appropriate authorities.

[0133] SAR reporting is enabled via a Regulatory Enforcement Access Field (REAF), which contains data addressed to one or more regulatory escrow agents. If SAR reporting is enabled by a compliance policy, the policy specifies that each transaction includes a REAF field, and that the SAR information should be incorporated into the data contained within the REAF. The REAF may include, for example, the wallet address, identification information of the parties associated with the wallet, device identifiers, IP addresses, information about related prior transactions, etc.

[0134] (It will be understood that the presence of a REAF field containing SAR data does not necessarily require that any other regulated escrow data be collected in the field. SAR reporting may optionally be combined with other regulated escrow functions using a single REAF, or a REAF field may contain only SAR data and no regulated escrow data. Other combinations are possible, for example a transaction may contain multiple REAF fields addressed to different regulated escrow agents, e.g., one REAF field containing SAR data and one REAF field containing regulated escrow data.)

[0135] The REAF field may be decoded by an authorized regulatory escrow agent responsible for conveying the SAR information to the appropriate authorities. Use of a SAR reporting policy requires that the REAF include a data field containing the output of any SAR reporting functionality embedded within the compliance policy. If the transaction does not trigger a SAR report, the data in this field may be omitted or left empty. If a SAR is triggered, the resulting report is specified by the policy logic and included in the REAF. Because the REAF is encrypted to a specific regulatory escrow agent, unauthorized parties should not be able to determine whether a given transaction embeds a SAR report.

[0136] An important design choice in the development of a suspicious activity reporting system is whether a transaction sender should be aware of whether a SAR will be triggered by a particular transaction. In many traditional banking contexts, both the SAR policy and knowledge of whether a SAR has been initiated may be kept secret from customers as a means to prevent circumvention of SARs. Compliance policies may address this by specifying parameters as confidential inputs to the compliance policy that are not available to transaction creators and / or recipients. Thus, transaction senders and / or recipients are neither aware of the inputs to the SAR nor of whether a SAR has been created in response to a transaction. Technical means for implementing confidential policy inputs are further described in the following sections.

[0137] The policy may specify various conditions for the automated issuance of a SAR, including, for example: (1) Anomalies in customer identifying information (e.g., KYC data), such as insufficient documentation, inconsistencies, or multiple accounts. (2) An abnormally high value of a transaction, whether within a single transaction or across multiple transactions (e.g., “structuring” in an attempt to evade detection), compared to either a fixed threshold specified by the policy, a dynamic threshold determined, for example, by parties authorized by the policy, or a dynamic threshold determined mathematically from other parameters (e.g., total trading volume in a given asset). (3) Transaction activity that is inappropriate for a customer’s profile or income (e.g., as identified during a KYC process associated with a customer’s wallet) or that is unusual compared to the customer’s past activity (e.g., intense activity in an account that was already dormant). (4) The account is flagged as suspicious or high risk by any rule imposed by the policy, by the identity provider's discretion, or by lists, warnings, or criteria imposed by parties specified by the policy (e.g., "politically exposed persons," geographic area, or sanctions lists, or case-specific court orders). (5) Activity associated with accounts or digital identities on other platforms related to the wallet owner, such as social network usernames, customer accounts with private companies (including financial institutions), employee databases, self-sovereign identity networks (based on blockchain or otherwise), ownership of internet domain names, etc. This association may be made directly or indirectly through an identity linking service such as Keybase. (6) Any other standards established by countries, states, international organizations such as the Financial Action Task Force, or private organizations for the issuance of reports, such as suspicious activity reports and cash transaction reports.

[0138] [Example 6] Exchange Asset Recognition Service Exchange services that allow users to trade one asset for another may require special processing to track the provenance of assets so that such transactions are meaningful. For example, consider the case in which the owner of wallet A uses an exchange to exchange asset X for asset Y, as shown in Figure 4.

[0139] Technically, asset X sent by wallet A will end up going to another user's wallet (wallet B). Similarly, asset Y received by wallet A originates from another user's wallet (wallet C). CRAI tracking focuses on this provenance. However, for bulk exchanges, wallets B and C exist simultaneously and are unrelated. Rather, CRAI should convey wallet A's exchange of asset X with asset Y across multiple assets by maintaining identifying information and past transaction history.

[0140] Compliance policies may reflect the above. However, compliance policies generally cannot directly specify the mechanics of properly tracking transactions, as the mechanics of transactions are specific to each exchange implementation. Thus, compliance policies allow exchanges as asset-aware services that can provide this tracking themselves.

[0141] In the case of a centralized exchange, this tracking may be implemented, for example, as a compliance policy that enables the exchange AAS to determine in exchange withdrawal transactions the associated CRAI that reflects properly tracked transactions. Proper tracking of transactions is performed internally by the exchange, technically at the discretion of the exchange, but backed by regulatory or contractual obligations regarding accuracy.

[0142] Some exchanges may be implemented by decentralized mechanisms that implement trading order books or autonomous trading algorithms, such as automated market markers (AAMs). In this case, there may be no legal parties to bind them regarding correct behavior. Therefore, instead, AAS may be mechanized and implemented as specific protocols (implemented as smart contracts and supporting software) that track transactions in a provably rigorous manner. Smart contracts may operate unencrypted, allowing anyone to observe transactions and verify the correctness of the CRAI. Alternatively, smart contracts may use privacy-preserving cryptographic mechanisms, such as zero-knowledge proofs, to allow users to execute transactions and prove that the user's own CRAI has been correctly updated without explicitly disclosing this CRAI to anyone (except those authorized according to compliance policies).

[0143] If the exchange operation involves ancillary assets, such as liquidity provider tokens of an AMM, these ancillary assets may also be tracked by the AAS and instructions for these ancillary assets may be specified by the policy. For example, if a party deposits assets with an AMM and receives a liquidity provider token in return, the AMM acting as an AAS may extend the liquidity provider token with the depositor's CRAI, such as identifying information and / or provenance of funds (conveyed by the deposited assets and the depositor's sealed wallet).

[0144] [Example 7] Risk Management The policies and SAPs may be used by regulated entities and other financial institutions to facilitate the implementation of risk-based approaches and the enforcement of risk tolerance policies. In some existing systems, entities such as financial institutions require a score assessment based on a user's activity on the blockchain. This "risk score" or "risk profile" represents a best estimate of the likelihood that a user or a user's funds are involved in non-compliant activity. Different entities may assign higher or lower risk scores to the same transaction or user depending on various factors. Such risk scores or profiles may be used by VASPs and regulated entities to manage and / or mitigate risk exposure and may be updated from time to time based on various metrics. Such risk management practices may be accomplished in a manner similar to the aggregate statistics example above or using a set of statistics calculated restricted to individual users. The risk calculation may be based, for example, on risk tolerance policies, collected information, etc.

[0145] [Example 8] Auditing your organization Organizations (including individuals) can impose policies on organization-owned wallets (e.g., corporate assets and employee expense wallets), facilitating audit capabilities. This organizational policy complements and extends the jurisdiction-imposed compliance policies to which the organization is subject. Audits may, for example, track aggregate statistics on funds flow and make them viewable by designated parties. Audits may, for example, make anomalous or high-risk transactions by some criteria at the organization's level, mutatis mutandis, in real time, similar to the suspicious activity reports disclosed above. Audits may reason against total deposit balances and block, issue warnings, or require manual approval if the total deposit balance exceeds a certain criterion (e.g., reserve or discretionary funds accounts fall below a threshold).

[0146] Additionally, the audited properties of an organization's sealed assets may be cryptographically authenticated for presentation to a third party using cryptographic proofs that rigorously convince the third party of the veracity of the assertions. Such proofs may include, for example, proofs that a balance is above a certain threshold and has been so for a certain period of time, proofs of net asset inflows, or proofs that the amount of deposits held matches any liabilities (whether or not the amount of those liabilities is disclosed).

[0147] [Example 9] Redundant checks A policy may include multiple redundant checks. For example, a policy may specify complex limits or reporting criteria that are mechanically enforced by a privacy-preserving protocol that performs the necessary accounting. The policy may then further specify that the relevant information is also to be made public to a designated auditor, who can double-check the calculations and ensure that the mechanical enforcement did not fail. This auditor may be legally bound to maintain secrecy and may only be called in (e.g., at the discretion of the organization's management or a court) if erroneous operation is suspected, but the presence of an auditor provides additional security and allows for recovery from technical failures.

[0148] [Example 10] Chargebacks and Funds Recovery A policy may dictate that a particular transaction is not irrevocably terminated until some criteria, such as the passage of a certain amount of time, is met. A policy may further specify criteria according to which a transaction can be actively reversed and virtual assets returned in whole or in part to the sender if the circumstances of the transaction meet the requirements of a chargeback policy (i.e., a "chargeback"). This policy may be used to verify the owner's authorization of the transaction, handle disputes in transit, facilitate the return of goods, enforce purchasing controls and facilitate possible transaction reversals, mitigate fraud, refund amounts of theft, loss, damage, and error, and detect suspicious merchant activity with respect to transactions facilitated on the blockchain (including due to "cyber attacks" that technically compromise the security of the wallet, or due to malicious human actions). By allowing chargebacks, the risk of damage from theft can be mitigated, thereby providing a potential disincentive to committing the crime in the first place.

[0149] [Example 11] Tax payment A policy may dictate that payments made to one or more particular wallets must be accompanied by other corresponding payments. For example, it may be required that any payment to a retail merchant's wallet be accompanied by payment of VAT to the relevant tax authority. The policy specifies the calculation of the associated payment and where it is to be paid, as well as which wallets the policy applies to. The policy may be imposed by a jurisdiction, or the policy may be voluntarily imposed by the merchant on itself as a means to ensure its own compliance with relevant tax laws, regulations, etc.

[0150] The policy may include tracking of CRAIs related to compliance with tax laws. For example, capital gains tax typically requires knowing the tax basis (cost of acquisition) of each asset sold. Currently, the calculation of this basis is not performed by existing distributed ledgers, and instead taxpayers must track the tax basis by themselves or by relying on a third-party service. The system includes the tax basis as a CRAI originally attached to the transaction. This allows for greater reliability and interoperability. Additionally, the system can handle more delicate concepts. For example, U.S. federal tax law allows for the specific identification of a tax lot, where a party selling an asset can contemporaneously specify which of multiple similar assets with different tax bases is the asset being sold. The policy may add this identified tax lot and the corresponding basis within the CRAI. The system may then provide attestation as to the amount of profit generated as a result of the transaction. The system may enforce requirements such as the identification of a specific lot being performed contemporaneously with the sale transaction, and the correct accounting of the tax lot (e.g., the same tax lot cannot be reported as sold more than once). The policy may then enforce payment of this tax to a taxing authority, e.g., as described above. The policy may also include calculation of the applicable tax rate, e.g., by tracking the holding period of the assets in the associated CRAI and inferring whether a long-term or short-term capital gains tax rate is applicable.

[0151] [Example 12] Managing Distributed Applications The consensus system may host one or more decentralized finance (DeFi) applications. These applications are typically implemented using smart contract programs that run directly on the consensus system to enable payments and other functions, although some DeFi systems also incorporate more centralized components, such as pricing oracles and exchange order matching systems. Unlike centralized systems, DeFi applications are not run by centralized parties and may not be able to store private keys. Thus, DeFi applications cannot store any secret components of the proof of identity. Because the operation of these decentralized systems is typically transparent, i.e., all parties can see the inputs and outputs the decentralized system processes, users interacting with DeFi applications are responsible for generating CRAIs for outgoing transactions sent to DeFi services, and for reconstructing the necessary CRAIs in subsequent transactions to show the complete history of funds passing through the DeFi application. In this case, the policy requires users to track the transaction history of their interactions with the DeFi application, and the system enforces integrity and correct inferences from this transaction history.

[0152] [Example 13] Foreign Account Reporting The policy may enforce compliance with foreign account reporting requirements, such as the U.S. Foreign Account Tax Compliance Act (FATCA) or the OECD Common Reporting Standard (CRS). If the sealed wallet is deemed, e.g., by a jurisdiction, to contain digital assets representing foreign accounts subject to mandatory reporting requirements, the policy may include the identity of such wallet (e.g., as provided by a wallet identity provider that provides identity proof to the sealed wallet). The policy may enforce the issuance of one or more reports, e.g., as defined by the jurisdiction, regarding such wallet, related to wallet ownership, identifiers (e.g., taxpayer identification number), balances, and / or any other required information. The reports may be issued automatically, e.g., using the REAF field, as described above in connection with the SAR. The reports may be issued periodically by the sealed wallet. The accuracy of these reports, including calculated contents such as annual maximum balances, may be enforced by cryptographic means, such as zero-knowledge proofs that prove that the reported outputs were correctly calculated from the underlying transactions and CRAI. The policy may integrate additional information obtained from the AAS or external due diligence procedures into these reports.

[0153] [Example 14] Enforcement of Prevention and Sanctions A policy may specify that some transactions are forbidden and blocked. This specification may be achieved by a computational decision procedure that examines tentative transactions and reports whether the transactions are permissible. The decision procedure may reason over information that is visible in plaintext in the transaction data. The decision procedure may further reason over CRAI that is not visible in plaintext in the transaction data, but whose presence and integrity are guaranteed by cryptographic means.

[0154] For example, a policy may specify a blocked or sanctioned list consisting of a set of countries and may specify rules whereby a transaction is prohibited if the nationality of the sender or recipient is within such list. The nationality may be specified within an identity proof attached to the sealed wallet. Thus, all transactions containing a party's identity proof specifying a nationality within the list are detected by the decision procedure as prohibited.

[0155] In this example, the nationality may be included in a private CRAI that is attached to the sealed wallet but not exposed to the public. Nevertheless, the policy may still be enforced by cryptographic means such as zero-knowledge proofs (e.g., as described below) that are generated by the sender and attached to the transaction and can be verified by a decision procedure.

[0156] A policy may specify blocking based on identity attributes such as name or national identification number, based on transaction history, based on associated account numbers, or based on any other data in the CRAI, oracles, or other sources available within the system.

[0157] Parties that extend the ledger with new records (e.g., miners or validators) may invoke a decision procedure to reject forbidden transactions from being included in the ledger.

[0158] Even if a prohibited transaction appears in the ledger (e.g., because a validator's miners have performed a decision procedure and failed to act in accordance with the decision procedure), any other party may perform a decision procedure, recognize the prohibited transaction, and then refuse to recognize the prohibited transaction as valid. Thus, the system described herein may operate as an overlay on top of existing consensus systems, where miners or validators of the system are not aware of the system's transaction checking rules.

[0159] The decision procedure may include a delay element that makes the decision result visible only after some time has passed or after some participants have performed some action. This delay element can prevent transaction senders from knowing in advance whether a transaction matches a sanctions rule, and thus facilitate the detection of attempts to circumvent sanctions or reverse engineer sender-opaque policies (see below).

[0160] [Example 15] Lending Asset Recognition Service Lending services that allow users to lend or borrow assets (and often accrue or pay interest on such loans) may require specialized processing to meaningfully track the provenance of assets. As described above with reference to Example 6 (Exchange Asset Aware Services), simply following the flow of assets may lead to incorrect tracking of the provenance of funds. For example, if a loan is lent to a lending service by a lender, followed by a loan from the lending service to a borrower, native tracking may show that the lender's assets are transferred to the borrower. Similarly, when a lender retracts, simple tracking may attribute the funds to transfers from other lenders that happened to have recently lent loans to the lending service, or to any borrowers who recently returned the loan. However, a more meaningful attribute of the provenance of funds is to represent the returned loan assets as having the CRAI (identification, provenance, etc.) of the original loan assets.

[0161] The policy may allow the loan service to be an asset-aware service providing the latter attribute of the provenance of the funds. This may be achieved by reliance on the operator of the asset-aware service or in a distributed manner using communication protocols and cryptography, for example, as described above with reference to the AAS.

[0162] The AAS may also track provenance across multiple asset types, such as when one asset type is lent out but another asset type is returned in the settlement of a loan, as described above with reference to Example 6. The AAS may propagate the CRAI and track the provenance of the loan collateral, collateral agreements, and / or re-collateralization.

[0163] [Example 16] Protecting assets from theft or extortion Asset owners may choose to impose policies on their own wallets and assets to protect themselves against loss of those assets due to, for example, theft or extortion.

[0164] According to some embodiments, policies may limit the movement of funds by preventing outbound movements unless additional verification criteria are met. Such criteria may include, but are not limited to, authorization, authentication, or identity verification performed by additional means or parties, and / or a time window during which a transaction may remain pending and be cancelled by the sender.

[0165] According to other embodiments, a policy may restrict the destinations to which funds may be sent, e.g., using an allow list or block list mechanism similar to the mechanism described above with reference to Example 14 (Enforcement of Blocks and Sanctions), except that the lists may be established by the asset owner.

[0166] According to a further embodiment, the policy may issue alerts viewable by the asset owner or other authorized parties regarding transactions in these wallets and assets, similar to the alerts described above with reference to embodiment 5 (reporting suspicious activity), but with different recipients of the alerts.

[0167] It will be appreciated that some or all of the above embodiments may be combined. For example, a policy may specify such limitations or blocking as being applicable to all assets and / or wallets of a particular participant or group of participants, or a policy may specify criteria for enabling limitations or reporting, such as transaction volume thresholds or any other criteria that may be evaluated against transaction patterns and CRAIs.

[0168] [Example 17] Organizational policies Organizations that handle virtual assets may impose policies on their wallets and assets to protect them from theft or extortion, and / or to track fraud, embezzlement, and other illegal activities, similar to those described above with reference to Example 16 (Protecting Assets from Theft or Extortion). The examples described above with reference to Example 16 are similarly applicable. Organizational policies may be written and deployed by authorized financial personnel of the organization. Organizational policies may specify that organizational personnel are permitted to approve restricted transactions. Organizational policies may specify organizational personnel as recipients of reports enforced by the policy. Policies may apply to transactions within the organization and / or between the organization and its counterparties, such as customers, suppliers, investors, etc.

[0169] Data Platform The data platform includes a system for collecting aggregate data from transactions conducted on the ledger and within the AAS, and presents this data for customers to view and for use as input to compliance policies. The data platform uses privacy-preserving techniques to ensure that minimal information about individual transactions is revealed to unauthorized parties, while still allowing the collection of aggregate statistics.

[0170] Data Oracle A data oracle is a system designed to expose data to participants, for example, in a cryptographically authenticated manner as is well known in the art, such that such data can be used by the distributed system, including transaction initiators, as input to compliance policies when generating new transactions.

[0171] Policy writing / deployment Compliance policies represent algorithms or logic circuits that define computations and (implicitly) mathematical relationships between inputs and outputs of specific transactions (because of the equivalence between algorithms and logic circuits, these terms and terms related to these terms are used interchangeably herein). Policies may be coded in a human-readable policy programming language, which is compiled into a low-level form that is directly consumed by the policy enforcement mechanism. Specific input and output variables to the policy program may be marked using a sensitivity labeling scheme that specifies who should be able to see which inputs and outputs. For each policy thus represented, the sensitivity markup information may be included as part of the policy program or written in a separate file. Policy programs can be written in several possible languages ​​(some of which already exist), or they may be written using special "domain-specific languages" designed for this purpose.

[0172] Some input and output variables are also explicitly reserved as relating to data of the transaction and / or data stored in the sealed wallet. For example, the program may include an input variable representing the amount of funds sent in the transaction, the address of the recipient of the transaction, or a field from the identity proof in the sealed wallet. Similarly, the input variable may reference ancillary data values ​​in the corresponding CRAI associated with the transaction or the associated wallet. The variable value may be provided directly by a process or participant (e.g., transaction amount), calculated by the system from other values ​​(e.g., sum of past transaction amounts), provided by a policy or a data source specified by the policy, may be a randomly drawn number, may be generated by a "data oracle" as described above, or may be generated by any other process.

[0173] Each program contains at least one required output, i.e., a Boolean (true / false) result indicating whether the requirements of the policy are met and therefore whether the transaction should be allowed by the network. This result may be explicitly output, but may also be implicitly defined by the programming language. For example, the program may generate an error message if a condition is not met. The program may specify zero or even additional explicit output values. Alternatively, the program may be expressed in the form of a logical predicate (e.g., a conjunction of constraints), using the rule that the output is "true" if the logical predicates (e.g., all constraints) are met.

[0174] Policies are written by a programmer and then compiled, typically by a compiler toolchain, into a form that can be evaluated and inferred by components of the system. Thus, developers can use multiple different high-level programming languages ​​for policy development, and the compiled output of each language becomes a shared representation that fits into the system.

[0175] In order for the policy to take effect, it is deployed to parties that require knowledge of the policy, which may include sealed wallets, AASs, data platforms, miners, validators, etc. Such deployment may be performed by various means, including publishing the policy on a public ledger, via an Internet service specified by a resource locator such as a hostname and URL, or via a data storage service (whether centralized or decentralized). The policy may be packaged together with the software that uses the policy. For example, a sealed wallet application may be distributed in a package (e.g., an APK or ZIP file) that includes a copy of the policy. The policy may be distributed in source or compiled form.

[0176] A policy may require authentication to ensure that it was issued by the intended party (e.g., a regulatory body or consortium). Such authentication may be performed with a cryptographic digital signature on the policy itself, indirectly by authentication of the digital channel through which the signature is retrieved (e.g., an HTTPS URL through which a server presents a digital certificate and digital signature), or by any other trusted channel. Authentication may require approval by multiple parties, which may be accomplished cryptographically by multiple digital signatures, by collective signatures, or by threshold signatures.

[0177] Policies may be imposed by individuals or organizations on the individuals or organizations themselves (i.e., on some or all of the wallets and assets that the individual or organization controls or owns), for example, as described above with reference to Example 16 (Protecting assets from theft or extortion) and Example 17 (Organizational policies).

[0178] A policy may be updated or revoked, in whole or in part (e.g., components such as allow lists or block lists), and such updates or revocations may be distributed and authenticated by any of the means described above.

[0179] Policy deployment, updates, and revocation may be publicly visible, or policy deployment, updates, and revocation may be fully or partially opaque, such as when implementing a sender-opaque policy (e.g., as described below).

[0180] Policy deployments, updates, and / or revocations may include a description of the policy changes along with any additional data required to implement these policies. For example, in the case of policies implemented by zero-knowledge proofs (see below) that make use of universal reference strings (also known as structured reference strings, public parameters, or trusted configuration parameters), the required universal reference strings may be included in the deployment or update. Alternatively, this data may be provided indirectly, for example by providing an Internet resource locator.

[0181] Policy Enforcement After a policy has been written and compiled, it is enforced by the system using several underlying mechanisms. These mechanisms may include cryptographic mechanisms, such as zero-knowledge proofs (interactive or non-interactive), private multi-party computation protocols (for two or more parties, whether interactive or non-interactive), encryption and homomorphic encryption mechanisms, and program obfuscation algorithms. The choice of the implementation mechanism employed depends on the content of the policy.

[0182] Before each sealed wallet can participate in a transaction, it must first be prepared using the wallet's implementation (embodied in software and possibly hardware, as described above) to correctly form transactions and CRAIs.

[0183] The consensus system itself may be prepared using a logical system that allows the network operator to validate the correct formation of transactions and CRAIs. In some cases, the consensus system may be built using existing flexibilities in public ledger systems, such as the "smart contract" mechanism in the Ethereum blockchain. This construction may be performed using extensions to existing or new platforms, for example by using "pre-compilation" (dedicated instructions in the Ethereum smart contract bytecode language) that allow verification of specific zero-knowledge proof systems. Alternatively, a new system may be added to the consensus system to support validation. Alternatively, validation may be performed separately from the underlying distributed ledger and its consensus policies, i.e. some transactions are included in the underlying ledger but fail validation when checked by the system and are therefore considered non-compliant and excluded from the pool of conformance.

[0184] Before submitting a transaction to the system, the sealed wallet component must receive the required compliance policies in machine-readable form. This form may consist of expressions in a high-level programming language and / or low-level "bytecode" (e.g., a low-level instruction language designed to be executed by a software component called a virtual machine) or circuit representations of the policy algorithms. These policies may be received directly from the consensus system's ledger or from some out-of-band location. The transaction sender then constructs the transaction data using the formatting steps required by the consensus system. The transaction sender then constructs the attached CRAI components as described below.

[0185] Compliance policies can be broadly classified into two categories: Sender-transparent policies include policies such that all compliance policy inputs are known by the sender at the time of transaction construction. Sender-opaque policies include policies such that some program input values ​​may not be known to the sender (either fully or partially). Sender-opaque policies arise because required inputs are selected by the transaction receiver, or because required inputs are selected by other components of the network, such as the compliance policy creator (or a designated party to whom the compliance policy creator has delegated this authority).

[0186] Sender transparency policy and blockchain integration Consider first the case where all necessary policy input values ​​are known to the sender. In this case, to construct the CRAI, the sender's wallet component first evaluates the compliance policy against the known inputs. Evaluating the policy requires the sender's wallet component to compute the algorithmic steps of the policy program, or the circuitry to compute the program's outputs. This computation may be done inside a virtual machine, a specialized software component designed to execute programs. Some input variables may be specified by the policy to represent data specific to the transaction (e.g., amount or transaction recipient), data held by a sealed wallet, data computed from other values, data provided by the policy or a data source specified by the policy, randomly drawn numbers, etc., and the system running the virtual machine must ensure that the corresponding data values ​​are actually used. At the end of this process, the sender's wallet component obtains the program output and / or any intermediate data computed in the course of executing the compliance program.

[0187] If the policy evaluation indicates a successful outcome, the transaction meets the compliance policy and therefore the transaction and all policy program outputs can be chained together and sent to the consensus system for inclusion in the ledger.

[0188] However, the consensus system may not trust that the sealed wallet evaluated the policy correctly. Moreover, because some inputs to the policy are secret (and therefore the sender's wallet does not reveal their values ​​to the network), the consensus system may not be able to verify the correctness of the policy program itself. To resolve this impasse, the sender's wallet component generates a zero-knowledge proof that the sender's wallet component evaluated the program correctly and attaches this proof to the transaction.

[0189] A "non-interactive zero-knowledge (ZK) proof system" is a well-known cryptographic technique that includes two logical components: a prover and a verifier. The prover takes as input some secret data known as a "proof", along with a "statement", which is a description of some mathematical relationship within the given data (often the statement is further separated into an "instance", which is non-secret data, and a "relation", which is a description of some mathematical relationship that includes both the proof and the instance). If this mathematical relationship is valid, the prover can generate a "ZK proof", which is itself a data object. The verifier component takes as input the ZK proof and the statement, and determines whether the proof is valid. If the verifier determines that a given proof is valid, this indicates with a very high probability that the prover did in fact know the correct secret input that satisfies the statement. In the context of computer programs, the input and output of a computer program may be considered as data, and the program itself may be treated as the mathematical relationship that defines the statement. As mentioned above, a policy program can be equated to a mathematical relationship between the program's input and output data, and thus ZK proofs can be used to prove that the output of a computer program is correct given some inputs, even if some of the input data is not presented to the verifier.

[0190] In particular, the system may utilize zero-knowledge non-interactive arguments of knowledge (zk-SNARKs), a form of non-interactive zero-knowledge proof system with added properties of efficiency and security. The system may also utilize "interactive zero-knowledge proof systems," which have similar properties but differ in that proofs are not data objects but interactive protocols executed by provers and verifiers.

[0191] To create a transaction, the wallet component used by the transaction sender incorporates a prover component for an appropriate zero-knowledge proof system. After the policy program is evaluated, the prover constructs a proof that the program's output is correct and that the transaction itself is correctly formed. The wallet program then combines the transaction with the non-secret program inputs and outputs and the zero-knowledge proof (in some cases, the non-secret inputs and outputs may already be known or computed by the transaction verifier, in which case those inputs do not need to be explicitly attached to the transaction, provided that the transaction verifier knows where to get the necessary data). This additional data attached to the transaction includes the CRAI. The transaction data augmented by the CRAI is then sent to the ledger network, where one or more transaction validator components incorporate a verifier component of the zero-knowledge proof system. The one or more validators validate the transaction data according to the rules specified by the underlying consensus system, and also validate that the zero-knowledge proof is valid. If both validation procedures indicate success, the transaction is accepted as a valid sealed transaction. Inclusion of a transaction in the ledger network may or may not be conditional on the validity of a zero-knowledge proof.

[0192] It will be appreciated that in some cases, the underlying consensus system (e.g., Bitcoin) may not be available or modified to validate zero-knowledge proofs and / or other PAS transaction validation rules using the rules of the consensus system. In that case, the CRAI may be attached to the transaction and validated by a separate validator component and / or the transaction receiver itself. Thus, the PAS may be configured to allow transaction data augmented by the CRAI to be checked by a new validator, called an overlay validator, which may be different from the validator of the underlying consensus system. Parties using the PAS rely on the overlay validator and / or perform their own validation to recognize transactions that are valid to the PAS and therefore in a matching pool of transactions in addition to being part of the state of the underlying consensus system. All transactions that appear in the state of the underlying consensus system but do not pass validation of the PAS rules may be processed as follows: If the transaction does not include a sealed asset, the transaction is not relevant to the PAS. If the transaction includes a sealed asset, an action determined by the policy is taken. For example, this may be considered by the sender to "break the seal" of the asset (eg, as described above).

[0193] Some consensus systems may be configured to store the CRAI within a transaction in a structured manner that can be accessed by validators in the underlying consensus layer. Other consensus systems may be configured to store the CRAI only as opaque data inferred by overlay validators (e.g., OP_RETURN data in the Bitcoin blockchain). Other consensus systems may not be able to store the CRAI with the transaction, or may impose extra costs to do so, and thus the CRAI associated with a transaction may be stored in an alternative location that references the actual transaction, or vice versa. Those skilled in the art will recognize that each of these alternatives provides properties similar to the preferred embodiment, in which the CRAI is validated by the consensus system and incorporated directly into the consensus system's ledger.

[0194] It should be noted that some existing consensus systems include provisions for verifying zero-knowledge proofs as part of the consensus system's transaction rules. For example, Ethereum includes a "smart contract" function that is verified by the Ethereum Virtual Machine (EVM). One operation currently supported by the EVM is a ZK verification operation for a particular ZK proof system that ensures that a given zero-knowledge proof is valid. In a preferred embodiment, validation of the zero-knowledge proof occurs using functionality native to the consensus system. This functionality may be added or performed outside the network, if desired.

[0195] Sender Opaque Policy In some cases, a policy program must reason on selected inputs that are not available to the wallet of the sender generating the transaction. A non-limiting example of such a policy program is one that generates suspicious activity reports (SARs), where it may be undesirable for authorities to make public the exact conditions for generating a SAR, and similarly, it may be undesirable to make public a list of sanctioned parties or other criteria. Similarly, a policy may reason on inputs that are known to the transaction recipient and not the sender. This input may include sensitive details of the recipient's identity proof.

[0196] If some inputs to the policy program are not known to the sender, then these policies are said to be fully or partially "sender-opaque." The consequence of such policies is that the sender cannot easily evaluate the policy and compute the program output if the inputs to the program are not known to the sender. Thus, the sender cannot compute zero-knowledge proofs for such inputs and outputs, as required by previous techniques.

[0197] To evaluate such policies, the system can utilize cryptographic systems known as non-interactive two-party computation (NI-2PC) systems.

[0198] Two-party computation (2PC) is a technique that allows two entities (a generator and an evaluator) to evaluate some program or circuit while maintaining confidentiality guarantees. Specifically, in 2PC, each party provides some pre-agreed subset of the program inputs, and each party receives some pre-agreed subset of the program outputs. A crucial security property of these systems is that the parties each learn only the appropriate parts of the program outputs, and do not learn any information about the other party's inputs, nor any intermediate values ​​that arose in the course of evaluating the program. 2PC is typically implemented as an interactive process, where the two parties exchange many data messages for each computation. However, a special variant, non-interactive 2PC, allows the evaluator to commit to specific data values ​​for a subset of input variables by broadcasting a single message. Party B of the generator can then choose its own values ​​for the remaining input variables and send a second message back to the evaluator. Most importantly, the messages broadcast by the evaluator do not reveal the evaluator's inputs, and the messages sent by the generator do not reveal the generator's inputs. At the end of the process, the evaluator learns only the appropriate output values ​​for the program. A key advantage of the NI-2PC system is that at any point when it wants to change an input value, the evaluator only needs to broadcast a message. However, a generator participant (or even many different participants playing the role of generator) can perform the second step repeatedly, specifying different input values ​​each time. This allows two parties to evaluate a computer program many times against different inputs provided by one or more generators.

[0199] According to the subject matter disclosed herein, NI-2PC may be utilized to implement sender-opaque policy programs. To implement such policies, a party, e.g., a policy creator wishing to enforce SAR, operates an evaluator. This party selects some secret inputs to the policy program and then broadcasts the evaluator's message to all parties wishing to use the policy (it will be understood that the term "broadcast" refers to distributing a message to all parties. If the evaluator's inputs are unlikely to change, this broadcast may be achieved by distributing the message together with the policy program, e.g., by writing it to a ledger. However, other mechanisms for distribution may also be used). Each sender's wallet incorporates the generator component of the NI-2PC system. In addition to the first message generated by the evaluator, the sender's wallet receives the policy program together with all policy program inputs known to the sender. The sender's wallet outputs a second message that is attached to the transaction as part of the CRAI and / or in any other suitable location. To ensure that this second message is correctly formed, the sender may attach a zero-knowledge proof of correct formation, using the same techniques described in the previous section. Finally, the original party can either compute the program output using an evaluator, or the original party can delegate this step to a third party by giving the third party the information necessary to perform the evaluation.

[0200] In some cases, the policy program is partially sender-opaque, i.e., some policy outputs may be computed using inputs that are all fully known to the sender, but other policy outputs may not be computed. In such cases, it may be desirable to split the policy program into two sub-programs: a first sub-program that is fully sender-transparent, i.e., uses inputs that are fully known to the sender, and a second sub-program that is sender-opaque, i.e., uses some inputs that are not known to the sender. Each transaction sender would then need to satisfy both policies simultaneously. To do so, the sender would need to use both of the systems described above for such transactions. The process of splitting the original policy program into sub-programs may be performed automatically using standard program analysis techniques.

[0201] Verifiable Encryption In some cases, it may be desirable for a policy program to output some auxiliary data that cannot be read by the public, but that may be readable by one or more selected parties. An example of such a situation is included in the example "Regulated Escrow" policy described earlier in this document.

[0202] This functionality can be supported by incorporating certain operations into the policy program without further modification of the aforementioned system. Specifically, a policy program can be specified that uses public key encryption to generate an encrypted output according to a selected party's key. More specifically, in such a policy, the policy identifies (1) a method to compute the plaintext data to be encrypted, (2) the recipient's public key, and (3) optionally some random bits provided by the transaction generator. The policy program then incorporates logic to specify an encryption procedure to generate a ciphertext as output (according to some embodiments, the ciphertext may be used as input). For other outputs, the ciphertext itself is then attached to the transaction as the CRAI, and a zero-knowledge proof ensures that the data contained within the ciphertext was correctly formed. However, only the party that has the appropriate private key to decrypt this ciphertext can recover the encrypted data. All other parties observing the ledger do not have access to this data.

[0203] To support this functionality for policy program developers, the policy development system can incorporate public key encryption functionality as a "library module" or "precompiler" (i.e., a pre-written software component that the policy developer can use to write the policy program). Policy programs can also implicitly support the use of verifiable encryption. For example, a confidentiality markup schema can allow a developer to specify that only certain parties can use a given output, and the system automatically enforces this policy by using the aforementioned verifiable encryption system.

[0204] Status and past blockchain transactions It is often desirable for a policy program to reason over information derived from past transactions, or possibly over information derived from a set of past policies. This can be accomplished by recording "state" information as the encrypted or "committed" output of the policy program and attaching this data to each transaction. Subsequent transactions can reference previous transactions on the ledger as non-private data and use this state information as input. This reference is facilitated by ledgers, such as Ethereum, that natively incorporate hash trees over data into the ledger. Such trees can be used to construct efficient proofs that a transaction exists in the ledger. A policy program can take such a proof as input, verify that the proof is correct, and then reason over the transaction data.

[0205] Statistical Data Collection Some of the example compliance policies listed above specify that statistical aggregates may be calculated from individual transaction data in a manner that does not reveal the details of individual transactions. A variety of techniques may be used to gather such aggregate statistical data about transactions in a privacy-preserving manner. We now briefly describe several different techniques that may be used by different policy programs and how they are used in the present system.

[0206] One approach to collecting statistical data is to delegate the statistical aggregation to an entity that is allowed to see the individual transaction data and can then compute the statistical aggregation from the transaction data. To ensure the privacy of the individual transaction data, this party must be trusted not to reveal it. Such trust may be achieved by legal or policy means, or by technical means. This party is called an aggregator.

[0207] After such participants are identified, individual transactions may submit relevant transaction data to this participant by using the aforementioned verifiable encryption technique in order to compute a statistical aggregation field (SAF) containing the encrypted data. Each transaction then contains such a SAF containing the relevant data and embedding a ciphertext encrypted according to the aggregator's key. The aggregator possesses the corresponding private key and receives the transaction data. The aggregator can then decrypt each transaction to obtain the raw transaction data, upon which it computes aggregate statistics as permitted by the policy creator.

[0208] From a technical perspective, aggregators can be realized using Hardware Security Modules (HSMs) or other trusted computing systems such as Intel's SGX processors. These are programmable systems designed to perform calculations on secret data, and contain both logical and physical countermeasures that prevent access to the internal data and also tampering with the program logic being executed, respectively. Some systems, such as Intel SGX, also include the ability to generate software attestation signatures. These signatures allow a trusted system to generate outputs and "sign" these outputs so that a remote party can be assured that the outputs were generated by a valid processor running a particular program. Statistical aggregators can be realized by specifying such a program and requiring it to publish a proof along with a public key.

[0209] A limitation of the above trusted aggregator approach is that users must trust that the aggregator system is operating correctly and has not been compromised. An alternative approach eliminates the need for trusted aggregators altogether by using public differential privacy techniques.

[0210] Differential privacy techniques are well known in the art. These techniques work by adding statistical "noise" to individual data records so that these data records do not reveal any clues about the data in that record. But at the same time, a set of many such records can be combined to recover a useful statistical aggregation over the full set. One well-known technique for this is randomized responses. If a party wishes to report a piece of data that contains two possible values ​​(e.g., yes / no), the party can first flip a coin. If the coin shows "heads," the party reports the actual answer. But if the coin shows "tails," the party flips the coin again and reports the result of the second coin flip, not the actual result. In this way, every individual report can represent either a true result or a meaningless random answer. Thus, no useful information about a single result can be determined. At the same time, any party can compute an approximate sum by aggregating many such responses and correcting for the random answers. This computation provides an answer that is close to the sum of the actual data for a large enough set of results. Differential privacy techniques can generalize this idea to other forms of data, such as numerical and other textual data (e.g., a histogram computed over an arbitrary set of data elements, such as strings, which may be achieved by using a hash function to compute a digest of the required elements and then using this digest to place the elements into a Bloom filter, which is a special data structure for recording established membership relationships. Noise may be added to the Bloom filter).

[0211] To enable this approach, the compliance policy program can specify a statistical aggregation field (SAF) that contains one or more transaction data elements calculated by the policy and augmented with an appropriate amount of randomized noise. More specifically, the policy program is responsible for identifying which transaction data is used to calculate these reports, how the reports are formatted, and how precisely the noise is b44erify44d to obscure the true transaction values. The policy program also uses random numbers provided by the sender's wallet to calculate the noise-augmented values. Finally, the policy program combines each reported value into a SAF output. The enforcement techniques described in the previous section allow participants in the consensus system to verify that the SAF is attached to the transaction data and calculated correctly.

[0212] Given multiple transactions that contain such SAF fields, an aggregator can perform a process that combines the SAF data from many transactions. Note that in that case, the aggregator does not need to possess any private keys and therefore can be treated as an untrusted party.

[0213] Secure Multiparty Computation (MPC), Homomorphic Encryption (HE), and Program Obfuscation (PO) are powerful general techniques for performing computations with private inputs and multiple parties, subject to integrity and privacy constraints. When such more specific techniques are unknown, unavailable, or relatively inefficient, the system may use MPC, HE, or PO to achieve behavior prescribed by policy.

[0214] Inter-blockchain operation SAP may be configured to maintain the CRAI and enforce compliance policies across transactions involving multiple types of sealed assets and / or multiple blockchain-based agreement systems (or other systems for representing virtual assets) to create a unified conforming pool. In such a configuration, each blockchain may have different means of integrating the CRAI and validating transactions (as described above in "Sender Transparency Policy and Blockchain Integration").

[0215] SAP may propagate the CRAI across multiple blockchains, e.g., by integration with a service that performs asset movement involving multiple blockchains, as described above with reference to Example 12 (management of distributed applications) and / or Example 15 (loan asset awareness service), and may modify or extend such a service to form an AAS. In this embodiment, the AAS propagates the CRAI from one blockchain to another.

[0216] SAP may propagate CRAI across multiple blockchains by embedding functionality for adding cross-blockchain annotations into the sealed wallet software. For example, SAP may include a reference to a related transaction on another blockchain within the CRAI that SAP adds to one blockchain.

[0217] Protocols and services implementing cross-blockchain representation of virtual assets are well known in the art. For example, WBTC (wrapped Bitcoin), tBTC, and renBTC are all existing virtual assets that represent BTC on the Ethereum blockchain and use various mechanisms for the creation and redemption of such assets. Such services and protocols may be extended to form an AAS that propagates the CRAI across multiple blockchains. For example, if a wrapped BTC token is created by depositing a sealed BTC coin, an implementation of the wrapped BTC AAS may attach the CRAI to the newly created wrapped BTC token, which propagates the CRAI attached to the original BTC coin.

[0218] Extensibility and Rollups Some consensus systems have technical features that impose limitations on the number of transactions that can be recorded within a given period of time. These limitations usually vary depending on the size of the transaction data that must be stored and distributed by the system, as well as the computation time required to verify each transaction. A known technique for addressing this problem is to use "rollups" to compress the amount of data that needs to be stored and verified by the consensus system.

[0219] In such a "rollup" configuration, one or more servers collect a sequence of related transactions and compute a compact representation that stands in for the full sequence. The underlying consensus system thus does not need to store or validate the original transactions, but only needs to validate and store the compact representation (the rollup summary).

[0220] Many such configurations are well known in the art. For example, "ZK rollup" uses cryptographic zero-knowledge proofs (also called verifiable computing) techniques to generate a short mathematical proof that all transactions represented by the rollup summary have been correctly verified, and that the rollup summary represents the final outcome of the evaluation of those transactions. This proof can be verified by a consensus system. In "optimistic rollup", the rollup summary does not entail a mathematical proof that the summary is correct. Instead, the system typically provides economic incentives to third parties to verify individual transactions, allowing the third parties to recover payments. This is done through the use of "proofs of fraud" that can be verified by the consensus system, and assets deposited as bonds by the servers, allowing the submitter of a proof of fraud showing that a given server approved a rollup summary that turns out to be invalid to thereby be entitled to recover that server's bond, thereby also penalizing server misconduct. Rollup can also be achieved using a multi-party computation protocol involving a committee of servers, where a majority of the servers must approve a rollup summary for it to be considered trustworthy; this approval may be combined with optimistic rollup to penalize cheating committee members.

[0221] To ensure high performance in the consensus system, the sealed transactions may be processed by a roll-up system. This roll-up system includes one or more servers that process transactions received from users, optionally verify the structure of the CRAI, and compute a roll-up summary from these transactions. The roll-up system may then generate, for example, a verifiable computation or ZK proof that the roll-up summary was correctly computed. Alternatively, the roll-up system may provide a third party with an opportunity to verify the roll-up summary and the verification of the individual transactions, as well as to generate one or more fraud proofs that allow the consensus system to detect fraud. In the latter case, the roll-up system may release the bond already deposited by the fraudulent server to the party that presented the fraud proof.

[0222] To verify the correctness of a transaction involving a sealed asset, the verifying server must validate the correctness of the transaction itself, as described by the rules of the underlying consensus system. In addition, the server must validate the correctness of the associated CRAI, which is cryptographically bound to the transaction. According to some embodiments, the transaction format of the underlying consensus system provides a means for including the CRAI in the transaction, and the validation rules of the consensus system can validate the CRAI. In such a case, the two validation operations are combined into a single operation. To compute a rollup, the server must validate each transaction and the associated CRAI, and compute a summary proof, which may include the output of a hash data structure (e.g., a Merkle tree or "cryptographic accumulator") for the set of transactions and the inputs and outputs of each transaction. For convenience, the system may generate multiple hash data structures to separately contain the inputs and outputs and other intermediate transaction details. These data structures may be combined to form the rollup summary.

[0223] To ensure that the rollup server does not omit validation and generate incorrect rollup summaries, the rollup server may optionally involve a financial bond (a quantity of virtual assets) that can be released to a third party if the third party is able to identify improper structure in the rollup summary. This may be done by the addition of a "fraud proof," which itself includes a portion of the Merkle tree that indicates that a subcomponent of the rollup summary was not computed properly. Other forms of fraud proof may be supported.

[0224] The rollup system ensures that a given sequence of transactions summarized by the rollup server is internally consistent and does not conflict with other transactions approved by the consensus system. This guarantee is needed to prevent "double spending" and / or situations where the amount sent by the customer exceeds the customer's balance. This guarantee is also needed to prevent inconsistencies related to auxiliary information processed by SAP, such as CRAIs attached to transactions, certificate updates or revocations, and / or policy updates. Thus, the rollup system can facilitate ensuring that no conflicting transactions or updates occur while a sequence of transactions is being processed by the rollup server.

[0225] This guarantee may be achieved by delegating the responsibility of processing all transactions related to a particular conforming pool to one or more designated rollup servers. In this configuration, transactions affecting the relevant pool may not be directly approved by the consensus system and may not be approved by other rollup servers except the designated servers. Meanwhile, the designated servers may be configured to ensure that all transactions, including all CRAIs, certification renewals or revocations, and policy updates, have a determined ordering and are internally consistent. The selection of one or more servers associated with a particular conforming pool may change periodically. According to some embodiments, multiple servers may collect transactions simultaneously and generate rollups containing conflicting transactions or orderings, provided that only one rollup is approved by the consensus system.

[0226] The rollup servers may be configured to recognize transactions in which assets are transferred from a source matching pool to a destination matching pool. Additionally, the agreement system and rollup servers may include a clearing mechanism configured to extract all necessary information regarding funds (e.g., knowledge of transfers to a given matching pool) from each rollup server's rollup summary and distribute this information to rollup servers that require knowledge of this information. Similarly, CRAIs, certification updates or revocations, and policy updates are distributed to rollup servers that require knowledge of this information.

[0227] When such a transfer from one matching pool to another occurs, a given rollup server may process these transactions in one of two different ways: (1) the rollup server associated with the source matching pool may refuse to process subsequent transactions that pay for funds being transferred to the destination matching pool, or (2) the rollup server associated with the source matching pool may grant an exception by allowing the transaction to pay for funds in the destination matching pool, provided that the transaction is guaranteed not to conflict with transactions managed by other rollup servers. The latter condition may arise, for example, in situations where the subsequent transaction cannot conflict with transactions being processed by other servers.

[0228] While the above description considers the rollup server to be distinct from the consensus system, this is merely for convenience of explanation, and some or all of the rollup server's functionality may be integrated into the consensus system. For example, Central Bank Digital Currencies (CBDCs) may use a centralized system to implement the consensus system, and the same centralized system may also be responsible for approving transactions and generating rollup summaries. These systems may not require proof that the rollup summaries were calculated correctly, since they are all operated by the same (trusted) parties, nor may they require a fraud proof mechanism to detect improper summaries.

[0229] Tracing Regulated Escrow Providers A system that provides regulated escrow (e.g., as described above) may be configured in any suitable manner, for example, to accommodate specific permissions for decrypting escrowed information and / or conditions specified pursuant to those permissions.

[0230] According to some embodiments, a policy defines a single escrow provider that holds one or more keys that can decrypt all escrow CRAIs recorded in the ledger according to the policy. The escrow provider may be realized as a committee that requires majority or unanimous agreement to approve decryption (e.g., by employing cryptographic threshold signatures). This may occur in a single regulatory body assuming the role of escrow provider.

[0231] According to another embodiment, the policy defines multiple providers, each with a decryption key for only a particular transaction made on the network. The escrow provider may be, for example, a VASP or exchange selected for the purpose by the customer, and may or may not be the same party as the identity provider that issued the credentials to the user.

[0232] According to an embodiment in which multiple regulated escrow providers can decrypt the CRAI on a particular transaction, a process is required to find an applicable regulated escrow provider to perform the decryption. One or more mechanisms may be provided to accomplish this process.

[0233] According to some embodiments, this mechanism involves providing a label in the CRAI in each relevant transaction that indicates which escrow providers can decrypt the transaction.

[0234] According to another embodiment, the mechanism includes providing the ciphertext encrypted using the escrow provider's key such that an attempt to decrypt the ciphertext by the escrow provider indicates whether the decryption was successful. Each provider can then attempt to decrypt the ciphertext using its key, and only the provider for which the ciphertext is intended will be successful.

[0235] According to a further embodiment, the mechanism defines an "escrow identifier" of a third party whose role it is to look at transactions to determine which escrow provider is responsible for each transaction. This party can then direct regulators, investigators, etc., to the relevant escrow provider, transaction by transaction. Accordingly, only this third party (or several such third parties) can see this information, and the public cannot use it. Thus, each transaction may contain an encrypted identifier of the escrow institution, plus any regular CRAI required for escrow of identifying information. This encryption is performed using a key belonging to the party of the "escrow identifier", which can decrypt the identifier. This party then uses the recovered information to direct investigators to the correct location.

[0236] Decentralized Applications (DeFi) In recent years, several decentralized finance applications have been deployed to provide financial services for digital currencies. Known as "DeFi" applications, these systems are typically implemented using "smart contracts," which are specialized computer programs that are evaluated by a consensus system and can programmatically control the flow of digital assets. While DeFi applications may include centralized components (such as exchange order books, price oracles, etc.), DeFi systems are typically designed to avoid reliance on centralized entities. The lack of a centralized entity located in a particular jurisdiction can lead to a more robust system, but also makes regulatory compliance more difficult.

[0237] For centralized applications such as asset exchanges, compliance policies may specify a party to play the role of Asset Awareness Service (AAS) that allows for the correct updating of CRAI on outgoing transactions. In decentralized applications, there may not be a trusted party that can perform the corresponding role, thus requiring a system that can correctly record compliance information without the use of trusted parties.

[0238] Enforcing proper preparation of the CRAI when interacting with a DeFi application may be performed in one of several different ways. The choice of which method to use depends on the nature of the DeFi application, e.g., as described below.

[0239] A user’s interaction with a DeFi application involves multiple interaction steps that can be characterized as follows: (a) Deposit: To interact with DeFi, the owner of a sealed asset sends virtual assets from a sealed wallet to the address of a smart contract controlled by a DeFi application. (b) User Interaction: During this stage, the owner of the sealed asset may interact with the DeFi application by issuing commands that describe how the asset should be processed. In some DeFi applications, this interaction stage does not occur. (c) Third Party Interactions: In addition to receiving commands from asset owners, DeFi applications may receive both additional deposits and additional commands from third parties. These third parties may be owners of the sealed assets or may not be participants in the sealed assets system. (d) Withdrawal: Asset owners may withdraw assets from a DeFi application to a sealed wallet. These assets may be the same as those originally deposited, or may be of a different type and / or amount of assets.

[0240] These interaction steps do not necessarily occur in a strict sequence. For example, a DeFi application may receive multiple deposit, withdrawal, and command interactions interleaved in any order. These interactions may occur one or more simultaneously, for example, in a trading transaction in which one type of asset is deposited and another type of asset is simultaneously withdrawn. There may be overlapping or intermixing of steps, for example, in an automated market maker (AMM) service, an asset is deposited and a token representing the deposit (a "liquidity provider" token) is withdrawn in one transaction, and the token is deposited (i.e., redeemed) and the asset is withdrawn in a subsequent transaction.

[0241] Additionally, there may be interactions other than deposits and withdrawals that may trigger events deemed to have regulatory significance. For example, a DeFi command may indicate a contract to transmit an asset of value to a third party.

[0242] Method 1: Whitelist DeFi Applications According to some embodiments, DeFi applications may be supported by designating the entire DeFi application as a trusted application, referred to herein as a Decentralized Asset Aware Service (DAAS). Similar to a centralized AAS, the DAAS may be configured to enforce the presence of a CRAI for deposits and withdrawals from the service. Internal operations of the DAAS that occur after a user deposits an asset and before the user withdraws the asset are not necessarily considered relevant to the enforcement of the CRAI. Thus, a user who deposits an asset and later withdraws the asset must attach a CRAI to each of these two transactions. However, if a smart contract performs operations involving mixed assets (even if those operations are requested by the user), those operations are not treated as relevant to the enforcement of the CRAI.

[0243] This approach may be appropriate when the inner workings of smart contracts are well understood by the policy creator and it is known that the smart contract itself cannot be used to circumvent regulatory enforcement. In such cases, the policy creator may be willing to allow exceptions to the processing of CRAI for certain DeFi applications. The advantage of many DeFi systems is that they are typically based on smart contract programs that can be analyzed and audited by the policy creator. Thus, the policy creator will know that a particular contract will not perform actions that pose a high risk to regulatory compliance. Thus, the policy creator can include an "allowed list" of addresses of authorized smart contracts in the policy program. Alternatively, the policy creator can specify in the policy program that a signed list of authorized DAAS providers may be provided to the policy as an external input.

[0244] The advantage of this approach is that construction of the CRAI can be performed by a sealed wallet due to the fact that withdrawals and deposits are typically initiated by (and from) the sealed wallet. The sealed wallet does not necessarily need to know or understand the logic within the smart contract, nor does it need to reason against any commands issued to the application by the sealed wallet owner or third parties.

[0245] Indeed, smart contracts (e.g., smart contract addresses and / or program code) that are deemed too risky to be safely used within regulated infrastructures may be added to a "block list," which may be included in the policy program and / or provided to the policy program as a separate input from some trusted source. Thus, users of sealed assets may never send assets to these systems.

[0246] Method 2: Inference on the activity of DeFi applications According to other embodiments, an application may be used in a manner that the policy creator considers to be "mixed," i.e., the application is deemed "compliant" when used in one way, but is deemed to violate regulatory guarantees and / or increase regulatory risk associated with the asset when used in a different way. For example, a DeFi application in which a policy creator performs passive investments may be deemed "safe," but a DeFi application in which users actively designate payees and loans may not be deemed "safe." Alternatively, a particular set of actions performed by a user may be stored in the CRAI to allow the system to evaluate them in a more sophisticated manner.

[0247] The system may base the CRAI determination on a particular set of actions taken on a DeFi smart contract between when a user deposits assets and when the user withdraws assets. The set of permitted actions is determined by a policy program. For example, a policy program may not allow a user to cancel a contract (with a valid CRAI) if a particular set of commands are issued by the user. The user needs some way to prove that the proper commands (and only the proper commands) were issued to satisfy the cancellation policy. This proof may be performed in one of several ways.

[0248] In one embodiment, a separate server component monitors the DeFi application and its transactions on the blockchain. This server component determines what commands are being made and how those commands affect the compliance and risk of different sealed wallets upon exit from the service. When a user wants to exit from a DeFi app, the user contacts this server for a decision. The server provides a digitally signed message containing the necessary information so that the signed message can be provided as an input to the policy program. For example, the server may issue a signed message indicating that a non-high-risk action was taken while the sealed wallet's assets were deposited in the DeFi app, or the server may issue a warning that the user performed a high-risk action, etc. The policy program processes these messages according to its own program and generates the appropriate CRAI.

[0249] In the second embodiment, no centralized server is used. Rather, the owner of each sealed wallet performs the task of monitoring DeFi applications on the blockchain, verifying commands that comply with the criteria specified by the policy, and generates a zero-knowledge proof as part of the CRAI. This statement of proof can be included in the policy program. This embodiment may be less efficient compared to the first embodiment described above, but it can reduce the need to establish and trust a server, for example, for complex monitoring tasks.

[0250] Identification information transmission system As previously mentioned, the compliance system may include an identity propagation system configured to facilitate the IP to perform one or more of its functions. According to some embodiments, the identity propagation system is configured to facilitate the IP to receive, verify, and / or record customer identity information and share portions of this information with service providers in a manner that minimizes the need for the service providers to store sensitive customer information. The identity propagation system may further facilitate a customer's authorization and control of distribution of certain portions of the customer's identity and / or pseudonym to selected providers. The identity propagation system may be further configured to enable distribution of this information from the identity provider in a manner that allows the service provider to verify authenticity, for example, without the service provider directly communicating with the identity provider. This may be enabled by providing the customer with cryptographic identity proofs and / or identity assertions.

[0251] According to some embodiments, the identity propagation system is further configured to facilitate the service provider defining requirements regarding the identity information needed and for the identity provider to meet these requirements and to request retention of specific customer information by the identity provider. The identity propagation system may further enable the service provider to compare customer identifiers and share information about a particular customer with the identity provider and other service providers such that this information can be linked to the customer's identity.

[0252] According to some embodiments, the identity propagation system is configured to operate in a centralized configuration, where information about a customer's identity is stored at a centralized identity provider, and service providers interact directly with the centralized identity provider using a secure authenticated network communication channel to obtain assertions about the customer's identity and to send back updated information about the customer's behavior.

[0253] According to some embodiments, the identity delivery system is configured to operate in a distributed configuration where information about a customer's identity is provided to the customer in a cryptographically authenticated form, and the service provider receives a subset of this information from the customer. Updates from the service provider may be stored in various locations, including at the identity provider, including the customer (for distribution to other service providers), or on a ledger of a consensus network such as a blockchain.

[0254] According to some embodiments, the identity propagation system is configured to operate according to a combination of features of each of the centralized and distributed configurations.

[0255] Components of the identity transmission system The identity conveyance system may be configured to make assertions regarding the identity of a customer, the customer owning and / or controlling one or more digital assets. The identity conveyance system may include, for example, an identity provider, a service provider, and a Customer Identity Manager configured to communicate with each other over a computer network.

[0256] Identity Providers (IPs) are configured to verify customer identity credentials, such as government-issued identity documents, and to securely record information about each customer. IPs may be further configured to issue "identity assertions" to service providers. Such identity assertions may be in the form of digital certificates and are configured to inform service providers of identity information about a customer, or the presence of identity information at the IP, in a manner that can be verified by the service provider itself.

[0257] A service provider (SP) is configured to provide one or more financial services to a customer. Examples of SPs may include, but are not limited to, virtual asset service providers (VASPs), banks, payment processors, credit card issuers, and fund transmission services. An SP may require identity verification to perform a transaction with a particular customer and may be configured to receive identity assertions from a trusted identity provider. An SP may be configured to interact with one or more SPs to exchange information about a customer and / or to verify that different SPs are interacting with the same customer.

[0258] A Customer Identity Manager (CIM) is configured to allow a customer to interface with service providers and identity providers. An instance of the CIM may be integrated as a subcomponent of a customer's "wallet" configured to control and store digital assets such as cryptocurrencies. The CIM communicates with computer networks, thereby allowing sending messages to and / or receiving messages from IP and SP systems. The CIM software or hardware may be directly controlled by the customer and / or operated by the service provider on behalf of the customer. According to some embodiments, the CIM is integrated with a wallet implemented on a dedicated device (a so-called "hardware wallet") that is only intermittently connected to the Internet, for example by connecting to a general-purpose computer connected to the Internet. According to some embodiments, the CIM is integrated with a wallet that is software-based, i.e. implemented in software installed on a general-purpose computer that is continuously connected to the Internet. According to some embodiments, the CIM is partially integrated with a hardware wallet and partially integrated with a software-based wallet.

[0259] In a given identity delivery system, there may be multiple instances of each of these components, which are communicatively coupled via a computer network to exchange information between each other. It will be understood that the terms IP, SP, and CIM describe given sets of functions, and thus a participant may function simultaneously as an IP, SP, and / or CIM.

[0260] Operation of the identification information transmission system During operation, the identity transfer system performs one or more functions, a non-limiting list of which is as follows:

[0261] Identity Verification: To establish identity in an identity delivery system, a customer communicates with an identity provider and delivers an identity document to be verified by IP. This document verification may be performed, for example, in person at a physical location, electronically over a computer network, and / or in any other suitable manner or combination thereof. One example of such a process may include, but is not limited to, uploading to a website a photo of a government-issued identity, one or more bills addressed to the customer, etc. Identity verification may include direct digital communication with a government agency and / or digital procedures such as the use of a digital identity document contained on a "smart card."

[0262] After the identity provider verifies the customer's identity, the identity provider may generate and issue a digital identity credential to the customer. The digital identity credential is a digital file that contains structured information about the user's identity, as well as cryptographic authentication data, such as a digital signature calculated over this information using a cryptographic key generated by the identity provider. According to some embodiments, the IP may store the identity locally.

[0263] Service Registration: When a customer wishes to register with a new service provider, the customer contacts the service provider via a network connection, such as an HTTP(S) request made to a website or via a mobile app. The customer then indicates which identity providers the customer has previously registered with and specifies information about their identities. This information may include a subset of the information stored in an identity certificate held by the customer, plus cryptographic information derived from the identity certificate. Alternatively, the customer may initiate direct communication between the identity provider and the service provider, possibly mediated by the customer's computer.

[0264] In this process, a customer may disclose a single specific identity provider. Alternatively, a customer may not disclose a specific identity provider, but rather disclose that the identity provider belongs to an authorized set of identity providers. The latter may be performed using cryptographic zero-knowledge proofs, for example referencing a list of certified identity providers in a jurisdiction, or referencing a digitally signed certificate issued by a relevant authority in the jurisdiction that certified the identity provider. Additionally, a customer may disclose multiple identity providers, so that separate information provided by identity providers about the customer can be complementary and checked for consistency.

[0265] At the end of this process, the service provider obtains relevant information about the customer, thereby verifying that the customer is registered with the identity provider and holds the identity in a favorable context. This information may be associated with the customer's account with the service provider. The information recorded by the service provider may be derived at least in part from a combination of the information requested by the SP and the IP and information the customer chooses to make public. According to some embodiments, this information may expose the complete identity, such as the user's name. According to other embodiments, the information communicated includes a "pseudonym," i.e., an identifier of the customer that is different from the customer's actual identity. The pseudonym is selected to uniquely identify the customer to the identity provider. The pseudonym may be selected such that each customer has a single pseudonym shared across multiple SPs with which the customer registers, or an individual pseudonym specific to a single provider.

[0266] Thus, the information learned by the service provider may convey coarse-grained summaries of attributes of a customer's identity without revealing precise details or corroborating evidence. For example, the information may reveal a customer's country of citizenship or residence (but not a specific address), a customer's age range (but not an exact age or date of birth), a customer's income range, and / or a customer's net worth range. Identifying information may also be of a negative nature (e.g., that a customer's citizenship is not within a particular deny list, while avoiding disclosing the specific country of citizenship).

[0267] Information may be requested by the service provider for a variety of purposes, including, but not limited to, compliance with remittance transmitter, virtual asset service provider, security, and / or banking regulations. For example, the requested information may be used to comply with Know Your Customer (KYC), anti-money laundering, counter-terrorism financing and sanctions mandates, to comply with the Travel Rule mandate, to verify accredited investor status (e.g., income, net worth pursuant to the Securities and Exchange Commission's Regulation D), to comply with the Foreign Account Tax Compliance Act (FATCA), and / or to comply with the Fair and Accurate Credit Transactions Act (FACTA), all of which require the collection and verification of customer information. Information may also be requested by the service provider to determine limitations or characteristics of the customer's account (e.g., options trading, margin, or other borrowed capital utilization) and / or to be used as data for customs risk-based policies.

[0268] Service Provider Reporting: After the service provider receives the customer's identity from the service provider, the service provider may perform services on behalf of the customer. The nature of these services may depend on the particular nature of the provider. The SP may record information that the SP wants to associate with the customer's identity. For example, the SP may store information that it only needs locally in an internal database. Additionally, the SP may obtain information that may be of interest to other parties in the identity transfer system. Examples of this information may include, but are not limited to, reports of fraudulent behavior by the customer (e.g., "reports of suspicious activity") that may need to be communicated to regulators or other parties in the identity transfer system, or information that can convey useful information about the customer's activities on the chain.

[0269] To facilitate this recording, the SP may transmit information to the identity provider and / or to other parties that may be usefully combined with the identity. This transmission may be accomplished in a number of ways, which are described further below.

[0270] Identity Revocation and Update: Parties in the identity propagation system may provide updates to identity information held by the SP and / or revoke previously created identity assertions. The former may occur when customer information changes at the IP, requiring new updated information to be sent to the SP. Alternatively, the IP may need to revoke a user's identity authority at one or more service providers. This revocation may occur, for example, if a user's identity is found to have been fraudulently accessed to register with a service provider. To facilitate this revocation, the IP may from time to time send one or more revocation messages to the SP via a broadcast message or via a dedicated message sent to the SP. These revocation messages are configured to ensure that the SP is aware that an identity assertion previously created for the SP is no longer accepted as valid. The mechanism of this process is described in more detail below.

[0271] Technical and Implementation Considerations The mechanism described above may be implemented in two different configurations. In the first (centralized) configuration, the identity provider (or an associated server authorized by the IP) communicates in real time with one or more service providers to convey the identity assertion. The advantage of this approach is that it can be implemented using many existing web-based technologies, such as HTTP, HTTPS, REST API, HTML, and web cookies. In the second (distributed) configuration, the IP sends the cryptographic object to the customer's customer identity manager, which stores this value and can make assertions about the identity directly to the SP. These two configurations, although different, may overlap in some respects, e.g. the distributed configuration does not exclude any communication between the SP and the IP.

[0272] Common elements: In each of the configurations, an identity provider maintains a database containing records about customers. This database includes information such as the customer's name, address, citizenship, passport details, national identification number, digital currency address, supporting documentation, and any verification procedures performed on the individual, plus any additional information (e.g., records regarding the customer's transaction history and / or credit score). The identity provider may be configured to summarize some of this information into alternative forms (e.g., convert a collection of transaction history data into a "risk score" that provides the service provider with a snapshot assessment of the customer's activity).

[0273] The IP may be further configured to communicate with a computer network, thereby accessing one or more consensus networks, such as a blockchain-based system (e.g., Bitcoin, Ethereum, etc.). The IP may use this access to gather additional information about the customer. The IP may communicate with the customer's machine, the customer identity manager, the service provider, and / or other connected components via the computer network (those skilled in the art will understand that the identity provider itself may split these functions across multiple computers or locations).

[0274] Each identity provider and one or more service providers may establish a trust relationship. This relationship requires the service provider to determine the IP as the source of authentic identity information. A service provider may establish trust relationships with multiple identity providers, and these trust relationships may be contingent on certain elements of the identity information, e.g., a service provider may trust an identity provider to validate identities in a particular jurisdiction, but not in other jurisdictions (e.g., an identity provider may validate identities in the United States, but not in France). Trust relationships may also apply in the opposite direction, e.g., an IP may only support assertions against certain pre-identified SPs, or an IP may support assertions against any SP.

[0275] This trust may be established between individual pairs of identity providers and service providers, or may employ a system that marks multiple identity providers and / or service providers as trusted, for example, via a list of certified identity providers in a jurisdiction, or via digital signature certificates issued by the relevant authorities in a jurisdiction.

[0276] Centralized Configuration: In a centralized configuration, the identity provider communicates in real time with the SP over a communications network, either directly or using the customer's computer as an intermediary (see further below).

[0277] A customer may establish a new relationship with a particular service provider and / or perform an action at an SP that requires verification of identity. In such cases, the SP and the IP may communicate with each other (directly or indirectly) to exchange certain information. This information may include, but is not limited to: 1. The SP indicates to the IP specifically what identity information is required. This may include a summary indicating that all available information is required, or that a subset of the identity information is required. Below, a mechanism for specifying this information is described. 2. The IP then determines whether the SP is permitted to receive information about the identity and what data the SP should receive. This decision process may include policies local to the IP, including the existence of a trust relationship between the IP and the SP. This decision process may include a step where the customer is required to provide explicit permission for the transfer of information. The decision regarding what data to deliver to the SP is made by a component called the Identity Summarization Engine, which is described in a later section. 3. The IP then distributes information regarding the customer's identity to the SP. This distribution may include a transmission containing a data structure that encodes the identity into fields. Each field may contain one aspect of the customer's identity, with all fields tied together as belonging to the same customer. This data structure should also incorporate the customer identifier value. The IP may distribute any auxiliary records it has received, such as updated risk information from other SPs intended for delivery. 4. At some point thereafter, the SP may develop information about the customer (e.g., information about fraudulent transactions, or updated risk scoring information). At this point, the SP may report the information to the IP, which may be further used to expand the IP's knowledge of the customer. This information may be stored in a database at the IP and / or by a third party using an identifier tied to the customer's identity.

[0278] The IP may be configured to identify at least a subset of the customer's identity for delivery to the SP. This "subset" may refer to a literal subset of identity fields in the database (i.e., some fields are selectively delivered and some fields are withheld). This subset may also refer to a process in which information is summarized into a form that provides reduced granularity. For example, a field in the IP's database may specify the customer's exact date of birth, but the IP may instead deliver an approximation of this exact date or age (e.g., "customer is over 21 years old"). The IP may further be configured to generate a "pseudonym" instead of explicitly identifying customer information. This pseudonym may be a customer identifier or number that is unique for this customer between the IP and this SP.

[0279] Information delivered to the customer and exchanged with the SP may be delivered in a manner that is secure against unauthorized tampering and / or eavesdropping by intermediaries. This delivery may be achieved by establishing a secure channel between the IP and the SP using the Transport Layer Security (TLS) protocol, which provides encrypted and cryptographically authenticated communication between the two machines over an Internet Protocol connection. However, alternative mechanisms may be used, for example, the identity provider may deliver information to the SP by using web-based redirects and other standard techniques, provided that this information is cryptographically authenticated to prevent tampering. Those skilled in the art will recognize that many common techniques exist for such communication, including the JSON WebToken standard.

[0280] Thus, the IP may be configured to securely deliver customer identifying information to the SP while ensuring that confidentiality and authenticity are maintained and that only necessary customer identifying information is revealed to the SP. The IP also establishes a unique identifier for the customer with the SP so that further communications regarding this customer can be uniquely referenced as part of the IP / SP communications.

[0281] A variation of the above mechanism, familiar to those skilled in the art, is that instead of sending messages directly between the IP and the SP, the IP and the SP can exchange messages using the customer's computer (e.g., a web browser) as an intermediary to pass messages between the two parties. The use of such an intermediate communication mechanism is a common technique in web-based systems such as single sign-on systems.

[0282] Distributed Configuration: The decoupled configuration of the identity conveying system does not require real-time communication between identity providers and service providers to authenticate each user. Instead, customers are provided with cryptographic proofs that embed relevant identity information. This proof may be stored by the customer in a Customer Identity Module (CIM). Additionally, some features of the proof (e.g., the public part of the proof and / or the commitment / hash) may be stored in a public ledger such as a blockchain. The Customer Identity Module may communicate with the service provider and the identity provider over a computer network. When the service provider needs to authenticate the user's identity, the service provider interacts with the CIM to obtain an identity assertion, which is a cryptographic object that specifies information about the customer's identity in a cryptographically authenticated manner, as described below.

[0283] A customer may establish a new relationship with a particular service provider or perform an action at an SP that requires verification of identity. When this occurs, the SP and CIM communicate (directly or indirectly through a second computer) to exchange certain information. This information may include, but is not limited to: 1. The SP specifically indicates to the CIM what identifying information is required. This may include a summary indicating that all available information is required or that a subset of identifying information is required. This request for information may be performed via a dedicated communication from the SP or may be published a priori by the SP. Specifically, this request for information may be attached to the address of the SP's virtual wallet, thereby informing the prospective customer that all transfers of funds involving this virtual wallet are subject to providing the specific requested information. 2. The CIM then decides whether the SP is allowed to receive information about the identity and what data the SP should receive. This decision process may include some policies defined by the IP and stored in the customer's identity certificate, in addition to policies local to the CIM. This decision process may include a step where the customer is required to provide explicit permission for the transfer of information. The decision as to what data should be delivered to the SP is made by a modified version of the Identity Summarization Engine, which in this configuration is located in the CIM. 3. The CIM then distributes information about the customer's identity to the SP. This distribution may consist of a transmission containing a data structure that encodes the identity into fields. Each field may contain one aspect of the customer's identity, and all fields are tied together as belonging to the same customer. This data structure should also incorporate the value of the customer identifier. To ensure that this information is authentic, the CIM may attach a cryptographic certificate (and / or signature) formed based on the identity certificate. This certificate may be verified by the SP to ensure that the information is authentic. Optionally, this certificate may indicate that the selective disclosures identified by the identity summary engine were correctly formed with respect to the policy of a given IP. 4. Using the information provided by the CIM, the SP may optionally request other information about the customer, such as updated information about the customer's risk score. This information may be stored in a public location (e.g., posted to a blockchain or stored in a publicly accessible data storage system), or it may be obtained from a private service, such as an originating IP. The identity and location of this service may be provided by the CIM to the SP as part of the information delivered in step (3), along with any customer identifiers and access codes needed to obtain this information. 5. At some point thereafter, the SP may develop new information about the customer (e.g., information about fraudulent transactions, or updated risk scoring information). At this point, the SP may report the information, which may be further used to extend the IP's known information about the customer. This information is sent to the location identified in the previous step (e.g., a public storage location or a private storage location such as the IP). This information is tied to the customer identifier at this location. As an additional element of protection for this data, it may be encrypted when stored in a public location. The decryption key required for this data may be included in the identity proof and may be delivered from the CIM to the SP as part of step (3).

[0284] As described above with reference to the centralized configuration, the CIM may be configured to use input from the IP to identify a subset of the customer's identity information for delivery to the SP. This "subset" may refer to a literal subset of identity fields in the database (i.e., some fields are selectively delivered and some fields are withheld). Identifying the subset may also refer to a process where information is summarized into a form that provides reduced granularity. Instead of explicitly identifying customer information, the CIM or IP may generate a "pseudonym." This pseudonym may be a customer identifier or number that is unique for this customer between the IP and this SP.

[0285] Even though the CIM is entirely under the control of the customer (which may be untrusted by the SP) since the IP is not necessarily involved in every identity assertion, cryptographic techniques may be provided so that the CIM can assert useful information about the identity to the SP. To achieve this, the CIM may be configured to implement one or more cryptographic techniques to generate a "non-interactive proof of correctness" for each identity assertion, for example from anonymous authentication information and zero-knowledge proof fields. This proof, which is a digital object, may be generated by the CIM using the identity proof and other local keying material as inputs and verified by the SP. If this proof verifies, the SP can be assured that the information contained in the identity assertion is genuine (i.e., the proof represents a true summary of the authenticated data in the identity proof). This proof can ensure that even a compromised CIM cannot issue a false identity assertion to the SP (the remaining concern is to handle the situation where the identity provider wants to "revoke" a customer's identity proof, or to revise such a proof using updated information, as will be explained below).

[0286] The decentralized setting may further support reporting of information by the SP. The information provided by the SP may be similar to the reporting described in the previous section. However, the mechanism by which reporting occurs may be different. In one embodiment, the SP may report information directly to the IP (as in the centralized setting) and receive updates directly from the IP. However, in other embodiments, the SP may report information to other public and private storage entities (e.g., blockchains, file sharing services, and / or third parties that simply hold the data for distribution to other users). To enable this, the identity proof may include an authentication token and a location for reporting data, so that the SP can exchange data via these services. The data reported by the SP may be encrypted according to an encryption key specified for the SP by the identity assertion of the CIM, and reports received by the SP from other SPs may be decrypted using the same encryption key (or related encryption keys). This mechanism is described in more detail below.

[0287] Because the CIM is located on the customer's machine, it may have access to additional information about the customer's transactions that the IP does not have access to. For example, if the CIM resides in the customer's digital "wallet", it may have access to a complete list of all past transactions, including recipient information and amounts. This information can also be incorporated into the assertions that the CIM makes to the SP. For example, the CIM may be configured to assert that some transactions were issued to a particular SP as proof that the customer has an existing relationship with the SP. This information may be provided explicitly (e.g., by reference to an explicit transaction on a digital currency network) or may be summarized using privacy-preserving cryptographic techniques. A standard approach for this is to use zero-knowledge proofs that indicate the existence of one or more transactions that meet certain criteria on a publicly visible cryptocurrency ledger, such as a blockchain. Techniques for computing such proofs have been proposed in the research literature.

[0288] Technical details Identity Summarization Engine and Identity Request and Assertion Syntax - Patent application One advantage of the identity information conveyance system described herein is the ability to selectively disclose information to service providers in a manner that can minimize the amount of the customer's Personal Identifiable Information (PII) about the customer that is stored at the service provider. The decision regarding what information is disclosed may vary between service providers, for example, because different providers have different requirements and different capabilities for securely storing data (selective disclosure may include, in addition to redacting certain fields, changing some identifying information to a less specific form, for example reducing precise data to categories or summaries). To ensure that the identity information conveyance system can scale to a large number of service providers and customers, the process of selective disclosure may be automated to a large extent.

[0289] To enable this process of automated selective disclosure, an Identity Summarization Engine (ISE) may be provided. An ISE is an identity delivery system that records one or more customer data records plus a request from a service provider detailing what data is required, and (optionally) some auxiliary information such as an identity policy. The ISE then determines which customer data should be selectively disclosed to the SP by selecting specific fields from the customer data or by summarizing the data into a precise but less specific form. The ISE may be operated directly by the identity provider (e.g., in a centralized setting) or may be deployed as part of a customer identity module (CIM).

[0290] ISE Behavior: At a basic level, an ISE takes in the request, customer record, and policies from the SP (but may take in additional information). The role of the ISE is to process each field of customer data to determine whether (1) this field should be delivered to the SP, (2) this field should be excluded from the assertion delivered to the SP, or (3) this field should be summarized with less specific information (or combined with information in other fields). The ISE's behavior for each field may depend on policies, which may dictate, for example, what information should be delivered, summarized, or withheld, in a manner specific to the SP.

[0291] The information used by the ISE may vary depending on the implementation. For example, the SP's request may include detailed information about which fields the SP is requesting, or may not include such details. The policy may be expressed in a general-purpose computer programming language or scripting language that encodes rules for processing each field, and may be Turing complete. Alternatively, the policy may simply describe a more restricted set of rules that can be interpreted by a data processing system to determine what action should be taken using each field.

[0292] Identity Request and Assertion Language: To implement an ISE, an identity delivery system according to some embodiments may specify an identity assertion made to an SP, as well as a request language for specifying identity requests from the SP. The request language specifies, in a machine-readable format (e.g., JSON), which identity fields the SP requires and at what granularity. For example, an SP may specify a tuple of required fields, such as: required_fields = {full_name, age, investor_status, legal_jurisdiction} Here, each of the above token names represents standard information stored within a customer record. Additionally, the SP may identify that certain fields may be delivered in an abridged form. For example, the SP's request may indicate that the SP only wishes to know "whether the customer is over 21 years old." This request may be expressed in multiple possible forms. The SP may also identify when an identification field may be treated as optional or may be replaced with a placeholder (e.g., a pseudonym instead of the customer's name). For example, required_fields = {full_name, age:{>=21}, investor_status, legal_jurisdiction={!=”EU”}} may indicate that the SP only requires to know that the customer is at least 21 years old, and that the customer is explicitly not located in an “EU” jurisdiction.

[0293] Any request may be processed by the ISE to determine if this information can be delivered to the SP, and each required field (if permitted) may be extracted from the customer data record and delivered to the SP. The response message is expressed in an assertion language, which is a machine-readable format that contains the requested data and may further include a customer identifier and fields to facilitate updates. For example, { “Customer_id”, 9“348723483” “full_name”:“Arthur Wallace Peterson”, “age”:43, “investor_status”:“accredited”, “legal_jurisdiction”:“US”, “update_location”:“https: / / identity-provider.com / updates” “update_token”:“932hbc0wehraehamsnebkaadk2efsvds2bzkhbjWz” }

[0294] Assertion language messages may include components depending on the particular request (e.g., specifying a customer data record). Assertion language messages may also include standard elements, such as the ability to identify when information fields have been redacted or summarized. For example, the following response may show a summary responsive to the second query above, and also indicates that the investor_status component of the record has been redacted due to policy restrictions: { “Customer_id”, 9“348723483” “full_name”:“Arthur Wallace Peterson”, "age"[>=21]:TRUE, “investor_status”:{null, not_available_with_policy}, “legal_jurisdiction”[!=EU]:TRUE, “update_location”:“https: / / identity-provider.com / updates” “update_token”:“932hbc0wehraehamsnebkaadk2efsvds2bzkhbjWz” }

[0295] The above example is one example of what the request and response language could be: a complete implementation may use a different notation, for example for interoperability with standard conventions or for conciseness.

[0296] As indicated above, the identity assertion may include a location where updated and revocation information for the customer can be found. This location may be identified by a URL and may include identifiers, such as authorization tokens (e.g., passwords) and decryption keys, needed to access the data and decrypt the retrieved information.

[0297] Policy: The ISE may be configured to receive as input one or more policies selected by the identity provider in addition to the SP's request and customer data. These policies, along with the SP's request, allow the ISE to determine which fields should be returned and which fields should be summarized or redacted. As previously mentioned, policies may include computer programs or scripts that can operate on elements of the SP's request and customer data and / or make decisions regarding how to output or summarize data. Alternatively, policies may simply specify basic rules that the ISE can evaluate against this data to make a decision.

[0298] Although the policies are described above as operating on the complete SP request and customer data, it will be appreciated that the policies may also reason on partial customer data. For example, the customer data may include only the names of fields in a customer record, and the ISE may output instructions regarding which fields should be summarized or excluded.

[0299] Cryptographic authentication In order to accept a new identity assertion, the SP must verify that the assertion is authentic, which means two things: (1) that the identity assertion matches information held by the identity provider, and, optionally, (2) that specific decisions about what information to send, exclude, and summarize are allowed by the identity provider.

[0300] Centralized Setup: In a centralized setup, the IP and SP communicate in real time, either directly or, optionally, using the customer's computer as an intermediary. In this setup, cryptographic authentication is handled in a variety of ways, including: 1. For direct communication between an SP and an IP, the two parties can use the Transport Layer Security protocol (formerly known as SSL), which provides one-sided or mutual authentication of the two parties using digital certificates to establish an encrypted and authenticated connection between the two parties. The SP initiating such a connection directly with the IP can verify the authenticity of all data received over this connection, including identity assertion, since the cryptographic protocol ensures that the connection is valid and that the data received is authentic, e.g., protected against modification or insertion of data by a third party. 2. In case of indirect communication between SP and IP, the two parties can authenticate messages delivered from IP to SP using digital signatures or message authentication codes. These values ​​can be delivered, for example, via JWT tokens or URLs. Several practical solutions are known in the literature for delivering encrypted and authenticated information between two systems via an intermediary web browser.

[0301] It will be appreciated that in this setting, because the identity assertion is derived directly from the identity provider, whenever the SP can verify that the assertion is authentic, the SP may also be configured to verify that the identity digest has also been determined by the IP, thereby obviating the need to provide an additional cryptographic mechanism to prove to the SP that this determination is true.

[0302] Distributed Setup: In this setup, the IP provides the customer (specifically the Customer Identity Manager component) with an identity proof that contains relevant details about the customer's identity. The CIM must then create an identity assertion to the SP that the SP can verify as authentic.

[0303] According to some embodiments, a CIM to SIP identity assertion is created by sending the entire identity proof from the CIM to the SP, without selective disclosure or summarization of any fields. In this setting, the identity proof may include a digital signature on its contents formed by the identity provider. Upon receipt of the identity proof, the SP can verify that the proof is valid (i.e., generated by the IP) by verifying that the signature is valid with respect to the IP's public key. (It will be understood that a digital signature is a cryptographic object similar to an actual signature in that it attests to the authenticity of a document. With respect to a digital signature, the signing party (in this case the IP) holds a private key with which it can sign any message (the identity proof data) so that this signature can be verified as genuine, using a second associated "public key" issued by the IP to all parties.)

[0304] According to some embodiments, the identity communication system is configured to allow selective disclosure while still allowing the SP to verify authenticity.

[0305] According to some embodiments in which selective disclosure is enabled while still allowing the SP to verify authenticity, the IP is configured to calculate a digital commitment for each data field, then combine all of the commitment values ​​and sign the combined result. The identity proof includes the complete list of digital commitments along with the signature, and the CIM is also given a plaintext list of the data fields and the "opening" values ​​of the commitments for each field. When the CIM sends an identity assertion to the SP, it sends the complete identity proof, which includes the commitments and signatures, along with the data fields themselves, in addition to the "open" values ​​of all commitments corresponding to the data fields that the CIM wants to expose to the SP. The SP can then verify that the signature is valid and that each data field and public value matches the corresponding commitment. (A digital commitment is a cryptographic object that resembles an envelope. To create a commitment, the data fields, along with optional random data, are provided as input, and the result is an object called a commitment that does not reveal the contents of the data fields, plus a "public" value. Given the commitment, the public value, and the content, any party can verify that the commitment is not contradictory. An important property of a commitment is that, once formed, it should be infeasible to "reveal" the commitment to a data value different from the data values ​​used to form the commitment.)

[0306] According to these embodiments, the CIM may be configured to selectively expose data fields to the SP. For fields that the CIM wishes to selectively expose, the CIM may be configured to provide for the exposure of the data field and the commitment (in addition to the commitment included in the identity proof). For fields that the CIM does not wish to expose, the CIM excludes the exposure of the data field and the commitment. The SP is then assured, using the identity proof, that all selectively exposed values ​​are consistent and authentic, but the SP does not learn any values ​​that the CIM does not choose to expose.

[0307] It will be appreciated that several variations of this structure are possible that may be more efficient. For example, the IP may choose to compute a Merkle hash tree over the tree, which may be included in the leaves of the hash tree, for all of the commitments, and publish a portion of the hash tree to convince the SP that all published values ​​are correct. The CIM may send a portion of the Merkle hash tree of values ​​that the CIM wants to publish. With this approach, the amount of data sent to the SP can be sublinear in the number of fields in the identity proof.

[0308] The above techniques can facilitate selective disclosure of fields in the identity proof. To provide a summary, cryptographic methods can exist that allow the CIM to expose a mathematical function of one or more fields in the identity proof without revealing the original values ​​in the proof, and can be provided to convince the SP that this function was calculated correctly. For example, a mathematical function can take the customer's age as input and output "true" if the customer is over 21 years old. Other functions can transform customer information into a less precise representation, for example, by "bucketizing" or otherwise summarizing the information.

[0309] An alternative embodiment of the distributed setup allows the CIM to create identity assertions using the "anonymous credentials" technique. A set of cryptographic techniques is known for creating cryptographic assertions for structured and authenticated documents. In this framework, a central "authority" cryptographically signs a document called a "credential" that contains information, e.g., including multiple fields. This credential may be signed directly by the authority and given to the user, or it may be signed using a "blind signature" in such a way that a person in possession of the credential can interact with the authority and obtain a signature for this credential, without the authority learning any (or any) information about the credential. A user holding the signed document can then generate an assertion for a particular content of the credential, and this user can "show" the credential, e.g., by generating a cryptographic message to some third party (called a "verifier") that indicates proof that the user is in possession of such a credential or that the credential contains certain information. This verifier party may be the same party as the original authority, or the verifier may be a third party. Such "anonymous credentials" can ensure that a credential "show" message cannot be easily linked back to the original credential signed by the authority. Thus, if an authority signs many credentials and then looks at a credential "show" message, the authority should not be able to determine which of these credentials are being displayed. Similarly, it should be infeasible for a user to "show" a credential that was not issued by the authority without fraudulent activity being detected by a verifier. Suitable anonymous credentials are well known in the art.

[0310] An even stronger variant of anonymous credentials uses "signatures with efficient protocols", which is also well known in the art. This variant defines a signature scheme that can sign a multi-field anonymous credential, allowing the user to prove arbitrary functions over the signed data. For example, a user holding a signed credential can simply reveal fields of the credential, can leave out fields of the credential, or can reveal a zero-knowledge proof of knowledge that the user entered fields from the signed credential that satisfy some mathematical function. This mathematical function can be a summary function that maps input fields to summarized inputs. The nature of this process is that a "show credential" reveals a summary of one or more fields of the credential, and can prove that the user performing the show has a credential that matches this summary. These signatures can be realized from the signatures based on the strong RSA assumption, bilinear mapping, and other cryptographic techniques.

[0311] According to some embodiments, a distributed setup uses such anonymous credentials as follows: To obtain an identity proof, the CIM obtains an anonymous credential for the customer's identity. This signed credential may be stored in a multi-field anonymous credential and delivered to the CIM using a blind signature extraction protocol or simply by having the IP sign the credential and deliver it to the CIM. When the SP needs an identity assertion from the CIM, the ISE system on the CIM now evaluates the policies, also stored in the CIM, to determine exactly which fields of the credential should be exposed to the SP and which should be summarized. For fields that should be summarized, the CIM now derives a mathematical summary function for the fields of the credential and outputs the summarized value. Finally, the CIM computes an credential "representation", which is a cryptographic message that proves that the published summary matches the signed credential.

[0312] One example of summarization is developing a pseudonym for the user that is unique for each exchange. The identity proof should include a customer identifier that is unique to the identity provider. However, the IP and CIM may not want to expose this unique identity to the SP, and instead want to generate a "pseudo-identifier" for each SP. To handle this case, the CIM may be configured to use a summarization function that "entangles" the customer identifier with an identifier unique to the SP to obtain a pseudo-ID unique to the SP. This summarization function may be a function, such as a pseudo-random function, where the key is the customer identifier, and the input to this function is the unique identifier of the SP.

[0313] report As previously mentioned, the SP may be configured to generate additional information that must be stored at the identity provider and / or distributed to other service providers. Such information may include, but is not limited to, information regarding fraudulent transactions generated by the customer, or new information regarding the customer's activities. This information may be targeted for distribution to all participants in the system or may be restricted to specific parties.

[0314] As mentioned above, in both centralized and distributed settings, information may be reported by sending the information directly to the identity provider. This reporting may be accomplished by delivering a reporting location (e.g., a URL) to the SP as part of the identity proof. This URL may be associated with one or more API keys or authentication tokens that allow access. To report new information, the SP establishes communication with the IP and sends the information in a secure manner, for example, via an HTTP(S) connection. This information may then be recorded in a database by the identity provider and processed for later distribution to other customers and SPs.

[0315] According to some embodiments, for example if the identity transfer system operates according to a decentralized setting, this information may be distributed to other SPs via a broadcast channel or a storage system. One such channel is the use of a consensus network such as a blockchain.

[0316] Multiple Identity Providers In some embodiments, a single identity provider may not be solely responsible for having the identity of a customer and / or storing the reported information. For example, a customer's identity may be split across multiple identity providers working together to provide identity assertions. This mechanism may be achieved by establishing a unique customer identifier across all providers and having each provider generate a partial identity assertion or proof that includes the relevant information held by that identity provider. These partial identity assertions or proofs may be combined according to the customer identifier to assemble a complete assertion at the SP or a complete set of information for use as an identity proof in the CIM.

[0317] Similarly, information reported by the SPs may be stored in multiple different locations, and provided that this information is identified by some identifier that allows the individual reported values ​​to be linked together, this information can be retrieved and combined by the SPs and other interested parties to obtain a complete picture of the reported information required.

[0318] Revocation and Renewal of Certificates From time to time, an issued identity proof or identity assertion may become invalid or may contain information that has been replaced with new information available by the identity provider. To handle this case, each identity proof and identity assertion may contain one of four fields: the identity of the assertion / proof, the expiration date of the assertion / proof, instructions (e.g., a URL) to use to obtain updated information about the assertion / proof, and a recommendation as to how often each proof should be updated.

[0319] In a centralized setting, the SP receiving the assertion from the IP may optionally receive these fields as part of the assertion. The SP may use this information to determine if the assertion has reached its expiration date, by a mechanism of comparing the expiration date to the current time. Similarly, in a distributed setting, the CIM may compare the expiration date to the current time to determine if the identity certificate has expired and needs to be renewed. Furthermore, in a distributed setting, the CIM may send to the SP, upon verification by the SP that the identity certificate has been verified as authentic, either (1) the expiration date of the identity certificate, or (2) a summary of the expiration date of the identity certificate. Examples of such summaries may include, but are not limited to, a summary indicating approximately when the identity certificate will expire, or simply an indication that the identity certificate has not yet expired as of the current time. Such summarization may be required to ensure that assertions made by the CIM to the SP do not leak the exact expiration time of the proof, since this information may expose information to the SP that would allow the SP to link different identity assertions by the CIM to the same identity proof, when this information should be hidden.

[0320] The IP may be configured to revoke and / or update information in an identity assertion or identity proof prior to the expiration date. This revocation and / or update may occur, for example, when new information arrives at the IP that changes the customer's status (e.g., a stolen identity proof or evidence of fraudulent intent). To address this case, the IP may be configured to publish a "revoke" message to one or more SPs, allowing the SP to determine that one or more customer identities must be updated. This message may include an identifier of the assertion or identity proof.

[0321] The identifier associated with the identity assertion received by the SP is unique for the customer, as described in the previous section, but may be shared across all SPs, or may be a different identifier used for each SP / IP combination to identify a single customer.

[0322] There are several protocols for the revocation of standard PKI certificates, such as those used to secure web sites. These protocols include Certificate Revocation Lists (CRL) and Online Certificate Status Protocol (OCSP), which are used to communicate that a given certificate has been revoked. These protocols can be applied to the identity certificates and assertions mentioned above with minor modifications, or specific protocols with similar purposes may be used instead. To use a Certificate Revocation List, the identity provider publishes a list containing the identifiers of all revoked identity certificates and / or assertions. In the OCSP example, each service provider periodically contacts the identity provider and requests whether the identifier of a given certificate / assertion has been revoked. A final variation of this approach involves a process of "OCSP stapling", in which a client such as a CIM can contact an IP and obtain a digitally signed file indicating that the identity certificate is still valid and has not been revoked. This file contains a "validity period" that indicates how long this file should be considered valid (e.g., up to three days from the time the file is requested). The CIM can then attach or "staple" this file to identity assertions made to the SP. Alternatively, the CIM can abstract the contents of this file using the techniques described for identity proofs. This eliminates the need for the SP to communicate directly with the IP and removes some of the resource cost from the SP in checking that the proof is still valid.

[0323] As an alternative to full revocation, an IP may wish to simply update the contents of the identity assertion or identity proof. The mechanism for this is similar to revocation, except that the IP should indicate as part of a message it publishes (e.g., a CRL or OCSP message) that the proof / assertion has not been revoked, but rather that parties should obtain an updated proof from the IP. In a centralized setting, the SP would then contact the IP as described in the previous section to obtain the new / renewed assertion. In a distributed setting, the CIM may need to contact the IP to obtain the updated identity proof, and the SP would then obtain the new assertion from the CIM.

[0324] Those skilled in the art to which the present invention pertains will readily appreciate that numerous changes, variations and modifications may be made thereto, mutatis mutandis, without departing from the scope of the subject matter disclosed herein.

Claims

1. 1. A computer-implemented compliance system configured to manage transactions on a digital asset network in accordance with a compliance policy, the digital asset network configured to enforce rules governing recording of transactions on a public ledger, the compliance system comprising: determining that the requested transaction complies with the compliance policy; generating at least partially encrypted Compliance Related Aid Information (CRAI), wherein the CRAI includes information configured to facilitate independent verification of the compliance; Associating at least a portion of the CRAI with transaction information stored in the public ledger and storing the associated CRAI in a storage location accessible via the digital asset network; A compliance system configured to:

2. Associating encrypted regulatory information with one or more of the user's transactions, where said regulatory information is decodable by an associated regulatory agent; generating a report including information regarding the one or more transactions; cryptographically storing said report including said associated regulatory information; The compliance system of claim 1 , further configured to:

3. 3. The compliance system of claim 2, wherein the compliance policy defines one or more conditions that constitute suspicious activity, and the compliance system is configured to determine that the one or more transactions constitute the defined suspicious activity.

4. 2. The compliance system of claim 1, wherein the compliance policy defines one or more attributes of a prohibited transaction, and the compliance system is configured to prevent execution of a transaction that is deemed prohibited by the compliance policy.

5. 2. The compliance system of claim 1, wherein the compliance policy defines one or more attributes of a transaction that require inference, and the compliance policy is configured to identify when a transaction requires inference, calculate the amount of inference, and initiate a transaction to satisfy the required inference.

6. a plurality of sealed wallets defined by said compliance policy; 2. The compliance system of claim 1, wherein the sealed wallet is configured to infer against the CRAI to determine whether a requested transaction complies with the compliance policy.

7. The compliance system of claim 1 , further configured to reason against a CRAI associated with one or more transactions.

8. The compliance system of claim 1 , wherein the CRAI includes a certification that the transaction complies with the compliance policy.

9. The compliance system of claim 1 , wherein the CRAI includes compliance information relevant to determining compliance of the requested transaction with the compliance policy.

10. The compliance system of claim 1 , further comprising an identity provider configured to verify information corresponding to a user and to issue an identity proof to the user upon said verification.

11. The compliance system of claim 1 , configured to extend native assets associated with the digital asset network by attaching a CRAI in accordance with the compliance policy, thereby generating a sealed asset.

12. The compliance system of claim 11 , configured to separate a CRAI from a sealed asset, thereby extracting the native asset from the sealed asset.

13. 12. The compliance system of claim 11, further configured to define conforming pools containing sealed wallets and sealed assets defined by compatible compliance policies.

14. 2. The compliance system of claim 1, wherein the CRAI includes a regulatory escrow access field configured to facilitate third-party verification of each transaction.

15. The compliance system of claim 1 , further configured to attach an encoded mathematical function associated with a transaction to the transaction.

16. The compliance system of claim 1 , further configured to analyze one or more transactions for suspicious activity.

17. The compliance system of claim 1 , wherein encryption of at least a portion of the CRAI facilitates verification of the CRAI without disclosing the contents of the CRAI.

18. The compliance system of claim 1 , wherein encryption of at least a portion of the CRAI is unrecoverable.

19. The compliance system of claim 1 , wherein the transaction information includes one or more selected from the group consisting of a cryptographic identifier of a sender of the transaction, a cryptographic identifier of a recipient of the transaction, and transaction details.

20. The compliance system of claim 1 , wherein the transaction includes transferring currency.

Images