WO2024137428A1 - Authenticated modification of blockchain-based data - Google Patents

Abstract

Example implementations may include: obtaining a first identifier relating to a first entity, wherein the first identifier uniquely identifies the first entity within a backwardly- immutabie cryptographic sequence of data blocks: exchanging, between the first entity and a second, entity; a set of conditions, wherein a second identifier uniquely identifies the second entity within the data blocks; receiving, from the first entity and the second entity, acceptances of tiie set of conditions; generating a self-executing unit of program logic that contains the first identifier, the second identifier, a representation of the set of conditions, and a third identifier that uniquely identifies a third entity having authority to suspend, modify, or override execution of the program logic; adding, as a new data block, the self-executing unit of program logic on the data blocks; and notifying one or more of the first entity or second entity of the self¬ executing unit of program logic.

Description

MBHB Docket No. 21-0361-WO3 Authenticated Modification of Blockchain-Based Data CROSS-REFERENCE TO RELATED APPLICATIONS [001] This application claims priority to U.S. provisional patent application nos. 63/433,818, filed December 20, 2022, and 63/453,201, filed March 20, 2023, both of which are hereby incorporated by reference in their entirety. BACKGROUND [002] A distributed, decentralized network is a network of entities, usually referred to as “nodes,” each of which stores or records a current state of the entire network, among other possible information. The state of the entire network may be made up of individual states, each associated with an entity that “owns” the individual state. The owning entity of a state is usually referred to as the “owner.” Among the characteristics and properties of a distributed, decentralized network is a principle that each node is bound by, or agrees to, a set of rules and/or protocols governing how and under what circumstances individual states may change. For example, proposed changes may need to be agreed upon by a majority of the nodes, and some form of proof or work or proof of stake may need to be carried out on any collection of one or more proposed state changes. Another rule may require that only the owner of a state can invoke or initiate a proposed change to that state. SUMMARY [003] A blockchain network is an example of a distributed, decentralized network. Specifically, a blockchain network may include a sequence of data structures, or “blocks,” each respective one of which records the entire history of the network states up through the time at which the respective block was added to the sequence. The sequence of blocks form a linked chain, and each block is encoded in such a way that it is practically, if not actually, impossible to modify once entered in the chain. New blocks can be added recording an updated state (temporal snapshot), but existing blocks cannot be changed. That is, the blockchain is backwardly immutable. [004] The backward immutability of blockchains, together with their distributed, decentralized nature of blockchains, can pose impediments to rectifying errant or otherwise defective network states recorded in blocks. The inventors have recognized that there is a need for a capability to remedy problematic network-state recordings in distributed, decentralized networks, but to be able to do so without tampering with the distributed, decentralized nature. Thus, the inventors have devised techniques, methods, and systems for achieving these desirable goals. MBHB Docket No. 21-0361-WO3 [005] Accordingly, a first example embodiment may involve a method carried out by a computing system configured for operating as a node of a network of nodes operating a blockchain. The method may involve operations including: receiving a request message for placing an entry on the blockchain, wherein the request message comprises: (i) a request specification for the entry including an action and an identity of at least one party subject to the action, (ii) an indicator specifying that the entry has been authorized by a trusted entity, and (iii) a plurality of cryptographic verification codes generated by a corresponding plurality of trust verifiers, each cryptographic verification code comprising an encoded action-payload supplied by the trusted entity and cryptographically signed by a respective one of the trust verifiers; applying a public encryption key of each respective trust verifier to the corresponding cryptographic verification code to decrypt a corresponding encoded action-payload; making a first verification that at least a threshold number of the decrypted corresponding encoded action-payloads are identical; and submitting the entry for block processing to be added to the blockchain in response to making at least the first verification. [006] A second example embodiment may involve method carried out by a computing system configured for operating as a node of a network of nodes operating a blockchain. The method may involve operations including: receiving a request message for placing an entry on the blockchain configured for invoking a contingency action of a smart contract previously entered on the blockchain, wherein the request message comprises: (i) a request specification including a link to the smart contract, an identifier of the contingency action, and an identity of a designated action-caller authorized to invoke the contingency action, (ii) an indicator specifying that the entry has been authorized by a trusted entity, and (iii) a plurality of cryptographic verification codes generated by a corresponding plurality of trust verifiers, each cryptographic verification code comprising an encoded action-payload supplied by the trusted entity and cryptographically signed by a respective one of the trust verifiers; applying a public encryption key of each respective trust verifier to the corresponding cryptographic verification code to decrypt a corresponding encoded action-payload; making a first verification that at least a threshold number of the decrypted corresponding encoded action-payloads are identical; generating a transaction specification and placing it in the entry in response to making at least the first verification, wherein the generated transaction specification comprises a directive to execute the identified contingency action as authorized by the trusted entity acting an authenticated alias of the designated action-caller; and submitting the entry for block processing to be added to the blockchain. MBHB Docket No. 21-0361-WO3 [007] A third example embodiment may involve a method carried out by a computing system configured for operating as database server for verifying and storing encoded action- triggers for digital assets entered on a blockchain network. The method may involve operations including: receiving a request message for verifying and storing a verified action-trigger for a digital transaction entered on the blockchain network, wherein the request message comprises a request specification including an action and an identity of at least one party associated with a digital asset subject to the action; receiving a plurality of cryptographic verification codes independently generated by a corresponding plurality of trust verifiers, each cryptographic verification code comprising a trigger code sourced from a trusted entity and cryptographically signed by a respective one of the trust verifiers; applying a public encryption key of each respective trust verifier to the corresponding cryptographic verification code to decrypt a corresponding trigger code; making a first verification that at least a threshold number of the decrypted corresponding trigger codes are identical; applying an encoder function to the request specification to derive a local version of the trigger code associated with the action; making a second verification that the local version of the trigger code is identical to that of each of the at least the threshold number of decrypted corresponding trigger codes that are identical; and storing the trigger code as the verified action-trigger in a database associated with the computing system. [008] A fourth example embodiment may involve method carried out by a computing system configured for operating as database server for verifying and storing encoded action- triggers for smart contracts entered on a blockchain network. The method may involve operations including: receiving a request message for verifying and storing a verified action- trigger for a smart contract entered on a blockchain network, wherein the request message comprises a request specification including a link to the smart contract and an identifier of the contingency action of the smart contract; receiving a plurality of cryptographic verification codes independently generated by a corresponding plurality of trust verifiers, each cryptographic verification code comprising a trigger code sourced from a trusted entity and cryptographically signed by a respective one of the trust verifiers; applying a public encryption key of each respective trust verifier to the corresponding cryptographic verification code to decrypt a corresponding trigger code; making a first verification that at least a threshold number of the decrypted corresponding trigger codes are identical; applying an encoder function to the request specification to derive a local version of the trigger code associated with the contingency action; making a second verification that the local version of the trigger code is identical to that of each of the at least the threshold number of decrypted corresponding trigger MBHB Docket No. 21-0361-WO3 codes that are identical storing the trigger code as the verified action-trigger in a database associated with the computing system. [009] In a fifth example embodiment, a computing system may include at least one processor, as well as memory and program instructions. The program instructions may be stored in the memory, and upon execution by the at least one processor, cause the computing system to perform operations in accordance with any one or more of the first, second, third, and fourth example embodiments. [010] In a sixth example embodiment, an article of manufacture may include a non- transitory computer-readable medium, having stored thereon program instructions that, upon execution by a computing system, cause the computing system to perform operations in accordance with any one or more of the first, second, third, and fourth example embodiments. [011] In an seventh example embodiment, a system may include various means for carrying out each of the operations of any one or more of the first, second, third, and fourth example embodiments. [012] These, as well as other embodiments, aspects, advantages, and alternatives, will become apparent to those of ordinary skill in the art by reading the following detailed description, with reference where appropriate to the accompanying drawings. Further, this summary and other descriptions and figures provided herein are intended to illustrate embodiments by way of example only and, as such, that numerous variations are possible. For instance, structural elements and process steps can be rearranged, combined, distributed, eliminated, or otherwise changed, while remaining within the scope of the embodiments as claimed.

MBHB Docket No. 21-0361-WO3 BRIEF DESCRIPTION OF THE DRAWINGS [013] Figure 1 illustrates a schematic drawing of a computing device, in accordance with example embodiments. [014] Figure 2 illustrates a schematic drawing of a server device cluster, in accordance with example embodiments. [015] Figure 3 illustrates a simplified block diagram of an example system in which various operations of a system-level implementation may be carried out, in accordance with example embodiments. [016] Figures 4A and 4B illustrate a two representations of example processing by a system-level implementation of an action-entry request, in accordance with example embodiments. [017] Figure 5 illustrates an example message flow diagram associated with various aspects of a system-level operations, in accordance with example embodiments. [018] Figure 6 illustrates a simplified block diagram of another example system in which various operations of an entry-level implementation may be carried out, in accordance with example embodiments. [019] Figure 7A and 7B illustrate a two representations of example processing by an entry-level implementation of action-request verification, in accordance with example embodiments. [020] Figure 8 illustrates an example message flow diagram associated with various aspects of an entry-level operations, in accordance with example embodiments. [021] Figure 9 illustrates a flow chart of an example system-level method for transactions, in accordance with example embodiments. [022] Figure 10 illustrates a flow chart of an example system-level method for smart contracts, in accordance with example embodiments. [023] Figure 11 illustrates a flow chart of an example entry-level method for transactions, in accordance with example embodiments. [024] Figure 12 illustrates a flow chart of an example entry-level method for smart contracts, in accordance with example embodiments. [025] Figure 13 illustrates a flow chart of example generation of a smart contract with third-party authority, in accordance with example embodiments. MBHB Docket No. 21-0361-WO3 DETAILED DESCRIPTION [026] Example methods, devices, and systems are described herein. It should be understood that the words “example” and “exemplary” are used herein to mean “serving as an example, instance, or illustration.” Any embodiment or feature described herein as being an “example” or “exemplary” is not necessarily to be construed as preferred or advantageous over other embodiments or features unless stated as such. Thus, other embodiments can be utilized and other changes can be made without departing from the scope of the subject matter presented herein. [027] Accordingly, the example embodiments described herein are not meant to be limiting. It will be readily understood that the aspects of the present disclosure, as generally described herein, and illustrated in the figures, can be arranged, substituted, combined, separated, and designed in a wide variety of different configurations. For example, the separation of features into “client” and “server” components may occur in a number of ways. [028] Further, unless context suggests otherwise, the features illustrated in each of the figures may be used in combination with one another. Thus, the figures should be generally viewed as component aspects of one or more overall embodiments, with the understanding that not all illustrated features are necessary for each embodiment. [029] Additionally, any enumeration of elements, blocks, or steps in this specification or the claims is for purposes of clarity. Thus, such enumeration should not be interpreted to require or imply that these elements, blocks, or steps adhere to a particular arrangement or are carried out in a particular order. I. Introduction [030] Blockchain-based technology underlies and facilitates a new form of decentralized computing that has been used to provide cryptocurrencies, smart contracts, non- fungible tokens (NFTs), identity protection, and secure voting, among many other applications. There is speculation, at least from some sources, that a new version of the world-wide web (“web 3.0”) can be built atop one or more blockchains. Regardless, it appears indisputable that blockchain-based technology has had an impact on computer networks and other aspects of society even though it has only existed in a practical form for a little over a decade. [031] Herein, “blockchain-based” technology refers to any variation of blockchain technology or any technology that employs or relies upon blockchain mechanisms. This includes current and future variations of blockchain technology. [032] In short, a blockchain is a list of entries stored as a distributed database that can grow over time based on consensus protocols carried out by blockchain nodes. Groups of MBHB Docket No. 21-0361-WO3 entries are added to the blockchain within data structures that take the form of blocks, and sequential blocks are cryptographically linked to one another. The blockchain nodes are computing devices or computing systems that can communicate with one another in a peer-to- peer fashion using blockchain software, and thus may reside in different locations and may be operated by different entities. Blockchain nodes may form an overlay on an existing computer network (e.g., the Internet), and may be jointly referred to as a blockchain network. To maintain independence and the decentralized character of the blockchain, each blockchain node may store its own copy of the entire blockchain. [033] Each block contains a cryptographic hash of the previous block in the blockchain, a timestamp, and data. The cryptographic hash may be produced by any one-way (hash) function that is mathematically and/or computationally impractical to reverse, such as SHA-256. The sequential linking of blocks through a cryptographic hash chain makes it very difficult for any party to modify a recently-placed block, and virtually impossible to modify earlier blocks. [034] Each blockchain user has a unique address to use with the blockchain. Each user also has a public key / private key pair that are cryptographically associated such that data encoded with the public key can be only be decoded by the corresponding private key, and vice versa. Thus, data encoded with a user’s public key are effectively encrypted so that they can only be decrypted by the user’s private key, and data encoded with the user’s private key results in a digital signature that is verifiable with the user’s public key. [035] An entry is typically some form of transaction between two or more users that includes the address of the “sending” user, the information being “sent,” and the address of one or more “receiving” users, all of which is signed with the digital signature of the sending user. Thus, the entry can easily be verified to be from the sending user (the sending user is authenticated) and have integrity (the entry was not changed after signing) as well as non- repudiation (the sender cannot later deny having signed the entry). The information being sent may be some amount of cryptocurrency, a smart contract, or some other token. [036] Proposed new entries are received by one or more blockchain nodes and their digital signatures are authenticated. In some cases, the validity of the entry may also be verified (e.g., an entry on a cryptocurrency blockchain cannot cause an amount of cryptocurrency held by the sender to be less than zero). These entries are formed into blocks, and then these blocks are distributed across the blockchain network to the other blockchain nodes. Each block may include one or more entries. [037] Each blockchain node independently authorizes received blocks through an MBHB Docket No. 21-0361-WO3 agreed-upon consensus protocol. An example of such a protocol is “proof of work,” where the blockchain nodes attempt to solve a mathematical puzzle by trial and error. For instance, the consensus protocol may require that the blockchain nodes attempt to find a nonce (e.g., an unknown value) such that a cryptographic hash function performed over the block with the nonce appended results in a hash value with a specified number of leading zeros. The process of carrying out this protocol is often referred to as “mining” and requires a significant amount of computational power. [038] The first blockchain node that discovers a suitable nonce broadcasts this nonce and the resulting hash value to the rest of the blockchain network. It is trivial for the other blockchain nodes to validate whether the nonce and hash value are correct. Such a block is said to have been “mined” and the discoverer may be awarded accordingly (e.g., with a small amount of cryptocurrency) to motivate participation in the protocol. Once a simple majority of the blockchain nodes agree that the block has been mined, the block is added to the blockchain by all blockchain nodes. Note that not all blockchain nodes need to act as miners in this fashion. [039] The cryptographic linking of blocks and proof of work being used for consensus, makes illegitimate modifications of a blockchain to be practically infeasible, as an attacker must modify all subsequent blocks in order for the modifications of one block to be accepted. Thus, blocks on a blockchain are effectively backwardly-immutable. Nonetheless, other consensus protocols, such as those based on proof of stake, may be used instead. [040] From time to time, a blockchain may undergo a fork and effectively change its character or become two different blockchains. Notably, the integrity of a blockchain relies on the blockchain nodes thereof agreeing on the rules used to add blocks and maintain history. If these nodes do not or cannot agree on the rules, or collectively agree to adopt a new set of rules, a fork is said to have occurred. [041] Some forks are accidental and short-lived. For instance, two miners may complete successful mining of a block at about the same time. After these miners begin broadcasting their solutions to the block, different blockchain nodes may add one or the other of these blocks to their local copies of the blockchain. Eventually, the addition of subsequent blocks will cause one of these versions of the blockchain to become longer than the other, and the blockchain nodes will abandon (orphan) the shorter version. [042] On the other hand, an intentional fork can happen when the rules are changed for at least some of the blockchain nodes. A soft fork occurs when the rules are changed in a backward-compatible fashion for a majority of the blockchain nodes (e.g., to add new types of MBHB Docket No. 21-0361-WO3 entries). Thus, a single blockchain remains, with the blockchain nodes for which the rules have not been updated still recognizing new blocks as valid. Eventually, all blockchain nodes may be updated to the new rules. [043] A hard fork occurs when a majority of the blockchain nodes adopt new rules that render blocks produced by the new rules to be considered invalid under the old rules. Unless all blockchain nodes upgrade to the new rules, a permanent split can occur with a single blockchain diverging to become two independent blockchains – one operating in accordance with the new rules and the other operating in accordance with the old rules. [044] One of the major uses of blockchain technology, in addition to supporting cryptocurrencies, is the formation and execution of smart contracts. Smart contracts are executable logic (e.g., programs or code snippets) that are placed in entries. A smart contract’s logic is run when certain predetermined conditions are met. A simple smart contract may consist of “if-X-then-Y” logic, where X is a set of one or more conditions and Y is a set of one or more operations to be carried out when X becomes true. [045] As an example, smart contract logic may specify that when a shipment arrives at a recipient’s location (X), the recipient pays the sender an amount of money (Y). The smart contract may also specify one or more external data sources (e.g., output from sensors or application programming interfaces of other computing systems) that will be used to determine whether and when X becomes true. These sources are referred to as “oracles” and are trusted by all parties to the smart contract. For instance, an oracle for the above-mentioned shipment might be a wireless location sensor attached to the shipment that provides global positioning system (GPS) data, or a representational state transfer (REST) interface of a computing device that is tracking the shipment’s location. [046] Since entries on a blockchain containing smart contracts cannot be modified, execution of a smart contract may place further entries on the blockchain to carry out the operations of Y. Alternatively, off-block software tools may be used to check the status of a smart contract and then add entries as necessary for Y. In some cases, these further entries may also be smart contracts with different sets of conditionally–executable logic. Thus, smart contracts can be chained to perform a complex series of operations. [047] Given all of this, current blockchains have a set of generally desirable properties. They are decentralized and thus do not rely upon a single governmental or societal authority for their operation. A blockchain is a typically a public document that can be stored, viewed, and analyzed by anyone. Anyone can become a miner, but a majority control over all mining entities is required to corrupt the blockchain. Any user can create a blockchain “account” by MBHB Docket No. 21-0361-WO3 creating a unique address for themselves, and thus interact with other users by way of the blockchain without needing preapproval. Invalid transactions are automatically discarded by blockchain nodes. As noted, blocks are effectively backwardly-immutable (existing blocks cannot be changed) once they are placed on the blockchain, and become even harder to change over time as subsequent blocks are added. [048] Nonetheless, current blockchain technology also suffers from a number of limitations. First, there is no built-in recourse for theft, fraud, money laundering, or deceptive practices. As a result, blockchains have become host to these and other types of illegal activities, and evidence suggests that criminals are actively attracted to blockchains due to their lack of a central authority. Further, copyrighted or confidential information placed on a blockchain is effectively impossible to remove therefrom. Moreover, there is no way to recover a lost, misplaced, or stolen private key, and the owner of such a private key will not be able to access their blockchain account. These factors ultimately create enough risk for the average user that blockchain-based technology may fail to have utility beyond a few niche areas. [049] For example, compare the situation that confronts a blockchain user who mistakenly sends cryptocurrency to the wrong address (or who is lured by a fraudster to submit such a transaction, or whose private key is stolen by a hacker) versus the same user sending fiat currency through traditional banking channels. For the former, current blockchains afford no mechanism by which the cryptocurrency can be restored to its rightful owner even though the recipient has no legal entitlement to the funds and may very well have broken the law to obtain them. In contrast, the latter enjoys a host of protections, all of which are made possible by the fact that the transaction takes place through a chain of intermediary banks or other entities that are locatable and subject to court enforcement if they breach warranties or fail to alter the transactions to conform to the background law. [050] The example embodiments herein overcome these fundamental drawbacks to blockchain technology without changing the core tenets of its immutable and decentralized nature. In particular, a third party agreed upon ahead of time by blockchain users, or possibly designated by law or regulation, may be permitted to modify certain blockchain transactions after the fact. These modifications are not to existing blocks, but instead allow the third party to add new blocks to a blockchain that enforce and/or compel pre-established agreements, regulations, or judicial decisions, for example. Thus, the effects and/or outcomes of transactions or agreements represented in older blocks can be modified (e.g., corrected, rectified, or reversed) with the addition of newer blocks even if the older blocks themselves are immutable. At the same time, in accordance with example embodiments, procedures by which MBHB Docket No. 21-0361-WO3 the third party may compel an action on the blockchain ensure that the third party’s authority to do so cannot be misused or corrupted. The procedures also operate according to the distributed, decentralized nature of the blockchain, and thereby do not compromise or forfeit the desirable aspects of blockchain-based technology. [051] A first possible embodiment is referred to herein as a “system-level” implementation because it involves changes to the blockchain itself – the data stored in entries and/or the rules carried out by blockchain nodes. This may involve deployment of a new blockchain or a soft or hard fork of an existing blockchain. All users that participate in this blockchain may explicitly (or implicitly through their use of the blockchain) agree that their entries are governed by a set of controls and enforcement of these controls that resides in one or more third parties (e.g., an arbitrator, court, other governmental body, or just another person or entity that is generally trusted). By way of example, the third party could be a judicial court. [052] By way of example, if there is a dispute between one or more users with respect to an entry in which they are involved, any of these users may request a ruling from such a third party. The third party may consider the request in light of the set of controls and/or applicable legal principles. If the third party decides that the entry needs to be modified, it records a representation of such a modification. This representation may be a new entry submitted directly to the blockchain, or a code, token, or other document published in a particular location (e.g., on a web site or a REST interface). The representation may identify the disputed entry, the users involved, the particular location (e.g., in the form of a uniform resource locator (URL)), and a transaction that the third party has determined to be appropriate to rectify or mitigate any harm done to one or more of the users. This representation may be digitally signed by the third party to establish its legitimacy, although a digital signature need not necessarily be required in all implementations and/or usage scenarios. [053] If the representation is not provided directly to the blockchain, an intermediary, off-chain entity controlling one or more server devices may obtain representations from the third party and submit them to the blockchain on behalf of the third party. For example, the intermediary entity may subscribe to notifications of new representations from the third party and/or periodically poll the third party (e.g., scrape its web site or REST interface). [054] Once submitted to blockchain nodes, these nodes may authorize the block and conduct the consensus protocol as described above. Additional authorization steps may be to verify the third party’s digital signature, verify that the representation actually exists at the particular location, and/or that the identified third party indeed has authority to modify entries on this blockchain. The blockchain nodes mine the entry’s block in the usual fashion and the MBHB Docket No. 21-0361-WO3 block gets added to the blockchain if a majority of the nodes agree that the block is valid and the mining was successful. [055] As an example, suppose that an entry on the blockchain involves user A transferring C units of cryptocurrency to user B. User A later finds out that their blockchain account was hacked to make this transaction. User A may contact the third party (e.g., a court), and supply evidence of the hacking (e.g., server logs, witness testimony, expert testimony, etc.). The third party may then rule in favor of user A and publish a representation of its ruling at a particular URL of its web site. [056] The representation may indicate that user B is to be compelled to transfer C units of cryptocurrency to user A on the blockchain (or some amount higher than C if user B was the perpetrator and punitive damages are included). The representation may include the URL, an effective date, and the identity of the third party, and may, if, for example necessary, be digitally signed by the third party. The effective date could be when a block containing the representation is mined, or at some point in the future (e.g., to give user B an opportunity to appeal or dispute the ruling). Alternatively, the effective date could be specified in the blockchain protocols and follow automatically. In some cases, the representation may temporarily freeze or seize the assets of user B on the blockchain so that user B cannot liquidate those assets prior to being compelled to make user A whole. [057] Once published, the intermediary entity may obtain the representation, form it into an entry, and submit it to the blockchain. During the mining process, the blockchain nodes may independently determine that the third party has the authority to compel this action (e.g., this capability of the third party may be built into the blockchain operation), and may also verify that the information stored at the URL matches the representation. As noted, once a majority of blockchain nodes agree that the block is valid and the mining was successful, the block can be added to the blockchain. [058] Advantageously, this mechanism does not require that the blockchain nodes, blockchain users, or third party trust the intermediary entity. Further, the blockchain might grant only certain powers to the third party with respect to the types of disputes that it can resolve, the remedies used, and the users over which it has authority. Moreover, the use of the consensus protocol guarantees that attempts to subvert or use the third party authority in an illegitimate fashion requires control over a majority of the blockchain nodes. As discussed above, the mining process makes doing so computationally infeasible for most actors. [059] While the above example illustrates the case of a transaction, the system-level implementation also provides operations for cases of smart contracts as well. More particularly, MBHB Docket No. 21-0361-WO3 in a scenario involving a smart contract, such as a dispute regarding fulfillment of a obligated action stipulated in the smart contract, the system-level implementation provides procedures for a trusted third party, such as a judicial court, act as an “authorized alias” for invoking the obligated action. As with the transaction case, the procedures ensure that any instance in which this new capability is exercised is secure and safe from hacking, corruptions, or any other form of misuse. [060] A second possible embodiment is referred to as an “entry-level” implementation because it involves coding pre-determined contingency actions into individual blockchain entries on an entry-by-entry basis, and subject to prior approval of only the parties participating in the agreement or transaction recorded in each such respective entry. The entry-level implementation may also be referred to as a “smart-contract” implementation because it may include smart-contract-like features of embedding coded actions in individual blockchain entries, but fortifies the confidence that the coded actions in any given entry will be carried out pursuant to the agreement by vesting authority to enforce the coded actions with a third party trusted by the parties to the agreement in the given entry. Unlike the first embodiment, the entry-level implementation may be able to be deployed using existing blockchains with smart contract support. Nonetheless, this embodiment could be carried out by way of a new blockchain or a fork of an existing blockchain. [061] Here, the entire blockchain need not necessarily be subject to the authority of any third party. Instead, pairs or groups of users may determine multilaterally to be bound by smart contracts that provide two new mechanisms: (i) a list of one or more remedial (or contingent) actions that are to be taken if certain conditions become true, and (ii) a third party who the users have agreed will have authority over the smart contract. Thus, the third party control may be granted on an entry-by-entry basis of the blockchain and not all blockchain entries are subject to such control. The remedial actions could be any type of state change that can be represented on the blockchain. [062] A smart contract may specify one or more conditions and associated remedial actions using the aforementioned “if-X-then-Y” logic. Each condition may be associated with a code, which could be a unique string of binary digits, a QR code, or take some other form. For example, user A and user B may engage in a smart contract in which user A will provide user B with 10 widgets and user B will provide user A with $500 (reflected in a digital asset) in return. These users may agree that the smart contract is further governed by two conditions, each with a remedial action: (i) if the widgets are not all delivered to user B by a particular time and date, then user A will refund $100 to user B, and (ii) if the widgets are not of workmanship MBHB Docket No. 21-0361-WO3 quality as understood in the industry, then user A will refund all $500 to user B. Similarly, the amount of the payout to A may be left as a variable assignable by the third party. In some cases, the users may include a provision in the smart contract such that any other unspecified condition giving rise to a dispute is to be remediated by the third party. [063] This smart contract is submitted to the blockchain, then validated and mined as described above. Suppose that user B contends that the first remedial action has been triggered, and that the users are unable to resolve the dispute on their own. User B may then involve the pre-established third party, and provide evidence of late delivery to the third party (e.g., a bill of lading indicating that the widgets were delivered a week late). The third party may rule in favor of user B and publish a representation of its ruling at a particular URL of its web site. [064] The representation may include the smart contract, the URL, an effective date, the identity of the third party, and the code identifying the condition, and may be digitally signed by the third party. Once published, the intermediary entity may submit an entry to the blockchain for mining as described for the first embodiment. Here, the blockchain nodes may further validate that the code matches one from the smart contract. Once placed on the blockchain this entry serves to “modify” the smart contract – particularly, the presence of the code in an entry signed by the third party causes the remedial condition in the smart contract to be invoked, transferring $100 from user A to user B. [065] This mechanism also does not require that the blockchain nodes, blockchain users, or third parties trust the intermediary entity. Additionally, each of set of users involved in a smart contract can independently select their own third party, further decentralizing authority over different smart contracts. Moreover, the third party’s ruling is unambiguous and not open to interpretation since it invokes logic already present in the smart contract. [066] The description of the entry-level implementation in terms of smart-contract- like operations should not be confused with the smart contract scenario of the system-level implementation. More particularly, each of the system-level implementation and the entry- level implementation provide operations and functionality for both transactions scenarios and smart contract scenarios. [067] A third possible embodiment is a hybrid of the first and second embodiments. Like the first embodiment, the blockchain is structured initially or forked so that all entries are governed by a set of controls and enforcement of these controls lies in one or more third parties. However, the controls also apply to smart contracts on the blockchain even if these smart contracts do not have the pre-established conditions and associated remedial actions of the second embodiment. Nonetheless, like the second embodiment, the third parties can “modify” MBHB Docket No. 21-0361-WO3 smart contracts by adding new entries that trigger transactions or contain smart contracts themselves. Otherwise, operation takes place in a similar fashion to that of the second embodiment. [068] This embodiment avoids the users involved in each smart contract having to identify a third party that they mutually trust to enforce provisions of the contract – the third parties are determined by the blockchain. While this makes entry into smart contracts simpler, it also requires that the users rely on the blockchain’s established third parties. Similarly, this embodiment allows non-parties to the smart contract (such as a government agency or an aggrieved non-party) to “modify” smart contract execution where the designated third party approves. [069] In any of these embodiments, the entry that enforces the third party’s ruling may be placed on a different blockchain from the previous entry that it “modifies.” Thus, the same blockchain need not be used for both types of entry, or a transaction on one blockchain can be used to remedy disputes that arise in connection with transactions on another blockchain. [070] Notably, all three embodiments facilitate an operation that is not currently supported by blockchain-based technology – a third party adding an entry that compels a transaction from a sending user to a receiving user, or that compels a smart contract operation, without requiring that this transaction is digitally signed by the sending user or by the receiving user or of the owner of the smart contract (e.g., in the case of a smart contract or the like). Instead, so long as the entry from the third party can be validated as having been legitimately sourced by, and/or originated from, the third party, it is added to the blockchain. Advantageously, such functionality may elevate and advance blockchain-based technologies to become reliable enough for general use, while retaining all of their desirable decentralized and distributed features. II. Example Computing Devices and Cloud-Based Computing Environments [071] Figure 1 is a simplified block diagram exemplifying a computing device 100, illustrating some of the components that could be included in a computing device arranged to operate in accordance with the embodiments herein. Computing device 100 could be a client device (e.g., a device actively operated by a user), a server device (e.g., a device that provides computational services to client devices), or some other type of computational platform. Some server devices may operate as client devices from time to time in order to perform particular operations, and some client devices may incorporate server features. [072] In this example, computing device 100 includes processor 102, memory 104, network interface 106, and input / output unit 108, all of which may be coupled by system bus MBHB Docket No. 21-0361-WO3 110 or a similar mechanism. In some embodiments, computing device 100 may include other components and/or peripheral devices (e.g., detachable storage, printers, and so on). [073] Processor 102 may be one or more of any type of computer processing element, such as a central processing unit (CPU), a co-processor (e.g., a mathematics, graphics, or encryption co-processor), a digital signal processor (DSP), a network processor, and/or a form of integrated circuit or controller that performs processor operations. In some cases, processor 102 may be one or more single-core processors. In other cases, processor 102 may be one or more multi-core processors with multiple independent processing units. Processor 102 may also include register memory for temporarily storing instructions being executed and related data, as well as cache memory for temporarily storing recently-used instructions and data. [074] Memory 104 may be any form of computer-usable memory, including but not limited to random access memory (RAM), read-only memory (ROM), and non-volatile memory (e.g., flash memory, hard disk drives, solid state drives, compact discs (CDs), digital video discs (DVDs), and/or tape storage). Thus, memory 104 represents both main memory units, as well as long-term storage. Other types of memory may include biological memory. [075] Memory 104 may store program instructions and/or data on which program instructions may operate. By way of example, memory 104 may store these program instructions on a non-transitory, computer-readable medium, such that the instructions are executable by processor 102 to carry out any of the methods, processes, or operations disclosed in this specification or the accompanying drawings. [076] As shown in Figure 1, memory 104 may include firmware 104A, kernel 104B, and/or applications 104C. Firmware 104A may be program code used to boot or otherwise initiate some or all of computing device 100. Kernel 104B may be an operating system, including modules for memory management, scheduling, and management of processes, input / output, and communication. Kernel 104B may also include device drivers that allow the operating system to communicate with the hardware modules (e.g., memory units, networking interfaces, ports, and buses) of computing device 100. Applications 104C may be one or more user-space software programs, such as web browsers or email clients, as well as any software libraries used by these programs. Memory 104 may also store data used by these and other programs and applications. [077] Network interface 106 may take the form of one or more wireline interfaces, such as Ethernet (e.g., Fast Ethernet, Gigabit Ethernet, and so on). Network interface 106 may also support communication over one or more non-Ethernet media, such as coaxial cables or power lines, or over wide-area media, such as Synchronous Optical Networking (SONET) or MBHB Docket No. 21-0361-WO3 digital subscriber line (DSL) technologies. Network interface 106 may additionally take the form of one or more wireless interfaces, such as IEEE 802.11 (Wifi), BLUETOOTH®, global positioning system (GPS), or a wide-area wireless interface. However, other forms of physical layer interfaces and other types of standard or proprietary communication protocols may be used over network interface 106. Furthermore, network interface 106 may comprise multiple physical interfaces. For instance, some embodiments of computing device 100 may include Ethernet, BLUETOOTH®, and Wifi interfaces. [078] Input / output unit 108 may facilitate user and peripheral device interaction with computing device 100. Input / output unit 108 may include one or more types of input devices, such as a keyboard, a mouse, a touch screen, and so on. Similarly, input / output unit 108 may include one or more types of output devices, such as a screen, monitor, printer, and/or one or more light emitting diodes (LEDs). Additionally or alternatively, computing device 100 may communicate with other devices using a universal serial bus (USB) or high-definition multimedia interface (HDMI) port interface, for example. [079] In some embodiments, one or more computing devices like computing device 100 may be deployed to support a blockchain and/or blockchain-related architecture. The exact physical location, connectivity, and configuration of these computing devices may be unknown and/or unimportant to client devices. Accordingly, the computing devices may be referred to as “cloud-based” devices that may be housed at various remote data center locations. [080] Figure 2 depicts a cloud-based server cluster 200 in accordance with example embodiments. In Figure 2, operations of a computing device (e.g., computing device 100) may be distributed between server devices 202, data storage 204, and routers 206, all of which may be connected by local cluster network 208. The number of server devices 202, data storages 204, and routers 206 in server cluster 200 may depend on the computing task(s) and/or applications assigned to server cluster 200. [081] For example, server devices 202 can be configured to perform various computing tasks of computing device 100. Thus, computing tasks can be distributed among one or more of server devices 202. To the extent that these computing tasks can be performed in parallel, such a distribution of tasks may reduce the total time to complete these tasks and return a result. For purposes of simplicity, both server cluster 200 and individual server devices 202 may be referred to as a “server device.” This nomenclature should be understood to imply that one or more distinct server devices, data storage devices, and cluster routers may be involved in server device operations. [082] Data storage 204 may be data storage arrays that include drive array controllers MBHB Docket No. 21-0361-WO3 configured to manage read and write access to groups of hard disk drives and/or solid state drives. The drive array controllers, alone or in conjunction with server devices 202, may also be configured to manage backup or redundant copies of the data stored in data storage 204 to protect against drive failures or other types of failures that prevent one or more of server devices 202 from accessing units of data storage 204. Other types of memory aside from drives may be used. [083] Routers 206 may include networking equipment configured to provide internal and external communications for server cluster 200. For example, routers 206 may include one or more packet-switching and/or routing devices (including switches and/or gateways) configured to provide (i) network communications between server devices 202 and data storage 204 via local cluster network 208, and/or (ii) network communications between server cluster 200 and other devices via communication link 210 to network 212. [084] Additionally, the configuration of routers 206 can be based at least in part on the data communication requirements of server devices 202 and data storage 204, the latency and throughput of the local cluster network 208, the latency, throughput, and cost of communication link 210, and/or other factors that may contribute to the cost, speed, fault- tolerance, resiliency, efficiency, and/or other design goals of the system architecture. [085] As a possible example, data storage 204 may include any form of database, such as a structured query language (SQL) database. Various types of data structures may store the information in such a database, including but not limited to tables, arrays, lists, trees, and tuples. Furthermore, any databases in data storage 204 may be monolithic or distributed across multiple physical devices. [086] Server devices 202 may be configured to transmit data to and receive data from data storage 204. This transmission and retrieval may take the form of SQL queries or other types of database queries, and the output of such queries, respectively. Additional text, images, video, and/or audio may be included as well. Furthermore, server devices 202 may organize the received data into web page or web application representations. Such a representation may take the form of a markup language, such as HTML, the eXtensible Markup Language (XML), or some other standardized or proprietary format. Moreover, server devices 202 may have the capability of executing various types of computerized scripting languages, such as but not limited to Perl, Python, PHP Hypertext Preprocessor (PHP), Active Server Pages (ASP), JAVASCRIPT®, and so on. Computer program code written in these languages may facilitate the providing of web pages to client devices, as well as client device interaction with the web pages. Alternatively or additionally, JAVA® may be used to facilitate generation of web pages MBHB Docket No. 21-0361-WO3 and/or to provide web application functionality. III. Example System-Level Blockchain Embodiment [087] In accordance with example system-level embodiments, a designated, trusted off-chain authority may cause an entry to be made in a blockchain that compels a blockchain- recorded action between two or more parties to a previously-recorded entry on the blockchain. Conventionally, a blockchain entry that specifies an action or arrangement (such as an agreement or contract) between two or more parties requires some cryptographically-verifiable form of the users’ identities, such as a digital signature, to verify the action and validate the new entry. In contrast, the designated, trusted off-chain authority of the system-level implementation is a third party, and not one of the parties to the previous entry. Example system-level embodiments put in place a set of procedures and protocols that safeguard the integrity and validity of any directive to compel a blockchain-recorded action, while at the same time leaving in place and undisturbed the distributed and decentralized operating principles of the blockchain. [088] By way of example, a blockchain-recorded action may be a transaction that specifies a transfer of digital assets from a sending party, or sender, to a receiving party, or receiver. In order for the transaction to be considered valid, and thereby recorded as an entry in a block of the blockchain, a cryptographic key of the sender, or other form proof of ownership of the digital asset, must be involved in the transaction, such that any blockchain node can verify the sender’s right to the digital asset, and thus the sender’s right to transfer the digital asset. In an example use case of the system-level embodiment, the designated, trusted off-chain authority may be asked to reverse the effect of the transaction by causing a remedial action of a transfer of the digital assets back from the receiver to the sender to be entered into the blockchain. [089] Also by way of example, a blockchain-recorded arrangement (such as an agreement or contract) between two or more parties may be a smart contract that embeds one or more contingency action to be carried out if and when the any one or more of the contingency actions is or are invoke, or “called,” by a “designated caller” who is authorized in the smart contract to make the call (i.e., to invoke the contingency action(s)). The smart contact, which is recorded in as an entry in the blockchain, typically includes executable code of each contingency action, as well as the identity of the designated caller (or callers) authorized to call the contingency action(s) and cause the associated code to run. In order for a call to be considered valid, and thereby cause the contingency action to be executed, a request or order to make the call can be made in a submission to the blockchain. The request includes a link to MBHB Docket No. 21-0361-WO3 the smart contract in question, an identification of the contingency action being requested, any parameters that the contingency action may take or require, and a cryptographic key of the caller (or some other form of authentication) that demonstrates the requestor’s authority to make the call. In an example use case of the system-level embodiment, blockchain operation may be configured to recognize the trusted off-chain authority as an “authorized alias” of the designated caller of a contingency action for the purpose of making a call, and thereby cause a contingency action of a smart contract to execute when asked or ordered to do so by the trusted off-chain authority. [090] Assuming the designated, trusted off-chain authority grants the request for an action or an aliased call, a specification of the action or call, authenticated by the trusted off- chain authority, may be electronically published or posted as a “trusted order” to a secure website or other server, and made available to a plurality of independent, trust verifiers. Each of the trust verifiers may then separately and independently retrieve the trusted order, and cryptographically sign it with a respective private cryptographic key, and separately and independently store their respective signed trusted order to a secure database. The plurality of signed trusted orders may then be retrieved from the secure database and provided, together with the specification of the remedial action, to the blockchain. For purposes of discussion, and by way of example, a trusted order may be created or generated as a hash of information that specifies the request embodied in the order. Similarly, the trust verifier function may be incorporated into the node protocols and thus allocated to all or a plurality of the nodes. Likewise, the secure database of signed trust orders can be housed on the blockchain or stored at another location. [091] Each of one or more nodes of the blockchain may then authenticate and decrypt the plurality of signed hashes using respective public keys of the trust verifiers, and verify that all of decrypted hashes are identical. This provides proof of validity of the hash. Each of the one or more nodes may then generate its own local version of the hash using the specification of the remedial action or of the requested aliased call. Upon verifying that the local version of the hash is identical to the retrieved, validated hash, each of the one or more nodes may thus be certain of the integrity and authenticity of the remedial action or aliased call, and proceed to encode it in a valid blockchain action according to usual blockchain procedures. Likewise, when the verification function is incorporated into the node protocols, a node may directly sign the remedial transaction on chain in lieu of signing and storing the trust order. Entry in a blockchain then causes the remedial action or aliased call to be effectively carried out and recorded in the blockchain. MBHB Docket No. 21-0361-WO3 [092] An example implementation of a system-level embodiment, referred to as a system-level implementation, is describe in more detail below. A. Example System Architecture and Technical Description [093] Figure 3 is a simplified block diagram showing an example arrangement of components of a system-level implementation of authenticated off-chain modification of blockchain-based transactions, in accordance with example embodiments. The block diagram of Figure 3 may also be considered as depicting aspects of an operational architecture of the system-level implementation. As shown, example embodiments can include various components, any one or more of which may be implemented as or in one or more computing devices. As such, components depicted in Figure 3 may themselves be or include hardware, software, firmware, or combinations thereof. Some of the components may be identified structurally, such as databases or other forms of data storage and management, and others may be identified in terms of their operation or function. Operational and/or functional components could be implemented as software and/or hardware modules, for example, and may also be referred to as “modules” for the purpose of the present discussion. [094] The example system-level implementation can also include one or more connection mechanisms that connect various components. By way of example, the connection mechanisms are depicted as arrows between components. The direction of an arrow may indicate a direction of information flow, though this interpretation should not be viewed as limiting. In this disclosure, the term “connection mechanism” means a mechanism that connects and facilitates communication between two or more components, devices, systems, or other entities. A connection mechanism can include a relatively simple mechanism, such as a cable or system bus, and/or a relatively complex mechanism, such as a packet-based communication network (e.g., the Internet). In some instances, a connection mechanism can include a non-tangible medium, such as in the case where the connection is at least partially wireless. A connection mechanism may also include programmed communication between software and/or hardware modules or applications, such as application program interfaces (APIs), for example. In this disclosure, a connection can be a direct connection or an indirect connection, the latter being a connection that passes through and/or traverses one or more entities, such as a router, switch, or other network device. Likewise, in this disclosure, communication (e.g., a transmission or receipt of data) can be a direct or indirect communication. [095] By way of example, various components and entities of the example system- level implementation of Figure 3 includes a blockchain network 302 having connected nodes MBHB Docket No. 21-0361-WO3 302-1, 302-2, …, 302-N, where ellipses in the connections to node 302-N indicate possibly additional connected nodes. Other example components and entities of the example system- level implementation include an off-chain request application 304 with a user interface (UI) 304-I/F, an off-chain trusted-authority server 306, a published enforcement actions server 308, an event watcher 310, trust verifier A 312-A, trust verifier B 312-B, trust verifier C 312-C, verified request database 314, request poller 316, off-chain transaction server 318, and trust verifier public keys 320. The ellipses following the trust verifier C 312-C indicates that there could be addition trust verifiers. In an example embodiment, the off-chain request application 304 could be an application program configured for execution on a computing device, such as a PC, laptop, smartphone, or server, among other possible devices. [096] The computational and/or functional roles of the example components and entities may be understood by considering example operational scenarios involving transactions on the blockchain and smart contracts on the blockchain. Both types of scenarios involve similar, and in some respects the same, operations. However, in order to help keep the distinguishing aspects of the two scenarios clear, operational examples of the two scenarios are described separately below. 1. Example system-level scenario for transactions on the blockchain [097] In an example transaction scenario, the parties to a prior transaction may each be blockchain users, and the designated, trusted off-chain authority may be a judicial court represented by individual judges. A sender of prior transaction may claim to have been defrauded by a receiver of the transaction, and request a remedial action of a reverse transfer. The request for may be submitted by the sender or a legal representative of the sender (e.g., a lawyer), and may include specific information and evidence that enables a judge to render a decision to grant the request. Other transaction scenarios are possible as well. [098] More specifically to the example transaction scenario, a sender of a digital asset, such as digital currency, to a receiver may seek to reverse a transaction that transferred the digital asset from the sender’s account to the receiver’s account. For example, the sender may have been tricked or defrauded by the receiver, and thus may look to a judicial court for remediation. The sender or a legal representative of the sender (e.g., a lawyer) may enter a requested-action input 301 at the UI 304-I/F. The requested-action input 301 may include information identifying the sender, the receiver, details about the original transfer from the sender to the receiver, the remedial action being requested, and particular information that provides and/or serves as evidence that the sender was tricked or defrauded into entering in the original transaction. In accordance with example embodiments, the UI 304-I/F may be or MBHB Docket No. 21-0361-WO3 include an online form with drop-down menus or the like, for example, that prompt the sender (or other more generally a user) for specific information required to construct a formal request and provide the court with requisite information for evaluating and granting or denying the request. It should be understood that the specific contents of the request-action input 301 listed above is just one example for purposes of the present illustration, and could include more, less, and/or different information in other usage scenarios and/or implementations. [099] The UI 304-I/F may provide the requested-action input 301 to the off-chain request application 304, which may then process the request for delivery to the judicial court, as well as (possibly conditionally) to the off-chain transaction server 318. Thus, in accordance with example embodiments, the off-chain request application 304 may arrange and/or format all or certain specific items or elements of the requested-action input 301 in a prescribed manner into a construct referred to for convenience herein as a “request specification,” and may then generate a one-way hash of the request specification. For purposes of clarity in the discussion, the one-way hash of the request specification is labeled in all capital letters as the “HASH” to identify it with a specific instance of a hash function, and to distinguish it from other general references to hashes, hash functions, and the like. By way of example the HASH could be encoded as text string or string of characters, such as the following: 0xc8c48f65db62af1cea5e804e99f0139d5173cb0f. Also for purposes of discussion, the HASH and request specification may be considered together as a data entity referred to as HASH plus request specification 303. It should be understood that this grouping is for convenience in the operational description and need not necessarily be implemented in practice (although the grouping is not necessarily excluded either). It should also be understood that other forms of encoding and/or representation of the request specification. Some non-limiting examples of alternatives are discussed below. [100] The HASH plus request specification 303 may then be provided to the off-chain trusted-authority server 306. In an example in which the trusted authority is a judicial court, the off-chain trusted-authority server 306 could be a server associated with the court and configured for receiving requests for compelling actions to be entered in a blockchain. For example, the off-chain trusted-authority server 306 may implement an API configured for receiving appropriately-formatted HASH plus request specification 303 messages or direct input. In other examples, the off-chain trusted-authority server 306 could be a more general server associated with the court and configured for receiving a variety of court/case-related input such as filing pleadings, or it could be a separate server for communicating to a judge. Other arrangements are possible as well. In some examples, the HASH plus request MBHB Docket No. 21-0361-WO3 specification 303 may be provided “manually” to a judicial court, optionally together with supporting evidence for the request, by a legal representative of the sender, for example. [101] After the HASH plus request specification 303 is received by the off-chain trusted-authority server 306, an evaluation may be made as to whether or not to grant the requested action. Again, considering the example in which the trusted authority is a judicial court, the evaluation may be made by a judge or other authorized representative of the court. This may entail the judge evaluating information and evidence, and then rendering a decision. In other examples, evaluation of the information provided in the HASH plus request specification 303 might be able to be carried out autonomously by a computer-based algorithm. How a decision is made, and whether or not it is favorable to the sender (requestor of the action), is not within the scope of example embodiments. However, the further processing of, and procedures relating to, an outcome that is a favorable decision are within the scope of example embodiments. [102] Assuming a decision (e.g., by a person or by an algorithm) is made to grant the request, a HASH plus enforcement specification 305 may be posted or published to the published enforcement actions server 308. In the judicial example, the HASH plus enforcement specification 305 may be a human-readable electronic file that articulates the decision and includes an embedded alpha-numeric representation of the HASH. For example, the HASH plus enforcement specification 305 could be a PDF file digitally signed by the court or uploaded by a court employee with authority to do so. The published enforcement actions server 308 could be a publically-accessible server to which such decisions, among other forms of court business, are posted. In the example of a judicial court, the published enforcement actions server 308 could be a server such as the Public Access to Court Electronic Records (PACER) server and the digital signature could be a clerk’s password for accessing PACER, for example. However, other arrangements are possible as well. [103] Also with a decision to grant the request, the off-chain trusted-authority server 306 may provide or send (e.g., transmit) a confirmation ID 307 to the off-chain request application 304, which may serve to inform the off-chain request application 304 of the decision, and provide it with identifying information for accessing the now-published HASH plus enforcement specification 305 at the published enforcement actions server 308. [104] In accordance with example embodiments, after the off-chain request application 304 receives the confirmation ID 307, it may in turn send the confirmation ID 307 to the event watcher 310. Doing so may alert the event watcher 310 to the availability of the HASH plus enforcement specification 305 at the published enforcement actions server 308. MBHB Docket No. 21-0361-WO3 The off-chain request application 304 may then also provide or send (e.g., transmit) the HASH plus request specification 303 to the off-chain transaction server 318 to make it, too, aware of the availability of the HASH plus enforcement specification 305 at the published enforcement actions server 308 and to initiate creation of a formal request for a requested action to be entered into the blockchain 302. Similarly, a party or an attorney, having received notice of the decision, could prompt the event watcher, or could enter a message on the blockchain with the confirmation ID which transactions are monitored by the event watcher or by the trust verifiers directly. [105] The event watcher 310, having been alerted with the confirmation ID, may then independently notify each of the trust verifiers A, B, and C, 312-A, 312-B, and 312-C, as well as any additional trust verifiers, as indicated in Figure 3. Each trust verifier could be a secure server or other networked secure computing system associated with a respective organization or institution, such as an established bank, brokerage, or network service provider, for example. Although not necessarily shown in the figure, the notification to each of the trust verifiers may also include the confirmation ID or other information enabling access to the HASH plus enforcement specification 305 at the published enforcement actions server 308. [106] Having been notified, each of the trust verifiers A, B, and C, 312-A, 312-B, and 312-C, as well as any additional trust verifiers (which could, in some examples, be one more of the nodes of the blockchain network), may then independently retrieve the HASH from the published enforcement actions server 308 over respective secure links. Each independent retrieval is shown with a label HASH 309 for purposes of the present discussion; again, the ellipses indicate additional retrievals of HASH 309 from additional trust verifiers. The trusted nature of the trust verifiers, together with secure retrieval allows each trust verifier to independently vouch for the authenticity of the retrieved HASH 309. Each trust verifier may do this by encrypting its retrieved HASH 309 with a private cryptographic key that serves as well as an authenticating digital signature. Thus, the trust verifier A 312-A generates the A-Signed(HASH) 311-A; the trust verifier B 312-B generates the B-Signed(HASH) 311-B; and the trust verifier C 312-C generates the C-Signed(HASH) 311-C. Each trust verifier may then store or deposit its respectively signed HASH in the verified request database 314. Additional signed HASHes may be generated and stored in the verified request database 314, as indicated (once more) by the ellipses. Similarly, a node itself may serve as a trust verifier and may be randomly selected to verify a given transaction (for example, the node that mined the last block or a random function based on data contained in the last block). [107] In further accordance with example embodiments, the off-chain transaction MBHB Docket No. 21-0361-WO3 server 318 having received the HASH plus request specification 303, may communicate with the request poller 316 to monitor the verified request database 314 for the presence and/or availability of the signed HASHes from the trust verifiers. This may be done by polling the verified request database 314, or by some other arrangement or protocol. In some examples, the verified request database 314 could itself be a blockchain to which the HASHes are entered in blocks or housed on a blockchain or smart contract, and which may be monitored by the request poller 316 or a similar functional element. Likewise, the request could take the form of a message sent to the blockchain and the poller could be a node that monitors the messages in the blockchain’s message pool. Similarly, the verifiers could directly co-sign the message with their private keys. [108] Upon determining that the HASHes have been added to the verified request database 314 and are available, the request poller 316 may retrieve the A-Signed(HASH) 311- A, the B-Signed(HASH) 311-B, and the C-Signed(HASH) 311-C (as well any additional signed HASHes), and provide them to the off-chain transaction server 318, and indicated in Figure 3. [109] The off-chain transaction server 318 may then generate an action-entry request 313 and send it to the blockchain network 302. In practice, the action-entry request 313 may be delivered or sent to one of the nodes, and from there propagate to some or all of the other nodes. As described below, the action-entry request 313 may include the request specification and all retrieved cryptographically-signed HASHes, in addition to other information pertinent to the action being requested. In particular, each node of the blockchain network 302 that ultimately receives the action-entry request 313 may independently verify each signed HASH using publically-available trust verifier public keys 320 to decrypt each signed HASH. Each such node may then validate each HASH by ensuring that they are all identical. Any discrepant HASH value may indicate a breach or hack somewhere in the sequence so far described, and thereby cause further processing of the request to abort. [110] Each receiving node may further generate its own local version of the HASH by applying a one-way hash function to the request specification in the received action-entry request 313. By checking that its local version of the HASH is identical to the HASH from each of the verifiers, each node may now confirm that the requested action is not only authentic and authorized, but also comports exactly with the action requested and granted by the designated off-chain trusted authority. Each receiving node may then process the request and submit the requested action for entry into the blockchain just as it would for any requested action or transaction submitted by blockchain users. In this way, the request action may be effectively carried out and recorded in the blockchain. Notably, each of the trust verifiers need MBHB Docket No. 21-0361-WO3 not be individually trusted, as at least a majority of the trust verifiers agreeing on the value of HASH provides a collective level of trust across all of the trust verifiers. [111] Figure 4A illustrates a representation of example processing of a system-level action-entry request by a blockchain node for a transaction scenario, in accordance with example embodiments. For this example, the action-entry request is labeled 313-A. By way of example and for purposes of illustration, only one node, node 302-2, is considered. It should be understood that any node receiving the action-entry request 313-A would apply the same rules in processing the request. In the figure, an expanded but still simplified view of the action-entry request 313-A is presented. By way of example, the expanded action-entry request 313-A for the transaction scenario includes a request specification, an off-chain request indicator, an action date, and the signed HASHes A-Signed(HASH) 311-A, B-Signed(HASH) 311-B, the C-Signed(HASH) 311-C (as well any additional signed HASHes, as indicated by the vertical ellipses). It should be understood that there could be additional information included as well, and that the format of the request is conceptually representational, and does not necessarily correspond to that of an actual implementation. [112] Also by way of example, the request specification is shown as including an identity of an asset owner and a description of an action to be applied to the asset(s) of the owner; a receiver may optionally be supplied if the action is a transfer from the owner to the receiver, for example. An example action for a transfer of “X” from the owner to a receiver is illustrated. In this example request specification, it is assumed that the receiver previously transferred some portion of digital assets to the owner, and is now requesting X amount of that transfer to be returned via the requested action. As shown, the off-chain request indicator is set to “true,” signifying that this is an off-chain request that follows rules established in accordance with example embodiments of the system-level implementation. [113] The action date is a parameter that sets a future date/time at which to carry out the requested action. Stipulating a future date for carrying out the action may introduce a further safeguard against possible corruption or misuse of the system-level procedures that produced the action-entry request 313-A and delivered it to the blockchain network 302. For example, if an illegitimate request somehow gets validated and entered into the blockchain, a delay in carrying out the action built into the node protocol provides time to discover and correct the error before the action takes effect. A future date may also enable any party to the requested action to dispute the authorization to implement the action. For example, if an action aims to reverse the effect of a transfer from a receiver to an owner by compelling a future reverse transfer, and the owner wishes to dispute the terms or evidence presented to a court that MBHB Docket No. 21-0361-WO3 rendered the decision to grant the request for the reverse transaction, a built-in delay provides time for the owner to present a case to deny the request. An action date could be specified as an amount of time past a particular date. By way of example, the amount of time could be 72 hours, seven days, or 30 days. Other amounts of time could be used. [114] In some usage scenarios, more than one action date may be specified. For example, an immediate freeze of 72 hours may be applied to a receiver’s account, with a follow- on date of an additional 30 days to fully resolve the correctness and/or legitimacy of an action request. Other timing arrangements are possible as well, and example embodiments are not limited to any particular timing arrangement. Rather, any variety of timing arrangements are within the scope of example embodiments. [115] As indicated in the box labeled “Notes,” the example action included in the request specification is non-limiting. Other non-limiting examples include freezing or unfreezing the owner’s access to X, transferring just a portion of X, and transferring X from the owner to an escrow account. Other actions may be possible as well. As also indicate in the Notes, the action date (or an actions date) could additionally or alternatively be included in the request specification. If additionally included in the request specification, a prescribed rule may be applied to determine which of multiple action dates takes precedence or an unalterable minimum delay may be required in the node protocol. Or multiple action dates could have different effects depending on whether they are included in, or place outside of, the request specification. [116] Example processing of the action-entry request 313-A by the node 302-2 is represented in a flow chart 400-A shown beneath the node 302-2. Upon receiving the action- entry request 313-A, the node 302-2 may not immediately know that the request is for creating a compulsory entry that implements a compulsory action. In accordance with example embodiments, an initial check is made to determine whether the request is an off-chain request or a conventional request. This could be done by checking the off-chain request indicator, for example. If it is false, then the node 302-2 may process the request in accordance with blockchain procedures. For this example, in which the off-chain request indicator is true, the node 302-2 may continue with off-chain request processing. [117] In accordance with example embodiments, for off-chain request processing, the node 302-2 may next determine if the action-entry request 313-A includes a required minimum number of signed HASHes. More particularly, requiring the inclusion of a minimum number of signed HASHes can significantly reduce the probability of a successful hack or corruption of the trust verifiers. For example, in a simple analysis, if the probability of a successful hack MBHB Docket No. 21-0361-WO3 of a trust verifier is 0.01 (1%), for example, then the probability that N of them are hacked is (0.01)^N, which becomes vanishingly small as N increases. The minimum number requirement may therefore be considered one of multiple safeguards against successful hacking or other forms of corruption of the process. As indicated, if the minimum number requirement is not met, the request is considered “bad” and processing may be aborted. Otherwise, processing continues. [118] In further accordance with example embodiments, if the minimum number requirement is satisfied (met), the node 302-2 may then decrypt each signed HASH using the trust verifiers respective public keys 320, which are assumed to be known and/or available to the node 302-2. For the example illustrated in Figures 3 and 4A, the decrypted HASHes are expressed, as shown, as: HASHA = Decrypt[A-Signed(HASH), A-Key] HASHB = Decrypt[B-Signed(HASH), B-Key] HASHC = Decrypt[C-Signed(HASH), C-Key], where A-Key is the public key of trust verifier A 312-A, and likewise for trust verifiers B and C, 312-B and 312-C. The vertical ellipses indicate similar decryptions of additional signed HASHes that may be included in the action-entry request 313-A. [119] In accordance with example embodiments, the node 302-2 may next test to ensure that all of the decrypted HASHes are identical. That is, a check that: HASH_A = HASH_B = HASH_C. Requiring that all the HASHes are identical even further reduces the likelihood of a successful hack or corruption of any of the trust verifiers. This is because a successful hack of the HASH provided by any less than all of the trust verifiers would cause this test to fail, thereby exposing the hack. Only an identical hack of all of the trust verifiers might enable the test to pass. However, as noted, the minimum number requirement helps make this extremely unlikely, if not virtually impossible. As indicated, if the identical HASH test fails, the request is considered “bad” and processing may be aborted. Otherwise, processing continues. [120] In further accordance with example embodiments, if the identical HASH test passes (i.e., if all the decrypted HASHes are identical), the node 302-2 may then take each identical decrypted value to be the true value of the HASH. Thus the node 302-2 may assign the value of HASH_A (or, equivalently, HASH_B or HASH_C, and so on) to a variable called, by way of example, “HASHis.” [121] In accordance with example embodiments, the node 302-2 may next carry out its own computation of the one-way hash function applied to the request specification in the MBHB Docket No. 21-0361-WO3 action-entry request 313-A in order to determine a “local” value of the HASH. This computation is the same one performed by the off-chain request application 304 that initiated the off-chain request, as described above. The computation may utilize any standard and/or known one-way hash function that meets a specified level of complexity. Non-limiting examples of such one-way hash functions include SHA-256, SHA-512, RIPEMD-320, and Whirlpool. As indicated in the flow chart 400-A, the local HASH is referred to as “ThisHASH.” [122] In further accordance with example embodiments, the node 302-2 may then test that ThisHASH is identical to HASHis. That is, the locally-computed HASH is equal to the HASH provided independently by all of the trust verifiers. A successful outcome of this test now validates the request specification, since ThisHASH is verifiably derived from the request specification, and agrees with the HASH from each of the trust verifiers. As indicated, if ThisHASH does not equal HASHis, the request is considered “bad” and processing may be aborted. Otherwise, processing continues. [123] Finally, if ThisHASH is confirmed to be identical to HASHis, the node 302-2 may submit the requested compulsory entry to blockchain, with an effective date for the action as specified in the action-entry request 313-A. [124] While the above description applies to processing of just the one example node 302-2, when the action-entry request 313-A is submitted to the blockchain network 302 by way of one of the nodes, it may be propagated to all or some number of the node. Each node that receives the action-entry request 313-A may process it as described for node 302-2. If a majority of the nodes agree that the requested entry is valid, they may all submit it to a pool of “candidate” entries (e.g., candidate transactions). In conventional processing, the entry may be placed in a prospective new block processed by a miner. Successful mining may then record the action as effectively carried out in a new block of the blockchain. 2. Example system-level scenario for smart contracts on the blockchain [125] In an example smart contract scenario, the parties to a prior smart contract may, again, each be blockchain users, and the designated, trusted off-chain authority may, again, be a judicial court represented by individual judges. As a simple example for the purposes of illustration the parties may be “user A” and “user B,” and the prior smart contract may apply an agreement of user A to supply a service to user B, and an agreement of user B to transfer digital asset money to user A upon delivery of the service. A first contingency action of the smart contract may be a notification that A has completed the service, and a second might be a transfer of funds from B to A. The designated caller of the first contingency action could be A, MBHB Docket No. 21-0361-WO3 and the designated caller of the second contingency action could be B. In an example, after A calls the service-complete action, B may refuse call the payment action, thereby refusing to pay A for the service. User A or a legal representative of user A (e.g., a lawyer) may then request that the court act as an authorized alias for user B to cause the second contingency action to execute. [126] More specifically to the example transaction scenario, the requested-action input 301 may include a link to the smart contract, an identification of the contingency action requested, and an identification of the caller – user B in this example. User A’s identity may also be included, if necessary, as well as any parameters of the contingency action that may be needed. All of the operations of the transaction scenario described above in connection with Figure 3 may then apply as well to the smart contract scenario. Besides the requested-action input 301, the primary differences relate to content (and possibly format) of the request specification, the enforcement action specification, and the contents of the action-entry request 313. [127] In this example smart contract scenario, a court would be asked to issue an order compelling the payment contingency action of the smart contract. Assuming the court agrees, the verification procedures described above for the transaction scenario would be carried out in the same way. The action-entry request 313 generated and sent (input) to the blockchain network 302 would be configured to cause the node(s) of the blockchain 302 to accept or allow the court to act as an authorized alias for calling the payment contingency action. [128] Each node that receives the action-entry request 313 may further generate its own local version of the HASH by applying a one-way hash function to the request specification in the received action-entry request 313. Again, this allows the node to confirm that the requested action is not only authentic and authorized, but also comports exactly with the action requested and granted by the designated off-chain trusted authority. Each node may then process the request and submit the requested action for entry into the blockchain just as it would for any requested action or transaction submitted by blockchain users. In this way, the request action may be effectively carried out and recorded in the blockchain. Again, each of the trust verifiers need not be individually trusted, as at least a majority of the trust verifiers agreeing on the value of HASH provides a collective level of trust across all of the trust verifiers. [129] Figure 4B illustrates a representation of example processing of a system-level action-entry request by a blockchain node for a smart contract scenario, in accordance with example embodiments. For the example smart contract scenario, the action-entry request is labeled 313-B. By way of example and for purposes of illustration, only one node, node 302- MBHB Docket No. 21-0361-WO3 2, is considered. It should be understood that any node receiving the action-entry request 313-B would apply the same rules in processing the request. In the figure, an expanded but still simplified view of the action-entry request 313-B is presented. By way of example, the expanded action-entry request 313-B for the smart contract scenario includes a request specification, an off-chain request indicator, an action date, and the signed HASHes A-Signed(HASH) 311-A, B-Signed(HASH) 311-B, the C-Signed(HASH) 311-C (as well any additional signed HASHes, as indicated by the vertical ellipses). It should be understood that there could be additional information included as well, and that the format of the request is conceptually representational, and does not necessarily correspond to that of an actual implementation. [130] By way of example, the request specification for the example smart contract scenario is shown as including a link to the smart contract, an identification of the contingency action, an identification of the designated caller of the contingency action, and (possibly optionally) parameters of the contingency action. Other information might be included as well, such as identification of one or more other parties to the smart contract, for example. An identity of an asset owner and a description of an action to be applied to the asset(s) of the owner, as well as a receiver, may optionally be supplied if the action is a transfer from the owner to the receiver, for example. As shown, the off-chain request indicator is set to “true,” signifying that this is an off-chain request that follows rules established in accordance with example embodiments of the system-level implementation. [131] The action date is a parameter that sets a future date/time at which to carry out the requested action. In the example smart contract scenario, the requested action is the contingency action. As indicated in the box labeled “Notes,” the action date (or dates of one or more actions) could additionally or alternatively be included in the request specification. If additionally included in the request specification, a prescribed rule may be applied to determine which of multiple action dates takes precedence. Or multiple action dates could have different effects depending on whether they are included in, or place outside of, the request specification. [132] Example processing of the action-entry request 313-B by the node 302-2 is represented in a flow chart 400-B shown beneath the node 302-2. In this example illustration, all of the steps of the flow chart 400-B for the smart contract scenario are the same as those in the flow chart 400-A for the transaction scenario, except for the final step. Specifically, for the smart contract scenario, if ThisHASH is confirmed to be identical to HASHis, the node 302-2 may generate a transaction directing that the contingency action be called by the trusted entity (e.g., the court) acting as an authorized alias for the designated caller. The transaction may be MBHB Docket No. 21-0361-WO3 placed in an entry, which may then be submitted for entry in the blockchain, with an effective date for the action as specified in the action-entry request 313-B. When the entry with the requested transaction is placed in the blockchain (e.g., after mining the block in which the entry is placed), the transaction will run, causing the contingency action to execute. 3. Example variations [133] As discussed above, the system-level implementation is designated as such because it entails modifying the behavior and/or operations of all blockchain nodes to be able to carry out the processing of action-entry requests just described by way of example. In the context of blockchain-based technologies, such modifications may involve adjusting and/or updating rules that all the nodes agree (or are bound) to follow. Accordingly, the introducing of the functions and operations of the system-level implementation to an existing blockchain may require a hard fork of the existing blockchain. The advantages and benefits of enabling a trusted off-chain entity, such as a judicial institution, to cause remedial actions that rectify otherwise irreversible blockchain actions and/or transactions, and to do so securely, reliably, and in a manner highly resistant to hacking or corruption, while also maintaining the decentralized, distributed nature of blockchain technology, may supply more than adequate impetus for such a hard fork to be adopted in favor of the pre-fork blockchain or for the community of miners to adopt the system-level implementation via a soft fork. [134] There may be a number of additional and/or alternative aspects of implementing a system-level embodiments. Some non-limiting examples are next described. [135] Instead of, or in addition to, using a hash of the request specification, the off- chain request application 304 or the off-chain trusted authority server 306 could create a form of encoded “action-payload” that represents the request action in some other way. Non-limiting examples include: a semantic representation of the request specification created by the off- chain trusted authority according to a prescribed formula or application program; and a semantic representation of the request specification generated by an artificial intelligence engine using the request specification as input, for example. More particularly, a semantic representation of the request specification could represent a requested action in a symbolic form that is interpretable by a computing device. By way of example a semantic representation could be encoded as text string or string of characters, such as the following: {"judicialEventId":"0x4176cd550cb468ed686d0462df28b4a162c7a743", "judicialDistrict":"USDC-NDOI","caseNumber":"09-cv-05453", "judicialAction":"freeze", "fromWallet":"0xF0b874003ECF7fb973a71B2Dbd0F656666809F35", MBHB Docket No. 21-0361-WO3 "toWallet":"0x05113E5A814b6162D85322f3D86868e36FB18E34", "coinId":"0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48", "amount":25.0}. In this illustrative example, which assumes the trusted authority is a judicial court, various identifiers that tag parameters of the request specification may be recognizable by node processing. [136] For the sematic representation embodiment, a node may not necessarily need to generate a hash, but instead confirm that it recreated the sematic representation. Once confirmed, the node may interpret the sematic representation to determine what action or actions are being requested, and prepare a transaction accordingly. [137] As another example variation, instead of, or in addition to, the off-chain trust verifiers, each of one or more nodes may incorporate functionality of a trust verifier. In this embodiment, a node may be “self-trusting” such that its own retrieval of the HASH or other form of action-payload from the published enforcement actions server 308 suffices to verify the authenticity of the retrieved data. Consequently, the action-entry request 313 need not necessarily include multiple signed HASHes or other action-payloads. The effect of multiple retrievals from the published enforcement actions server 308 (or the like) by different entities may instead be realized by all or a threshold number of multiple nodes agreeing that their respective retrievals agree. This could follow from “majority” rules of blockchain nodes, for example. [138] In still another example variation, multiple retrievals of the HASH or other action-payload need not necessarily require unanimous agreement. Instead, majority agreement could suffice. Or a threshold number of agreements could be specified. The threshold could correspond to a majority number, or some other specific number. Still further, the particular trust verifiers (or other retrievers, such as nodes) whose retrieved, signed HASHes are compared to test for identical values could be identified specifically or chosen at random. Other arrangements are possible as well. [139] A further example variation may involve implementing the verification actions of the nodes, such as those described by way of example above, in one or more miners of a blockchain network. In this way, even though processing by miners occurs only after the nodes or trust verifiers have verified and validated a requested action for entry in a block, the miner could perform another check before expending time and effort mining. This could serve as an additional safeguard against hacking or corruption. Since such validation/verification may be part of blockchain operation, the system-level operations for transactions and/or smart contract MBHB Docket No. 21-0361-WO3 of example embodiments here would be at least as secure and safe against hacking and corruption such operation, if not more. [140] In still further example variations, authority to compel an entry on the blockchain could be vested in an entity that may initiate procedures for creating an action-entry request 313, or the like, independently of any request made by a blockchain user. Each such request would still be subject to the case-by-case safeguards described above, but could originate directly from the entity. [141] In yet another example variation, node procedures may be modified to autonomously insert a prescribed set of special contingency actions in all smart contracts. These could be actions deemed to be mandatory for all smart contracts, and would provide the ability to subject all smart contract to these contingencies. [142] It will be appreciated that the operations and procedures illustrated in Figures 3, 4A, and 4B may be straightforwardly modified, adapted, and/or extended to correspond to any one or more to the example variations described above. That is, the particular form and contents of Figures 3, 4A, and 4B apply to just one example of operation of a system-level embodiment, and not intended to be limiting with respect to other possible embodiments. B. Example Operations [143] Example operations of a system-level implementation may be illustrated in a message flow diagram. An example of such a diagram is depicted in Figure 5. More particularly, the message flow diagram of Figure 5 depicts example operational sequence timelines of the various components and elements of an example system-level implementation example system shown in Figure 3 in the context of information (e.g., messages) that passes between them. The example message flow diagram may be considered as applying to the system-level implementation examples of both the transaction scenario and the smart contract scenario. The differences, again, being the content and format of: the requested-action input 301, the request specification, the enforcement action specification, and the action-entry request 313. [144] Each component of Figure 3 is represented by a labeled box at the top of Figure 5. A vertical timeline extends below each component, with time increasing downward. The timelines are not intended to convey or represent precise timing, but rather an ordering or sequence of operations. The operations are shown as horizontal directed arrows between pairs of components, and labeled as “S<n>” followed by a description of the information passed between the components (and where <n> is a numeric label). Some operations are shown as self-directed arrows for operations that are carried out at one component, without necessarily MBHB Docket No. 21-0361-WO3 involving passing information to another component. It should be understood that the particular sequences shown in Figure 5 represent one example of operational flow, and should not be taken as limiting or as excluding other sequences or sequence orders that may achieve the same results. [145] An example usage scenario may begin with a user providing input, such as the requested-action input 301 of Figure 3, to the off-chain request application 304 (the UI 304-I/F has been omitted from Figure 5 for the sake of clarity). At step S1, the off-chain request application 304 generates a HASH plus request specification and at step S2 it sends (e.g., transmits or provides) the HASH plus the request specification to the off-chain trusted- authority server 306. Assuming the request is granted (e.g., after evaluation by a judge, for example; this action not explicitly shown in the figure), the off-chain trusted-authority server 306 may at step S3 post or publish a HASH plus enforcement action specification to the published enforcement actions server 308. At step S4, the off-chain trusted-authority server 306 may send or provide a confirmation ID to the off-chain request application 304. [146] The off-chain request application 304 may then send (or provide) the HASH plus request specification to the off-chain transaction server 318 at step S5, and send (or provide) the confirmation ID to the event watcher 310 at step S6. [147] In response to receiving the confirmation ID, the event watcher 310 may separately notify each of the trust verifiers A, B, and C, 312-A, 312-B, and 312-C, in steps S7-A, S7-B, and S7-C, respectively. Each notification may also include (or be) the confirmation ID, or some other identifier suitable for retrieving information from the published enforcement actions server 308. [148] At steps S8-A, S8-B, and S8-C, the trust verifiers A, B, and C separately and independently interact with the published enforcement actions server 308 to separately and independently retrieve the HASH. The double arrows of these interactions represent possible two-way communications involved in this retrieval process. [149] At step S9-A, the trust verifier A signs the HASH with its private key, and at step S10-A, it sends (provides) the A-signed(HASH) to the verified request database 314 for recording or storage. Similarly, at step S9-B, the trust verifier B signs the HASH with its private key, and at step S10-B, it sends (provides) the B-signed(HASH) to the verified request database 314 for recording or storage; and at step S9-C, the trust verifier C signs the HASH with its private key, and at step S10-C, it sends (provides) the C-signed(HASH) to the verified request database 314 for recording or storage. Since the trust verifiers act independently, the sequence ordering shown should be considered just one possible example. In terms of MBHB Docket No. 21-0361-WO3 processing logic, it may only be required that cryptographic signing of the HASH at step S9-<A,B,C> precedes sending the signed HASH to the verified request database 314 at step S10-<A,B,C>. [150] Step S11 represents polling activities of the request poller 316 and its communications with the off-chain transaction server 318. Within this context, the off-chain transaction server 318 may advise the request poller 316 to poll the verified request database 314 for the presence and/or availability of the signed HASHes. Thus, at steps S12 and S13 the request poller 316 may engage in this polling, and eventually determine when the signed HASHes are available for retrieval from the verified request database 314. [151] At step S14, the off-chain transaction server 318 may retrieve the signed HASHes from the verified request database 314 in a “pull” action, for example. It may be noted that this differs somewhat from Figure 3, which suggests that the request poller 316 retrieves the signed HASHes and provides them to the off-chain transaction server 318. This illustrates an example the types of variations in processing that may be used to achieve the same or similar results. [152] At step S15, the off-chain transaction server 318 creates (or generates) the off- chain action-entry request, and at step S16 sends the request to the blockchain network 302. The nodes of the blockchain network 302 may the process the request as described by way of example above in connection with Figures 4A and/or 4B. [153] Although the structure and contents of the off-chain action-entry request, and the modifications to the blockchain rules and node operations incorporate particular novel aspects of example embodiments of the system-level implementation that introduce many of the advantages and benefits of the system-level implementation, the operations described by way of example above in connection with creating an off-chain action-entry request and delivering it to the blockchain network facilitate the security and safeguards at least equal to, if not surpassing, that of conventional blockchain operations. And as noted, this is achieved without sacrificing the distributed and decentralized operational architecture of blockchain- based technologies. [154] As with Figures 3, 4A, and 4B, Figure 5 may be modified, adapted, and/or extended to correspond to any one or more to the example variations described above. That is, the particular form and contents of Figure 5 apply to just one example of operation of a system- level embodiment. But the particular form and contents of Figure 5 are not intended to be limiting with respect to other possible embodiments. IV. Example Entry-Level Implementation MBHB Docket No. 21-0361-WO3 [155] In accordance with example entry-level embodiments, the functionality of contingency actions of blockchain smart contracts may be extended to take direction to execute by off-chain trigger codes supplied by a trusted off-chain authority, and authenticated, verified and stored in a trusted and secure database known to and accessible by nodes of the blockchain. In particular, the capabilities introduced in accordance with example entry-level embodiments do not involve or require modifying node operations at a system level. Rather, the capabilities are introduced by “connecting” certain node operations to trusted database that serves as a sort of repository of trigger codes supplied by the trusted off-chain authority. Example entry-level embodiments put in place a set of procedures and protocols that safeguard the integrity and validity of the trigger codes in the repository, while at the same time leaving node operation unchanged, leaving the distributed and decentralized operating principles of the blockchain in place and undisturbed. [156] As described above, the conventional model of a blockchain transaction involves some form of digital token(s) and an owner of the token(s) that has the authority to use – or “transact with” – the digital token(s). A token may have some inherent value, or be imbued with value, by virtue of its usefulness in transactions. For example, digital tokens may be traded for real goods and services. Non-limiting examples of digital tokens in this context include digital currency and NFTs. While the term “token” accommodates a level of generality in describing transactions on a blockchain, the illustrations herein are described by way of example mostly in terms more specifically suggestive of value. Accordingly, in the remaining discussion the term “asset” is used instead of “token” as a sort of reminder of the usefulness in transactions. It should be understood, however, that there is no loss in generality by this particular choice of terminology. [157] Thus, an owner of an asset or assets that has the authority to use those assets in transactions on the blockchain. That is, these assets – referred to herein as “conventional” (digital) assets – may hold or represent useable value, such as for making purchase, but are not themselves associated with any functionality. In accordance with example embodiments, conventional digital assets may effectively be “converted” in a form that retains its value and adds particular functional capabilities associated with transactions. The converted assets may thus be used in transactions in the same way as their unconverted, conventional instantiations can, but they may also be subject to one or another set of specific actions that are callable only by applying authenticated, validated, and verified trigger codes. Further, all instances of actual trigger codes must be generated on a case-by-case basis by the off-chain trusted authority, and be specific to a particular owner of the converted assets. MBHB Docket No. 21-0361-WO3 [158] The conventional digital assets may be converted by “wrapping” the conventional assets in executable code that implements the desired functionality. Accordingly, the converted digital assets are referred to herein as “wrapper assets,” and the actions that wrapper assets are subject to are referred to herein as “wrapper actions.” Non-limiting examples of wrapper actions include transferring from the owner to a specific receiver (e.g., another user or another account), freezing, and unfreezing. In accordance with example embodiments, an owner of conventional assets may convert any portion of them to wrapper assets, and thereafter use them in transactions in the same way as conventional assets may be used. This, then, corresponds to a transaction scenario of the entry-level embodiment. [159] Similarly to wrapper assets, any contingency action of a smart contract may be constructed to be executed by a specific trigger code. In this case, a trigger code may specify a link to the smart contract, an identification of a particular contingency action, and possible parameters of the contingency action. As in the transaction scenario of the entry-level embodiment, the smart contract scenario of the entry-level embodiment, the trigger codes must be generated on a case-by-case basis by the off-chain trusted authority, but in this case, specific to a particular smart contract. This, then, corresponds to a smart contract of the entry-level embodiment. [160] For both the transaction scenario and the smart contract scenario, implementations of example of the entry-level embodiments involve components and procedures for ensuring safe and secure creation and storage of authenticated, validated, and verified trigger codes. Thus, example embodiments ensure that the flexible and versatile functionality introduce by wrapper digital assets and triggered smart contracts is protected from hacking and/or other forms of misuse or corruption. [161] An example implementation of an entry-level embodiment, referred to as an entry-level implementation, is describe in more detail below A. Example System Architecture and Technical Description [162] Figure 6 is a simplified block diagram showing an example arrangement of components of an entry-level implementation of authenticated off-chain modification of blockchain-based transactions, in accordance with example embodiments. The block diagram of Figure 6 may also be considered as depicting aspects of an operational architecture of the entry-level implementation. As shown, example embodiments can include various components, any one or more of which may be implemented as or in one or more computing devices. As such, components depicted in Figure 6 may themselves be or include hardware, software, firmware, or combinations thereof. Some of the components may be identified structurally, MBHB Docket No. 21-0361-WO3 such as databases or other forms of data storage and management, and others may be identified in terms of their operation or function. Operational and/or functional components could be implemented as software and/or hardware modules, for example, and may also be referred to as “modules” for the purpose of the present discussion. [163] The example entry-level implementation can also include one or more connection mechanisms that connect various components. By way of example, the connection mechanisms are depicted as arrows between components. The direction of an arrow may indicate a direction of information flow, though this interpretation should not be viewed as limiting. In this disclosure, the term “connection mechanism” means a mechanism that connects and facilitates communication between two or more components, devices, systems, or other entities. A connection mechanism can include a relatively simple mechanism, such as a cable or system bus, and/or a relatively complex mechanism, such as a packet-based communication network (e.g., the Internet). In some instances, a connection mechanism can include a non-tangible medium, such as in the case where the connection is at least partially wireless. A connection mechanism may also include programmed communication between software and/or hardware modules or applications, such as application program interfaces (APIs), for example. In this disclosure, a connection can be a direct connection or an indirect connection, the latter being a connection that passes through and/or traverses one or more entities, such as a router, switch, or other network device. Likewise, in this disclosure, communication (e.g., a transmission or receipt of data) can be a direct or indirect communication. [164] By way of example, various components and entities of the example system- level implementation of Figure 3 includes a blockchain network 602 having connected nodes 602-1, 602-2, …, 602-N, where ellipses in the connections to node 602-N indicate possibly additional connected nodes. Other example components and entities of the example system- level implementation include an off-chain request application 604 with a user interface (UI) 604-I/F, an off-chain trusted-authority server 606, a published enforcement actions server 608, an event watcher 610, trust verifier A 612-A, trust verifier B 612-B, trust verifier C 612-C, request verification server 614, verified request database 616, and trust verifier public keys 620. The ellipses following the trust verifier C 612-C indicates that there could be addition trust verifiers. In an example embodiment, the off-chain request application 604 could be an application program configured for execution on a computing device, such as a PC, laptop, smartphone, or server, among other possible devices. [165] The computational and/or functional roles of the example components and MBHB Docket No. 21-0361-WO3 entities may be understood by considering example operational scenarios involving transactions on the blockchain and smart contracts on the blockchain. Both types of scenarios involve similar, and in some respects the same, operations. However, in order to help keep the distinguishing aspects of the two scenarios clear, operational examples of the two scenarios are described separately below. 1. Example entry-level scenario for transactions on the blockchain [166] In the example transaction scenario of the entry-level embodiment, a sender of a wrapper digital asset to a receiver may seek to reverse the effect of a transaction that transferred the wrapper digital asset from the sender’s account to the receiver’s account. As in the system-level illustration, the sender may have been tricked or defrauded by the receiver, and thus may look to a judicial court for remediation. In the example transaction scenario of the entry-level embodiment, a remedial action may be ordered by the generation or creation of a trigger code associated with an appropriate contingency action of the wrapper digital asset. For the current example, the remedial contingency action may be a transfer of the wrapper digital asset from the receiver back to the sender. Thus, a trigger code might specify the receiver as the owner of the wrapper digital asset, a transfer action as the contingency action, and the original sender as the target of the requested transfer. This information may be provided as the requested-action input 601, for example. [167] Thus, the sender or a legal representative of the sender (e.g., a lawyer) may enter a requested-action input 601 at the UI 604-I/F. The requested-action input 601 may include information identifying the sender, the receiver, details about the original transfer from the sender to the receiver, the remedial action being requested, and particular information that provides and/or serves as evidence that the sender was tricked or defrauded into entering in the original transaction. In accordance with example embodiments, the UI 604-I/F may be or include an online form with drop-down menus or the like, for example, that prompt the sender (or other more generally a user) for specific information required to construct a formal request and provide the court with requisite information for evaluating and granting or denying the request. [168] The UI 604-I/F may provide the requested-action input 601 to the off-chain request application 604, which may then process the request for delivery to the judicial court. Thus, in accordance with example embodiments, the off-chain request application 604 may arrange and/or format all or certain specific items or elements of the requested-action input 601 into request specification, and may then generate a one-way hash of the request specification. As in the discussion of the system-level embodiment, the one-way hash of the request MBHB Docket No. 21-0361-WO3 specification is labeled in all capital letters as the HASH. Also for purposes of discussion, the HASH and request specification may be considered together as a data entity referred to as HASH plus request specification 603. It should be understood that this grouping is for convenience in the operational description and need not necessarily be implemented in practice (although the grouping is not necessarily excluded either). [169] The HASH plus request specification 603 may then be provided to the off-chain trusted-authority server 606. In an example in which the trusted authority is a judicial court, the off-chain trusted-authority server 606 could be a server associated with the court and configured for receiving requests for compelling actions to be entered in a blockchain. For example, the off-chain trusted-authority server 606 may implement an API configured for receiving appropriately-formatted HASH plus request specification 603 messages or direct input. In other examples, the off-chain trusted-authority server 606 could be a more general server associated with the court and configured for receiving a variety of court/case-related input, including the off-chain trusted-authority server 606. Other arrangements are possible as well. In some examples, the HASH plus request specification 603 may be provided “manually” to a judicial court, together with supporting evidence for the request, by a legal representative of the sender, for example. [170] After the HASH plus request specification 303 is received by the off-chain trusted-authority server 606, an evaluation may be made as to whether or not to grant the requested action. Again considering the example in which the trusted authority is a judicial court, the evaluation may be made by a judge or other authorized representative of the court. This aspect may be the same as that described for the system-level embodiment. [171] Assuming a decision (e.g., by a person or by an algorithm) is made to grant the request, a HASH plus enforcement specification 605 may be posted or published to the published enforcement actions server 608. In the judicial example, the HASH plus enforcement specification 605 may be a human-readable electronic file that articulates the decision and includes an embedded alpha-numeric representation of the HASH. For example, the HASH plus enforcement specification 605 could be a PDF file digitally signed by the court. The published enforcement actions server 608 could be a publically-accessible server to which such decisions, among other forms of court business, are posted. In the example of a judicial court, the published enforcement actions server 608 could be a server such as the PACER server, for example. However, other arrangements are possible as well. [172] Also with a decision to grant the request, the off-chain trusted-authority server 606 may provide or send (e.g., transmit) a confirmation ID 607 to the off-chain request MBHB Docket No. 21-0361-WO3 application 604, which may serve to inform the off-chain request application 604 of the affirmative decision, and provide it with identifying information for accessing the now- published HASH plus enforcement specification 605 at the published enforcement actions server 608. [173] In accordance with example embodiments, after the off-chain request application 604 receives the confirmation ID 607, it may in turn send the confirmation ID 607 to the event watcher 610. Doing so may alert the event watcher 610 to the availability of the HASH plus enforcement specification 605 at the published enforcement actions server 608. The off-chain request application 604 may then also provide or send (e.g., transmit) the HASH plus request specification 603 to the request verification server 614 to make it, too, aware of the availability of the HASH plus enforcement specification 605 at the published enforcement actions server 608 and to initiate creation of a corresponding trigger code. [174] The event watcher 610, having been alerted with the confirmation ID, may then independently notify each of the trust verifiers A, B, and C, 612-A, 612-B, and 612-C, as well as any additional trust verifiers, as indicated in Figure 6. Each trust verifier could be a secure server or other networked secure computing system associated with a respective organization or institution, such as an established bank, brokerage, or network service provider, for example. Although not necessarily shown in the figure, the notification to each of the trust verifiers may also include the confirmation ID or other information enabling access to the HASH plus enforcement specification 605 at the published enforcement actions server 608. [175] Having been notified, each of the trust verifiers A, B, and C, 612-A, 612-B, and 612-C, as well as any additional trust verifiers, may then independently retrieve the HASH from the published enforcement actions server 608 over respective secure links. Each independent retrieval is shown with a label HASH 609 for purposes of the present discussion; again, the ellipses indicate additional retrievals of HASH 609 from additional trust verifiers. The trusted nature of the trust verifiers, together with secure retrieval allows each trust verify to independently vouch for the authenticity of the retrieved HASH 609. Each trust verifier may do this by encrypting its retrieved HASH 609 with a private cryptographic key that serves as well as an authenticating digital signature. Thus, the trust verifier A 612-A generates the A-Signed(HASH) 611-A; the trust verifier B 612-B generates the B-Signed(HASH) 611-B; and the trust verifier C 612-C generates the C-Signed(HASH) 611-C. Each trust verifier may then provide (e.g., send or transmit) its respectively signed HASH in the request verification server 614. Additional signed HASHes may be provided to the request verification server 614, as indicated (once more) by the ellipses. MBHB Docket No. 21-0361-WO3 [176] The request verification server 614 may then carry out operations to verify and validate the HASH and an authenticated, verified, and validated trigger code, and store it in the verification request database. At this point, the trigger code is available triggering an action associated with the request-action input 601. For this example, the trigger code, as noted above, might specify the receiver as the owner of the wrapper digital asset, a transfer action as the contingency action, and the original sender as the target of the requested transfer. In an example embodiment, a verified HASH 613 may serve as the trigger code, and validation and verification processing by the request verification server 614 may be considered validation and verification of the trigger code. [177] An example subsequent scenario is show in a box enclosing the blockchain network 602 in the upper right of Figure 6. In a first step, labeled “1,” a request action is made by providing node 602-2 with a HASH plus action request 615. The HASH plus action request 615 may alert the node 602-2 to the presence and availability of a trigger code associated with the wrapper assets of the owner as specified in the action request. At a second step, labeled “2,” the node 602-2 may then pull the trigger code, which in this example is the verified HASH 613, from the verified request database. Since the database is trusted by the blockchain network 602, the node 602-2 may execute the contingency action associated with the trigger code. In this example, the action causes a transfer of some amount of wrapper assets from the owner to the original sender in the disputed transaction. Some or all of the node processing may be according to blockchain operation. Thus, the HASH plus action request 615 may propagate to all or some number of the nodes, and all that receive it may engage in the processing just described. [178] Figure 7A illustrates a representation of example processing the request verification server 614 of an entry-level action-entry for a transaction scenario, in accordance with example embodiments. As indicated in Figure 6, and again in Figure 7A, the request verification server 614 also receives the signed HASHes A-Signed(HASH) 611-A, B-Signed(HASH) 611-B, the C-Signed(HASH) 611-C (as well any additional signed HASHes, as indicated by the vertical ellipses). In the figure, an expanded but still simplified view of the HASH plus request specification 603-A is presented. By way of example, the expanded HASH plus request specification 603-A for the transaction scenario includes a request specification, an off-chain request indicator, and an action date. It should be understood that there could be additional information included as well, and that the format of the request is conceptually representational, and does not necessarily correspond to that of an actual implementation. [179] Also by way of example, the request specification is shown as including an MBHB Docket No. 21-0361-WO3 identity of an asset owner and a description of an action to be applied to the asset(s) of the owner; a receiver may optionally be supplied if the action is a transfer from the owner to the receiver, for example. Again, the asset in this case is wrapper asset. An example action for a transfer of “X” from the owner to a receiver is illustrated. In this example request specification, it is assumed that the receiver previously transferred some portion of digital assets to the owner, and is now requesting X amount of that transfer to be returned via the requested action. As shown, the off-chain request indicator is set to “true.” [180] The action date is a parameter that may be used to set a future date/time at which to carry out the requested action. Stipulating a future date for carrying out the action may introduce a further safeguard against possible corruption or misuse of the entry-level procedures that produced the trigger code (verified HASH 613 in this example) and delivered it to the verified request database 614. For example, if an illegitimate request somehow gets validated and entered a trigger code, a built-in delay in carrying out the action provides time to discover and correct the error before the action takes effect. A future date may also enable any party to the requested action to dispute the authorization to implement the action. For example, if an action aims to reverse the effect of a transfer from a receiver to an owner by compelling a future reverse transfer, and the owner wishes to dispute the terms or evidence presented to a court that rendered the decision to grant the request for the reverse transaction, a built-in delay provides time for the owner to present a case to deny the request. Similarly, stipulating a future date may also be a necessary procedure for the trusted authority to act, such as the time to lodge an appeal of a court order. An action date could be specified as an amount of time past a particular date. By way of example, the amount of time could be 72 hours, seven days, or 30 days. Other amounts of time could be used. [181] As indicated in the box labeled “Notes,” the example action included in the request specification is non-limiting. Other non-limiting examples include freezing or unfreezing the owner’s access to X, transferring just a portion of X, and transferring X from the owner to an escrow account. Other actions may be possible as well. As also indicate in the Notes, the action date (or an actions date) could additionally or alternatively be included in the request specification. If additionally included in the request specification, a prescribed rule may be applied to determine which of multiple action dates takes precedence. Or multiple action dates could have different effects depending on whether they are included in, or place outside of, the request specification. [182] Example processing by the request verification server 614 is represented in a flow chart 700 shown beneath the request verification server 614. In accordance with example MBHB Docket No. 21-0361-WO3 embodiments, the request verification server 614 may determine if it has received a required minimum number of signed HASHes. As explained above, requiring the inclusion of a minimum number of signed HASHes can significantly reduce the probability of a successful hack or corruption of the trust verifiers. As indicated, if the minimum number requirement is not met, the request is considered “bad” and processing may be aborted. Otherwise, processing continues. [183] In further accordance with example embodiments, if the minimum number requirement is satisfied (met), the request verification server 614 may then decrypt each signed HASH using the trust verifiers respective public keys 620, which are assumed to be known and/or available to the request verification server 614. For the example illustrated in Figures 6 and 7A, the decrypted HASHes are expressed, as shown, as: HASHA = Decrypt[A-Signed(HASH), A-Key] HASHB = Decrypt[B-Signed(HASH), B-Key] HASHC = Decrypt[C-Signed(HASH), C-Key], where A-Key is the public key of trust verifier A 612-A, and likewise for trust verifiers B and C, 612-B and 612-C. The vertical ellipses indicate similar decryptions of additional signed HASHes that may be carried out. [184] In accordance with example embodiments, the request verification server 614 may next test to ensure that all of the decrypted HASHes are identical. That is, a check that: HASH_A = HASH_B = HASH_C. Requiring that all the HASHes are identical even further reduces the likelihood of a successful hack or corruption of any of the trust verifiers. This is because a successful hack of the HASH provided by any less than all of the trust verifiers would cause this test to fail, thereby exposing the hack. Only an identical hack of all of the trust verifiers might enable the test to pass. However, as noted, the minimum number requirement helps make this extremely unlikely, if not virtually impossible. As indicated, if the identical HASH test fails, the request is considered “bad” and processing may be aborted. Otherwise, processing continues. [185] In further accordance with example embodiments, if the identical HASH test passes (i.e., if all the decrypted HASHes are identical), the request verification server 614 may then take each identical decrypted value to be the true value of the HASH. Thus the request verification server 614 may assign the value of HASH_A (or, equivalently, HASH_B or HASH_C, and so on) to a variable called, by way of example, “HASHis.” [186] In accordance with example embodiments, the request verification server 614 may next carry out its own computation of the one-way hash function applied to the request MBHB Docket No. 21-0361-WO3 specification in HASH plus request specification 603-A in order to determine a “local” value of the HASH. This computation is the same one performed by the off-chain request application 604 that initiated the off-chain request, as described above. The computation may utilize any standard and/or known one-way hash function that meets a specified level of complexity. Non- limiting examples of such one-way hash functions include SHA-256, SHA-512, RIPEMD-320, and Whirlpool. As indicated in the flow chart 700, the local HASH is referred to as “ThisHASH.” [187] In further accordance with example embodiments, the request verification server 614 may then test that ThisHASH is identical to HASHis. That is, the locally-computed HASH is equal to the HASH provided independently by all of the trust verifiers. A successful outcome of this test now validates the request specification, since ThisHASH is verifiably derived from the request specification, and agrees with the HASH from each of the trust verifiers. As indicated, if ThisHASH does not equal HASHis, the request is considered “bad” and processing may be aborted. Otherwise, processing continues. [188] Finally, if ThisHASH is confirmed to be identical to HASHis, the request verification server 614 may store the verified HASH 613 in the verified request database 616. 2. Example entry-level scenario for smart contracts on the blockchain [189] In an example smart contract scenario, a smart contract may be constructed so that the contingency actions may be triggered by trigger codes stored in the verified request database or otherwise provided to the contract. The parties to a prior smart contract may, again, each be blockchain users, and the designated, trusted off-chain authority may, again, be a judicial court represented by individual judges. As in the system-level example, a simple example is considered in which the parties may be “user A” and “user B,” and the prior smart contract may apply an agreement of user A to supply a service to user B, and an agreement of user B to transfer money to user A upon delivery of the service. A first contingency action of the smart contract may be a notification that A has completed the service, and a second might be a transfer of funds from B to A. The designated caller of the first contingency action could be A, and the designated caller of the second contingency action could be B. In an example, after A calls the service-complete action, B may refuse to call the payment action, thereby refusing to pay A for the service. User A or a legal representative of user A (e.g., a lawyer) may then request that the court act as an authorized alias for user B to cause the second contingency action to execute. [190] More specifically to the example transaction scenario, the requested-action input 601 may include a link to the smart contract, and an identification of the contingency MBHB Docket No. 21-0361-WO3 action requested, as well as any parameters of the contingency action that may be needed. All of the operations of the transaction scenario described above in connection with Figure 6 may then apply as well to the smart contract scenario. Besides the requested-action input 601, the primary differences relate to content (and possibly format) of the request specification, the enforcement action specification, and the contents of the greater generality of contingency actions that may be called (for example a variable for the amount or a finding of fact). [191] In this example smart contract scenario, a court would be asked to issue an order compelling the payment contingency action of the smart contract. Assuming the court agrees, the verification procedures described above for the transaction scenario would be carried out in the same way. The verified HASH 613 would be a trigger for the contingency action requested. The example subsequent action shown in the box in the upper right of Figure 6 applies in the smart contract scenario as well. [192] Figure 7B illustrates a representation of example processing the request verification server 614 of an entry-level action-entry for a transaction scenario, in accordance with example embodiments. The discussion of Figure 7A applies identically to Figure 7B, except that the specification request supplies different information. Specifically in the HASH plus specification request 603-B, the request specification for the example smart contract scenario is shown as including a link to the smart contract, and an identification of the contingency action, and (possibly optionally) parameters of the contingency action. Other information might be included as well, such as identification of one or more other parties to the smart contract, for example. An identity of an asset owner and a description of an action to be applied to the asset(s) of the owner, as well as a receiver, may optionally be supplied if the action is a transfer from the owner to the receiver, for example. 3. Example variations [193] There may be a number of additional and/or alternative aspects of implementing entry-level embodiments. Most are the same as in the system-level embodiment, and so are not repeated again here. [194] It will be appreciated that the operations and procedures illustrated in Figures 6, 7A, and 7B may be straightforwardly modified, adapted, and/or extended to correspond to any one or more to the example variations previously described. That is, the particular form and contents of Figures 6, 7A, and 7B apply to just one example of operation of an entry-level embodiment, and not intended to be limiting with respect to other possible embodiments. B. Example Operations [195] Example operations of an entry-level implementation may be illustrated in a MBHB Docket No. 21-0361-WO3 message flow diagram. An example message flow diagram for entry-level implementation is depicted in Figure 8. The format is the same as that described in connection with Figure 5, except that some of the components are different. [196] Each component of Figure 6 is represented by a labeled box at the top of Figure 8. As in Figure 5, a vertical timeline extends below each component, with time increasing downward. The timelines are not intended to convey or represent precise timing, but rather an ordering or sequence of operations. The operations are shown as horizontal directed arrows between pairs of components, and labeled as “T<n>” followed by a description of the information passed between the components (and where <n> is a numeric label). Some operations are shown as self-directed arrows for operations that are carried out at one component, without necessarily involving passing information to another component. It should be understood that the particular sequences shown in Figure 8 represent one example of operational flow, and should not be taken as limiting or as excluding other sequences or sequence orders that may achieve the same results. [197] An example usage scenario may begin with a user providing input, such as the requested-action input 601 of Figure 6, to the off-chain request application 604 (the UI 304-I/F has been omitted from Figure 8 for the sake of clarity). At step T1, the off-chain request application 604 generates a HASH plus request specification and at step T2 it sends (e.g., transmits or provides) the HASH plus the request specification to the off-chain trusted- authority server 606. Assuming the request is granted (e.g., after evaluation by a judge, for example; this action not explicitly shown in the figure), the off-chain trusted-authority server 606 may at step T3 post or publish a HASH plus enforcement action specification to the published enforcement actions server 608. At step T4, the off-chain trusted-authority server 606 may send or provide a confirmation ID to the off-chain request application 604. [198] The off-chain request application 604 may then send (or provide) the HASH plus request specification to the request verification server 614 at step T5, and send (or provide) the confirmation ID to the event watcher 610 at step T6. [199] In response to receiving the confirmation ID, the event watcher 610 may separately notify each of the trust verifiers A, B, and C, 612-A, 612-B, and 612-C, in steps T7-A, T7-B, and T7-C, respectively. Each notification may also include (or be) the confirmation ID, or some other identifier suitable for retrieving information from the published enforcement actions server 608. [200] At steps T8-A, T8-B, and T8-C, the trust verifiers A, B, and C separately and independently interact with the published enforcement actions server 608 to separately and MBHB Docket No. 21-0361-WO3 independently retrieve the HASH. The double arrows of these interactions represent possible two-way communications involved in this retrieval process. [201] At step T9-A, the trust verifier A signs the HASH with its private key, and at step T10-A, it sends (provides) the A-signed(HASH) to the request verification server 614 for recording or storage. Similarly, at step T9-B, the trust verifier B signs the HASH with its private key, and at step T10-B, it sends (provides) the B-signed(HASH) to the request verification server 614 for recording or storage; and at step T9-C, the trust verifier C signs the HASH with its private key, and at step T10-C, it sends (provides) the C-signed(HASH) to the request verification server 614 for recording or storage. Since the trust verifiers act independently, the sequence ordering shown should be considered just one possible example. In terms of processing logic, it may only be required that cryptographic signing of the HASH at step T9-<A,B,C> precedes sending the signed HASH to the request verification server 614 at step T10-<A,B,C>. [202] At step T11 the request verification server 614 may verify the HASH as described above. At step T12, the request verification server 614 may store the verified HASH as the verified trigger code in the verified request database 616. [203] An example subsequent scenario is shown in the dashed box in the lower right of Figure 8. As shown, the input HASH plus requested action is input to the blockchain network 602 as step T13. This could represent a user or a user’s legal representative submitting an entry to the blockchain that alerts it to the presence and availability of a trigger code in the verified request database 616. Then at step T14, one or more nodes of the blockchain pull the trigger code (verified HASH in this example) and act on it as described above. [204] As with Figures 6, 7A, and 7B, Figure 8 may be modified, adapted, and/or extended to correspond to any one or more to the example variations described above. That is, the particular form and contents of Figure 8 apply to just one example of operation of an entry- level embodiment. But the particular form and contents of Figure 8 are not intended to be limiting with respect to other possible embodiments. V. Unbiased Blockchain-Based Transaction Methods and Systems A. Introduction [205] The systems and methodologies described above may be extended and/or adapted to provide and/or support systems and methods for integrating electronic payments for products and services with dispute resolution in a manner that reduces or removes otherwise natural tendencies toward subject biases that can unfairly disadvantage one or more parties to MBHB Docket No. 21-0361-WO3 a transaction with respect to one or more others. The integrated payment and dispute resolution systems and methods, or “PDRSM” as referred to herein, may protect both sides of a transaction from the risk of fraud, breach or substandard performance by a counterparty by enforcing contractual agreements between both sides, and suppressing subjective influences in actions intended for remedying unanticipated contract disputes. [206] More particularly, electronic transactions, such as transactions carried out over the internet, or any transaction not occurring face-to-face, tend to involve an inherent inequality because one or the other side of a transaction must go first: the buyer must pay the seller before the seller ships the item, or the seller (e.g., freelancer) has to provide the work product or service for the client to review before the client pays the fee. The side that goes first is typically at an unfair disadvantage because the counter-party stands to gain by minimizing their own performance once they have received the benefit of first mover’s performance: the seller once paid can deliver a defective product or less than the buyer was promised (or less quickly) while the client who has already received the work product may refuse to pay or attempt to renegotiate. After the fact legal remedies require substantial costs to be borne by the first mover and thus still leave the first mover at a disadvantage in any post breach negotiation. [207] Conventional systems and methods for addressing disputes may involve payment intermediaries, such as credit card networks. However, payment intermediaries offer limited protection for a buyer’s side of a transaction, in the form of customer complaints and chargebacks. But the process is usually cumbersome and often unfair because the intermediary may be biased against chargebacks, lest sellers stop accepting their service as a means of payment. Moreover, there is no protection for a provider who goes first – e.g., a freelancer has no remedy from a credit card company (or other conventional payment intermediary) if the client refuses to pay after the work product has been delivered. Buyer/Customer rating systems used inside of an on-line ecosystem (e.g., online retailers) can disincentivize consistently poor performance by a seller to some extent, but they provide no protection against one-off breaches nor any remedy for an aggrieved buyer. Further, rating systems only work when parties agree to transact through an intermediary website, which limits the type/form of transaction the parties can conduct and adds expense. And rating systems tend to be useless in the mass of transactions that take place outside of an online ecosystem. [208] Example embodiments of PDRSM described below level the playing field by allowing both parties to perform simultaneously though an automated, jointly controlled smart contract. Incorporated dispute resolution methods allow the elimination of intermediaries and trusted third parties from the transaction. The system eliminates the incentive for the receiving MBHB Docket No. 21-0361-WO3 party to act in bad faith once the first mover performs. PDRSM also distributes the costs of resolving any dispute in a manner that incentivizes both sides to minimize such costs and prevents one side from using the threat of such costs to gain an advantage over the other. [209] Some of the aspects of example embodiments of PDRSM operating principles include: x Each party holds a unique cryptographic private key that uniquely guarantees their respective identity. x Either party initiates a request to enter into a digital lock by initiating a request and entering their respective public key as one party to a “digital contract.” x Once the second party enters their respective public key, a smart contract representing a digital relationship is deployed into a public blockchain, for example in a manner similar to the one above. x The smart contract immutably holds the public keys of both parties and limits its data transfer functions as to those two keys. x The smart contract may hold a cryptographic hash of a respective written contract that the parties entered into. The hash is an electronic address location (e.g., link) that holds electronic versions of respective paper contracts (e.g., PDF copies). The electronic address may reference a file in an electronic storage system, such as the “InterPlanetary File System” or IPFS, that cryptographically guarantees that the paper contract is immutable. x Either party can add pre-agreed data into the smart contract such as cryptographic coins, NFT’s, or any other data that may represent anything in the physical world or virtual world that may be requested to be moved from one party to the other party. x The contract will lock the given data for a period of time agreed by both parties or until an immutably observable condition is met. The lock may automatically expire if insufficient data was locked by a given time / condition or other specified digital terms. x Either party may exit the contract and release the lock. For example, either party may give up their claim to the locked data. x Either party may request the release of the lock via conflict resolution facilities provided by, and methodologies prescribed by, the PDRSM. [210] The above aspects are not intended to be limiting, but are rather a selected list of highlights. Further details are described below. MBHB Docket No. 21-0361-WO3 [211] Another form of payment intermediary is an escrow or escrow account. Conventional escrows used in business agreements, such as sales and/or real estate transactions, are controlled by an “escrow agent” that is an institution (e.g., bank) with actions that may be invoked by a person. The escrow agent executes actions according to a contract agreement. Dispute resolution procedures are typically governed by courts, arbitration, and/or rules of the escrow agent, for example. But, as with other forms of payment intermediary, an escrow agent is not immune to acting with bias. Example embodiments of PDRSM involve four high-level features: x Feature 1: Smart-contract-based escrow. This replaces a conventional escrow agent with a smart contract so that escrow actions execute automatically according to the smart contract. The smart contract may be constructed such that it will release the escrowed contents only to one or both of the parties and no other address. x Feature 2: A mechanism to unlock a smart contract governing an escrow in the event of a dispute (or dispute conditions) that is (are) not covered by the smart contract. Rules governing this mechanism ensure only legitimate and authenticated actors may lock, unlock, or alter the execution of the smart contract. x Feature 3: A dispute-resolution mechanism that implements a prescribed procedure driven by subjective inputs, but in a manner designed to iteratively suppress subjectivity and converge toward a shared view, and thereby construct a resolution agreeable to all parties to a contract. In the event that a threshold level of convergence or an agreement is not achieved, a dispute may be submitted to an agreed-upon third party, such as a court, via the blockchain- based smart contract procedures described above. Though not necessarily required, this may be facilitated by establishing the escrow smart contract using the blockchain-based system to begin with. The dispute resolution mechanism when combined with Features 1 and 2 allows for the elimination of intermediaries/escrow agents while still maintaining the features of an escrow. x Feature 4: A scoring mechanism for scoring reputation/reliability of potential parties to an escrow in a manner that maintains anonymity, enabling parties entering into an escrow to remain anonymous while ensuring a verified level of reputation and reliability. [212] Each of the four high-level features may be implemented as one or more MBHB Docket No. 21-0361-WO3 modules and/or subsystems having one or more processors configured for executing computer- readable instructions. As described above, modules and/or subsystems may include one or another form of hardware, software, and/or firmware. B. Example Implementation and Operation [213] In accordance with example embodiments, PDRSM may use smart contracts to eliminate incentives to engage in fraud, bad faith or breach. This is illustrated by considering the following table.

Table 1 [214] In the first scenario the Provider (e.g. a freelancer) goes first and there is no escrow. There is an opportunity for fraud and the Payor stands to gain by withholding payment or renegotiating in bad faith, as by unjustifiably criticizing the Provider’s work product. Thus, the Payor can win – defined as getting the performance for less than the full agreed payment, and the Provider can lose – defined as performing and not receiving the full agreed payment. Note that the same result would obtain in reverse if the Payor paid before receiving the Provider’s performance because the provider could breach, delay, and/or provide poor work product. [215] In the second scenario the Payor places the payment into an escrow smart contract before the Provider commences work. This sort of escrow was proposed by Satoshi Nakamoto, the presumed pseudonymous person or persons who developed blockchain-based crypto currency, “bitcoin.” The smart contract permits the Payor to release the payment to the Provider’s wallet, but this is the only function: the smart contract will not send the payment to any other wallet. With this escrow, neither side can win because the most they will accomplish is to part with their own performance and receive the agreed performance from the other side. But either side still can lose. The Provider can lose if the Payor refuses to release the escrow after receiving the product. Similarly, the Payor can lose if the Provider fails to provide some or all of the promised performance (or of the promised quality) after the Payor funds the escrow because the smart contract will not reverse the payment. The Satoshi escrow payment method has not gained popularity largely because it leaves both sides of the transaction at a disadvantage. MBHB Docket No. 21-0361-WO3 [216] The parties could agree to split the payment (or refund it entirely) if the payor releases it from the smart contract, but this still leaves the Payor at the same disadvantage in Scenario 1 because the counterparty could breach the agreement after the payment is released. Likewise, the smart contract could be programmed to empower either side to release the full or partial escrow to the counterparty, but it would still be the case that one of them must release the payment first and the first mover is at the same disadvantage in Scenario 1. [217] In the third scenario, PDRSM deploys a smart contract over which neither side has control. The Payor escrows payment before the Provider performs, and the smart contract sends the payment to the Provider’s wallet after the passage of a sufficient amount of time for the Payor to have received and inspected the Provider’s product. If the Payor invokes dispute resolution before that time expires, the smart contract will suspend the payment until it receives notice that there is a resolution of the dispute (as described below, this can be by a third-party arbitration, PDRSM’s dispute reduction method, and/or a lawsuit result supplied to the smart contract via the blockchain-based smart contract system described above). The smart contract will then divide the escrow between the Payor’s and Provider’s wallets per the resolution (which could be any split in a range of 100%/0% or vice versa). [218] Note that the parties could alternatively surrender the smart contract key to an intermediary who would then have the control needed to effectuate an arbitration decision or court order. PDRSM eliminates the need for an intermediary because the escrow may ultimately be placed under control of the court via the blockchain-based smart contract procedures described above (either because the dispute is decided by a court in the first instance or because an arbitration award is enforced in court). Eliminating the intermediary reduces transaction costs, avoids the need for trust (an intermediary can steal the funds or conspire with one or the other side), and avoids a central point of failure were the intermediary to be hacked [219] Neither side of the PDRSM transaction can win because the escrow will be paid pursuant to a dispute resolution method (that presumably produces a fair result, as ensured by PDRSM dispute resolution procedures). As a result, there is no incentive for one side to treat the other unfairly and so no disincentive to using the process (unless one or both of the parties had intended to take advantage of the other). Further, the escrowed payment can be secured against malicious actors if the smart contract only permits the escrow to be sent to the Provider’s and Payor’s wallets. This way, a hacker (or an intermediary with a key) cannot divert the funds to his own wallet. [220] In conventional approaches, chargebacks offered by payment intermediaries, such as a credit card network do not solve the problem. First, they can only apply when the MBHB Docket No. 21-0361-WO3 buyer is a first mover and so are useless in contracts where the seller must perform first such as a freelancer providing workproduct for the client’s approval. The process is also controlled by the intermediary and may therefore be unfair – the intermediary may be biased in favor of the sellers so as not to discourage them from accepting Visa payments in the future. Also, the intermediary’s incentive is to spend as little effort as on the decision process. Similarly, the rating systems used in online marketplaces are useless for the mass of transactions that take place outside an online marketplace, and also provide no remedy for the aggrieved buyer following a breach. 1. Escrow smart contract creation module [221] In accordance with example embodiments, a first module may create the escrow smart contract through a series of steps that result in a proposal and acceptance through a user interface (UI) of PDRSM. Although the process can be initiated by either side of the transaction, in a typical usage scenario, a Provider would initiate by proposing terms, and a Payor would accept by escrowing the payment. [222] Using an example of a freelancer to illustrate, the freelancer (Provider) would use the PDRSM UI to specify the client (Provider), which minimally involves supplying means of contact (such as an email address or wallet address). The Provider may also specify terms through the UI including. Non-limiting examples of terms may include the amount and type of coin to be escrowed, the deadline for the Payor to fund the escrow (the acceptance deadline), and a period of time following the acceptance deadline after which the smart contract will send payment to the Provider (this can include a product delivery date and an additional approval period following delivery). Collectively, these may be referred to as the “Specified Terms.” [223] The Provider can also provide additional terms governing the deal (the “Additional Terms”). The Additional Terms can be uploaded to the UI, for example as a PDF file, or typed directly into a UI field designated for Additional Terms. [224] The Provider may then use the UI to agree to terms of use governing PDRSM’s services (“Terms of Use”) which govern dispute resolution processes, among other matters. To the extent any Additional Terms conflict with the Specified Terms or Terms of Use, a prescribed priority scheme may be applied, such as the Terms of Use providing that the Specified Terms and Terms of Use control. [225] At some point the Provider also specifies a blockchain wallet address for receiving payment. This can be done either by inputting the address into the UI or by connecting the wallet to the UI so that the information can be captured. In an example, the Provider may do so prior to the smart contract deployment so that the smart contract can limit MBHB Docket No. 21-0361-WO3 payout to that specified wallet prior to receiving the escrow payment. Doing so protects against hackers because the hacker can only direct escrowed funds to the Provider’s or Payor’s wallet. [226] Upon completion of the forgoing steps (which may include specification of the Payor’s wallet address(es)), the UI will send a message to the Payor (e.g., prospective client) listing the Proposed Terms and providing a copy of Additional Terms, if any. The client can then accept the proposal through the UI by agreeing to the Proposed Terms, the Additional Terms (if any), and the Terms of Use. Optionally, the Payor can specify their wallet address (by data entry in the UI or by connecting the Payor’s wallet to the UI, for example). Alternatively, the Payor wallet can also be specified in the UI at a later time or added automatically when payment is received by the smart contract because the smart contract can read the Payor’s wallet address information from the blockchain ledger. [227] Once the Payor accepts all terms via the UI, PDRSM may generate an escrow smart contract which reflects the Specified Terms. PDRSM then provides notices to both sides that the contract has been formed, gives them the smart contract address, and sends an email or on-chain message memorializing the Specified Terms, the Additional Terms (if any), and the Terms of Use. The email serves as proof of the complete terms of the parties’ agreement. Optionally or alternatively, the complete terms may also be written to an immutable store (e.g., IPFS), rather than cloud storage, and tagged to the smart contract on chain. [228] Pursuant to the Terms of Use, the contract may be automatically revoked if the Payor fails to fund the specified payment by the specified deadline. If the deadline passes without the Payor making complete payment, the smart contract may return all payments to the Payor’s wallet (including partial payments made before the deadline), possibly after deducting one or another form of fee (e.g., for processing, etc.). [229] As an illustrative example, a Provider could use the UI to specify a particular cryptocurrency payment to be funded by November 1, 2022, with a product delivery date of January 1, 2023, and a 15-day acceptance period. A smart contract could be deployed and programmed to accept a payment of the specified cryptocurrency in the specified amount until November 1, 2022. The contract would hold the “coins” of the payment from November 1, 2022 through the delivery date and the acceptance period. It would transfer the coins to the Provider’s specified wallet address at, e.g., 5pm UTC on January 16, 2023 unless the client invokes the dispute resolution system prior to that time. [230] An alternative formulation involves a bi-lateral escrow where the parties are exchanging digital goods. The UI and creation process would run as above. The smart contract would be created with a deadline specified for each side to fund the escrow and it would MBHB Docket No. 21-0361-WO3 automatically send the escrowed item (or coins) to the counterparty after the expiration of time and absent initiation of a dispute by either party. This is discussed below. 2. Contract unlocking module [231] The smart contract may be constituted to unlock following resolution of a dispute and alter the preprogrammed distribution of its contents. This can include, for example, executing the parties/accord reached through the UI, responding to a third-party key controlled by an arbitrator, responding to a court ordered disposition via the above disclosed blockchain based smart-contract procedures, and responding to a court ordered disposition enforcing the decision of an arbitrator via the above disclosed blockchain based smart-contract procedures. 3. Dispute resolution module [232] In accordance with example embodiments, a dispute resolution module may implement a dispute resolution method. The resolution may result, for example, in an input to the escrow smart contract that ends the suspension of payment and causes it to execute accordingly (and which may include an appeal period prior to execution). As another example, the resolution may result, for example, in an input to the escrow smart contract that causes return of some portion of the escrow to the Buyer. Other actions caused by a resolution are possible as well. [233] There may be multiple ways to resolve a dispute that can result in the needed input. Non-limiting examples include: direct submission to an arbitrator who has the key to the contract, direct submission to a court with the judgment requirements supplied to the smart contract via the blockchain-based smart contract procedures described above, and an arbitration award which is submitted to a court for an enforcement order (carried out via the blockchain- based smart contract procedures described above). [234] In accordance with example embodiments, the dispute resolution method may automatically guide parties to a contract through several steps designed to narrow the dispute and suppress biases, the result of which may be an accord that ends the dispute. By narrowing the amount in dispute, the costs of resolving the dispute will be reduced (or eliminated entirely if the parties reach an accord). As an illustrative example, for a situation in which the seller says that he deserves $200k and the buyer says the seller deserves $0, a lawsuit or full-blown, expensive arbitration may be needed for resolution if dispute resolution is not invoked. On the other hand, dispute resolution may guide the parties reduce the dispute to $160k on the high end and $150k on the low end, whereby the dispute is adjusted to about $10k instead of $200k. Having reduced the amount in dispute, summary arbitration then makes economic sense when a full-blown arbitration would otherwise be required. This method thus provides an inexpensive MBHB Docket No. 21-0361-WO3 dispute resolution option, where PDRSM decides the narrowed dispute, as part of the PDRSM escrow service. [235] The narrowing process may involve a series of offers and counteroffers about how to split the escrow between the Payor and Provider wallets. Response time limits may be built in and failure to respond in time may be deemed an acceptance. An initial offer and each successive counteroffer may include a written justification that can be evaluated by the other party, while the total set of all the justifications may become a record that a PDRSM arbitrator may use to evaluate the remaining dispute and issue a decision. [236] In accordance with example embodiments, parties can make the offer/counteroffer via their wallet such that the smart contract is updated directly by the parties as they narrow their dispute. Alternatively, the process may proceed solely through the UI, with PDRSM updating the smart contract through a retained key, for example. If the parties reach an accord the smart contract may execute accordingly. [237] Once PDRSM decides a dispute, the parties can agree to live with PDRSM’s summary decision or reserve the right to go to court or a full-blown arbitration. Accordingly, the blockchain-based smart contract procedures and systems described above can play a role, but court access may not be strictly necessary to this narrowing method nor to its use with the PDRSM escrow contract. [238] In accordance with example embodiment disincentives to appealing may be implemented and/or imposed. For example, a appealer may be required to pay some of the opposing party’s costs up front for the appeal or be responsible for both sides’ costs if the final decision is not more favorable than the PDRSM decision. 4. Smart-contract-based exchange of electronic goods module [239] In accordance with example embodiments, exchange of electronic goods may be supported by a smart contract-based exchange of electronic goods, which may be illustrated by way of an operational example. In one such example, a seller may escrow an NFT and a buyer may escrow a cryptocurrency payment (or each side may escrow a different cryptocurrency to be swapped or a different NFT to be swapped). A smart contract may execute by sending the agreed exchanges to each counterparty’s wallet after a set period of time (e.g., a period for reviewing the provenance of the escrowed NFT on the blockchain) or other triggering condition. By design, the module provides the ability of either party to back out of the transaction by rescinding it before the contract executes. [240] Operation may also handle a usage scenario in which a purchaser prefers to receive the escrowed NFT and receive compensation for any difference between the contracted MBHB Docket No. 21-0361-WO3 for item and the escrowed item. In this usage scenario, the dispute resolution mechanism outlined above may be followed, and the smart contract may execute accordingly. For example, the smart contract may send the NFT to the buyer’s wallet, send 80% of the escrowed payment to the seller’s wallet and return 20% of the escrowed payment back to the buyer’s wallet. It should be understood that other payment proportions or actions may be executed by the smart contract. 5. Reputation scoring module [241] In accordance with example embodiments, a reputation scoring module may provide functions including: x Allowing a buyer to validate integrity of the seller. x Enabling both a buyer and a seller tp remain anonymous. x Enabling a seller to create multiple wallets to interact with buyers while leveraging the same root reputation score. [242] The reputation scoring module and the functions it provides may further support additional features, as described below. [243] Hierarchical score [244] As is known, BIPP44 is a standard that defines a logical hierarchy for deterministic wallets. In accordance with example embodiments, the reputation scoring module may provide a hierarchical score by leveraging the BIP44 algorithm to create a hierarchical view of wallet addresses to rollup reputation/ownership/identity to a single root owner – allowing a single anonymous owner to accumulate reputation across multiple escrow contracts and a new wallet address to be able to leverage another wallets reputation score – and to prove ownership/identity without revealing any information. [245] Reputation options [246] In accordance with example embodiments, the reputation scoring module may provide a variety options for determining reputation scores. Non-limiting examples include scoring in an inclusive range of 1 to 5, up voting, and a ranking algorithm of sorts that blends multiple dimensions. [247] Zero knowledge proof [248] In accordance with example embodiments, the reputation scoring module may reformulate the problem such that a buyer wants to know the trustworthiness of a seller but without the seller revealing their identity nor any information such as the dollar amount or count of payments nor count of escrow contracts nor conflict events. 6. Additional features MBHB Docket No. 21-0361-WO3 [249] Additional contract features [250] The above discussion describes aspects of the various PDRSM components. In particular: (1) an escrow that may be unilateral or bilateral, and (2) one or more a dispute resolution mechanisms. [251] A unilateral escrow smart contract may be used either to provide payment for a performance that takes place outside of the smart contract (e.g., importing conditions for release of the payment), or to make a gift such as a smart contract that pays legatees upon death of the testator. A bilateral escrow may be used for an exchange of digital assets (e.g., NFT for coins, one type of coins for another type, or NFT for NFT). [252] In further accordance with example embodiments, there may be additional and/or alternative implementations as well. In an example, an escrow could be constituted as a multilateral contract (for example single payor, multiple recipients; multiple payers, single recipient; and multiple payers, multiple recipients). In this example, a smart contract might model an ETF by arranging dividend payments from multiple companies and distributing these to multiple investors. Another possibility is a “chain-contract,” whereby a buyer may be another escrow contract. Even further, a seller may itself be another contract – which creates a chain of payments flowing from one contract to the other. [253] In further accordance with example embodiments, an escrow contract may use, follow, and/or be compliant with, an existing standard. By way of example, an escrow contract could follow known ERC20 and NFT standards. In this way an escrow contract may behave as a coin with the total-value equivalent to the total assets being held within the escrow. The escrow may visible as a coin in any ERC20 compatible wallet such as Meta Mask – and may support the standard interfaces such as balance, and transfer. Additionally, the escrow can be imported as an NFT into a wallet and will display the publicly visible terms such as meta- data/tags regarding the contract. [254] In this arrangement, it becomes possible for any digital asset to be deposited into the contract – such as ERC20 and NFT. The escrow contract may be regarded as the owner of the deposited assets. [255] Additional functions of an escrow smart contract x If a payor wallet is specified at the time of contract deployment, then the contract may be able to reject (return) payments from any other wallet. If the payor wallet is not specified at the time of contract deployment, the contract may record and/or lock-in the payor address when it funds the escrow. x Although the payor wallet is normally the refund wallet, a different refund MBHB Docket No. 21-0361-WO3 wallet could be specified at the time of contract creation. x A contract could also be created to allow payor to change the refund wallet after contract creation, and may allow the provider to change the payee wallet after contract creation. This could be accomplished through the UI and/or by using the then currently designated wallet. x A buyer may be enabled to transfer some or all escrowed assets directly to the seller (e.g., release of payment). x A seller may be enabled to transfer some or all escrowed assets directly to the buyer (e.g., return of funds). x While transfer is usually restricted to only Buyer Wallet and Seller Wallet that were provided during contract creation or at funding, a contract may also be created to allow transferee wallets to be specified even after funding. In an example;e, specification could be limited to the funder wallet, the payee wallet, both, or specifiable be a designee wallet or through the UI. x In normal configuration, a buyer cannot transfer assets to themselves and a seller may be restricted from transferring assets to themselves. [256] Complex Counterparties [257] In accordance with example embodiments, a Buyer and/or Seller may be another smart contract that is governing the respective rules for asset deposit and transfer. For example, a DAO contract could be a Buyer. Either a buyer or a seller may itself be another escrow contract. [258] Automatic Transfer [259] In accordance with example embodiments, assets may be transferred to a Seller on regular schedule, such as a pre-agreed interest on regular payment schedule (monthly, quarterly, yearly). A seller can stop automatic transfer at any time. [260] A contract may also have an end date, at which point, the entire balance of escrow is sent to the seller unless the buyer intervenes to raise an objection. A buyer can have multiple options to stop automatic funds, such as stopping all or some of the payments. [261] The contract may also “reverse” after a given time – e.g., a “repo contract.” A contract may pay out a certain percentage on regular basis, but after a given time, the principal value may be returned to the buyer, rather than the seller. A financial example maybe a form of collateral pledging, which itself, maybe repledged. The original buyer may be paying an interest, which flows across the contracts, and at maturity, the escrowed asset may be transferred back to the buyer – or optionally, reverses along a chain of contracts. MBHB Docket No. 21-0361-WO3 [262] Contract terms [263] During contract initiation, a buyer and seller can optionally upload a written document that governs the terms of the given relationship (e.g., Additional Terms). By way of example, this could uploaded as a PDF file, text file, or entered directly into the UI. An additional Terms file may be uploaded into IPFS, for example – with a hash representing the contents of the Additional Terms being generated – and added as input for escrow contract initiation. [264] PDRSM may also provide traditional cloud storage to hold the PDF documents securely, and send copies of the document to each of the parties. The document can be shared as email, IPFS link, web link, or encrypted email, among other non-limiting examples [265] A new or modified PDF file can be uploaded and the hash inside the escrow contract modified, but only if both the buyer and seller approve. [266] The contract hash may be both the location of the document on the IPFS network, for example, and an immutable version guarantee that the terms are unchanged. [267] PDRSM may provide template legal documents that users can use to generate boilerplate PDF or text legal documents. As a possible optional feature, a Buyer/Seller may be able to follow an online workflow for standard contractual agreements to both create the legal paperwork and deploy the escrow contract. Other users may choose to not deploy legal terms, or deploy custom terms directly, while remaining fully anonymous. [268] Metadata [269] An escrow contract may be constructed or configured to be compliant with NFT metadata and the NFT interface signature (e.g., as specified according to the ERC721 standard). [270] Specifically, a contract may provide a base-URI with a reference to an IPFS or s3 metadata file location with the respective meta-data for the given contract. [271] All attributes (which may be optional) once set, may become information that is publicly available if the contract address is known. [272] Additional, possibly optional, information may be included, non-limiting examples of which include: x Name of Contract x Description x Contract Duration x URL to the PDF containing the contract terms x Image of Seller’s Logo MBHB Docket No. 21-0361-WO3 [273] These may (possibly optionally) information may be relevant to contract interpretation (e.g., description), or may be excluded. [274] Notifications [275] In accordance with example embodiments, events associated with an escrow contract may generate notifications to all parties of the contract. The contract itself may be decentralized and the parties to the contract may wish to remain anonymous. Notice can be provided in multiple ways: x PDRSM UI: a user can query the contract for events, and request or configure displaying of events when the buyer/seller wallet is connected; the UI may also have a bulletin board type notice which is available for public review. x Email: PDRSM can provide as a service, and users can select any messaging provider such as Protomail. x On-chain notification: Transaction residue or “dust” – small amounts of cryptocurrency unspent in a transaction associated with a memo field sent to the wallet – may show up in a transaction list of a wallet provider. Simultaneous notification may be provided via the wallet software or free-standing PDRSM app. x Third parties: Other providers may be leveraged. [276] Non-limiting examples of notifications may include: x Contract terms/Acceptance x Escrow funded x Periodic notification of days remaining until payment is released x Disagreement / Conflict x Judicial Event [277] Example conflict resolution operation [278] In a scenario where a buyer disagrees, the buyer can initiate a dispute that pauses any automatic payment and proceeds through a resolution process. In an example, a conflict may have three stages: [279] Stage 1 – Reducing the conflict width between buyer and seller; and providing evidence. [280] A Buyer and Seller may be requested to present their reasonable offers/counteroffers and justification for the offer/evidence backing up the justification – with the view of reducing the width of the conflict – to a mutually agreeable release of funds. A request may cycle back and forth between buyer and seller – with the width reducing with each MBHB Docket No. 21-0361-WO3 cycle – until either party signals an impasse or agreement to the other’s proposal. [281] Non-limiting examples of technical considerations may include: x Communication can be stored as encrypted data in a smart contract itself or as events emitted from the contract, or in the PDRSM cloud database or server. x Data encryption options o Symmetric Cryptography / Shared secret – a buyer/seller may agree to shared secret for communication (this is akin to password; password cannot be recovered nor reset); but a new conversation can be started with a different passcode. This can be thought of as a case number. o Asymmetric Cryptography - Public key encryption to be only read by holder of key (requires wallet interaction for decryption). x Buyer and Seller may remain anonymous, in which case communication/negotiation may be between two wallets. x A Buyer/Seller can be contacted by the notification procedures dwscribed out above. x With encrypted data, post stage 2 – either party may need to provide a means to read the data to the PDRSM arbitrator. [282] Stage 2 – Decision by PDRSM arbitrator; decision professional arbitration association (enforced through PDRSM or judicial court); decision by judicial court (enforced through the blockchain-based smart contract system described above). [283] Stage 3 – appeal of PDRSM decision to professional arbitration association or official court. [284] Example usage scenarios x Freelance contractors x Physical asset delivery x Digital asset swaps x Real estate escrow (which can include a deed NFT) x Direct collateral and re-hypothecated collateral x DAO dispute resolution C. Selected technical notes 1. Usage context [285] Example embodiments may be used to address a specific class of smart contracts that hold data state linked to an Address – Mapping(Address => Data State). The MBHB Docket No. 21-0361-WO3 data state can be anything such as a number denoting an amount held by that Address or more complex data state such as hash of an image or metadata describing more complex state. For example, a common usage of metadata is an NFT – where the metadata has a URL to an image, along with a description of an image, or possible tags associated with the image. The Address is in the family of asymmetric cryptography – where the Address represents some variation of a public key – or hash of the public key – but where the private key is held separately – and can be used to cryptographically show control over this Address. The owner of the private key (a system or a person) is holding a public reference within the smart contract (hash of the public key or some other algorithmic representation of the public key), which in turn has some associated data state there (number or a more complex dataset). [286] An example usage scenario of distributed ledger technology is the ability to represent a single copy of a given state. This single copy of the data state can then be managed atomically – for example, such as moving it from one Address to another Address. Because of the asymmetric cryptography, the address that currently references the state can cryptographically show that they own the private key for a given Address that has that reference and can initiate a transfer from their Address to another Address that they don’t own the key for. In the simplest terms, one system may dictate the transfer of data state from itself to another system, and by doing so, gives up control of the data state to that other system. [287] Example embodiments are directed to the more complex state transfer between Addresses, where there is an atomic swap of data. One address transfers data to the other Address, and in turn, receives some other data back. The actual data may be managed by different smart contracts, each of which has something akin to Mapping linking the owning Address to the data state. An aspect of complexity may then relate how to transfer state across multiple contracts such that state is transferred in an atomic swap, where the parties tangentially retain control of the data state until the moment of transfer, they have full control of the other data state. [288] In accordance with example embodiments, there may be various permutations in the algorithm, such as where either side’s Address is unknown until the moment of data transfer, or more complex models of multi-party transfer or multi-data state transfer swap. Other permutations may relate to where data state is swapped across blockchains not just across smart contracts within the same blockchain. For example, the ability to create an atomic swap between data state on blockchain-based smart contract (e.g., Ethereum) and/or data state on blockchain-based cryptocurrency (e.g., Bitcoin). In further accordance with example embodiments a solution to an atomic swap operation may be provided, where the data swap is MBHB Docket No. 21-0361-WO3 between data state on chain and data state off chain or swapping on chain data state with off- chain state that’s unknown (e.g., inaccessible to verification or inaccessible to proof of transfer for one side of the data swap). 2. Implementation details [289] An example may relate to a data swap with [P1] party to [P2] party with[D1] dataset from [P1] for [D2] dataset managed by [P2]. The parties may be defined as having access to the private keys associated with the given Addresses that are managing the respective data state. The parties themselves may be persons or systems reacting to their own respective events or other contracts, which are in-turn are triggered by a system or a person that has access to the private key associated with the respective asymmetric cryptography Address. [290] [P1] may request a deployment of a new smart contract. The deployment of a new smart contract request can be made in multiple ways but traditionally can be via an API request or via a user interface by a person. At the initiation of the smart contract, [P1] may not know the Address of the [P2]. [291] A first consideration may be how to ensure that the newly deployed smart contract [SC] has no backdoors, no god-mode, and the master key (private key) of the Address that owns the smart contract is thrown away with no traceability nor means of recovery. A basic premise is that the smart contract will act as the intermediary data state manager to the atomic swap between parties, ensuring that each party retains that tangential access to their dataset until the swap completes. In effect, the smart contract Address may act as an intermediary owner of the data until the swap operation finishes. A focus is on the verifiability that the master key is not preserved. The smart contract signing may be done inside a TDX/SGL enclave with remote code attestation. In an example, the actual code may also be made open source, thereby allowing anyone ability to verify. A verification signature may also be included within the smart contract constructor. The smart contract code may also be made public and registered to the smart contract address on-chain. The enclave may create a new random asymmetric key pair, perform the smart contract signing, and trigger the deployment on-chain, and thereafter throw away the private key part of the key pair. [292] As a further aspect, the [SC] may be hardened by locking in the [P1] and [P2] addresses at contract deployment or prior to, or simultaneously with, the transfer of [D1] or [D2], so it may not always be necessary to destroy the master key. The master key may be constituted such that it can only control or modify transfer of [D1] and [D2] to [P1] and [P2] but to no other address. Similarly, the smart contract could be hardened by locking in the [P1] and [P2] addresses at contract deployment or prior to, or simultaneously with, the transfer of MBHB Docket No. 21-0361-WO3 [D1] or [D2], but also including a third-party address [P3] with the authority to control or modify transfer of [D1] and [D2] to [P1] and [P2] but to no other address (including [P3]). [293] Once the smart contract is deployed, [P1] may transfer their dataset to the Address of the smart contract. Ownership of the data may the move from [P1] to the contract [SC]. In the simplest variation, [SC] does not restrict what data can be transferred to the contract nor by who. The only restriction may be that the data transfer is unidirectional: [P1] can transfer any data to [SC], but [SC] follows its own set of rules in what conditions the data maybe returned back to [P1] or transferred to [P2]. The actual transfer of data by [P1] to [SC] may take multiple forms. A more traditional approach would be to direct the respective contracts that are holding the state to move the referenced data from Address of [P1] to Address of [SC]. [SC] only needs to be aware of the address of the smart contract that holds the data, and that it now effectively owns. In one example implementation this may be achieved by creating a transfer function in [SC], which takes the address of the target smart contract. [P1] calls the transfer function on [SC], passing the smart contract address of [D1]. When [P1] makes the call, [SC] records the [D1] contract address and then in turn makes the call to [D1] contract as [P1] to transfer data state [D1] from [P1] to [SC]. [294] In this way, [P1] can transfer any state over any period of time to [SC]. This may be a form of data state accumulation, if the state is not immediately available. A primary consideration may be that state transfer is unidirectional. [SC] will not return the state unless its own internal rules are satisfied. Additionally, what state is held in [SC] may be publicly visible and can be systematically verified on chain by either querying the state of [SC] or querying the state of the smart contract holding [D1]. [295] There may be various ways [P2] may be resolved. [P2] maybe known at the contract initiation, in which case, [P2] Address can be added to the [SC] constructor, thereby creating a hardwired restriction of data swap between [P1] and [P2]. Alternatively, [P2] may be unknown but can be specified prior to or at the time of [D1] or [D2] transfer to [SC] such that the data state can only flow [P1]-[SC][P2] and/or vice versa. [296] [SC] contract may be directly referenced via its on-chain Address for direct programmatic use or via a user-interface, which would create a more human accessible access to the available operations. For human readable access, the [SC] may be converted into a web- URL that references the contract and visually presents the [SC] state and available operations given the type of rules the contract encodes for data swap operation. For example, the url referring to [SC] could be - https://PDRSM.com/username/contract - where the username can be any unique value specified by the owner of [P1], and contract refers to [SC]. MBHB Docket No. 21-0361-WO3 [297] At the time of contract initiation, the initiating party [P1] may define the type of data swap rules that will be embedded in the smart contract. [298] Non-limiting examples of rules applied to parties may include the following. 1. Unknown [P2] where the contract will lock-in the first [P2] that provides the requested [D2] state. At contract initiation [P1] does not know the Address of [P2]. [P2] may be decided algorithmically rather than explicitly set by [P1]. An example algorithm to decide on [P2] might be first-to-arrive with required [D2] state. A more complex algorithm might be a secure multi-party computation (MPC) that attempts to maximize [D2] but where the actual value of each potential [D2] provided by each potential [P2] is kept secret until the moment of swap operation. At the moment of swap, the [P2] and their respective [D2] is chosen that’s the maximum of offered and revealed. 2. Known [P2] that will be locked-in during contract initiation with no means to replace either [P1] or [P2]. 3. Each of [P1], [P2] and [P3] can be limited to a set of addresses meeting verifiable criteria. [299] Non-limiting examples of rules associated with the data state may include the following. 1. Where contract is one time use to swap [D1] for [D2] once. 2. Where contract is a multi-use, with ongoing swap operation of [D1] for [D2]. For every atomic unit of required [D1] and required atomic unit of [D2], the contract will perform the atomic data transfer. 3. [D1] swapped for off-chain verifiable state, where [D2] can be verified via an on-chain Oracle. [D2] may reside on another chain or represent a different off-chain data state- that can be observed via an on-chain Oracle. 4. [D1] swapped for off chain state that’s not verifiable. [P1] can verify that [P2] has provided the state but outside of the ability of [SC] to verify [D2] nor ability for [SC] to manage or transfer [D2]. In this model, [D1] is owned by [SC] and [P2] can verify [D1], but [P1] will need to vouch to [SC] that [D2] was provided. Alternatively, [D2] may be verified by a third party [P3]. a. Note that [D1] and [D2] need not be binary. Partial state may be exchanged for partial state. Thus verification also need not be binary but could be verification of partial state. MBHB Docket No. 21-0361-WO3 5. [D2] is not provided, where the swap is essentially a state transfer but with specific rules around [P2] or conditions allowing the transfer of [D1] such as verification with off-chain data, on-chain data, or time. [300] [SC] may time box certain options to limit the duration of allowed activity or to systematically reverse a partial data swap. Non-limiting example of rules associated with time may include the following ([SC] may track relative time based on the block height and the block time). 1. [P1] has a limit to provide [D2] state, and/or [P2] has a time limit to provide [D2] state. 2. [SC] may lock both [D1] and/or [D2] for an interval of time, to allow either [P1] or [P2] to request a reversal or require sufficient time for data state verification where systematic unchain verification is not applicable. 3. [SC] may lock [D1] state until a verifiable off chain event, at which point, [D1] will be transferred to [P2]. [301] Example embodiments may be further expanded with support to allow changing of [D1] or [D2] definition, where the [SC] allows for it and after the initial rules for [D1] or [D2] are already set. The use of this feature could be more prevalent where the [D2] state is unverifiable and exists off-chain. Example embodiments may provide for modification of the data state characteristics in specific scenarios, non-limiting examples of which include the following. 1. [P1] and [P2] mutually agree to a modified data state. This could be achieved either on-chain or off chain but both sides need to present their proposal (signed by their respective private keys) to [SC], and if the terms match, [SC] will modify internal rules and allow the swap to proceed. 2. [P1] and [P2] are unable to arrive to an agreed modified state for data swap. In this scenario, [SC] can delegate control of the data swap terms to an external agreed trusted authority [P3]. [SC] will delegate to a trusted on- chain oracle. There are various trusted authorities that both [P1] and [P2] accept that could dictate new [D1] and [D2] for the data swap. The trusted authority will need to publish the modified terms into the trusted on-chain oracle, which will then allow [SC] to proceed with the data swap based on the new definition of [D1] and [D2]. Alternatively, [P3] can publish the modified terms directly to [SC] via a [SC] master key or via transaction from [P3] address. 3. Smart contract inputs MBHB Docket No. 21-0361-WO3 [302] In practice, smart contracts require data to execute the logical functions they are programmed to perform. Conventional smart contracts typically can only execute based on objective, electronically-generated inputs, such as a market price feed, a GPS location, or weather instrument data. In accordance with example embodiments, the smart contract implementation of PDRSM includes a procedure and facility that introduces vastly expand utility over conventional smart contracts by enabling subjective inputs in a maximally reliable way. [303] An example may be illustrated by considering a smart contract designed to enforce standards of conduct for a decentralized community or decentralized autonomous organization (DAO). By way of example, one such standard may forbid participants from engaging in hateful speech that harms or endangers a member of the community. In order to enforce such a standard, a smart contract may need be able to determine a proper sanction for an infraction – e.g., a length of suspension based on the nature of the infraction. Generally, this determination is a subjective one, involving conclusions as to whether the speech was hateful, if so, how far it varied from the community standard and how serious of an impact it had on the community or a subset of its members. [304] Conventional solutions for supplying authoritative subjective data to smart contracts require that one or more persons make the subjective determination and then control the smart contract with a key or contract call. The data supplied in this manner leaves a wide field of subjectivity. For example, the data may be generated solely from the opinion of the keyholder. The use of a trusted intermediary with control of the smart contract is also antithetical to the norms of decentralization. [305] [SC] may implement a method that supplies subjective data from multiple agents in an iterative manner that consistently reduces the dimensions of subjectivity, and thus increases the accuracy and reliability of the data input to the smart contract. [306] In an example implementation of the method, each agent may first establish its credentials. The credential could be (i) highly specific, such as a wallet address, (ii) moderately specific, such as an email address on a given domain, or (iii) very general, such as proof of U.S. (or other national) citizenship. In the above example, the credential may be taken as proof of membership in the DAO via a token. Each credentialed agent may submit an initial value which is shared with each other credentialed agent after that agent makes a submission. [307] Each agent may have sole control over that agent’s submission and can modify the value in an iterative fashion upon reviewing the values submitted by the other agents. However, a modification may be constrained to only be made in the direction of the mean (or MBHB Docket No. 21-0361-WO3 some weighted average) of the then-current values submitted by all agents. For example, an attempted alteration of a given agent’s submission may be accepted only so long as it moves directionally towards the mean of all other agents’ submitted values. Each initial submission and each iteration may cause an update to the mean for all agents. The value data can be augmented with other information that the agent choses to share with the cohort. In this way updates may converge to an acceptable mean value, for example. [308] In the above example the iterative revisions could reduce or augment towards a common value, being the length of suspension. [309] The process may run for a determinable period (for example, a set number of days, a set number of iterations, a set number of blocks, a total number of iterations, or a given reduction in the rate of iterations or the augmented/reduced amount). At the end of that process the range of subjectivity may be expected to have been narrowed and the field may then be fixed. If a final value is needed it may be set in a number of ways. For example, it can be calculated via an algorithm (for example the median value of the final submissions, an average of the two values closest to the median, and average of all final values, etc.) or assigned by a designee. [310] The example method may be particularly well-suited for blockchain-based smart contracts, but can be implemented used for other computerized systems, for example, autonomous vehicles. In one example, an autonomous vehicle may have alternatives for emergency handling that would result in different degrees of injury. For example, an emergency condition may involve a person bicycling in the crosswalk and another who is passenger in the back seat of the autonomous vehicle. A vehicle operating choice that may cause injury to one or the other person in this situation is ultimately a moral choice that machines are not suited to make. The inability of autonomous vehicles to make a moral decision is often posited as a reason to restrict their general use. Similarly, a moral choice might be made regarding how to allocate a scholarship fund among multiple deserving applicants, how to administer justice, or any other manner of decision that could be allocated to an artificial intelligence. [311] An electronic system which establishes using subjective inputs as per the method above would result in automated execution that implements a moral choice with the least subjectivity. VI. Example Methods A. Example System-Level Methods [312] Figures 9 and 10 are flow charts illustrating a respective example methods 900 MBHB Docket No. 21-0361-WO3 and 1000 of an example system-level embodiment. The methods illustrated by Figures 9 and 10 may both be carried out by a computing system or computing device configured for operating as a node of a network of nodes operating a blockchain. Non-limiting examples of the computing system computing system or computing device include computing device 100 or server cluster 200, for example. However, the method can be carried out by other types of devices or device subsystems. For example, the process could be carried out by a portable computer, such as a laptop or a tablet device. [313] The embodiments of Figures 9 and 10 may be simplified by the removal of any one or more of the features shown therein. Further, these embodiments may be combined with features, aspects, and/or implementations of any of the previous figures or otherwise described herein. [314] The example methods 900 and 1000 may also be embodied as instructions executable by one or more processors of the one or more server devices of the system or virtual machine or container. For example, the instructions may take the form of software and/or hardware and/or firmware instructions. In an example embodiment, the instructions may be stored on a non-transitory computer readable medium. When executed by one or more processors of the one or more servers, the instructions may cause the one or more servers to carry out various operations of the example method. [315] Example method 900, directed to a transaction scenario of a system-level embodiment, is described first. [316] Block 902 of example method 900 may involve receiving a request message for placing an entry on the blockchain. The request message could be received at the UI 304-I/F, for example. The request message may include (i) a request specification for the entry including an action and an identity of at least one party subject to the action, (ii) an indicator specifying that the entry has been authorized by a trusted entity, and (iii) a plurality of cryptographic verification codes generated by a corresponding plurality of trust verifiers. Each cryptographic verification code may include an encoded action-payload supplied by the trusted entity and cryptographically signed by a respective one of the trust verifiers. In some examples, an actual identity of the at least one party may not be known. Instead, some other form of link to the party may be available, such as an address, or a cryptographic key, for example. These may be used in place of an actual identity. [317] Block 904 of example method 900 may involve applying a public encryption key of each respective trust verifier to the corresponding cryptographic verification code to decrypt a corresponding encoded action-payload. MBHB Docket No. 21-0361-WO3 [318] Block 906 of example method 900 may involve making a first verification that at least a threshold number of the decrypted corresponding encoded action-payloads are identical. [319] Finally, block 908 of example method 900 may involve submitting the entry for block processing to be added to the blockchain in response to making at least the first verification. [320] In accordance with example embodiments, example method 900 may further involve applying a payload-encoder function to the request specification to derive a local version of the encoded action-payload, and then making a second verification that the local version of the encoded action-payload is identical to that of each of the at least the threshold number of decrypted corresponding encoded action-payloads that are identical. In this arrangement, submitting the entry for block processing may entail submitting the entry for block processing to be added to the blockchain in response to making both the first verification and the second verification. [321] In accordance with example embodiments, the threshold number may be the total number of the plurality, a majority of the total number of the plurality, or an integer number closest to a specified fraction of the total number of the plurality. [322] In accordance with example embodiments, making the first verification that at least the threshold number of the decrypted corresponding encoded action-payloads are identical may entail making a selection of a predetermined number of the decrypted corresponding encoded action-payloads to compare. Further, the threshold number may equal predetermined number. With this arrangement, the selection may be one of random, and/or based on prescribed identities of particular ones of the corresponding plurality of trust verifiers. [323] In accordance with example embodiments, the encoded action-payload supplied by the trusted entity may be a hash, and the payload-encoder function may be a hash function. In this arrangement, each corresponding encoded action-payload may be a corresponding hash value, and the local version of the encoded action-payload may be a local hash value. Further in this arrangement, making the first verification that the at least the threshold number of the decrypted corresponding encoded action-payloads are identical may involve verifying that at least the threshold number of the corresponding hash values are identical, and making the second verification that the local version of the encoded action-payload is identical to that of each of the at least the threshold number of decrypted corresponding encoded action-payloads that are identical may involve verifying that the local hash value is identical to that of the at least the threshold number of the corresponding hash values that are identical. MBHB Docket No. 21-0361-WO3 [324] In accordance with example embodiments, the encoded action-payload supplied by the trusted entity may include a semantic representation of the request specification created by the trusted entity and interpretable by a computing device. [325] In accordance with example embodiments, the encoded action-payload supplied by the trusted entity may include a semantic representation of the request specification generated by an artificial intelligence engine based on a natural-language description of the request specification, and interpretable by a computing device. [326] In accordance with example embodiments, submitting the entry for block processing to be added to the blockchain may involve including the entry in a candidate block that is input to a mining procedure. [327] In accordance with example embodiments, the at least one party may be associated with particular digital assets recorded in the blockchain. The action may be: transferring a specified amount of the particular digital assets from the at least one party to another party associated with the blockchain; freezing a specified amount of the particular digital assets; unfreezing a specified amount of the particular digital assets; transferring a specified amount of the particular digital assets from the at least one party to an escrow account associated with the blockchain; and/or transferring a specified amount of the particular digital assets from the at least one party to particular account associated with the blockchain. [328] In accordance with example embodiments, execution of the action may be delayed by a specified amount time from a specified date and time, or scheduled for a particular date and time. [329] Example method 1000, directed to a smart contract scenario of a system-level embodiment, is described next. [330] Block 1002 of example method 1000 may involve receiving a request message for placing an entry on the blockchain configured for invoking a contingency action of a smart contract previously entered on the blockchain. The request message could be received at the UI 304-I/F, for example. The request message may include (i) a request specification including a link to the smart contract, an identifier of the contingency action, and an identity of a designated action-caller authorized to invoke the contingency action, (ii) an indicator specifying that the entry has been authorized by a trusted entity, and (iii) a plurality of cryptographic verification codes generated by a corresponding plurality of trust verifiers. Each cryptographic verification code may include an encoded action-payload supplied by the trusted entity and cryptographically signed by a respective one of the trust verifiers. Non-limiting examples to a link to a smart contract include an address (e.g., a URL) to location, a pointer to MBHB Docket No. 21-0361-WO3 a database entry, and an address on a blockchain. In some examples, an actual identity of the designated action-caller may not be known. Instead, some other form of link to the designated action-caller may be available, such as an address, or a cryptographic key, for example. These may be used in place of an actual identity. In some examples, the identity of the designated action-caller may be omitted. [331] Block 1004 of example method 1000 may involve applying a public encryption key of each respective trust verifier to the corresponding cryptographic verification code to decrypt a corresponding encoded action-payload. [332] Block 1006 of example method 1000 may involve making a first verification that at least a threshold number of the decrypted corresponding encoded action-payloads are identical. [333] Block 1008 of example method 1000 may involve generating a transaction specification and placing it in the entry in response to making at least the first verification. The generated transaction specification may then include a directive to execute the identified contingency action as authorized by the trusted entity acting an authenticated alias of the designated action-caller. [334] Finally, block 1010 of example method 1000 may involve submitting the entry for block processing to be added to the blockchain. [335] In accordance with example embodiments, example method 1000 may further involve applying a payload-encoder function to the request specification to derive a local version of the encoded action-payload, and then making a second verification that the local version of the encoded action-payload is identical to that of each of the at least the threshold number of decrypted corresponding encoded action-payloads that are identical. In this arrangement, generating the transaction specification and placing it in the entry may entail generating the transaction specification and placing it in the entry in response to making both the first verification and the second verification. [336] In accordance with example embodiments, example method 1000 may further involve causing the identified contingency action of the smart contract previously entered on the blockchain to execute. [337] In accordance with example embodiments, the request specification may further include one or more parameters of the identified contingency action. [338] In accordance with example embodiments, the threshold number may be the total number of the plurality, a majority of the total number of the plurality, or an integer number closest to a specified fraction of the total number of the plurality. MBHB Docket No. 21-0361-WO3 [339] In accordance with example embodiments, making the first verification that at least the threshold number of the decrypted corresponding encoded action-payloads are identical may entail making a selection of a predetermined number of the decrypted corresponding encoded action-payloads to compare. Further, the threshold number may equal predetermined number. With this arrangement, the selection may be one of random, and/or based on prescribed identities of particular ones of the corresponding plurality of trust verifiers. [340] In accordance with example embodiments, the encoded action-payload supplied by the trusted entity may be a hash, and the payload-encoder function may be a hash function. In this arrangement, each corresponding encoded action-payload may be a corresponding hash value, and the local version of the encoded action-payload may be a local hash value. Further in this arrangement, making the first verification that the at least the threshold number of the decrypted corresponding encoded action-payloads are identical may involve verifying that at least the threshold number of the corresponding hash values are identical, and making the second verification that the local version of the encoded action-payload is identical to that of each of the at least the threshold number of decrypted corresponding encoded action-payloads that are identical may involve verifying that the local hash value is identical to that of the at least the threshold number of the corresponding hash values that are identical. [341] In accordance with example embodiments, the encoded action-payload supplied by the trusted entity may include a semantic representation of the request specification created by the trusted entity and interpretable by a computing device. [342] In accordance with example embodiments, the encoded action-payload supplied by the trusted entity may include a semantic representation of the request specification generated by an artificial intelligence engine based on a natural-language description of the request specification, and interpretable by a computing device. [343] In accordance with example embodiments, submitting the entry for block processing to be added to the blockchain may involve including the entry in a candidate block that is input to a mining procedure. [344] In accordance with example embodiments, causing the identified contingency action of the smart contract previously entered on the blockchain to execute may entail causing execution to be delayed by a specified amount time from a specified date and time, or scheduled for a particular date and time. B. Example Entry-Level Methods [345] Figures 11 and 12 are flow charts illustrating respective example embodiments of methods 1100 and 1200 of example entry-level embodiments. The methods illustrated by MBHB Docket No. 21-0361-WO3 Figures 11 and 12 may both be carried out by a computing system or computing device configured for operating as database server for verifying and storing encoded action-triggers for digital assets entered on a blockchain network. Non-limiting examples of the computing system computing system or computing device include computing device 100 or server cluster 200, for example. However, the method can be carried out by other types of devices or device subsystems. For example, the process could be carried out by a portable computer, such as a laptop or a tablet device. [346] The embodiments of Figures 11 and 12 may be simplified by the removal of any one or more of the features shown therein. Further, these embodiments may be combined with features, aspects, and/or implementations of any of the previous figures or otherwise described herein. [347] The example methods 1100 and 1200 may also be embodied as instructions executable by one or more processors of the one or more server devices of the system or virtual machine or container. For example, the instructions may take the form of software and/or hardware and/or firmware instructions. In an example embodiment, the instructions may be stored on a non-transitory computer readable medium. When executed by one or more processors of the one or more servers, the instructions may cause the one or more servers to carry out various operations of the example method. [348] Example method 1100, directed to a transaction scenario of an entry-level embodiment, is described first. [349] Block 1102 of example method 1100 may involve receiving a request message for verifying and storing a verified action-trigger for a digital transaction entered on the blockchain network. The request may include the request message comprises a request specification including an action and an identity of at least one party associated with a digital asset subject to the action. Non-limiting examples to a link to a smart contract include an address (e.g., a URL) to location, a pointer to a database entry, and an address on a blockchain. In some examples, an actual identity of the at least one party may not be known. Instead, some other form of link to the party may be available, such as an address, or a cryptographic key, for example. These may be used in place of an actual identity. [350] Block 1104 of example method 1100 may involve receiving a plurality of cryptographic verification codes independently generated by a corresponding plurality of trust verifiers. Each cryptographic verification code may include a trigger code sourced from a trusted entity and cryptographically signed by a respective one of the trust verifiers. [351] Block 1106 of example method 1100 may involve applying a public encryption MBHB Docket No. 21-0361-WO3 key of each respective trust verifier to the corresponding cryptographic verification code to decrypt a corresponding trigger code. [352] Block 1108 of example method 1100 may involve making a first verification that at least a threshold number of the decrypted corresponding trigger codes are identical. [353] Block 1110 of example method 1100 may involve applying an encoder function to the request specification to derive a local version of the trigger code associated with the action. [354] Block 1112 of example method 1100 may involve making a second verification that the local version of the trigger code is identical to that of each of the at least the threshold number of decrypted corresponding trigger codes that are identical. [355] Finally, block 1114 of example method 1100 may involve storing the trigger code as the verified action-trigger in a database associated with the computing system. [356] In accordance with example embodiments, the threshold number may be the total number of the plurality, a majority of the total number of the plurality, or an integer number closest to a specified fraction of the total number of the plurality. [357] In accordance with example embodiments, making the first verification that at least the threshold number of the decrypted corresponding encoded action-payloads are identical may entail making a selection of a predetermined number of the decrypted corresponding encoded action-payloads to compare. Further, the threshold number may equal predetermined number. With this arrangement, the selection may be one of random, and/or based on prescribed identities of particular ones of the corresponding plurality of trust verifiers. [358] In accordance with example embodiments, the trigger code supplied by the trusted entity may be a hash, and the encoder function may be a hash function. In this arrangement, each corresponding trigger code may be a corresponding hash value, and the local version of the trigger code may be a local hash value. Further in this arrangement, making the first verification that the at least the threshold number of the decrypted corresponding trigger codes are identical may involve verifying that at least the threshold number of the corresponding hash values are identical, and making the second verification that the local version of the trigger code is identical to that of each of the at least the threshold number of decrypted corresponding trigger codes that are identical may involve verifying that the local hash value is identical to that of the at least the threshold number of the corresponding hash values that are identical. [359] In accordance with example embodiments, the trigger code supplied by the trusted entity may include a semantic representation of the request specification created by the MBHB Docket No. 21-0361-WO3 trusted entity and interpretable by a computing device. [360] In accordance with example embodiments, the trigger code supplied by the trusted entity may include a semantic representation of the request specification generated by an artificial intelligence engine based on a natural-language description of the request specification, and interpretable by a computing device. [361] In accordance with example embodiments, the at least one party may be associated with particular digital assets recorded in the blockchain. The action may be: transferring a specified amount of the digital asset from the at least one party to another party associated with the blockchain; freezing a specified amount of the digital asset; unfreezing a specified amount of the digital asset; transferring a specified amount of the digital asset from the at least one party to an escrow account associated with the blockchain; and/or transferring a specified amount of the digital asset from the at least one party to particular account associated with the blockchain. [362] In accordance with example embodiments, execution of the action may be delayed by a specified amount time from a specified date and time, or scheduled for a particular date and time. [363] In accordance with example embodiments, example method 1100 may further involve sending a copy of the verified trigger code to the node device in response to receiving a request from a node device of the blockchain network. [364] Example method 1200, directed to a smart contract scenario of an entry-level embodiment, is described next. [365] Block 1202 of example method 1200 may involve receiving a request message for verifying and storing a verified action-trigger for a smart contract entered on a blockchain network. The request message may include a request specification including a link to the smart contract and an identifier of the contingency action of the smart contract. Non-limiting examples to a link to a smart contract include an address (e.g., a URL) to location, a pointer to a database entry, and an address on a blockchain. [366] Block 1204 of example method 1200 may involve receiving a plurality of cryptographic verification codes independently generated by a corresponding plurality of trust verifiers. Each cryptographic verification code may include a trigger code sourced from a trusted entity and cryptographically signed by a respective one of the trust verifiers. [367] Block 1206 of example method 1200 may involve applying a public encryption key of each respective trust verifier to the corresponding cryptographic verification code to decrypt a corresponding trigger code. MBHB Docket No. 21-0361-WO3 [368] Block 1208 of example method 1200 may involve making a first verification that at least a threshold number of the decrypted corresponding trigger codes are identical. [369] Block 1210 of example method 1200 may involve applying an encoder function to the request specification to derive a local version of the trigger code associated with the contingency action. [370] Block 1212 of example method 1200 may involve making a second verification that the local version of the trigger code is identical to that of each of the at least the threshold number of decrypted corresponding trigger codes that are identical. [371] Finally, block 1214 of example method 1200 may involve storing the trigger code as the verified action-trigger in a database associated with the computing system. [372] In accordance with example embodiments, the threshold number may be the total number of the plurality, a majority of the total number of the plurality, or an integer number closest to a specified fraction of the total number of the plurality. [373] In accordance with example embodiments, making the first verification that at least the threshold number of the decrypted corresponding encoded action-payloads are identical may entail making a selection of a predetermined number of the decrypted corresponding encoded action-payloads to compare. Further, the threshold number may equal predetermined number. With this arrangement, the selection may be one of random, and/or based on prescribed identities of particular ones of the corresponding plurality of trust verifiers. [374] In accordance with example embodiments, the trigger code supplied by the trusted entity may be a hash, and the encoder function may be a hash function. In this arrangement, each corresponding trigger code may be a corresponding hash value, and the local version of the trigger code may be a local hash value. Further in this arrangement, making the first verification that the at least the threshold number of the decrypted corresponding trigger codes are identical may involve verifying that at least the threshold number of the corresponding hash values are identical, and making the second verification that the local version of the trigger code is identical to that of each of the at least the threshold number of decrypted corresponding trigger codes that are identical may involve verifying that the local hash value is identical to that of the at least the threshold number of the corresponding hash values that are identical. [375] In accordance with example embodiments, the trigger code supplied by the trusted entity may include a semantic representation of the request specification created by the trusted entity and interpretable by a computing device. [376] In accordance with example embodiments, the trigger code supplied by the MBHB Docket No. 21-0361-WO3 trusted entity may include a semantic representation of the request specification generated by an artificial intelligence engine based on a natural-language description of the request specification, and interpretable by a computing device. [377] In accordance with example embodiments, execution of the action may be delayed by a specified amount time from a specified date and time, or scheduled for a particular date and time. [378] In accordance with example embodiments, example method 1200 may further involve sending a copy of the verified trigger code to the node device in response to receiving a request from a node device of the blockchain network. C. Example Generation of a Smart Contract with Third-Party Authority [379] Figure 13 is a flow chart illustrating an example embodiment of a method 1300. The methods illustrated by Figure 13 may be carried out by a computing system or computing device configured for operating as database server for verifying and storing encoded action- triggers for digital assets entered on a blockchain network. Non-limiting examples of the computing system computing system or computing device include computing device 100 or server cluster 200, for example. However, the method can be carried out by other types of devices or device subsystems. For example, the method could be carried out by a portable computer, such as a laptop or a tablet device. [380] The embodiment of Figure 13 may be simplified by the removal of any one or more of the features shown therein. Further, this embodiment may be combined with features, aspects, and/or implementations of any of the previous figures or otherwise described herein. [381] The example method 1300 may also be embodied as instructions executable by one or more processors of the one or more server devices of the system or virtual machine or container. For example, the instructions may take the form of software and/or hardware and/or firmware instructions. In an example embodiment, the instructions may be stored on a non- transitory computer readable medium. When executed by one or more processors of the one or more servers, the instructions may cause the one or more servers to carry out various operations of the example method. [382] Example method 1300, directed to generating a smart contract with third-party authority, is described next. [383] Block 1302 of example method 1300 may involve obtaining a first identifier relating to a first entity, wherein the first identifier uniquely identifies the first entity within a backwardly-immutable cryptographic sequence of data blocks. MBHB Docket No. 21-0361-WO3 [384] Block 1304 of example method 1300 may involve exchanging, between the first entity and a second entity, a set of conditions, wherein a second identifier uniquely identifies the second entity within the backwardly-immutable cryptographic sequence of data blocks. [385] Block 1306 of example method 1300 may involve receiving, from the first entity and the second entity, acceptances of the set of conditions. [386] Block 1308 of example method 1300 may involve generating a self-executing unit of program logic that contains the first identifier, the second identifier, a representation of the set of conditions, and a third identifier that uniquely identifies a third entity having authority to suspend, modify, or override execution of the program logic. [387] Block 1310 of example method 1300 may involve adding, as a new data block, the self-executing unit of program logic on the backwardly-immutable cryptographic sequence of data blocks. [388] Block 1312 of example method 1300 may involve notifying one or more of the first entity or the second entity of the self-executing unit of program logic. [389] In accordance with example embodiments, the first identifier and the second identifier are addresses on the backwardly-immutable cryptographic sequence of data blocks. [390] In accordance with example embodiments, the backwardly-immutable cryptographic sequence of data blocks comprises a blockchain. [391] In accordance with example embodiments, the backwardly-immutable cryptographic sequence of data blocks comprises a distributed database. [392] In accordance with example embodiments, ein the self-executing unit of program logic comprises a smart contract. [393] In accordance with example embodiments, the self-executing unit of program logic includes an indication that the first entity and the second entity have agreed to be bound by the set of conditions. [394] In accordance with example embodiments, the self-executing unit of program logic causes a digital token to be transferred between the first entity and the second entity upon determining that the set of conditions have been met. [395] In accordance with example embodiments, the self-executing unit of program logic causes a digital token to be automatically transferred between the first entity and the second entity at a predetermined point in time. [396] In accordance with example embodiments, the self-executing unit of program logic is revoked or suspended upon determining that a digital token has not been provided by MBHB Docket No. 21-0361-WO3 the first entity or the second entity by a predetermined point in time or that at least one of the set of conditions has not been met. [397] In accordance with example embodiments, the third entity is an arbiter, a judicial court, or another party whose resolutions the first entity and the second entity have agreed to be bound. [398] Some example embodiments may further involve: receiving a request from the first entity or the second entity to invoke the authority of the third entity to suspend, modify, or override execution of the program logic; providing, to the third entity, a representation of the set of conditions; and receiving, from the third entity, instructions to suspend, modify, or override execution of the program logic. [399] Some example embodiments may further involve: receiving a request from the first entity or the second entity indicating that the set of conditions have not been met and a variance to the set of conditions; and guiding the first entity and the second entity through a series of actions that narrow a scope of the variance. [400] Some example embodiments may further involve adding, as a further new data block, a representation of execution of the program logic on the backwardly-immutable cryptographic sequence of data blocks. [401] In accordance with example embodiments, the set of conditions include conditions provided by the first entity, the second entity, or both the first entity and the second entity. [402] In accordance with example embodiments, exchanging the set of conditions comprises an original set of conditions begin modified into the set of conditions through transactions between the first entity and the second entity. [403] In accordance with example embodiments, the second identifier is provided by the first entity. [404] In accordance with example embodiments, the second identifier is provided by the second entity. VII. Closing [405] The present disclosure is not to be limited in terms of the particular embodiments described in this application, which are intended as illustrations of various aspects. Many modifications and variations can be made without departing from its scope, as will be apparent to those skilled in the art. Functionally equivalent methods and apparatuses within the scope of the disclosure, in addition to those described herein, will be apparent to those skilled in the art from the foregoing descriptions. Such modifications and variations are MBHB Docket No. 21-0361-WO3 intended to fall within the scope of the appended claims. [406] The above detailed description describes various features and operations of the disclosed systems, devices, and methods with reference to the accompanying figures. The example embodiments described herein and in the figures are not meant to be limiting. Other embodiments can be utilized, and other changes can be made, without departing from the scope of the subject matter presented herein. It will be readily understood that the aspects of the present disclosure, as generally described herein, and illustrated in the figures, can be arranged, substituted, combined, separated, and designed in a wide variety of different configurations. [407] With respect to any or all of the message flow diagrams, scenarios, and flow charts in the figures and as discussed herein, each step, block, and/or communication can represent a processing of information and/or a transmission of information in accordance with example embodiments. Alternative embodiments are included within the scope of these example embodiments. In these alternative embodiments, for example, operations described as steps, blocks, transmissions, communications, requests, responses, and/or messages can be executed out of order from that shown or discussed, including substantially concurrently or in reverse order, depending on the functionality involved. Further, more or fewer blocks and/or operations can be used with any of the message flow diagrams, scenarios, and flow charts discussed herein, and these message flow diagrams, scenarios, and flow charts can be combined with one another, in part or in whole. [408] A step or block that represents a processing of information can correspond to circuitry that can be configured to perform the specific logical functions of a herein-described method or technique. Alternatively or additionally, a step or block that represents a processing of information can correspond to a module, a segment, or a portion of program code (including related data). The program code can include one or more instructions executable by a processor for implementing specific logical operations or actions in the method or technique. The program code and/or related data can be stored on any type of computer readable medium such as a storage device including RAM, a disk drive, a solid-state drive, or another storage medium. [409] The computer readable medium can also include non-transitory computer readable media such as non-transitory computer readable media that store data for short periods of time like register memory and processor cache. The non-transitory computer readable media can further include non-transitory computer readable media that store program code and/or data for longer periods of time. Thus, the non-transitory computer readable media may include secondary or persistent long-term storage, like ROM, optical or magnetic disks, solid-state drives, or compact disc read only memory (CD-ROM), for example. The non-transitory MBHB Docket No. 21-0361-WO3 computer readable media can also be any other volatile or non-volatile storage systems. A non- transitory computer readable medium can be considered a computer readable storage medium, for example, or a tangible storage device. [410] Moreover, a step or block that represents one or more information transmissions can correspond to information transmissions between software and/or hardware modules in the same physical device. However, other information transmissions can be between software modules and/or hardware modules in different physical devices. [411] The particular arrangements shown in the figures should not be viewed as limiting. It should be understood that other embodiments could include more or less of each element shown in a given figure. Further, some of the illustrated elements can be combined or omitted. Yet further, an example embodiment can include elements that are not illustrated in the figures. [412] While various aspects and embodiments have been disclosed herein, other aspects and embodiments will be apparent to those skilled in the art. The various aspects and embodiments disclosed herein are for purpose of illustration and are not intended to be limiting.

Claims

MBHB Docket No. 21-0361-WO3 CLAIMS 1. A computer-implemented method comprising: obtaining a first identifier relating to a first entity, wherein the first identifier uniquely identifies the first entity within a backwardly-immutable cryptographic sequence of data blocks; exchanging, between the first entity and a second entity, a set of conditions, wherein a second identifier uniquely identifies the second entity within the backwardly-immutable cryptographic sequence of data blocks; receiving, from the first entity and the second entity, acceptances of the set of conditions; generating a self-executing unit of program logic that contains the first identifier, the second identifier, a representation of the set of conditions, and a third identifier that uniquely identifies a third entity having authority to suspend, modify, or override execution of the program logic; adding, as a new data block, the self-executing unit of program logic on the backwardly- immutable cryptographic sequence of data blocks; and notifying one or more of the first entity or the second entity of the self-executing unit of program logic. 2. The computer-implemented method of claim 1, wherein the first identifier and the second identifier are addresses on the backwardly-immutable cryptographic sequence of data blocks. 3. The computer-implemented method of claim 1, wherein the backwardly- immutable cryptographic sequence of data blocks comprises a blockchain. 4. The computer-implemented method of claim 1, wherein the backwardly- immutable cryptographic sequence of data blocks comprises a distributed database. 5. The computer-implemented method of claim 1, wherein the self-executing unit of program logic comprises a smart contract. MBHB Docket No. 21-0361-WO3 6. The computer-implemented method of claim 1, wherein the self-executing unit of program logic includes an indication that the first entity and the second entity have agreed to be bound by the set of conditions. 7. The computer-implemented method of claim 1, wherein the self-executing unit of program logic causes a digital token to be transferred between the first entity and the second entity upon determining that the set of conditions have been met. 8. The computer-implemented method of claim 1, wherein the self-executing unit of program logic causes a digital token to be automatically transferred between the first entity and the second entity at a predetermined point in time. 9. The computer-implemented method of claim 1, wherein the self-executing unit of program logic is revoked or suspended upon determining that a digital token has not been provided by the first entity or the second entity by a predetermined point in time or that at least one of the set of conditions has not been met. 10. The computer-implemented method of claim 1, wherein the third entity is an arbiter, a judicial court, or another party whose resolutions the first entity and the second entity have agreed to be bound. 11. The computer-implemented method of claim 1, further comprising: receiving a request from the first entity or the second entity to invoke the authority of the third entity to suspend, modify, or override execution of the program logic; providing, to the third entity, a representation of the set of conditions; and receiving, from the third entity, instructions to suspend, modify, or override execution of the program logic. 12. The computer-implemented method of claim 1, further comprising: receiving a request from the first entity or the second entity indicating that the set of conditions have not been met and a variance to the set of conditions; and guiding the first entity and the second entity through a series of actions that narrow a scope of the variance. MBHB Docket No. 21-0361-WO3 13. The computer-implemented method of claim 1, further comprising: adding, as a further new data block, a representation of execution of the program logic on the backwardly-immutable cryptographic sequence of data blocks. 14. The computer-implemented method of claim 1, wherein the set of conditions include conditions provided by the first entity, the second entity, or both the first entity and the second entity. 15. The computer-implemented method of claim 1, wherein exchanging the set of conditions comprises an original set of conditions begin modified into the set of conditions through transactions between the first entity and the second entity. 16. The computer-implemented method of claim 1, wherein the second identifier is provided by the first entity. 17. The computer-implemented method of claim 1, wherein the second identifier is provided by the second entity. 18. A non-transitory computer-readable medium storing program instructions that, when executed by one or more processors of a computing system, cause the computing system to perform the operations of any one of claims 1-17. 19. A computing system comprising: one or more processors; memory; and program instructions, stored in the memory, that upon execution by the one or more processors cause the computing system to perform the operations of any one of claims 1-17.