Temporary consensus network in resource transfer system

Abstract

Systems and techniques for use in resource transfer systems are provided. An instruction to transfer a first quantity of resources from a first resource pool to a second resource pool can be received. A constraint can be placed on a second quantity of resources in the first resource pool. The first quantity of resources that is constrained can not be transferred from the first resource pool until the constraint is released. The constraint can be released in response to receiving a message that satisfies a condition related to the constraint and an instruction to perform the transfer. A register associated with the resource in the first resource pool can be decremented by the first quantity and a register associated with the resource in the second resource pool can be incremented by the first quantity.

Description

BACKGROUND

[0001] Resource transfers between two parties can require the involvement of one or more third parties. For example, if a sender has a type of resource (such as U.S. dollars) to send, but a recipient expects to receive a different type of resource (such as Euros), a third party can be needed to convert the sender's resource (U.S. dollars) into the resource that the recipient expects (Euros). More parties can be introduced into the resource transfer. For example, a first intermediary can convert U.S. dollars into Japanese Yen, and a second intermediary can convert Japanese Yen into Euros for the recipient. As the number of intermediaries increases, the risk of the parties involved in the transfer can increase. For example, one of the third parties (such as an intermediary) between the sender and the recipient takes resources (such as U.S. dollars from a third party), but retains the resources instead of converting the resources into a different type of resource (e.g., Japanese Yen) and passing the resources to another intermediary toward the recipient. It is possible that a third party transfers resources (such as Euros) to the recipient, which cannot be reimbursed by the sender or an intermediary between the sender and the third party. A malicious sender can also initiate a resource transfer that is intended to temporarily bind resources that one or more other parties are bound to the transaction. SUMMARY

[0002] The systems and techniques disclosed herein can allow for resource transfer systems. Additional features, advantages, and embodiments of the disclosed subject matter can be set forth or apparent from consideration of the following detailed description, drawings, and claims. Moreover, it should be appreciated that the foregoing summary and the following detailed description are examples only and are intended to provide further explanation without limiting the scope of the claims.

[0003] An instruction to transfer a first amount of a first resource type from a first resource pool to a second resource pool can be received. An instruction to set a constraint on a second amount of the first resource type in the first resource pool can be received. An authorization to set the constraint on the second amount of the first resource type in the first resource pool can be received. In response to receiving the authorization, the constraint on the second amount of the first resource type in the first resource pool can be set to create a constrained second amount of the first resource type. The constrained second amount of the first resource type cannot be transferred from the first resource pool until the constraint is released.

[0004] A message can be received that satisfies a condition of the constraint. An instruction to perform a transfer of the first quantity of the first resource type from the first resource pool to the second resource pool can be received. In response to receiving the message that satisfies the condition related to the constraint and the instruction to perform the transfer, the constraint on the second quantity of the first resource type can be released, a first register associated with the first resource type in the first resource pool can be decremented by the first quantity, and a second register associated with the first resource type in the second resource pool can be incremented by the first quantity.

[0005] A message can be received that includes a proposed transfer. The proposed transfer can include a source transfer of a first quantity of a first resource type from a first resource pool to a second resource pool and a destination transfer of a second quantity of a second resource type from a third resource pool to a fourth resource pool. A message can be received that indicates a constraint is placed on a third quantity of the first resource type in the first resource pool. A message can be sent that is associated with the progress of the destination transfer. A message can be received that indicates a condition of the constraint on the third quantity of the first resource type in the first resource pool is satisfied. An instruction to perform the source transfer of the first quantity of the first resource type from the first resource pool to the second resource pool can be sent.

[0006] A prepare transfer receipt can be received from each resource tracking system of a plurality of resource tracking systems in a transfer chain. The prepare transfer receipt can indicate that each resource tracking system places a constraint on each quantity of each resource type. A signed message can be sent to each resource tracking system of the plurality of resource tracking systems and each intermediary of a plurality of intermediaries. The signed message can satisfy a condition of each constraint placed by each resource tracking system and cause each intermediary of the plurality of intermediaries to send at least one instruction to perform a transfer to one of the plurality of resource tracking systems. BRIEF DESCRIPTION OF DRAWINGS

[0007] The accompanying drawings, which are included to provide a further understanding of the subject matter of the disclosure and are incorporated in and constitute a part of this specification, illustrate embodiments of the subject matter of the disclosure and together with the

[0008] Figure 1 An example system suitable for use in a resource transfer system is shown in accordance with an implementation of the subject matter disclosed.

[0009] Figure 2 An example system suitable for use in a resource transfer system is shown in accordance with an implementation of the subject matter disclosed.

[0010] Figure 3An example system suitable for a resource transfer system is shown in accordance with an implementation of the disclosed subject matter.

[0011] Figure 4 An example system suitable for a resource transfer system is shown in accordance with an implementation of the disclosed subject matter.

[0012] Figure 5 An example system suitable for a resource transfer system is shown in accordance with an implementation of the disclosed subject matter.

[0013] Figures 6A-6D An example configuration suitable for a resource transfer system is shown in accordance with an implementation of the disclosed subject matter.

[0014] Figures 7A-7C An example configuration suitable for a resource transfer system is shown in accordance with an implementation of the disclosed subject matter.

[0015] Figures 8A-8C An example configuration suitable for a resource transfer system is shown in accordance with an implementation of the disclosed subject matter.

[0016] Figures 9A-9C An example configuration suitable for a resource transfer system is shown in accordance with an implementation of the disclosed subject matter.

[0017] Figure 10 An example configuration suitable for a resource transfer system is shown in accordance with an implementation of the disclosed subject matter.

[0018] Figure 11 An example sequence suitable for a resource transfer system is shown in accordance with an implementation of the disclosed subject matter.

[0019] Figure 12 An example sequence suitable for a resource transfer system is shown in accordance with an implementation of the disclosed subject matter.

[0020] Figure 13A An example sequence suitable for a resource transfer system is shown in accordance with an implementation of the disclosed subject matter.

[0021] Figure 13B An example sequence suitable for a resource transfer system is shown in accordance with an implementation of the disclosed subject matter.

[0022] Figure 14 An example sequence suitable for a resource transfer system is shown in accordance with an implementation of the disclosed subject matter.

[0023] Figure 15 An example sequence suitable for a resource transfer system is shown in accordance with an implementation of the disclosed subject matter.

[0024] Figure 16 An example configuration suitable for a resource transfer system is shown in accordance with an implementation of the disclosed subject matter.

[0025] Figure 17A An example configuration suitable for a resource transfer system is shown in accordance with implementations of the disclosed subject matter.

[0026] Figure 17B An example configuration suitable for a resource transfer system is shown in accordance with implementations of the disclosed subject matter.

[0027] Figure 18A An example process suitable for a resource transfer system is shown in accordance with implementations of the disclosed subject matter.

[0028] Figure 18B An example process suitable for a resource transfer system is shown in accordance with implementations of the disclosed subject matter.

[0029] Figure 19 An example process suitable for a resource transfer system is shown in accordance with implementations of the disclosed subject matter.

[0030] Figure 20A An example process suitable for a resource transfer system is shown in accordance with implementations of the disclosed subject matter.

[0031] Figure 20B An example process suitable for a resource transfer system is shown in accordance with implementations of the disclosed subject matter.

[0032] Figure 21 An example process suitable for a resource transfer system is shown in accordance with implementations of the disclosed subject matter.

[0033] Figure 22 A computer is shown in accordance with embodiments of the disclosed subject matter.

[0034] Figure 23 A network configuration is shown in accordance with embodiments of the disclosed subject matter. DETAILED DESCRIPTION

[0035] According to embodiments disclosed herein, a resource transfer system can allow for the transfer of different types of resources from a sender to a recipient and involving one or more third parties, such as intermediaries, while reducing the risk to the involved parties. The sender can use any suitable computing device to initiate the transfer of resources to the recipient. The transfer can be made using a resource tracking system, which can be any suitable computing device for tracking the ownership of resources by the parties. The sender, recipient, and intermediary can use computing devices such as a sender, intermediary, and recipient. The sender, intermediary, recipient, and resource tracking system can be considered part of a transfer chain from the sender to the recipient.

[0036] As used herein, a transfer of a resource on a resource tracking system to a given participant in a transfer is referred to as a "source transfer" to that participant, and a transfer of a resource away from that participant is referred to as a "destination transfer." Source and destination transfers to the same participant can occur using two separate resource tracking systems, where both resource tracking systems can track resources controlled by the participant. In the case of two participants each having resources that can be tracked using a resource tracking system, the resource tracking system can be between the two participants, such that the resource tracking system can transfer resources between the participants.

[0037] A hold can be placed on a resource to be transferred. The purpose of a hold is to reduce the amount of risk assumed by one or more participants in a transfer chain. Generally, a "hold" prevents the transfer of a certain amount of resources and / or a particular resource unless and until certain conditions of the hold are met. These conditions can be, for example, receiving a signed message from a trusted computing device or system of all participants to a transfer indicating that the transfer can proceed, receiving a receipt such as a pre-approval signed message from a designated participant that can be a recipient or some third party to whom responsibility is delegated. The designated third party can be, for example, one of an intermediary or a resource tracking system in the transfer chain, a third party notary, or some other appropriate participant. The conditions can also be, for example, that a source transfer to a participant can proceed upon receiving a message ("receipt") that can be evidence of a destination transfer of resources from that participant. As another example, the conditions can be evidence that one or more other holds are in place at one or more different points in the transfer chain. The conditions can also be, for example, evidence that a smart contract is being executed, or a digital signature or other signed message from a third party indicating the occurrence of an event such as a digital signature confirming that a physical package was successfully delivered by a delivery service. The conditions of a hold can also be, for example, evidence that a plurality of other non-hold conditions are met, including, for example, the receipt of signatures from a plurality of other participants.

[0038] A sender or "sender computing device" using a sender computing device can initiate a transfer to a recipient by requesting a quote. The quote can be related to resources required for the transfer from the sender to the recipient. The quote can include an amount of resources to be transferred to the recipient, as well as any fees to effectuate the transfer. These fees can be charged by an intermediary. The quote can be requested from any appropriate participant using any appropriate computing device or system that can communicate with computing devices or systems used by various intermediaries.

[0039] For all transfer chains, using any conditions related to the amount of resources and intermediate institutions constrained, the sender can accept the offer and authorize the constraining of its own resources to be transferred. The constraining can be appropriately implemented on the resource tracking system between the sender and the first intermediate on the transfer chain, which can be a sender-intermediary resource tracking system. The sender-intermediary resource tracking system can track the particular resources controlled by the sender and other resources controlled by the first intermediate. In general, the constraints can be appropriately set on the resource tracking system responsible for tracking the resources of the adjacent participants on the transfer chain. For example, a record of the amount and type of sender resources can be stored in a database that is part of the resource tracking system. When a constraint is set on a particular amount of resources belonging to the sender, the resource tracking system can prevent the transfer of that amount of resources and / or the particular resources unless and until the particular condition of the constraint is met. The resources of both the sender and the next participant in the transfer chain can be of the same type. Once the constraint is authorized, the next participant in the transfer (e.g., an intermediate using an intermediary computing device, or "intermediary") can cause the resource tracking system to implement the constraint on the resources as authorized by the sender. This can lock some amount of the sender's resources, preventing other transfers from reducing the amount of the sender's resources on the sender-intermediary resource tracking system below the constrained amount for some period of time. The sender-intermediary resource tracking system can send a constraint receipt that can indicate that the requested constraint has been set on the resources in preparation for the planned transfer ("pre-transfer receipt"). The constraint can be set by transferring the constrained resources to a constraint account on the resource tracking system. The constraint account can be owned by the operator of the resource tracking system, or by a third party. For example, a third party can establish an account on the resource tracking system to which the sender's resources are to be transferred in the transfer. The sender's resources can be transferred to a third party account on the resource tracking system in addition to being transferred to the first intermediate's account in the transfer chain.

[0040] For a single intermediate transfer chain, the conditions under which the resource tracking systems allow the transfer of the constrained resource can be the receipt of a signed message from a trusted system indicating that the transfer can proceed. The intermediate institution can receive a prepared transfer receipt sent by the sender-intermediary resource tracking system. In response, the intermediate institution can place a constraint on the particular quantity of resource controlled by the intermediary and tracked with the intermediary-recipient resource tracking system, which can also track the resource controlled by the recipient. With the constraints placed on all resources used for the transfer set for transfer, the transfer can proceed. This can prevent a partial transfer without going through all of the parts of the transfer. The condition for releasing the constraints can be the receipt of a cryptographically signed statement from a trusted third party ("trusted system") that verifies that the constraints have been placed on the appropriate resources involved in the transfer on the different resource tracking systems and that the transfer can proceed. The trusted system can base this statement on verification messages from, for example, the quantity-constrained resource tracking systems involved in the transfer (the sender-intermediary resource tracking system and the intermediary-recipient resource tracking system).

[0041] The trusted system can receive a prepared transfer receipt (constraint receipt) indicating that constraints were placed on resources at both resource tracking systems in the transfer and can send a signed message to the resource tracking systems and the intermediate institution indicating that the transfer can proceed. The intermediate institution can send instructions to the intermediary-recipient resource tracking system to transfer the intermediary's resource with the constraint to the recipient. The intermediate institution can also instruct the sender-intermediary resource tracking system to transfer the sender's resource with the constraint to the intermediary. As the constraint conditions can have been fulfilled by receiving the signed message from the trusted system, the resource tracking systems can perform the transfer as instructed by the intermediate institution and can send a transfer confirmation receipt to the intermediate institution. The intermediate institution can notify the recipient at the recipient computing device or "recipient" and the sender that the transfer is complete, for example.

[0042] In some implementations, the trusted system of a transfer chain is an ad hoc consensus network. The ad hoc consensus network of a transfer chain can include a plurality of systems or nodes, which can be, for example, resource tracking systems or intermediate institutions that are not part of the transfer chain. The nodes in the ad hoc consensus network can be selected based on the intersection of trust lists collected from stakeholders in the transfer chain. The stakeholders can be, for example, the sender, the recipient, and any intermediaries in the transfer chain. The trust list of a stakeholder can be a list of nodes trusted by the stakeholder as part of the ad hoc consensus network of the transfer chain.

[0043] In setting up a transfer chain, the initiator of the transfer can request trust lists from the various stakeholders. The request can be sent to the appropriate systems of, for example, the sender, the recipient, and the intermediary institution for each stakeholder. The initiator can be the system of any party that initiates the transfer. For example, the initiator can be the sender, the recipient, the intermediary institution, or a coordinator that can be responsible for setting up the transfer chain but can not be part of the transfer chain. Upon receiving the trust lists from the systems of the various stakeholders, the initiator can determine a set of nodes that are common to all of the received trust lists or that exist at the intersection of all of the received trust lists. These nodes can be the member nodes of a temporary consensus network of the transfer chain. The minimum number of member nodes in the temporary consensus network can be based on the fault tolerance specified by the stakeholders from which the trust lists were collected. The fault tolerance specified by the stakeholders, for example, can be the minimum number of Byzantine faults that the temporary consensus network must be able to tolerate. The minimum number of nodes, for example, can be more than three times the highest specified tolerance from the stakeholders. If there are not enough intersection nodes on the collected trust lists to satisfy the minimum number of nodes of the temporary consensus network, the transfer can be aborted. Some stakeholders can not have or maintain their own trust lists. These stakeholders can allow a trust list to be provided on their behalf by, for example, a resource tracking system. The resource tracking system can provide the trust list on behalf of the stakeholders for which the resource tracking system is part of the transfer chain for the transfer resource.

[0044] The initiator can send a request to the systems of all of the stakeholders in the transfer chain that their respective resources be set with appropriate constraints conditional on the approval of the transfer by the temporary consensus network as summarized from the trust lists. The systems of the stakeholders (e.g., the sender, the recipient, and any intermediary institution) can instruct the appropriate resource tracking systems to set the constraints on their resources conditional on the release of the constraints only upon proof that the temporary consensus network approved the transfer. The systems of the stakeholders can also confirm to the initiator that they agree to participate in the transfer chain. A prepared transfer receipt from the resource tracking systems can be sent to the initiator. If a confirmation is not received from all of the systems of the stakeholders, the transfer can be aborted.

[0045] The initiator can present the proof to the member nodes of the ad hoc consensus network that all appropriate constraints for the transfer chain have been set by the stakeholders, e.g., using the ready-to-transfer receipts. The member nodes of the ad hoc consensus network can verify that the appropriate constraints were set by, e.g., checking the ready-to-transfer receipts to determine that they are authentic, tracking the system receipt of the ready-to-transfer receipts for each resource in the transfer chain, and that the ready-to-transfer receipts indicate that the correct amount of the correct resource type is constrained in the correct resource pool for transfer to the correct resource pool, where the constraint is that a message is received indicating that the ad hoc consensus network approved the transfer. The member nodes also verify the timestamps on the ready-to-transfer receipts to ensure that the resources are constrained prior to the transfer deadline or timeout.

[0046] The member nodes of the ad hoc consensus network can reach consensus on whether to approve the transfer. The member nodes can communicate decisions using any appropriate type of communication to reach consensus in any appropriate manner. For example, the member nodes can use a practical Byzantine fault tolerance consensus. The consensus can be reached by a quorum of the member nodes, where the quorum can be 2 / 3 of the member nodes in the ad hoc consensus network. The initiator can request from the member nodes of the ad hoc consensus network signed statements of the ad hoc consensus network regarding whether the transfer can be approved. The statements can be cryptographically signed. The initiator can wait until such signed statements are received from more than 1 / 3 of the member nodes.

[0047] If the ad hoc consensus network approves the transfer, the initiator can present the signed statements from 1 / 3 of the member nodes to the stakeholders indicating that the ad hoc consensus network approved the transfer. The stakeholders can then proceed to perform the transfer across the transfer chain, where the signed statements from the member nodes are presented to the resource tracking systems in the transfer chain to release the constrained resources and enable the constrained resources to be transferred to the appropriate resource pool. If the ad hoc consensus network does not approve the transfer, e.g., due to late, lost, forged, or otherwise untrustworthy ready-to-transfer receipts, the transfer can be aborted. The initiator can present the signed statements from 1 / 3 of the member nodes to the stakeholders indicating that the ad hoc consensus network did not approve the transfer. The stakeholders can roll back the transfer.

[0048] After the transfer is completed or aborted, the ad hoc consensus network can dissolve or can be bound for more transfers involving the same stakeholders. The member nodes in the ad hoc consensus network can each be weighted equally when reaching a quorum, or can be weighted by, e.g., computing power.

[0049] Another example of a condition that must be satisfied in order to release a constraint on a resource is evidence that a particular transfer of the resource has occurred. For example, in a single intermediate transfer chain, in response to receiving a prepare transfer receipt sent by the sender-intermediary resource tracking system, the intermediary can instruct the intermediary-recipient resource tracking system to transfer a resource controlled by the intermediary to the recipient. Once the transfer is complete, the intermediary can receive a transfer confirmation receipt from the intermediary-recipient resource tracking system. This transfer confirmation receipt can be sent to the sender-intermediary resource tracking system as evidence that a destination transfer of the resource from the intermediary has occurred. This can satisfy a condition for releasing a constraint on the resource of the sender at the sender-intermediary resource tracking system, enabling the transfer of the resource of the sender to the intermediary. The intermediary can send a notification to the recipient and the sender that the transfer (from the sender to the recipient) is complete.

[0050] Another example of a condition that must be satisfied in order to release a constraint on a resource can be receiving a receipt from the recipient that can be a signed message of some pre-agreement. For example, in a single intermediate transfer chain, in response to receiving a prepare transfer receipt sent by the sender-intermediary resource tracking system, the intermediary can instruct the intermediary-recipient resource tracking system to place a constraint on an amount of resource controlled by the intermediary and tracked by the intermediary-recipient resource tracking system, enabling the tracking of resources controlled by the recipient as well. A receipt can be sent to the recipient indicating that a constraint was placed on the resource controlled by the intermediary at the intermediary-recipient resource tracking system. The recipient can send a signed message to the sender-intermediary resource tracking system, the intermediary-recipient resource tracking system, and the intermediary that the content can have been pre-agreed to by the parties in the transfer chain and can not itself indicate any circumstances related to the transfer status of the chain. The signed message can be cryptographically signed and can satisfy a condition for releasing a constraint on the resource of the sender at the sender-intermediary resource tracking system, enabling the transfer of the resource of the sender to the intermediary, and can satisfy a condition for releasing a constraint on the resource of the intermediary at the recipient-intermediary resource tracking system, enabling the transfer of the resource of the intermediary to the recipient.

[0051] The intermediary can send instructions to the intermediary-receiver resource tracking system to transfer the intermediary's resources subject to the constraints to the receiver. The intermediary can also instruct the sender-intermediary resource tracking system to transfer the sender's resources subject to the constraints to the intermediary. Since the constraint condition is satisfied by receiving the signed message from the receiver, the resource tracking system can perform the transfer as instructed by the intermediary and can send a transfer confirmation receipt to the intermediary. The intermediary also notifies the receiver, e.g., at the receiver computing device or "sink," that the transfer is complete and the sender that the transfer is complete.

[0052] When the condition for a constraint on a resource in the transfer chain is the receipt of a receipt from the receiver, the receiver can be able to reject the incoming transfer, which causes the transfer chain to fail. For example, a receipt from the intermediary-receiver resource tracking system indicating that a resource subject to a constraint for the intermediary is transferred to the receiver can be sent to the receiver. The receiver can examine the receipt and can determine that they do not wish to accept the transfer. The receiver can instruct the receiver not to send out a receipt that will satisfy the condition related to the constraints on all resources in the transfer chain. Ultimately, the transfer will time out and fail, and all of the constraints will be released without the need to release any resources. In some implementations, the receiver can automatically reject the transfer for any appropriate reason without intervention by the receiver. For example, the receiver can be configured to automatically reject a transfer if a receipt from the intermediary-receiver resource tracking system indicates that the amount or value of resources subject to a constraint for a transfer to the receiver's account is incorrect.

[0053] The receiver can also delegate responsibility for generating and sending a receipt to some third party designated by the receiver. Responsibility for a receipt can be delegated to any appropriate party as long as the receiver accepts that the condition is satisfied, can be caused to be satisfied, or trusts the third party to act on their behalf. For example, the receiver can forward any receipt from the intermediary-receiver resource tracking system to a third party notary, who can verify that the receipt indicates that the appropriate amount of resources are subject to a constraint and will be transferred to the receiver's account, and then send out a receipt on behalf of the receiver to satisfy the constraint condition. As another example, the receiver can delegate responsibility to a shipper of physical goods, and the condition for a constraint on a resource in the transfer chain can be a receipt from the shipper that explicitly or implicitly indicates that shipment or delivery of the physical goods is a pre-approved message. The receipt from the intermediary-receiver resource tracking system can be forwarded to the shipper, who can verify that the receipt indicates that the appropriate amount of resources are subject to a constraint and will be transferred to the receiver's account, and can proceed with shipment or delivery of the physical goods and generate and send out a receipt to confirm the action and satisfy the constraint on a resource in the transfer chain.

[0054] The receipt sent by the recipient can be implemented using a one-way function, such as a hash function. For example, the recipient can publish a value derived from the secret value to the one-way function when setting up the transfer chain, such that the value is accessible by other systems in the transfer chain. For example, the derived value can be a hash value resulting from hashing the secret value, and the recipient can publish the hash value such that it is accessible by the intermediary and resource transfer systems in the transfer chain. The derived value can be published in any suitable manner, such as being available at a publicly available network location, at a pre-agreed network location, or by being sent directly to the systems in the transfer chain by the recipient or a coordinator of the transfer, or by being passed sequentially between the systems of the transfer chain in any other suitable manner. The one-way function used by the recipient to generate the derived value can also be published. The secret value can be kept private by the recipient. The condition for the resource in the transfer chain can be the receipt of a receipt including the secret value.

[0055] In the event that the recipient wishes to execute the transfer, such as after receiving a ready-to-transfer receipt from the last resource tracking system in the transfer chain, the recipient can send a receipt including the secret value out to the intermediary and resource tracking systems in the transfer chain. The resource tracking systems can verify the receipt by applying the one-way function as published by the recipient to the secret value in the receipt, and determining whether the result is consistent with the derived value published by the recipient. If the result is consistent with the derived value, the receipt can be verified as coming from the recipient and satisfying the condition for the resource. This can enable the resource to be transferred, thereby executing the transfer.

[0056] In some implementations, a receipt from the receiver or a system of a participant delegated responsibility by the receiver can be sent to the ad hoc consensus network. For example, a constraint at the resource tracking system in the transfer chain for the resource can be approval of the transfer by the ad hoc consensus network as summarized from a list of trusted parties from the receiver, the sender, or an intermediary in the transfer chain. After receiving a prepared transfer receipt from the last intermediary in the transfer chain, the receiver or a system of a participant delegated responsibility by the receiver can send the receipt or a signed message to an initiator or coordinator of the transfer chain. The initiator or coordinator can send the receipt to a member node of the ad hoc consensus network. The receiver can send the receipt directly to a member node of the ad hoc consensus network. The member node of the ad hoc consensus network can validate the receipt from the receiver, for example, verifying a cryptographic signature on the receipt to ensure that the cryptographic signature is from the receiver or a system of a participant delegated responsibility by the receiver. The member node can approve the transfer by notarizing the receipt, for example, signing the receipt and timestamping the receipt with a time of submission of the receipt to the member node of the ad hoc consensus network. The signed receipt can be sent back to the initiator or coordinator, which can present the signed receipt as evidence of approval of the transfer to the sender, the receiver, the intermediaries, and the resource tracking system. This can satisfy the constraint at the resource tracking system in the transfer chain for the resource, enabling the transfer to be executed.

[0057] In some cases, there can be more than one intermediary and the conditions under which the resource tracking system allows the transfer of the constrained resource can be a signed message from a trusted system. The trusted system can be any appropriate centralized or decentralized system, such as a consensus network and simple independent signer nodes, among others. The prepare-to-transfer receipt sent out by the sender-intermediary resource tracking system can be received by the trusted system and the intermediary. In response, the intermediary can set a constraint on the resource controlled by the intermediary at the resource tracking system between the intermediary and the next intermediary in the transfer chain. In a multi-intermediary transfer chain, the resource tracking system between two intermediaries can be an intermediary-intermediary resource tracking system. Both intermediaries in the transfer chain can have access to the resource tracking system that tracks the resources belonging to the intermediaries for each intermediary. For example, the transfer chain can include a sender, intermediary A, intermediary B, intermediary C, and a recipient. The transfer chain can also include intermediary A-intermediary B and intermediary B-intermediary C resource tracking systems. In some implementations, the condition for the constraint on the resource in a transfer chain with more than one intermediary can be the receipt of a receipt from the recipient or a participant to whom the recipient has delegated responsibility. The prepare-to-transfer receipt can be sent from the last intermediary or resource tracking system in the transfer chain to the recipient or a participant or system designated by the recipient, who can then send a pre-agreed signed message to the systems in the transfer chain, including all intermediaries, to enable the transfer.

[0058] In the event that a party such as an intermediary institution places a constraint on a resource, a resource tracking system that tracks the constrained resource can send a ready-to-transfer receipt to the trusted system. The ready-to-transfer receipt can also be sent directly or via the trusted system to the next intermediary institution in the transfer chain, the previous intermediary institution in the transfer chain, or the sender of the transfer chain. The ready-to-transfer receipt can include the type and amount of the constrained resource, the owner of the constrained resource, an identifier corresponding to the transfer associated with the constrained resource, a time limit for the constraint, and / or other conditions that must be satisfied for the constraint to be released. Upon receiving the ready-to-transfer receipt, the next intermediary institution can also place a constraint on the resources controlled by the intermediary at the next resource tracking system, resulting in another ready-to-transfer receipt that can be sent to yet another intermediary until the last intermediary institution in the transfer chain is reached. The last intermediary institution in the transfer chain can place a constraint on the resources controlled by the intermediary at the intermediary-recipient resource tracking system between the last intermediary and the recipient and send a ready-to-transfer receipt to the trusted system. The trusted system, having received a ready-to-transfer receipt indicating that the appropriate resources are constrained at each resource tracking system in the transfer chain, can send a signed message to all of the intermediary institutions and resource tracking systems in the transfer chain indicating that the transfer can proceed. All of the intermediary institutions in the transfer chain (e.g., intermediary institutions A and B) can then instruct the appropriate resource tracking systems to transfer the constrained resources to the desired destination. For example, the constrained amount belonging to the sender at the sender-intermediary A resource tracking system can be transferred to intermediary A. Likewise, the constrained amount belonging to intermediary A at the intermediary A-intermediary B resource tracking system can be transferred to intermediary B. Intermediary B can instruct the intermediary B-recipient resource tracking system, which can be the last resource tracking system in the transfer chain, to transfer the constrained resources of the intermediary to the recipient. Because the conditions for transferring the constrained resources at each tracking resource system can have been satisfied by the signed message from the trusted system, the transfers can be performed all at once or in any order, in whole or in part. A notification of the completion of the transfer can also be sent to the sender and recipient from any appropriate computing device or system involved in the transfer, including the trusted system and any intermediary institutions.

[0059] In some implementations, each intermediary institution places a constraint on the resources controlled by each intermediary after the intermediary receives a message indicating that a constraint is to be placed. The message can be, for example, a signed message from the trusted system or a message from another intermediary institution. In such implementations, the intermediary institution can not need to receive a ready-to-transfer receipt before placing a constraint on the resources of each intermediary.

[0060] In some cases, there can be more than one intermediary, and the condition that allows the transfer of the constrained resource can be the receipt of a receipt indicating that a destination transfer of the resource from that participant occurred. In this case, in response to receiving a ready-to-transfer receipt sent out by the sender-intermediary resource tracking system, the intermediary can place a constraint on the resource that the intermediary controls at the intermediary's and the next intermediary's resource tracking system (e.g., the intermediary A-intermediary B resource tracking system). The constraint can result in the ready-to-transfer receipt being sent to the next intermediary in the chain of transfers. Upon receiving the ready-to-transfer receipt, the next intermediary can also place a constraint on the resource that the intermediary controls at the next resource tracking system, which can result in another ready-to-transfer receipt being sent to another intermediary, and so on, until the last intermediary in the chain of transfers receives the ready-to-transfer receipt. The last intermediary in the chain of transfers can receive the ready-to-transfer receipt indicating that the previous intermediary placed a constraint on the resource at the resource tracking system between the previous intermediary and the last intermediary. In response, the last intermediary in the chain of transfers can instruct the resource tracking system between the last intermediary and the recipient (e.g., the last intermediary-recipient resource tracking system) to transfer the resource that the last intermediary controls to the recipient. Since the last intermediary can be transferring the resource that it controls, the resource tracking system between the intermediary and the recipient can perform the transfer, and thus can not require any conditional constraints or other conditions to be satisfied. This can be a destination transfer for the last intermediary. Once the transfer is successful, the last intermediary can receive a transfer confirmation receipt from the last intermediary-recipient resource tracking system. The transfer confirmation receipt can be sent to the resource tracking system between the previous intermediary and the last intermediary. The transfer confirmation receipt can be evidence that a destination transfer of the resource from the last intermediary occurred, thus satisfying the condition for allowing a source transfer of the constrained resource from the previous intermediary to the last intermediary. This can result in the transfer confirmation receipt being sent to the previous intermediary, thus confirming a destination transfer for the previous intermediary. The previous intermediary can send the transfer confirmation receipt to the appropriate resource tracking system and instruct the resource tracking system to perform a source transfer for the previous intermediary. The transfer confirmation receipt can be evidence that a destination transfer of the resource from the previous intermediary occurred, thus satisfying the condition for allowing a source transfer of the constrained resource to the previous intermediary. The source transfer can be a destination transfer for another intermediary, and another transfer confirmation receipt can be generated, where the other intermediary can then use the other transfer confirmation receipt as evidence to cause another resource tracking system to perform a source transfer to the intermediary, and so on, until the sender-intermediary resource tracking system is instructed to perform a source transfer to the intermediary, thus transferring the sender's resource.The last intermediary can indicate both the source transfer and the destination transfer for the intermediary, while all other intermediaries in the transfer can indicate the source transfer for the intermediary upon receiving a transfer confirmation receipt confirming the destination transfer for the intermediary. The resource tracking system in the chain of transfers can successively transfer the constrained resource, starting from the resource tracking system between the last intermediary and the recipient (e.g., the last intermediary-recipient resource tracking system) and ending at the resource tracking system between the sender and the intermediary (e.g., the sender-intermediary resource tracking system). In some implementations, a resource tracking system can not be able to transfer the constrained resource if a resource tracking system closer to the recipient in the chain of transfers has not transferred the constrained resource. A notification of the completion of the transfer can also be sent to the sender and the recipient from any appropriate computing device or system involved in the transfer, including the trusted system and any intermediary. In some implementations, the intermediaries in the chain of transfers can be sub-contractors. For example, the chain of transfers can be constructed iteratively. The sender can contact a first intermediary that can agree to be responsible for the resource transfer to the recipient. The first intermediary can then find a second intermediary to act as a sub-contractor, agreeing to be responsible for the resource transfer from the first intermediary to the recipient. The second intermediary can then find a third intermediary to act as a sub-contractor, and so on, until the intermediary that will transfer the resource directly to the recipient is sub-contracted, completing the construction of the chain of transfers.

[0061] In some implementations, an intermediary can instruct a resource tracking system to make a resource transfer at any time. For example, once an intermediary receives an instruction from the sender authorizing the transfer based on the bid, the intermediary can send an instruction to the resource tracking system between the intermediary and the previous intermediary to make a source transfer to the intermediary. The resource tracking system can cache the instruction and can only make the transfer once the appropriate constraints for the resource used for the source transfer are set, and the conditions for the constraints are satisfied by receiving a signed message or receiving evidence of a successful destination transfer, such as a transfer confirmation receipt.

[0062] In the case of a transfer of a resource to a recipient, for example, on an intermediary-recipient resource tracking system, the transfer can include a notification to the recipient of the identity of the sender and / or an identification that the resource belongs to a particular transfer. This can allow the recipient to determine the purpose of the received resource. For example, the received resource can be used to settle a debt owed by the sender to the recipient. To judge that the debt has been satisfied, the transfer of the resource can include, for example, an account amount associated with the sender and other identifiers, so that the recipient can apply the received resource to the debt of the sender.

[0063] The sender can be a computing device or system used by the sender, where the sender can be any party that wishes to send or transfer resources under the control of the sender to some other party (e.g., a recipient). The sender can be used by, for example, any appropriate person, group, organization, or computer hardware and software, and can be any appropriate computing device or system. For example, the sender can be an appropriate computing device such as a laptop computer used by a person initiating a transfer of resources. The sender can be used by, for example, a person who wishes to transfer money to another person, business, or organization. The sender can be used by the sender and can be used on behalf of the sender. For example, the sender can be a person and the sender can be a bank computer system that can be used to initiate a transfer of resources on behalf of the sending party. The sender can also be, for example, a server system used by a server management system running on a server system. The sender can be able to initiate a transfer by requesting a quote (e.g., by sending a communication via any appropriate wired or wireless connection to an appropriate computing system or device for arranging a quote for the transfer). The connection can be a network connection such as a WAN or LAN connection, or can be an internal bus connection, for example, within a computing system. The sender can use the sender to send out a request for a quote, where the quote can include an amount that the sender wishes to transfer, an amount that the sender wishes the recipient to receive, a type of resource to be transferred from the sender, a type of resource to be received by the recipient, and what conditions can be acceptable for the transfer.

[0064] The request for a quote can specify an amount of a resource that the sender wishes to send or an amount of a resource that the sender wishes the recipient to receive. For example, the sender can wish to transfer funds to a recipient and can want to transfer dollars. The recipient can desire to receive euros. The sender, when requesting a quote, can specify that the sender will send out an amount of dollars and then the recipient will receive an amount of euros based on an exchange rate and any fees that can be charged for the transfer during the entire transfer. Alternatively, the sender can specify that the recipient should receive an amount of euros and the quote can include an amount of dollars that the sender will need to send out to ensure that the recipient receives the specified amount of euros, accounting for the exchange rate and fees. As another example, the sender can provide a particular computing resource such as processor cycles on a computing system controlled by the sender to a recipient who wishes to receive a different computing resource such as computer-readable memory space on a cloud-based memory system. Such a transfer can occur, for example, via an intermediary that provides various computing resources, thus being able to utilize and / or provide both processor time or cycles and memory space. Continuing the example, the sender can specify an amount to be transferred in processor operations or in memory amount. The quote will then provide the appropriate amount of processor operations required from the sender, taking into account an effective conversion factor between processor operations and memory space according to the intermediary.

[0065] Once the sender receives the offer, the sender can accept the offer and authorize the transfer of the sender's resource. The sender can authorize the transfer by, for example, sending a message to the appropriate system or computing device authorizing the setting of a constraint on the resource that the sender is going to transfer. The authorization can be sent, for example, to a trusted system or other system that can be responsible for coordinating the transfer, to an intermediary that has resources tracked by the same resource tracking system that is tracking the resource that the sender wants to send, or directly to the resource tracking system. Once the sender sends out the authorization of the transfer, the sender can wait to receive a notification of the success or failure of the transfer. The sender can also use the sender to check the resource tracking system to verify the transfer of the sender's resource.

[0066] The resource tracking system can be any appropriate system for tracking resources owned by the various participants and for transferring resources between the participants. The resource tracking system can be any appropriate computing device or system having any appropriate combination of hardware and software, such as a system run by a financial institution, a hardware or software component of a server system or computing device, or a distributed system (e.g., a cryptocurrency ledger or blockchain that can exist on multiple different computing devices and be coordinated in a cooperative manner, etc.), or can be centralized. The resource tracking system can track ownership of any quantity of resources of the participants. A participant, such as a sender, intermediary, or recipient, can have a pool of resources on the resource tracking system. The pool of resources for a participant on the resource tracking system can include an identification of the participant, as well as quantities of various resources owned or controlled by the participant and tracked by the resource tracking system. A participant can have more than one type of resource tracked by an individual resource tracking system.

[0067] For example, a resource tracking system that is a blockchain of a cryptocurrency can include a resource pool for each participant (e.g., individual or organization) that owns some amount of the cryptocurrency. The resource pool can identify the owner of the cryptocurrency, for example, using an encryption public key stored with the resource pool, such that the cryptocurrency can only be accessed by the participant with the corresponding private key. The resource pool can also include the amount of the cryptocurrency. The resource tracking system of the financial institution can be, for example, a ledger hosted on a server system. The resource pool can be an account owned by an account holder at the financial institution and can track various assets owned by the account holder and tracked by the financial institution. For example, a resource pool for a participant can include the type and amount of one or more currencies and the type and amount of other types of assets such as stocks, bonds, and deposit certificates. Alternatively or additionally, the resource pool can include or record ownership of other resources such as commodities or any resource that can be commoditized, finished physical goods, raw materials, computing resources, real estate, or any other resource that can be owned by an entity and transferred from one entity to another. The account holder can be identified by any suitable information and can need, for example, proof of identity such as a username and password for the account to access the account. The resource tracking system of the server system can be, for example, some suitable combination of hardware and software for tracking resources and ownership of those resources on the server system. For example, the resource tracking system of the server system can track computing resources such as storage space or processor time owned by each user of the server, where the user can be a physical individual or organization or a virtual user of the system such as a system account or various processes running on the server system.

[0068] The resource tracking system can track any type of resource. For example, the resource can be a currency, a cryptocurrency, a financial instrument, a commodity, or a computing resource such as processor time, volatile and non-volatile storage space, and network bandwidth. The record of ownership and amount of the resource by the resource tracking system can also be the resource itself or can be a separate record of resource ownership. For example, in a resource tracking system that is a blockchain of a cryptocurrency, the record of ownership of some amount of the cryptocurrency can be the cryptocurrency. In a resource tracking system that tracks ownership of a commodity, the record of ownership can correspond to a separately existing physical resource such as gold, oil, or other commodity. These resources can be transferred by transferring ownership, although the physical instance of the resource can not necessarily be transferred.

[0069] A resource tracking system can be able to receive a proposed transfer. For example, upon a sender requesting and accepting an offer for a transfer, a resource tracking system involved in the transfer can receive the proposed transfer based on the offer accepted by the sender. The proposed transfer can indicate to the resource tracking system that certain resources are to be transferred from one resource pool (a source resource pool) of the resource tracking system to another resource pool (a destination resource pool) of the resource tracking system. The proposed transfer can also indicate the type and amount of resources to be transferred, and conditions related to releasing constraints on the resources to be transferred and implementing the transfer of the resources. Upon receiving the proposed transfer, the resource tracking system can determine whether there is also an authorization to constrain the resources being transferred. If there is such a constraint authorization, the resource tracking system can place a constraint on the resources and send out a ready-to-transfer receipt. Otherwise, the resource tracking system can send out a proposed transfer receipt and wait to receive a proper constraint authorization for the transfer before sending out a ready-to-transfer receipt. The proposed transfer receipt and the ready-to-transfer receipt can be sent to any appropriate computing device or system, such as a trusted system, a coordinator of the transfer, or an intermediary used by an intermediary party that can be the owner of the destination resource pool on the resource tracking system, etc.

[0070] A resource tracking system can be able to place a constraint on a resource. For example, a resource tracking system can receive an authorization from a participant that owns a resource tracked by the resource tracking system to place a constraint on a specified amount of a specified type of resource related to a transfer. The constraint authorization can be sent along with a proposed transfer, or it can arrive later and can specify the associated proposed transfer. The resource tracking system can place the constraint on the specified amount of the specified type of resource in a resource pool owned by the participant that sent the constraint authorization. The constraint can prevent the transfer of the specified amount of the resource and / or a particular resource whose amount is equal to the specified amount, unless and until a condition of the constraint is satisfied. For example, a constraint can be placed on $20 of an account that has a balance of $100. The constraint can prevent the $20 from being transferred until a message is received indicating that a condition of the constraint is satisfied, thereby ensuring that the account will always have at least $20 when the constraint is placed. Likewise, for possibly different resources, such as in the case of a transfer of access to a particular block of memory, the constraint can prevent other transfers or uses of the particular resource unless and until a condition of the constraint is satisfied. The constraint can last for a period of time. The period of time can be any appropriate period of time, including seconds or fractions of a second, minutes, hours, or days. Upon expiration of the period of time, the resource tracking system can be able to release the constraint on the resource. The constraint can specify one or more conditions that must be satisfied in order to release. For example, the constraint can specify that a message is received from a third party indicating a level of trust associated with one or more parties before the constraint can be released. Likewise, the constraint can specify that a message is received from a third party indicating that the proposed transfer complies with relevant laws, regulations, and / or rules.

[0071] The resource tracking system can automatically implement the transfer of the constrained resource from the source resource pool to the destination resource pool (i.e., cause the transfer to occur) upon satisfying a condition associated with the constraint and receiving an instruction to perform the transfer. The condition can be, for example, receiving a signed message from a trusted system indicating that the transfer can proceed. For example, the resource tracking system can receive a signed message from a trusted system in connection with the constraint on the preparation of the transfer of the resource. Upon receiving the signed message from the trusted system, and an execution instruction sent from a computing device used by a participant that owns the destination resource pool used for the preparation of the transfer, the resource tracking system can automatically transfer the constrained resource from the source resource pool to the destination resource pool. The condition can be, for example, receiving a receipt that a destination transfer for the transfer, which can be the source transfer, has occurred on another resource tracking system. For example, the resource tracking system can receive a transfer confirmation receipt that can be cryptographically signed, where the transfer confirmation receipt can indicate that a participant that owns the destination resource pool has caused a resource that it owns on another resource tracking system to be transferred on that resource tracking system to another participant on the transfer chain. This can be evidence that the destination transfer for the source transfer is complete. Upon receiving the transfer confirmation receipt and an execution instruction sent from a computing device used by a participant that owns the destination resource pool used for the preparation of the transfer, the resource tracking system can automatically transfer the constrained resource from the source resource pool to the destination resource pool. The condition can be, for example, evidence that a smart contract is being executed. For example, the transfer chain can be set in connection with a smart contract, and can be transferred upon execution of the smart contract. A signed message from a system executing the smart contract can be received by the resource tracking system. Upon receiving the signed message indicating that the smart contract is being executed, the resource tracking system can automatically transfer the constrained resource from the source resource pool to the destination resource pool. The condition can also be, for example, a digital signature confirming the occurrence of an event, such as the delivery of a physical package or shipment by a delivery service.

[0072] Upon completion of the transfer, the resource tracking system can be able to send out a transfer confirmation receipt indicating that the transfer of the resource was successful. The transfer confirmation receipt can be sent to any appropriate computing device or system, including, for example, the trusted system, the coordinator of the transfer, or a computing device or system used by any other participant to the transfer, including, for example, a participant that owns the source resource pool used for the transfer. The transfer confirmation receipt from the resource tracking system can be evidence that the destination transfer for the source transfer is complete, satisfying the transfer condition at another resource tracking system.

[0073] A resource tracking system can implement a transfer of an encumbered resource by modifying the recorded amount of the resource as constrained by the party that owns the resource pool involved in the transfer. For example, to transfer an encumbered resource from a source resource pool to a destination resource pool, the resource tracking system can simultaneously or sequentially cause the recorded amount of the resource as owned by the party that owns the source resource pool to decrease and the recorded amount of the resource as owned by the party that owns the destination resource pool to increase. The amount of the recorded resource in the source resource pool can decrease by the same amount that the recorded resource in the destination resource pool increases. The amount can be, for example, the amount of the resource for which the encumbrance was placed, or can be a different amount, such as higher or lower, for example, to account for positive or negative fees involved in the transfer. The resource tracking system can be able to cause the amounts of resources tracked in resource pools on the resource tracking system to increase and decrease, and can only be able to transfer resources between two parties that both have resource pools on the resource tracking system. In the case of a transfer of an encumbered resource, the resource transfer system can transfer the specific resource that is encumbered, or can transfer an appropriate amount of resource that can or can not include any specific resource that can have been encumbered. For example, if an encumbrance is placed on $20 in an account that has $100, the encumbrance can be placed on any $20 or on a specific dollar amount (e.g., $1-20). In the case of a transfer of an encumbered dollar amount, the resource tracking system can transfer the specific dollar amount that is encumbered (e.g., $1-20), or can transfer any $20 (e.g., $11-30, or $81-100, or $51-60 and $75-84).

[0074] In some implementations, a resource tracking system can be able to transfer specific resources between resource tracking pools. For example, in transferring goods, a resource tracking system can be able to transfer goods encumbered at a specific location between resource pools. The amount of a resource that has a physical instance can also indicate a location at which the physical item is intended to be located. For example, gold can be encumbered in a specific storage facility. A resource tracking system can transfer resources located at a specific location by causing the amount of the resource in two resource pools to decrease and increase, respectively. For example, a resource pool can include gold stored in storage facility B and storage facility A. A resource tracking system can transfer gold from storage facility A to another resource pool. The resource tracking system can cause the recorded amount of gold stored at storage facility A in the source resource pool to decrease, and cause the recorded amount of gold stored at storage facility A in the destination resource pool to increase. The specific resource transferred by the resource tracking system can also include, for example, physical items that can exist in one or more copies, such as: artwork including paintings, sculptures, and prints; manufactured items; collectibles such as sports memorabilia and comic books; jewelry, gems, and any other such items; or mass-market goods such as smart phones and food.

[0075] The transfer of the constrained resource from the source resource pool to the destination resource pool using the resource tracking system can be deterministic upon satisfaction of the condition associated with the constraint and receipt of an instruction to perform the transfer. The resource tracking system, as a computing device or system having any suitable combination of hardware and software, can always automatically implement the transfer of the constrained resource upon satisfaction of the condition and receipt of the instruction to perform the transfer, without being able to interrupt or abort the transfer upon satisfaction of the condition and receipt of the instruction. This can eliminate the possibility that the constrained resource will not be transferred even after satisfaction of the condition associated with the constraint and receipt of the instruction to transfer, as the transfer can occur without the need for intervention from an outside party, human or other form. This can ensure that any party in the destination transfer that is transferred the resource and receives a transfer confirmation receipt can cause the resource to be transferred to that party in the source transfer by sending the transfer execution instruction and the transfer confirmation receipt.

[0076] The intermediary can be a computing device or system used by an intermediary party that agrees to participate in the transfer as part of the chain of transfers between the sender and the recipient. The intermediary can be used by, for example, any suitable person, group, organization, or computer hardware and software such as a program or process, and can be any suitable computing device or system. For example, the intermediary can be a person using a suitable computing device to participate in the transfer, a computing system belonging to an exchange, financial institution, or trader, or for example, can be part of a server management system running on a server system. The intermediary can be able to receive a request for a quote and reply to the quote, for example, by sending a communication to a suitable computing system or device that can be responsible for arranging the transfer from the sender to the recipient via any suitable wired or wireless connection. The connection can be a network connection such as a WAN or LAN connection, or can be an internal bus connection within a computing system, for example. The intermediary party uses the intermediary to reply to the quote request with quotes that can include, for example, any restrictions relating to the amount of resource that the intermediary party can be able to transfer, any exchange rate that the intermediary party can use, and any fees that the intermediary party can extract during the transfer.

[0077] An intermediary can be able to receive a proposed transfer. In the case where, for example, the sender using the sender accepts an offer sent out by the intermediary, the intermediary can be added to the chain of transfers between the sender and the recipient. The proposed transfer received by the intermediary can indicate only the portion of the overall transfer that the intermediary will participate in, which includes the resource tracking system from which the intermediary will receive resources and the resource tracking system to which the intermediary will transfer resources. The proposed transfer can also include conditions associated with the resource constraints that will be in place during the transfer. The intermediary can verify that the conditions related to the constraints can be a signed message received from a computing device or system trusted by all participants in the transfer indicating that the transfer can proceed, or that the source of the participant's resources can proceed when a receipt is received indicating that evidence of the destination transfer of the participant's resources has occurred. If the proposed transfer does not include any of these conditions related to the constraints, the intermediary can refuse to participate in the transfer.

[0078] An intermediary can be able to place constraints on resources controlled by the intermediary at the resource tracking system. For example, if a trusted system exists, upon receiving and verifying the proposed transfer, the intermediary can send an authorization to the resource tracking system that will transfer the intermediary's participant resources to constrain the intermediary's resources. If a trusted system does not exist, the intermediary sends an authorization to the resource tracking system that will transfer the intermediary's participant resources to constrain the intermediary's resources after receiving an indication that the resources to be transferred to the intermediary have been constrained at the resource tracking system that will transfer the resources to the intermediary. This can enable the intermediary to ensure that the resources for the source transfer are constrained and ready for transfer before the intermediary authorizes the constraints on the resources for the destination transfer.

[0079] The intermediary can be able to receive a signed message from the trusted system and send execution instructions to the resource tracking system based on receiving the signed message. For example, once the trusted system receives the ready-to-transfer receipt from all of the resource tracking systems in the chain of transfers, the trusted system can send a signed message to all of the computing devices and systems in the chain of transfers. Upon receiving the signed message, the intermediary sends execution instructions to the resource tracking systems. For example, the intermediary can send execution instructions to the resource tracking systems that have resource pools for both the intermediary and the participant that constrained the resource to be transferred to the intermediary, causing the resource to be transferred to the resource pool of the intermediary. If there are also resource tracking systems that have resource pools for both the intermediary and the recipient, the intermediary can send execution instructions to the resource tracking systems to transfer the resource from the intermediary to the recipient. Because the signed message from the trusted system can have fulfilled the conditions for transferring any constrained resources and can have received execution instructions from the intermediary, the resource tracking systems can automatically make the transfers.

[0080] The intermediary can be able to send execution instructions to the resource tracking systems based on receiving the ready-to-transfer receipt. For example, if there is no trusted system and the intermediary is the last intermediary in the chain of transfers, the intermediary, upon receiving a ready-to-transfer receipt indicating that the resource to be transferred to the intermediary can have been constrained at another resource tracking system, can send instructions to the resource tracking systems between the intermediary and the recipient to execute the transfer of the resource of the intermediary. This can ensure that in the case of a resource that was constrained as a source transfer for use by the intermediary being transferred to the recipient, the intermediary only sends instructions to transfer the resource of the intermediary to the recipient as a destination transfer for use by the intermediary.

[0081] The intermediary can be able to receive a transfer confirmation receipt from a resource tracking system and send the received transfer confirmation receipt to another resource tracking system. For example, if there is a trusted system, the intermediary can receive transfer confirmation data for any transfers made by the resource tracking systems according to instructions from the intermediary. If there is no trusted system, the intermediary can receive a transfer confirmation receipt from a resource tracking system that had a destination transfer of the intermediary, transferring a resource from the intermediary to another participant such as another intermediary or a recipient. The intermediary can then send the transfer confirmation receipt to a resource tracking system that constrained a resource to be transferred to the intermediary from, for example, another intermediary or a sender, as a source transfer for the intermediary. The intermediary can also send instructions to execute the transfer along with the transfer confirmation receipt to the resource tracking system. The transfer confirmation receipt can satisfy the constraints for the resource to be transferred to the intermediary, and thus the instructions to execute the transfer can cause the resource tracking system to automatically transfer the constrained resource to the intermediary.

[0082] A trusted system can be any suitable computing device or system that can be trusted by all parties and systems involved in a transfer chain between a sender and a recipient. For example, a trusted system can be associated with a financial institution or exchange, a computing resource trading system, an energy exchange system, and can be a trusted process on a server system. A trusted system can be any computing device or system in the transfer chain (e.g., one of the intermediary institutions), or can be a computing device or system outside of the transfer chain. A trusted system can also be a network (e.g., a switching network) that can include multiple intermediary institutions of multiple intermediary parties all trusted by the trusted system. A trusted system can also be a decentralized consensus network. A trusted system can also be a group of independent servers that can verify satisfaction of non-binding conditions (such as conditions related to a smart contract) and can provide signed messages to satisfy binding conditions related to various resource tracking systems in the transfer chain.

[0083] A trusted system can be selected by, for example, a sender, and can also be used by the sender to receive offers based on offers from intermediary parties and to coordinate transfers among all parties and computing devices and systems in the transfer chain. A trusted system can be able to communicate with all computing devices and systems involved in the transfer chain in any suitable manner (such as through a network connection), although the trusted system can not necessarily be able to communicate with a recipient. A trusted system can receive proposed transfer receipts and prepare transfer receipts, and can be able to verify when all resource tracking systems in the transfer chain sent prepared transfer receipts. Once all prepared transfer receipts are received, the trusted system can send a signed message (e.g., that can be cryptographically signed) to intermediary institutions and resource tracking systems in the transfer chain. The signed message from the trusted system can satisfy binding conditions at the resource tracking systems for the resources, and can cause the intermediary parties to send transfer execution instructions to the resource tracking systems, such that the resource tracking systems automatically transfer the resources bound, completing the transfer within the transfer chain.

[0084] For example, a sender can have an account at a financial institution that includes an amount of dollars. The sender can accept an offer to send 100 dollars to a recipient that can desire to receive euros, which involves a chain of transfers with an intermediary that has an account at the same financial institution as the sender and an account at another financial institution that also has an account for the recipient. The sender can send a constraint authorization to a resource tracking system or ledger of the financial institution where the sender has an account. The resource tracking system of the financial institution can also receive a proposed transfer that indicates that the resource tracking system should transfer 100 dollars from the account of the sender to the account of the intermediary. The constraint authorization sent by the sender can indicate that 100 dollars is to be constrained in the account of the sender. The resource tracking system of the financial institution can set a constraint on the 100 dollars in the account of the sender and can send out a prepared transfer receipt that indicates that the constraint is set. The prepared transfer receipt can be sent to a trusted system that can then send the prepared transfer receipt to the intermediary institution, or the prepared transfer receipt can be sent to a coordinator of transfers that can then send the prepared transfer receipt to the intermediary institution, or the prepared transfer receipt can be sent directly to the intermediary institution.

[0085] If a trusted system exists, the constraint of $100 in the sender's account can be a signed message received from the trusted system indicating that the transfer can proceed. The trusted system can receive a prepare transfer receipt from the resource tracking system of the financial institution that the sender and the intermediary have accounts with. The trusted system can then wait to receive another prepare transfer receipt from the resource tracking system of the financial institution that the intermediary and the recipient have accounts with. Upon receiving the prepare transfer receipt indicating that a constraint was set for $100 in the sender's account, the intermediary institution can send an authorization for a constraint for an amount of euros in the intermediary's account at the resource tracking system of the financial institution that the intermediary and the recipient have accounts with. The constraint can be for an amount of euros equal in value to $100, according to the exchange rate used by the intermediary institution and adjusted for any fees. For example, if the intermediary institution uses an exchange rate of 1.10 dollars for 1 euro and a fee of 0.5%, the intermediary institution can set a constraint for 90.46 euros, with the constraint condition being a signed message received from the trusted system indicating that the transfer can proceed. The resource tracking system, upon receiving the authorization to constrain 90.46 euros in the intermediary's account, can send a prepare transfer receipt to the trusted system indicating that 90.46 euros have been constrained in the intermediary's account. The trusted system can then send a signed message to the computing devices or systems used by all parties in the transfer chain, including the resource tracking systems and the intermediary institution, indicating that the transfer can proceed. In some implementations, the trusted system can not send a signed message to the sender and the recipient. The intermediary institution can send instructions to the two resource tracking systems in the transfer chain to perform the transfer, which, in combination with the signed message from the trusted system, can satisfy the constraint conditions for both $100 and 90.46 euros. The resource tracking system at the financial institution that the sender and the intermediary have accounts with, for example, can automatically transfer the constrained $100 from the sender's account to the intermediary's account, resulting in a decrease of $100 in the sender's account and an increase of $100 in the intermediary's account. The resource tracking system of the financial institution that the intermediary and the recipient have accounts with, for example, can automatically transfer the constrained 90.46 euros from the intermediary's account to the recipient's account, resulting in a decrease of 90.46 euros in the intermediary's account and an increase of 90.46 dollars in the recipient's account. The recipient can receive transfer confirmation receipts from both resource tracking systems and can send a notification to the sender and the recipient that the transfer is complete.

[0086] If no trusted system exists, the condition of restricting $100 in the sender's account can be receiving evidence that a destination transfer occurred at another resource tracking system for which the transfer of $100 from the sender to the intermediary can be used as a source transfer. The destination transfer can be, for example, a transfer of euros from the intermediary to the recipient using a resource tracking system at a financial institution that has accounts for both the intermediary and the recipient. Upon receiving the receipt indicating the ready transfer of $100 that is restricted, the intermediary institution can send instructions to the resource tracking system at the financial institution that has accounts for both the intermediary and the recipient to transfer euros from the intermediary's account to the recipient's account. Since no restriction is placed on the euros, no condition of the transfer can need to be met other than an indication of the transfer by the owner, i.e., the intermediary. The instructions sent by the intermediary institution can indicate that $90.46 should be transferred from the intermediary's account to the recipient's account. The resource tracking system receiving the instructions can complete the transfer, e.g., such that the intermediary's account is reduced by $90.46 and the recipient's account is increased by $90.46. The recipient can be notified of the transfer. The completion of the transfer of $90.46 can cause a transfer confirmation receipt to be sent to the intermediary institution. The intermediary institution can then send the transfer confirmation receipt to the resource tracking system of the financial institution that has accounts for the sender and the intermediary. The transfer confirmation receipt can be evidence that the destination transfer ($90.46) has been completed for the source transfer ($100). The resource tracking system, upon receiving the instructions from the intermediary institution to transfer $100, can determine that the condition of the restriction of $100 has been met and can automatically transfer $100, e.g., such that the sender's account is reduced by $100 and the intermediary's account is increased by $100. The intermediary institution can receive the transfer confirmation receipt and can notify the sender of the completion of the transfer.

[0087] For example, the sender can have an account at a first bank that includes an amount of dollars. The account can be recorded on a ledger of the first bank. The sender can owe the recipient 100 euros. The sender can send out a request for a quote. The request can specify that the sender will transfer dollars and the recipient will need to receive 100 euros. The quote request can be sent to various traders to obtain quotes, and a transfer chain can be assembled from the quotes. The sender can receive a quote that can be assembled from the quotes of the traders that are part of the transfer chain, and can specify how many dollars the sender will have to transfer and to which trader the dollars will be transferred in order for the recipient to receive 100 euros. For example, if the total transfer cost across the entire transfer chain is 1.5% of the amount the recipient is to receive, and the exchange rate is 1.10 dollars per 1 euro, then the sender can need to transfer out 111.65 dollars for the recipient to receive 100 euros. During the transfer, the first trader and the second trader can collectively secure 1.65 dollars (or 1.5% of the 110 dollars needed to ensure the recipient receives 100 euros) as a transfer cost.

[0088] The transfer chain can include a first trader and a second trader, where the first trader can have an account in dollars at a first bank and an account of cryptocurrency on a distributed ledger, and the second trader can have an account of cryptocurrency on the distributed ledger and an account in euros at a second bank (which is recorded on a ledger of the second bank). The recipient can also have an account in euros at the second bank. The cryptocurrency can be converted to dollars at an exchange rate of 1000 units per 1 dollar.

[0089] The first trader, the second trader, the first bank, the distributed ledger, and the second bank can each receive a proposed transfer individually. The proposed transfer can be received before, after, or along with the binding authorization sent by the sender to the first bank, indicating that the sender accepted the quote and initiated the transfers within the entire transfer chain. The proposed transfer can include conditions related to any constraints placed by the first bank, the distributed ledger, and the second bank. The constraint condition can be receiving a signed message from a trusted system, or receiving evidence of a completed destination transfer.

[0090] The proposed transfer received by the first bank can indicate that the first bank will receive a constraint of 111.65 dollars in the sender's account, set the constraint upon receiving the authorization from the sender, and transfer 116.50 dollars to the first trader's account upon satisfying the constraint condition and receiving instructions from the first trader.

[0091] The proposed transfer received by the first exchange can represent that the first exchange will receive 111.65 USD into the first bank's account as the source transfer, and will authorize a constraint of 110,770 units of cryptocurrency in the account of the distributed ledger to transfer to the second exchange as the destination transfer, which accounts for 0.08% of the transfer cost of 110 USD.

[0092] The proposed transfer received by the distributed ledger can represent that the distributed ledger will receive a constraint of 110,770 units of cryptocurrency in the first exchange's account, set the constraint upon receiving authorization from the first exchange, and transfer 110,770 units to the second exchange's account upon satisfying the constraint condition and receiving instructions from the first exchange.

[0093] The proposed transfer received by the second exchange can represent that the second exchange will receive 110,770 units of cryptocurrency from the first exchange as the source transfer, and will authorize a constraint of 100 EUR in the second bank's account to send to the recipient, or instruct the second bank to transfer 100 EUR from its account to the recipient's account without a constraint, as the destination transfer, which accounts for 0.07% of the transfer cost of 110 USD.

[0094] The proposed transfer received by the second bank can represent that the second bank will receive a constraint of 100 EUR in the second bank's account, set the constraint upon receiving authorization from the second exchange, and transfer 100 EUR to the recipient's account upon satisfying the constraint condition and receiving instructions from the first exchange, or transfer 100 EUR from the second exchange's account to the recipient's account without setting any constraint upon receiving instructions from the second exchange.

[0095] The sender can send a constraint authorization to the first bank's ledger, thereby authorizing the first bank to set a constraint of 111.65 USD in the sender's account in conjunction with the proposed transfer. The constraint authorization can be a cryptographically signed message from the sender. Upon receiving the constraint authorization, the first bank's ledger can set the constraint of 111.65 USD in the sender's account on the first bank's ledger, and can send out a prepared transfer receipt representing that a constraint was set on 111.65 USD in the sender's account at the first bank.

[0096] The first merchant can receive the prepared transfer receipt sent by the first bank's ledger. This can indicate to the first merchant that the $111.65 to be transferred to the first merchant is bound in the sender's account at the first bank. The first merchant can send a binding authorization to the distributed ledger, authorizing the distributed ledger to bind 110,770 units of cryptocurrency in the first merchant's account in conjunction with the proposed transfer. Upon receiving the binding authorization, the distributed ledger can bind 110,770 units of cryptocurrency in the first merchant's account and can send out a prepared transfer receipt indicating that 110,770 units of cryptocurrency are bound in the first merchant's account at the distributed ledger.

[0097] The second merchant can receive the prepared transfer receipt sent by the distributed ledger. This can indicate to the second merchant that 110,770 units of cryptocurrency to be transferred to the second merchant are bound in the first merchant's account at the distributed ledger.

[0098] If there is a trusted system and the binding condition as indicated in the proposed transfer is received as a signed message from the trusted system, the second merchant can send a binding authorization to the second merchant's account, authorizing the second bank to bind 100 euros in the second merchant's account in conjunction with the proposed transfer. Upon receiving the binding authorization, the second bank ledger can bind 100 euros in the second merchant's account and can send out a prepared transfer receipt indicating that 100 euros are bound in the second merchant's account at the second bank.

[0099] The trusted system can receive the prepared transfer receipts from the first bank's ledger, the distributed ledger, and the second bank's ledger. The trusted system can confirm that the appropriate amount of the appropriate asset type is bound at the ledgers of the transfer chain. The trusted system can then send a signed message to the first bank's ledger, the first merchant, the distributed ledger, the second merchant, and the second bank's ledger.

[0100] The signed message can satisfy conditions related to constraints at each ledger and can cause the first trader to send an execute instruction to the first bank's ledger and the second trader to send an execute instruction to the distributed ledger and the second bank's ledger. The first bank's ledger, upon receiving the signed message from the trusted system and the execute instruction from the first trader, can release the constraint of $111.65 in the sender account and transfer the $111.65 out of the sender account and into the first trader account. The distributed ledger, upon receiving the signed message from the trusted system and the execute instruction from the second trader, can release the constraint of 110,770 units of cryptocurrency in the first trader account and transfer the 110,770 units of cryptocurrency out of the first trader account and into the second trader account. The second bank's ledger, upon receiving the signed message from the trusted system and the execute instruction from the second trader, can release the constraint of 100 euros in the second trader account and transfer the 100 euros out of the sender account and into the recipient account. Each ledger can send out a transfer confirmation receipt that can be used to confirm the successful transfer.

[0101] If the trusted system does not exist, and the constraint condition as indicated in the proposed transfer is the receipt of evidence of the completion of the destination transfer, the second trader can send an execute instruction to the second bank's ledger to transfer 100 euros from the second bank's account to the recipient account upon receiving the prepare transfer receipt from the distributed ledger. The second bank's ledger, upon receiving the execute instruction from the second trader, can perform the transfer, thereby taking 100 euros from the second trader account and adding the 100 euros to the recipient account. The second bank's ledger can send out a transfer confirmation receipt, which can indicate the successful transfer of 100 euros from the second trader to the recipient.

[0102] The second trader can receive the transfer confirmation receipt and can send the transfer confirmation receipt and the execute instruction to the distributed ledger. The transfer confirmation receipt can indicate to the distributed ledger that the destination transfer of 100 euros from the second trader to the recipient was successfully completed, thereby satisfying the constraint of 110,770 units of cryptocurrency in the first trader account. The distributed ledger can release the constraint of 110,770 units of cryptocurrency in the first trader account and can transfer the 110,770 units of cryptocurrency out of the first trader account and into the second trader account. The distributed ledger can send out a transfer confirmation receipt, which can indicate the successful transfer of 110,770 units of cryptocurrency from the first trader to the second trader.

[0103] The first broker can receive the transaction confirmation receipt and can send the transfer confirmation receipt and the execution instruction to the first bank's ledger. The transfer confirmation receipt can indicate to the first bank's ledger that the destination transfer of 110,770 units of cryptocurrency from the first broker to the second broker was successfully completed, satisfying the 111.65 dollar constraint in the sender account. The first bank's ledger can release the 111.65 dollar constraint in the sender account and can transfer the 111.65 dollars out of the sender account and into the first broker account. The first bank's ledger can send out a transfer confirmation receipt, which can indicate the successful transfer of 111.65 dollars from the sender to the first broker.

[0104] In this way, the sender can send out 111.65 dollars and the recipient can receive 100 euros. Since the first broker can receive 111.65 dollars and transfer out 110,770 units of cryptocurrency worth 110.77 dollars, the first broker can charge a transfer fee of 0.88 dollars. Since the second broker can receive 110,770 units of cryptocurrency worth 110.77 dollars and can transfer out 100 euros worth 110 dollars, the second broker can charge a transfer fee of 0.77 dollars in the form of 770 units of cryptocurrency.

[0105] Each intermediary can request a minimum guaranteed transfer as part of the quote sent from the intermediary institution. The minimum guaranteed transfer can indicate some minimum amount of resources that will be transferred to the intermediary in the event of a transfer failure. The minimum guarantee can be based on, for example, the requesting party or the sender's trustworthiness of the intermediary, the percentage of resources of the intermediary that can need to have constraints placed on them during the transfer, and the lockout timeout that the intermediary institution is requesting the transfer for. The minimum guaranteed transfer can ensure that in the event of a transfer failure, for example, due to malicious action by the sender, the intermediary can be compensated for the resources that had constraints placed on them and thus could not be used for a period of time before the transfer failure. Each intermediary in the transfer chain can have a smaller minimum guaranteed transfer than the previous intermediary, since each intermediary can have a shorter lockout timeout than the previous intermediary, and each intermediary can need to cover the minimum guaranteed transfer that all subsequent intermediaries in the transfer chain can need.

[0106] Guaranteed minimum transfer can occur when a transfer fails and the constraints on the resource are rolled back. For example, a sender can set up a transfer using a sender request and approved offer. After constraints are placed on the sender's resources at the sender-intermediary resource tracking system, the sender can send a cancel message to the resource tracking system to cancel the transfer and remove the constraints on the sender's resources. The resource tracking system can be aware of the guaranteed minimum transfer and can release the constraints on the portion of the sender's resources that are not covered by the guaranteed minimum. In this way, the intermediary can still send execution instructions to the resource tracking system to cause the guaranteed minimum transfer of the sender's resources to the intermediary. Likewise, if there are other intermediaries involved in the transfer, these participants can require the guaranteed minimum transfer of the constrained resources from the previous intermediary. The guaranteed minimum transfer of an intermediary can cover the resources that the intermediary expects to require as a guaranteed minimum and the resources that the next intermediary will require as a guaranteed minimum. In this way, all intermediaries in a transfer can require some resources from the sender in the event of a failed transfer, preventing a malicious sender from intentionally setting up multiple failed transfers to tie up resources belonging to intermediaries.

[0107] As used herein, a constraint (or "lock") timeout refers to the amount of time that an intermediary will agree to have its resources constrained at the resource tracking system. If the transfer from the sender to the recipient is not completed before the lock timeout expires, the constraints on the resources can be released and the transfer can fail. In the absence of a trusted system, the lock timeout can be short, which can prevent malicious behavior from tying up resources constrained by intermediaries for long periods of time. In the presence of a trusted system, the lock timeout can be long (e.g., days or unlimited), because all participants can trust the trusted system and therefore are less worried about the risk posed by malicious behavior. The lock timeout in a transfer chain can be specified by the requestor of the offer (e.g., the sender) or by the coordinator of the transfer. Intermediaries can also advertise acceptable lock timeouts for transfers on various resource tracking systems.

[0108] Any amount of resource types can be used between the sender and the recipient. For example, the transfer can involve three intermediaries with three intermediary institutions. The sender can transfer dollars to a first intermediary on a first resource tracking system with a pool of resources at the sender and the first intermediary. The first intermediary can transfer cryptocurrency to a second intermediary on a second resource tracking system with a pool of resources at the first intermediary and the second intermediary. The second intermediary can transfer a commodity (e.g., oil) to a third intermediary on a third resource tracking system with a pool of resources at both the second intermediary and the third intermediary. The third intermediary can transfer euros to the recipient on a fourth resource tracking system with a pool of resources at both the third intermediary and the recipient. In this way, the sender can send euros to the recipient using dollars.

[0109] The value of the resources transferred by a participant in a destination transfer of the participant can differ from the value of the resources transferred to the participant in a source transfer of the participant for each transfer. For example, the value of the cryptocurrency transferred from the first intermediary to the second intermediary can be less than the value of the dollars transferred from the sender to the first intermediary. The difference in value can be, for example, a transfer cost or fee imposed by the intermediary on the transfer. Likewise, the value of the oil transferred by the second intermediary to the third intermediary can be less than the value of the cryptocurrency transferred by the first intermediary to the second intermediary. The offers provided by the intermediaries can include any fees or transfer costs, and the sender can determine the amount of the resource to constrain based on these fees or transfer costs and the value of the resource the sender wants the recipient to receive. For example, the transfer cost or fee can be zero, or can be negative, such that the participant transfers a resource of greater value than the resource the participant has been transferred. In some implementations, the transfer cost can be constrained to and transferred to an appropriate participant outside of the transfer chain. For example, the resource tracking system can constrain the transfer cost resulting from a participant when transferring resources to the participant in a separate account. The resources to cover the transfer cost can be constrained in the participant's aggregate and later transferred to the participant's account independent of any particular transfer chain. In some implementations, the resource tracking system can impose its own transfer costs on source transfers that are part of a transfer chain. These transfer costs can be included as part of the offer from the intermediary transferring resources on the resource tracking system, or can be offered separately. The resource tracking system can collect the transfer costs at the time of transfer execution, such that in addition to transferring resources to the intermediary, the recipient, or the sender in a loop transaction, the appropriate resources are transferred to the resource tracking system's account.

[0110] A transfer can be initiated by a participant other than the sender. For example, the recipient can use the recipient to initiate a pull transfer. In a pull transfer, the recipient can request, receive, and accept an offer, and can then obtain authorization from the sender to bind the sender's resources to initiate a transfer. The sender can be obligated to authorize the binding for the resources, and can automatically send the binding authorization from the sender upon request from the recipient. A transfer can also be initiated by a participant that is not the sender or the recipient. For example, the sender and the recipient can agree to a smart contract, which can be a computer-based contract that uses any suitable combination of hardware and software to determine when contract conditions are met and to execute the terms of the contract. For example, the smart contract can specify that the sender will transfer $100 in euros to the recipient if a condition is met. Upon detecting that the condition is met, a computing device or system that hosts the smart contract can request, receive, and accept an offer to transfer $100 in euros from the sender to the recipient. The computing device of the smart contract can be able to bind the sender's resources ($100) to initiate the transfer, or can be able to otherwise force the sender to automatically send such a binding authorization.

[0111] A transfer chain can include parallel paths. For example, a sender can wish to transfer a large amount of resources to a recipient. There can not be a suitable intermediary that alone controls enough resources on the recipient's resource tracking system for the pool of resources to make the transfer to the recipient. The transfer chain can be set up with parallel paths, such that the sender transfers resources to more than one intermediary, and the recipient receives resources from more than one intermediary. The sender can transfer resources to the intermediaries on the same resource tracking system for the pool of resources for all participants, or on separate resource tracking systems. Likewise, the recipient can receive resources on the resource tracking system for the pool of resources for the recipient and all participants that transfer resources to the pool of resources for the recipient, or on separate resource tracking systems. Since the paths can be parallel, it can be possible for a transfer to fail across one of the paths while a transfer succeeds on the other path.

[0112] For example, a sender can wish to transfer $1,000,000 in the form of Euros to a recipient. No intermediary can have enough Euros in a resource pool on a resource tracking system of the recipient to complete the transfer. For example, parallel paths can be set up in the transfer chain, with a first path through a first intermediary institution of a first intermediary having Euros worth $600,000 in a resource pool on a resource tracking system between the first intermediary and the recipient, and a second path through a second intermediary institution of a second intermediary having Euros worth $400,000 in the resource pool on the same resource tracking system. Transfers along the first path and the second path can be performed in parallel. For example, the sender can send a constraint authorization for $1,000,000 to a resource tracking system of which the sender, the first intermediary, and the second intermediary all have resource pools. The constraint authorization can indicate that $600,000 is being constrained for the first intermediary, and $400,000 is being constrained for the second intermediary. A prepare transfer receipt can be sent to the first intermediary institution and the second intermediary institution. Upon receiving the prepare transfer receipt, the first intermediary institution can send an execute instruction to the resource tracking system of the first intermediary having Euros worth $600,000, causing the Euros to be transferred to the resource pool of the recipient, and the second intermediary institution can send an execute instruction to the same resource tracking system, causing the Euros worth $400,000 to be transferred to the resource pool of the recipient. Both the first intermediary institution and the second intermediary institution can receive transfer confirmation receipts, which are sent to the resource tracking system of the $1,000,000 constraint of the sender along with the execute instructions. The transfer confirmation receipts can satisfy the $1,000,000 constraint, and the execute instructions can cause the resource tracking system to transfer $600,000 to the resource pool of the first intermediary and $400,000 to the resource pool of the second intermediary, completing the transfer. If, for example, one of the parallel paths fails, the second intermediary institution does not perform the transfer to the recipient, and if, for example, the other path can still be successful, the first intermediary institution can still perform the transfer to the recipient, receive the transfer confirmation receipt, and use the transfer confirmation receipt to fulfill the constraint of the sender for $600,000 of the $1,000,000, causing $600,000 to be transferred to the resource pool of the first intermediary institution.

[0113] The chain of transfers can be circular. For example, the sender can make a purchase from the recipient. The chain of transfers can include a forward portion, through which resources can be transferred from the sender to the recipient via any suitable number and arrangement of intermediate institutions and resource tracking systems, and a reverse portion, through which resources can be transferred from the recipient to the sender via any suitable number and arrangement of intermediate institutions. The recipient can likewise act on intermediate institutions in the circular chain of transfers. For example, where the recipient receives an indication that the last intermediate institution in the forward direction placed a constraint on the resource at the last resource tracking system in the forward direction, the recipient can in turn place a constraint on the recipient's resource at the first resource tracking system in the reverse direction. If there is only one resource tracking system in the reverse direction, then depending on the constraints placed on the resource in the circular chain of transfers, the sender or a trusted system can receive a prepared transfer receipt from the resource tracking system, or the recipient can instruct the resource tracking system to perform the transfer of the recipient's resource to the sender. For example, the constraint in the circular chain of transfers can be a pre-agreed signed receipt. In the circular chain of transfers, the sender can be responsible for sending out the signed receipt, or delegate that responsibility to a third party. The circular chain of transfers can be a non-circular chain of transfers with the sender at both ends of the chain.

[0114] The resources involved in a transfer can be computing resources, e.g., processing time on CPUs, GPUs, cryptographic processors, or other general- or special-purpose processor types; persistent or lease-based storage (including non-volatile storage such as disk-based HDDs, solid state disks, and other forms of non-volatile flash storage, as well as volatile storage such as cache and RAM); and bandwidth including, e.g., total amounts of incoming and outgoing network traffic, and maximum speeds of incoming and outgoing network traffic. For example, a sender can have an account on a server system that includes an amount of processor time that the sender can have access to use on the server system. The sender can be, e.g., a user or organization that has an account on the server system, or can be a process or program running on the server system (which can or can not have a user account on the server system), but can have a separate tracking of resources that can be used on the server system. The sender can accept an offer to send 1 TB of SSD storage for 12 months to a recipient that can expect to receive CPU processing time, involving a transfer chain with an intermediary that has an account on the same server system as the sender, and an account on another server system on which the recipient also has an account. The sender can send a constraint authorization to a resource tracking system of the server system on which the sender has an account. The resource tracking system of the server system can also receive a proposed transfer, indicating that the resource tracking system should transfer 1 TB of SSD storage for 12 months from the account of the sender to the account of the intermediary. The constraint authorization sent by the sender can indicate that 1 TB of SSD storage for 12 months is to be constrained in the account of the sender. The resource tracking system of the server system can set a constraint on 1 TB of SSD storage for 12 months in the account of the sender, and can send out a prepared transfer receipt indicating that the constraint was set. The prepared transfer receipt can be sent to a trusted system, which can then send the prepared transfer receipt to the intermediary, or the prepared transfer receipt can be sent to a coordinator of the transfer, which can then be sent to the intermediary, or the prepared transfer receipt can be sent directly to the intermediary.

[0115] If a trusted system exists, the condition that 1 TB of SSD storage is constrained for 12 months in the sender's account can be that a signed message is received from the trusted system indicating that the transfer can proceed. The trusted system can receive a ready-to-transfer receipt from the resource tracking system of the financial institution that the sender and the intermediary have accounts with. The trusted system can then wait to receive another ready-to-transfer receipt from the resource tracking system of the financial institution that the intermediary and the recipient have accounts with. Upon receiving the ready-to-transfer receipt indicating that 1 TB of SSD storage for 12 months is set as a constraint in the sender's account, the intermediary institution can send an authorization at the resource tracking system of the financial institution that the intermediary and the recipient have accounts with to release a quantity of CPU processing time from the intermediary's account subject to a constraint. The constraint can be for a quantity of CPU processing time equal in value to 1 TB of SSD storage for 12 months, according to the exchange rate used by the intermediary institution and adjusted for any fees. For example, if the intermediary institution uses an exchange rate of 1 TB of SSD storage per month for 600 hours of CPU processing time and uses a fee of 0.5%, the intermediary institution can set a constraint of 7164 hours of CPU processing time subject to receiving a signed message from the trusted system indicating that the transfer can proceed. The resource tracking system, upon receiving the authorization to constrain 7164 hours of CPU processing time in the intermediary's account, can send a ready-to-transfer receipt to the trusted system indicating that 7164 hours of CPU processing time is constrained in the intermediary's account. The trusted system can then send a signed message to the computing devices or systems of all parties in the transfer chain including the resource tracking systems and the intermediary institution, where the signed message indicates that the transfer can proceed. In some implementations, the trusted system can not send the signed message to the sender and the recipient. The intermediary institution can send instructions to the two resource tracking systems in the transfer chain to perform the transfer, where the instructions, in combination with the signed message from the trusted system, can satisfy the constraint conditions for 1 TB of SSD storage for 12 months and 7164 hours of CPU processing time. The resource tracking system at the server system that the sender and the intermediary have accounts with may, for example, automatically transfer the constrained 1 TB of SSD storage for 12 months from the sender's account to the intermediary's account, thereby decreasing the sender's account by 1 TB of SSD storage for 12 months and increasing the intermediary's account by 1 TB of SSD storage for 12 months. The resource tracking system at the server system that the intermediary and the recipient have accounts with may, for example, automatically transfer the constrained 7164 hours of CPU processing time from the intermediary's account to the sender's account, thereby decreasing the intermediary's account by 7164 hours of CPU processing time and increasing the recipient's account by 7164 hours of CPU processing time.The recipient can receive transfer confirmation receipts from both resource tracking systems and can send a notification of the completion of the transfer to the sender and the recipient.

[0116] If there is no trusted system, the 12-month 1 TB SSD memory constraint in the sender's account can be receiving evidence that a destination transfer was sent at another resource tracking system, where the 12-month 1 TB SSD memory transfer from the sender to the intermediary can be used as a source transfer for the other resource tracking system. The destination transfer can be, for example, a transfer of CPU processing time from the intermediary to the recipient with a resource tracking system at a server system where the intermediary and the recipient have accounts. Upon receiving the prepared transfer receipt indicating the 12-month 1 TB SSD memory constraint, the intermediary can send an instruction to the resource tracking system at the server system where both the intermediary and the recipient have accounts to transfer the CPU processing time from the account of the intermediary to the account of the recipient. Since there is no constraint on the CPU processing time, there is no condition to be met for the transfer, as long as the owner (i.e., the intermediary) indicates the transfer. The instruction sent by the intermediary can indicate that 7164 hours of CPU processing time should be transferred from the account of the intermediary to the account of the recipient. The resource tracking system receiving the instruction can, for example, complete the transfer, thereby decreasing the account of the intermediary by 7164 hours of CPU processing time and increasing the account of the recipient by 7164 hours of CPU processing time. The recipient can be notified of the transfer. The completion of the transfer of 7164 hours of CPU processing time can cause a transfer confirmation receipt to be sent to the intermediary. The intermediary can then send the transfer confirmation receipt to the resource tracking system of the server system where the sender and the intermediary have accounts. The transfer confirmation receipt can be evidence that the destination transfer (7164 hours of CPU processing time) for the source transfer (the 12-month 1 TB SSD memory transfer) has been completed. The resource tracking system, upon receiving the instruction from the intermediary to transfer the 12-month 1 TB SSD memory, can determine that the $100 constraint condition has been met and can, for example, automatically transfer the 12-month 1 TB SSD memory, thereby decreasing the account of the sender by 12-month 1 TB SSD memory and increasing the account of the intermediary by 12-month 1 TB SSD memory. The intermediary can receive the transfer confirmation receipt and can notify the sender of the completion of the transfer.

[0117] The transfer of computing resources between accounts on different server systems can allow, for example, the trading of owned computing resources between parties using different cloud computing platforms. The transfer can also allow a party having accounts on separate cloud computing platforms to use computing resources controlled by the party on a server system of one of the cloud computing platforms to obtain computing resources used by an account on a server system of a different cloud computing platform. In this case, the same party can be both the sender and the recipient, as the party can control two accounts at two server systems and can use an intermediary to facilitate the obtaining of computing resources on one server system using computing resources on another server system.

[0118] The resources in the transfer can also be computing resources from any computing device connected to a network such as the Internet, output from small-scale manufacturing and 3D printing devices, shares of time on smart devices, such as vehicles and shipped physical goods, and the like. The shipped physical goods can be, for example, physical gold or other tangible commodities or goods. Constraints on the shipped physical goods can be enforced by, for example, a delivery service that implements the delivery of the physical goods.

[0119] Communications between computing devices and systems of a party can occur directly between, for example, the sender, intermediary, recipient, and resource tracking system, or can be routed in any suitable manner. For example, the communications can be routed via a trusted system, or via a transfer coordinator that can not be a trusted system but can coordinate the transfer process. The transfer coordinator can be any suitable computing device or system that can be part of a transfer chain (e.g., an intermediary, etc.) or can be external to the transfer chain. The communications can occur directly using any suitable communication protocol, such as HTTPS, and the like. In some implementations, instead of a message being sent by one computing device or system to another computing device or system, the computing device or system can check for a message on the other computing device or system. For example, if there is a trusted system for a transfer chain, other computing devices and systems in the transfer chain can be able to check for a message, such as a signed message indicating that the transfer can proceed, in the trusted system instead of waiting for the trusted system to send out the message.

[0120] All communications between the participating computing devices and systems (including proposed transfers, execution instructions for the transfer, signed messages from trusted systems, proposed transfer receipts and prepared transfer receipts, and transfer confirmation receipts) can be cryptographically signed. For example, communications can be cryptographically signed using a private key constrained by the participant sending the communication and verified using a corresponding public key constrained by the participant receiving the communication, thus confirming the communication's validity. This ensures that only the participants involved in the transfer chain can communicate, preventing malicious participants from inserting communications into the transfer chain. Communication can also use symmetric encryption, or a shared key or token between the communicating computing devices and systems. Communication can also occur on a private network to which the systems in the transfer chain can connect. This private network can be encrypted. Using a private network for communication allows systems in the transfer chain to waive the use of cryptographic signatures on communications transmitted between these systems. Communication can also occur between systems in the transfer chain using any other suitable form of secure communication (e.g., including quantum entanglement).

[0121] Transfer chains can be used to make payments for HTTP requests. For example, the sender can be a computing device used to submit an HTTP request, for example, via any suitable web browser. The HTTP request could be for an article or other content type hosted on the web, or for a file to be downloaded. Submitting an HTTP request also allows the transfer chain to establish a connection between the sender and the host, owner, or provider of the requested content or file. The transfer chain can transfer resources (such as funds from a designated account belonging to the sender) in any form acceptable to the recipient to the host or owner, who could be the recipient. For example, the sender could send cryptocurrency, and the recipient could receive US dollars. The transfer chain can use any suitable intermediary between the sender and the recipient. The transfer could be, for example, a micropayment.

[0122] Figure 1 An example system suitable for a resource transfer system, based on an implementation of the disclosed subject matter, is shown. The intermediate computing device 100 may include an actuator 110, a quote generator 120, and a memory 140. The intermediate computing device 100 may be any suitable computing device (e.g., such as...). Figure 22The computer 20, etc.) or components thereof, for implementing the enforcer 110, the offer generator 120, and the storage 140. The intermediary computing device 100 can be a single computing device, or can include multiple connected computing devices, and can be, for example, a laptop, a desktop, a personal server, a server farm, or a distributed server system, or can be a virtual computing device or system. The intermediary computing device 100 can be part of a computing system and network architecture, or can be otherwise connected to the computing system and network architecture. The enforcer 110 can be any suitable combination of hardware and software on the intermediary computing device 100 for verifying conditions related to a proposed transfer, sending out a constraint authorization that allows a resource owned by an intermediary party to be bound, and determining when an execution instruction can be issued to implement a transfer based on receipts and messages in the storage 140, and for sending out the execution instruction. The offer generator 120 can be any suitable combination of hardware and software on the intermediary computing device 100 for receiving an offer request, and generating and sending out an offer in response to the offer request. The storage 140 can store receipts and other messages in any suitable manner, such as a proposed transfer message 142, a ready-to-transfer receipt 144, a transfer confirmation receipt 146, or a signed message from a trusted system 148, etc. The intermediary computing device 100 can be an intermediary used by an intermediary party, such as a trader, an exchange, or a user of a server system, etc.

[0123] The enforcer 110 can be any suitable combination of hardware and software for verifying conditions related to a proposed transfer 142, sending out a constraint authorization to constrain resources owned by an intermediary party to be bound based on a prepared transfer receipt 144, and determining when to issue an execution instruction to implement a transfer based on the prepared transfer receipt 144, a transfer confirmation receipt 146, or a signed message 148, and for sending out the execution instruction, for example, to a resource tracking system. The enforcer 110 can be capable of receiving a proposed transfer 142 from the memory 140. The proposed transfer 142 can include, for example, an indication of a source transfer and a destination transfer involving resources owned by an intermediary party using the intermediary institution computing device 100 as part of an offer sent out by the intermediary party and accepted by a sending party. The enforcer 110 can be capable of determining whether conditions in the proposed transfer 142 related to constraints on resources for the source transfer and the destination transfer are the same, for example, receiving a signed message 148 from a trusted system, or whether the conditions for the source transfer are successfully received a transfer confirmation receipt 146 representing the destination transfer. If any of the conditions are determined to be true, the enforcer 110 can be capable of accepting the proposed transfer 142. The enforcer 110 can also be capable of determining whether the proposed transfer includes a transfer cost or fee sent out by the intermediary institution computing device 100 in response to a request for an offer, a guaranteed minimum transfer, and a lockout timeout, and rejecting the proposed transfer if any are not included. The enforcer 110 can be capable of receiving a prepared transfer receipt 144 from the memory 140, where the prepared transfer receipt 144 can have been stored after being received from another computing device or system. The enforcer 110 can be capable of authorizing a constraint at a resource tracking system for resources owned by the intermediary party based on the prepared transfer receipt 144, or can issue an execution instruction to implement a transfer on the resource tracking system based on the prepared transfer receipt 144. The enforcer 110 can be capable of receiving a transfer confirmation receipt 146 or a signed message 148 from the memory 140, where the transfer confirmation receipt 146 or the signed message 148 can have been stored in the memory 140 after being received at the intermediary institution computing device 100 from another computing device or system. The enforcer 110 can be capable of sending an execution instruction to implement a transfer on the resource tracking system upon receiving the signed message 148, and can be capable of sending the transfer confirmation receipt 146 and an execution instruction to implement a transfer on the resource tracking system upon receiving the transfer confirmation receipt 146. The execution instruction can implement, for example, a transfer of a resource to a resource pool owned by the intermediary party, or a transfer of a resource outside of a resource pool owned by the intermediary party.

[0124] The quotation generator 120 may be able to receive requests for quotations, for example, from a trusted system, a transfer coordinator, or other computing device or system. A request for a quotation may include source and destination transfers that the quotation requester wants the intermediary to perform using the intermediary computing device 100, including the type and amount of resources involved in both the source and destination transfers, and the identities of the participating parties. The quotation request may also identify resource tracking systems where the source and destination transfers should occur. The quotation generator 120 may be able to generate a quotation in response to a request for a quotation. The quotation may include any transfer costs or fees, guaranteed minimum transfer amounts, and lockout timeouts that the intermediary may wish to impose on the conditions of acceptance of the proposed transfer based on the quotation request.

[0125] Figure 2 An example system suitable for a resource transfer system, based on an implementation of the disclosed subject matter, is shown. The resource tracking computing device 200 may include a resource manager 210, a receipt generator 220, and a memory 240. The resource tracking computing device 200 may be any suitable computing device (e.g., such as...). Figure 22 The computer 20 (or similar device) or its components are used to implement the resource manager 210, receipt generator 220, and memory 240. The resource tracking computing device 200 may be a single computing device or may include multiple connected computing devices, and may be, for example, a laptop, desktop computer, personal server, server farm, or distributed server system, or may be a virtual computing device or system. The resource tracking computing device 200 may be part of a computing system and network architecture, or may be otherwise connected to a computing system and network architecture. The resource manager 210 may be any suitable combination of hardware and software on the resource tracking computing device 200 for managing resources belonging to the parties and tracked by the resource tracking computing device 200. These resources may be tracked in resource pools (e.g., resource pools 242 and 244 in memory 140). The receipt generator 220 may be any suitable combination of hardware and software for generating receipts such as prepare transfer receipt 144 and transfer confirmation receipt 146 based on actions of the resource manager 210. The memory 240 can store pending transfers 246 and resource pools such as resource pools 242 and 244 for each participant having resources tracked by the resource tracking computing device 200. The memory 240 can also store receipts such as transfer confirmation receipts 248 or signature messages 250. Resource pools 242 and 244 can be records of resources owned by the participants and tracked by the resource tracking computing device 200, including the type and quantity of resources, and the identifiers of the participants who own or control the resources in the resource pools. The resource tracking computing device 200 can be a resource tracking system that may or may not belong to a specific individual or organization, or it can be a component of a server system.

[0126] The resource manager 210 can be any suitable combination of hardware and software on the resource tracking computing device 200 for managing resources belonging to the various participants and tracked by the resource tracking computing device 200. The resource manager 210 can be capable of receiving a proposed transfer, which can represent a transfer of resources tracked by the resource tracking computing device 200 from one resource pool on the resource tracking computing device 200 to another resource pool on the resource tracking computing device 200, and conditions associated with any constraints placed on the resources in relation to the proposed transfer. The resource manager 210 can be capable of determining whether the participant controlling the resources to be transferred also received a constraint authorization for the resources to be transferred by the proposed transfer. In the event that the constraint authorization has not been received, the resource manager 210 can generate a pending transfer 246, which can be stored in the memory 240 and can represent that the proposed transfer is still awaiting the constraint authorization.

[0127] In the event that the constraint authorization is received, the resource manager 210 can be capable of placing constraints on the type and amount of resources in the appropriate resource pool as represented by the proposed transfer. For example, in the event that the proposed transfer represents a transfer of resources from resource pool 242 to resource pool 244, the resource manager 210 can place constraints on the resources recorded in resource pool 242 and receive a constraint authorization from the participant owning resource pool 242. The constraints placed by the resource manager 210 can occupy the resources that have been constrained such that they cannot be moved or transferred unless in conjunction with the proposed transfer that caused the constraints. The constraints can occupy specific resources or a certain amount of resources. The constraints can include a lockout timeout, which can be a period of time after which the resource manager 210 can release the constraints without transferring the resources. The lockout timeout can be indicated in the proposed transfer received by the resource tracking computing device 200.

[0128] The resource manager 210 can be able to verify when conditions related to constraints placed on resources are met. For example, if the condition of a constraint is receiving evidence that a destination transfer occurred, the resource manager 210 can be able to determine whether a transfer confirmation receipt 250 confirming a destination transfer at another resource tracking computing device was received. If the condition of a constraint is receiving a signed message from a trusted system, the resource manager 210 can be able to determine whether a signed message 250 was received indicating that the trusted system indicated that the transfer continued. Upon determining that the condition related to a constraint was met, the resource manager 210 can be able to receive execution instructions from the appropriate intermediary computing device 100 and execute the transfer of the resource. The resource manager 210 can be deterministic such that meeting the constraint conditions for a resource and receiving instructions to execute the transfer of that resource can always result in the automatic transfer of the resource.

[0129] The resource manager 210 can be able to transfer resources between resource pools, such as resource pool 242 and resource pool 244, by decreasing the amount of resources in one resource pool and increasing the amount of resources in another resource pool by the same amount. For example, the resource manager 210 can transfer $100 from resource pool 242 to resource pool 244 by decreasing the amount of dollars recorded by resource pool 242 by $100 and increasing the amount of dollars recorded by resource pool 244 by $100.

[0130] The receipt generator 220 can be any suitable combination of hardware and software for generating receipts such as the ready-to-transfer receipt 144 and the transfer confirmation receipt 146 based on the actions of the resource manager 210. The receipt generator 220 can be capable of determining when the resource manager 210 sets a constraint on a resource in a resource pool in relation to a proposed transfer, and can be capable of generating a ready-to-transfer receipt such as the ready-to-transfer receipt 144 that indicates the resources required for the transfer are constrained. The ready-to-transfer receipt can include, for example, an indication of the constrained resources including type and amount, the participant that owns the constrained resources, the conditions of the constraint on the resources, and any lock timeouts related to the constraint on the resources. The ready-to-transfer receipt generated by the receipt generator 220 can be sent to any suitable computing device or system, such as the trusted system, the transfer coordinator, or the intermediary computing device 100. The receipt generator 220 can be capable of determining when the resource manager 210 performs a transfer of a resource from one resource pool to another resource pool on the resource tracking computing device 200, and can be capable of generating a transfer confirmation receipt such as the transfer confirmation receipt 146 that indicates the transfer was performed. The transfer confirmation receipt can include, for example, an indication of the transferred resources including type and amount, the participant that owns the resource pool from which the resources were transferred, the participant that owns the resource pool to which the resources were transferred, the conditions of the constraint on the transferred resources, and an indication of the evidence that the conditions of the constraint were met to allow the transfer to occur. The transfer confirmation receipt generated by the receipt generator 220 can be sent to any suitable computing device or system, such as the trusted system or the transfer coordinator, or the intermediary computing device 100.

[0131] Figure 3 An example system suitable for use in a resource transfer system is shown in accordance with an implementation of the disclosed subject matter. The sender computing device 300 can include an authorizer 310, an offer requestor 320, and a memory 340. The sender computing device 300 can be any suitable computing device (e.g., as described above with respect to the intermediary computing device 100) that is capable of performing the functions of the authorizer 310 and the offer requestor 320. The sender computing device 300 can be capable of determining when a resource manager 210 sets a constraint on a resource in a resource pool in relation to a proposed transfer, and can be capable of generating a ready-to-transfer receipt such as the ready-to-transfer receipt 144 that indicates the resources required for the transfer are constrained. The ready-to-transfer receipt can include, for example, an indication of the constrained resources including type and amount, the participant that owns the constrained resources, the conditions of the constraint on the resources, and any lock timeouts related to the constraint on the resources. The sender computing device 300 can be capable of determining when the resource manager 210 performs a transfer of a resource from one resource pool to another resource pool on the resource tracking computing device 200, and can be capable of generating a transfer confirmation receipt such as the transfer confirmation receipt 146 that indicates the transfer was performed. The transfer confirmation receipt can include, for example, an indication of the transferred resources including type and amount, the participant that owns the resource pool from which the resources were transferred, the participant that owns the resource pool to which the resources were transferred, the conditions of the constraint on the transferred resources, and an indication of the evidence that the conditions of the constraint were met to allow the transfer to occur. Figure 22The computer 20) or components thereof, are used to implement the authorizer 310, the offer requestor 320, and the storage 340. The resource tracking computing device 200 can be a single computing device, or can include multiple connected computing devices, and can be, for example, a laptop, a desktop, an individual server, a server farm, or a distributed server system, or can be a virtual computing device or system. The sender computing device 300 can be part of a computing system and network architecture, or can otherwise be connected to a computing system and network architecture. The authorizer 310 can be any suitable combination of hardware and software on the sender computing device 300 for verifying constraints related to a source transfer and a destination transfer included in an offer for a transfer, and for sending an authorization on the resource tracking computing device 200 to constrain resources owned by a sender in relation to a transfer, such as a transfer in an offer or a proposed transfer received by the sender computing device 300. The offer requestor 320 can be any suitable combination of hardware and software for requesting an offer for a transfer of resources by a sender using the sender computing device 300 to a recipient. The storage 340 can store offers 342 or proposed transfers 344 in any suitable manner. The sender computing device 300 can be a sender used by a sender, which can be any suitable party that can wish to transfer resources to a recipient. The sender can be the same party as another party in a chain of transfers, or can be a separate party. For example, the sender and the recipient can be the same party, such as an organization having multiple branches that use resources constrained at one branch to obtain another type of resource used by another branch.

[0132] The authorizer 310 can be any suitable combination of hardware and software on the sender computing device 300 for verifying constraints for a source transfer and a destination transfer, and for sending an authorization on the resource tracking computing device 200 to constrain resources owned by a sender in relation to a transfer. The authorizer 310 can be able to verify constraints related to a source transfer and a destination transfer, which can be part of an offer for a transfer, such as the offer 342, or a proposed transfer, such as the proposed transfer 344, that is received by the sender computing device 300 and for which the sender wishes to participate to send resources to a recipient. The authorizer 310 can be able to determine that a constraint of a resource owned by the sender for the source transfer is receiving evidence that the destination transfer occurred or receiving a signed message from a trusted system. If either condition is true, the authorizer 310 can be able to send an authorization of the constraint of the resource to the resource tracking computing device 200 that tracks the resources, which can be the resource tracking computing device 200 that the sender has a pool of resources, such as the resource pool 242.

[0133] The offer requestor 320 can be any suitable combination of hardware and software for requesting an offer for a resource transfer that a sender wishes to make to a recipient using the sender computing device 300. The offer requestor 320 can be capable of receiving parameters for the transfer, for example, from the sender entering the parameters into the sender computing device 300 or from the sender computing device's memory 340. Parameters for the offer request can include, for example, an indication of the recipient for the transfer, a type of resource that the sender will transfer out, a type of resource that the recipient will receive, and an amount of resource that the sender will transfer out or an amount of resource that the sender wishes to reach the recipient. For example, the offer can represent that the sender will transfer out $100 and the recipient will receive an amount of euros based on an exchange rate and a value of resource, for example, deducted from the $100 by an intermediary, or the offer can represent that the recipient will receive 100 euros and an amount of dollars transferred out by the sender can be determined to ensure that the recipient will receive 100 euros taking into account the exchange rate and any deducted resource. The offer request can also include a transfer chain, where the transfer chain includes the identities of intermediary institution computing devices and resource tracking computing devices that the sender wants to use in the transfer chain, the identities of the parties in the transfer chain, the amounts to transfer from and to the parties, and other suitable details related to the transfer and the transfer chain.

[0134] The offer request generated by the offer requestor 320 can be sent to any suitable computing device or system. For example, the offer request can be sent to various possible intermediary institution computing devices 100, where the intermediary institution computing devices 100 can evaluate the offer request and respond with an offer to participate in a transfer in a transfer chain to the recipient. The offer request can be sent to a trusted system or transfer coordinator or other computing device that can route to obtain offers from various possible intermediary institution computing devices 100 to set up a transfer chain between the sender and the recipient. In the case where, for example, the offer request includes a transfer path specified by the sender or a computing device or system that receives the offer request with liquidity information related to various indexed intermediary institution computing devices and resource tracking computing devices, routing can not be needed.

[0135] Figure 4 An example system suitable for a resource transfer system in accordance with implementations of the disclosed subject matter is shown. The coordinator 400 can include a transfer chain generator 410, an offer requestor 420, and a memory 440. The coordinator 400 can be any suitable computing device (e.g., as described above with respect to the coordinator 200) that is capable of generating a transfer chain for a resource transfer between a sender and a recipient, receiving an offer request for a resource transfer, and routing to obtain offers from various possible intermediary institution computing devices 100 to set up a transfer chain between the sender and the recipient. Figure 22The computer 20, etc.) or components thereof, for implementing the transfer chain generator 410, the offer requestor 420, and the storage 440. The coordinator 400 can be a single computing device, or can include multiple connected computing devices, and can be, for example, a laptop computer, a desktop computer, a personal server, a server farm, or a distributed server system, or can be a virtual computing device or system, or can be distributed among various computing devices and systems in the transfer chain (e.g., the intermediary computing devices 100 and the sender computing device 200, etc.). The coordinator 400 can be part of a computing system and network architecture, or can otherwise be connected to a computing system and network architecture. The transfer chain generator 410 can be any suitable combination of hardware and software for generating a transfer chain from a sender to a recipient, for example, from various offer summary chains collected from various intermediaries, as received from the various intermediary computing devices 100. The offer requestor 420 can be any suitable combination of hardware and software for requesting offers from a sender using the sender computing device 300 for a resource transfer that the sender desires to make to a recipient. The storage 440 can store in any suitable manner, prepared transfer receipts (such as the prepared transfer receipt 442, etc.) and transfer confirmation receipts (such as the transfer confirmation receipt 444, etc.). The coordinator 400 can be a computing device or system or components thereof, and can have its functions distributed among multiple computing devices or systems. The coordinator 400 can be, for example, a trusted system, or can be a transfer coordinator for transfers from a sender to a recipient. The coordinator 400 can be, or be part of, an intermediary computing device 100 in a transfer chain between a sender and a recipient.

[0136] The coordinator 400 can be capable of setting up a transfer chain for a transfer, for example, using the transfer chain generator 410 and the offer requestor 420. For example, the coordinator 400 can be capable of receiving an offer request from the sender computing device 300, can be capable of determining intermediary computing devices 100 that can be part of a transfer chain to satisfy the offer, can be capable of generating offer requests that can be sent to these intermediary computing devices 100, and can be capable of using the transfer chain generator 410 to construct a transfer chain between the sender requesting the offers and the recipient indicated in the original offer request using the offers received from the intermediary computing devices 100. The coordinator 400 can also include in the storage 400 an index of the liquidity information of the various intermediary computing devices and resource tracking computing devices that can be used instead of the offer requestor 420 to construct a transfer chain.

[0137] The coordinator 400 can be capable of coordinating communication and messaging between various computing devices and systems in the transfer chain. For example, the coordinator 400 can receive various receipts, such as the prepare transfer receipt 442 and the transfer confirmation receipt 444, and send these receipts to the appropriate computing devices and systems, such as the intermediary computing devices 100 and the resource tracking computing devices 200 in the transfer chain.

[0138] The coordinator 400 can be a trusted system. In the case that the coordinator 400 is a trusted system, the condition for all constraints placed on resources on the resource tracking computing devices 200 in the transfer chain can be the receipt of a signed message from the coordinator 400. The coordinator 400 can be capable of determining when all resource tracking computing devices 200 in the transfer chain have sent a prepare transfer receipt to the coordinator 400, indicating that all resources being transferred in the transfer chain are constrained, and can be capable of generating and distributing a signed message to all intermediary computing devices 100 and resource tracking computing devices 200 in the transfer chain to enable the transfer to continue. The signed message can also be capable of cancelling the transfer, if necessary.

[0139] Figure 5 An example system suitable for use in a resource transfer system is shown in accordance with implementations of the disclosed subject matter. The resource pool 242 on the resource tracking computing device 200 can include a resource owner identifier 510 and resource records 520 and 530. The resource owner identifier 510 can be any suitable identification of a participant that owns the resources recorded in the resource pool 242. For example, the resource owner identifier can be a name of a person, an organization, or a user or process on a server system, an arbitrary name, a username and password combination, a pass phrase or password, a unique number, or a cryptographic public key. The resource records 520 and 530 can include a resource type 522 and 532 and a resource amount 524 and 534. The resource type 522 and 532 can represent the type of resource recorded in the resource records 520 and 530. The resource type 522 and 532 can be any suitable asset resource, such as currency, cryptocurrency, commodity, financial instrument, and computing resource, among others. The resource amount 522 and 524 can represent the amount of the resource type 522 and 532 owned by the participant identified with the resource owner identifier 510 and tracked in the resource pool 242. The resource amount 522 and 524 may, for example, be stored in a register or memory location on the resource tracking computing device 200.

[0140] The resource tracking computing device 200 can track resources in any suitable manner. For example, the resource tracking computing device 200 can aggregate resources by type, wherein each resource pool, such as resource pool 242, tracks a specific resource type, such as resource type 522. Then, resource pool 242 can use a resource owner identifier, such as resource owner identifier 510, to include the resource quantity 524 of resource type 522 constrained by each participant who owns any amount of resource type 522.

[0141] Figures 6A-6D An example configuration suitable for a resource transfer system, based on an implementation of the disclosed subject, is shown. Figure 6A In this context, sender computing device 200 can send a request for a quote. This request may indicate that the sender wishes to use sender computing device 300 to transfer resources to a receiver. The request for a quote may be received by, for example, a coordinator 400, which may distribute the request for a quote to various intermediate computing devices. Intermediate computing device 100 may reply with a quote, which may be sent back to sender computing device 300.

[0142] exist Figure 6B In this process, the sender computing device 300 can accept the offer, for example, by sending it back to the coordinator 400. For instance, the sender can accept an offer from the intermediary computing device 100, where the offer includes any transfer costs, a guaranteed minimum transfer, and a lockout timeout requested in the offer. The coordinator 400 can send the proposed transfer to the intermediary computing device 100, and also to a resource tracking computing device 200 (which can serve as a sender-intermediary resource tracking system between the sender computing device 300 and the intermediary computing device 100) and a resource tracking computing device 600 (which can serve as an intermediary-receiver resource tracking system between the intermediary computing device 100 and the receiver, since the receiver can have a resource pool on the resource tracking computing device 600). The resource tracking computing devices 200 and 600 can verify the conditions associated with the proposed transfer and return a receipt for the proposed transfer to the coordinator 400. The proposed transfer can instruct the resource tracking computing devices 200 and 600 what type and how much of the resources to be moved, and between which resource pools the sender's desired transfer is implemented.

[0143] exist Figure 6CIn the case of a transfer, the sender computing device 300 can send a constraint authorization to the resource tracking computing device 200, which can have a pool of resources available to the sender. The constraint authorization can be sent through the coordinator 400. Upon receiving the constraint authorization, the resource tracking computing device 200 can place a constraint on the resources owned by the sender to be used in the transfer and can send a prepare transfer receipt to, for example, the intermediary computing device 100, e.g., via the coordinator 400.

[0144] In the case of a transfer, the sender computing device 300 can send a constraint authorization to the resource tracking computing device 200, which can have a pool of resources available to the sender. The constraint authorization can be sent through the coordinator 400. Upon receiving the constraint authorization, the resource tracking computing device 200 can place a constraint on the resources owned by the sender to be used in the transfer and can send a prepare transfer receipt to, for example, the intermediary computing device 100, e.g., via the coordinator 400. Figure 6D In the case of a transfer, the sender computing device 300 can send a constraint authorization to the resource tracking computing device 200, which can have a pool of resources available to the sender. The constraint authorization can be sent through the coordinator 400. Upon receiving the constraint authorization, the resource tracking computing device 200 can place a constraint on the resources owned by the sender to be used in the transfer and can send a prepare transfer receipt to, for example, the intermediary computing device 100, e.g., via the coordinator 400.

[0145] The resource tracking computing device 600 can send a transfer confirmation receipt of the destination transfer that can reach the resource tracking computing device 200, e.g., through the intermediary computing device 100, the coordinator 400, or both. The intermediary computing device 100 can also send an execution instruction to the resource tracking computing device 200. The transfer confirmation receipt can satisfy the conditions of the constraint placed on the resources of the sender on the resource tracking computing device 200. Upon receiving the execution instruction, the resource tracking computing device 200 can automatically transfer the constrained resources from the pool of resources 242 that can be owned by the sender to the pool of resources 244 that can be owned by the intermediary using the intermediary computing device 100.

[0146] Figures 7A-7C An example configuration suitable for a resource transfer system is shown in accordance with an implementation of the disclosed subject matter. In Figure 7A In the case of a transfer, the sender computing device 300 can send a constraint authorization to the resource tracking computing device 200, which can have a pool of resources available to the sender. The constraint authorization can be sent through the coordinator 400. Upon receiving the constraint authorization, the resource tracking computing device 200 can place a constraint on the resources owned by the sender to be used in the transfer and can send a prepare transfer receipt to, for example, the intermediary computing device 100, e.g., via the coordinator 400.

[0147] In Figure 7B , the sender computing device 300 can send a constrained authorization to a resource tracking computing device 200 that can have a pool of resources for the sender. The constrained authorization can be sent via the coordinator 400. Upon receiving the constrained authorization, the resource tracking computing device 200 can set constraints on the resources owned by the sender to be used in the transfer and can send a prepare transfer receipt, e.g., via the coordinator 400, to, e.g., the intermediary computing device 100.

[0148] In Figure 7C , the intermediary computing device 100 can send a constrained authorization to a resource tracking computing device 600 that can be used as an intermediary-intermediary resource tracking system, where the intermediary using the intermediary computing device 100 can have a pool of resources on the resource tracking computing device 600. The constrained authorization can be sent via the coordinator 400. Upon receiving the constrained authorization, the resource tracking computing device 600 can set constraints on the resources owned by the intermediary using the intermediary computing device 100 to be used in the transfer and can send a prepare transfer receipt, e.g., via the coordinator 400, to, e.g., the intermediary computing device 710.

[0149] Figures 8A-8C An example configuration suitable for a resource transfer system according to implementations of the disclosed subject matter is shown. If the transfer does not include a trusted system, the intermediary computing device 710, upon receiving a prepare transfer confirmation receipt as in Figure 7A , sends an execute instruction to a resource tracking computing device 720 that can be used as an intermediary-receiver resource tracking system. The execute instruction can cause the resource tracking computing device 720 to transfer resources from a pool of resources 742 that can be owned by the intermediary using the intermediary computing device 710 to a pool of resources 744 that can be owned by the receiver. The type and amount of resources transferred can be as shown in the proposed transfer sent to the intermediary computing device 710 and the resource tracking computing system 720. The resource tracking computing device 720 can send a transfer confirmation receipt, e.g., to the intermediary computing device 710. The transfer confirmation receipt or some other notification of the transfer can also be sent to the sender computing device 300 to notify the sender that the receiver successfully received the resources.

[0150] In Figure 8BIn an implementation, the intermediary computing device 710 can send the transfer confirmation receipt received from the resource tracking computing device 700 to the resource tracking computing device 600, e.g., via the coordinator 400. The intermediary computing device 710 can also send execution instructions to the resource tracking computing device 600 to implement a transfer of a resource owned by the intermediary using the intermediary computing device 100 and constrained in the resource pool 644 of the resource tracking computing device 600 to the resource pool 642. The transfer can be a source transfer to the intermediary using the intermediary computing device 720. The transfer confirmation receipt can satisfy the condition for the constraint on the resource owned by the intermediary using the intermediary computing device 100 because it can be evidence of the completion of a destination transfer of the resource from the intermediary using the intermediary computing device 600. The resource tracking computing device 600 can automatically transfer the constrained resource from the resource pool 644 to the resource pool 642 upon receiving the execution instructions from the intermediary computing device 600. The resource tracking computing device 600 can send out the transfer confirmation receipt, e.g., to the intermediary computing device 100.

[0151] In an implementation, Figure 8C In an implementation, the intermediary computing device 100 can send the transfer confirmation receipt received from the resource tracking computing device 600 to the resource tracking computing device 200, e.g., via the coordinator 400. The intermediary computing device 100 can also send execution instructions to the resource tracking computing device 200 to implement a transfer of a resource owned by the sender using the sender computing device 300 and constrained at the resource pool 242 of the resource tracking computing device 200 to the resource pool 244. The transfer can be a source transfer to the intermediary using the intermediary computing device 100. The transfer confirmation receipt can satisfy the condition for the constraint on the resource owned by the sender using the sender computing device 300 because it can be evidence of the completion of a destination transfer of the resource from the intermediary using the intermediary computing device 100. The resource tracking computing device 200 can automatically transfer the constrained resource from the resource pool 242 to the resource pool 244 upon receiving the execution instructions from the intermediary computing device 100. This can complete the transfer because the recipient can have received the resource, the sender can have sent the resource, and the intermediary can have done both sending and receiving the resource to facilitate the transfer chain.

[0152] Figures 9A-9C An example configuration suitable for a resource transfer system is shown in accordance with an implementation of the disclosed subject matter. In Figure 9A In an implementation, if the transfer includes a trusted system (e.g., the coordinator 400), the intermediary computing device 710 sends the transfer confirmation receipt to the resource tracking computing device 600, e.g., via the coordinator 400, as Figure 7AUpon receiving the ready-to-transfer receipt, the sender computing device 300 sends a constraint authorization to the resource tracking computing device 720. Upon receiving the constraint authorization, the resource tracking computing device 720 can place a constraint on the resource owned by the intermediary using the intermediary computing device 710 that is to be transferred to the recipient and can send a ready-to-transfer receipt, for example, to the coordinator 400. In some implementations, where there is a trusted system such as the coordinator 400, the sender computing device 300, the intermediary computing device 100, and the intermediary computing device 710 send their respective constraint authorizations at the same time, for example, upon receiving a message from the coordinator 400 indicating that the transfer is to proceed.

[0153] In some implementations, the intermediary computing device 710 can send a signed message to the resource tracking computing device 600 and 720 for the source and destination transfers, respectively. The signed message can be a message signed by the intermediary computing device 710 using a private key and verifiable by the resource tracking computing device 600 and 720 using a corresponding public key that the resource tracking computing device 600 and 720 have a copy of. The signed message can indicate that the transfer is to proceed. The resource tracking computing device 600 and 720 can receive the signed message and can determine that the transfer is to proceed. Figure 9B In some implementations, the intermediary computing device 710 can send a signed message to the resource tracking computing device 600 and 720 for the source and destination transfers, respectively. The signed message can be a message signed by the intermediary computing device 710 using a private key and verifiable by the resource tracking computing device 600 and 720 using a corresponding public key that the resource tracking computing device 600 and 720 have a copy of. The signed message can indicate that the transfer is to proceed. The resource tracking computing device 600 and 720 can receive the signed message and can determine that the transfer is to proceed.

[0154] In some implementations, the intermediary computing device 710 can send a signed message to the resource tracking computing device 600 and 720 for the source and destination transfers, respectively. The signed message can be a message signed by the intermediary computing device 710 using a private key and verifiable by the resource tracking computing device 600 and 720 using a corresponding public key that the resource tracking computing device 600 and 720 have a copy of. The signed message can indicate that the transfer is to proceed. The resource tracking computing device 600 and 720 can receive the signed message and can determine that the transfer is to proceed. Figure 9C In some implementations, the intermediary computing device 710 can send a signed message to the resource tracking computing device 600 and 720 for the source and destination transfers, respectively. The signed message can be a message signed by the intermediary computing device 710 using a private key and verifiable by the resource tracking computing device 600 and 720 using a corresponding public key that the resource tracking computing device 600 and 720 have a copy of. The signed message can indicate that the transfer is to proceed. The resource tracking computing device 600 and 720 can receive the signed message and can determine that the transfer is to proceed.

[0155] The intermediary computing device 100 can send an execute instruction to the resource tracking computing device 200 for its resource. The signed message received by the resource tracking computing device 200 can have satisfied the constraint condition for the resource in the resource pool 242. The resource tracking computing device 200, upon receiving the execute instruction, can automatically transfer the constrained resource from the resource pool 242 owned by the sender using the sending computing device 300 to the resource pool 244 owned by the intermediary using the intermediary computing device 100.

[0156] Figure 10 An example configuration suitable for a resource transfer system is shown in accordance with an implementation of the disclosed subject matter. To implement the transfer of the constrained resource from the resource pool 242 to the resource pool 244 on the resource tracking computing device 200, the constraint condition for the resource must be satisfied. This condition can be satisfied, for example, by sending a transfer confirmation receipt 1090 from the intermediary computing device 100 to the resource tracking computing device 200, where the transfer confirmation receipt 1090 indicates that the destination transfer of the source transfer of the resource from the resource pool 242 to the resource pool 244 has been completed. Alternatively, the trusted system can send the signed message to the resource tracking computing device 200.

[0157] The intermediary computing device 100 can send an execute instruction to the resource tracking computing device 200. The execute instruction can be received by the resource manager 210, which can verify that the constraint condition for the resource has been satisfied. The resource manager 210 can then cause the amount of resource 524 in the resource pool 242 to be decreased by the amount of the constrained resource, and cause the amount of resource 1024 in the resource pool 244 to be increased by the same amount. The resource type 522 and 1022 can be the same. This can cause the resource pool 244 to record that the participant identified by the resource owner identifier 1010, which can be, for example, an intermediary using the intermediary computing device 100, owns an increased amount of the resource type 1022. The resource pool 242 can record that the participant identified by the resource owner identifier 510, for example, the sender or other intermediary, now owns a decreased amount of the resource type 522. The total amount of the resource type 522 or 1022 tracked by the resource tracking computing device 200 can not change, only the amount of resource owned by the participants owning the resource pools 242 and 244 can change.

[0158] The resource amounts 524 and 1024 can be counts stored in registers or memory locations. As the resource amount 524 decreases, the count can record the amount of the resource that is constrained, although the actual resource identified as constrained can not be the resource removed when the resource amount 524 decreases. For example, for a resource type 522 of dollars, the resource amount 524 can be 1000. A constraint can be placed on 100 of those dollars. When the constraint condition is met and a transfer occurs, the resource amount 524 can decrease by 100, but this can represent the removal of any set of 100 dollars from the resource record 520. The constraint ensures that there are at least 100 dollars to transfer, but if there are more than 100, then any of the dollars can be transferred. The resource amounts 524 and 1024 can also include a location or other identifier of a particular resource, such as a resource that has a physical instance of a commodity or memory block, or a financial instrument or other resource that can be individually distinguishable. This can allow for the transfer of particular resources, such as a particular commodity stored at a particular location, a particular share of stock, a particular bond, a particular contract such as an options contract, and so on.

[0159] Figure 11An example sequence applicable to a resource transfer system according to implementations of the disclosed subject matter is shown. The transfer chain can have one intermediary institution computing device (i.e., intermediary institution computing device 100, which can also be a trusted system of the transfer chain). At time 1110, sender computing device 300 can send a constraint authorization to intermediary institution computing device 100. At time 1120, intermediary institution computing device 100 can instruct resource tracking computing device 200, which can be used as a sender-intermediary institution resource tracking system, to set a constraint on a resource owned by the sender. The instruction can include the constraint authorization from sender computing device 300. Intermediary institution computing device 100 can instruct resource tracking computing device 600, which can be used as an intermediary institution-recipient resource tracking system, to set a constraint on a resource owned by an intermediary using intermediary institution computing device 100. At time 1130, intermediary institution computing device 100 can receive a ready-to-transfer receipt from resource tracking computing devices 200 and 600, which indicates that constraints are set on the resource of the sender and the resource of the intermediary. At time 1140, intermediary institution computing device 100 can send both a signed message and an execution instruction to both resource tracking computing devices 200 and 600. At time 1150, resource tracking computing devices 200 and 600, which can have performed respective transfers upon receiving the signed message and the execution instruction from intermediary institution computing device 100, can send a transfer confirmation receipt to intermediary institution computing device 100. Resource tracking computing device 600 can also send a notification of completion of the resource transfer to recipient computing device 1100, which can be any appropriate computing device used by the recipient. At time 1160, intermediary institution computing device 100 can notify sender computing device 300 of the completion of the transfer.

[0160] Figure 12An example sequence applicable to a resource transfer system is shown in accordance with implementations of the disclosed subject matter. The transfer chain can have one intermediary institution computing device (intermediary institution computing device 100) and can not have a trusted system. At time 1210, sender computing device 300 can send a constraint authorization to resource tracking computing device 200, which can be used as a sender-intermediary resource tracking system. At time 1220, intermediary institution computing device 100 can instruct resource tracking computing device 200 to set a constraint on a resource owned by the sender, as authorized by the constraint authorization. At time 1230, intermediary institution computing device 100 can receive a prepare transfer receipt from resource tracking computing device 200, which indicates that the sender's resource is constrained. At time 1240, intermediary institution computing device 100 can send an execute instruction to resource tracking computing device 600, which can be used as an intermediary-institution-recipient resource tracking system. At time 1250, resource tracking computing device 600, which can have performed a resource transfer from the intermediary to the recipient upon receiving the execute instruction from intermediary institution computing device 100, can send a transfer confirmation receipt to intermediary institution computing device 100. Resource tracking computing device 600 can also send a notification of completion of the resource transfer to recipient computing device 1100. At time 1260, intermediary institution computing device 100 sends the execute instruction and the transfer confirmation receipt from resource tracking computing device 600 to resource tracking computing device 200. At time 1270, resource tracking computing device 200, which can have performed a resource transfer from the sender to the recipient upon receiving the execute instruction and the transfer confirmation receipt from intermediary institution computing device 100 to satisfy the constraint on the sender's resource, can send a transfer confirmation receipt confirming the resource transfer to the intermediary to intermediary institution computing device 100. At time 1280, intermediary institution computing device 100 can notify sender computing device 300 of the completion of the transfer.

[0161] Figure 13AAn example sequence suitable for a resource transfer system is shown in accordance with implementations of the disclosed subject matter. The transfer chain can have two intermediary computing devices 100 and 710, where intermediary computing device 100 can also be a trusted system for the transfer chain. At time 1310, sender computing device 300 can send a constraint authorization to intermediary computing device 100. At time 1315, intermediary computing device 100 can instruct resource tracking computing device 200, which can be used as a sender-intermediary resource tracking system, to set a constraint on a resource owned by the sender. The instruction can include the constraint authorization from sender computing device 300. At time 1320, intermediary computing device 100 can receive a ready-to-transfer receipt from resource tracking computing device 200, which indicates that the resource of the sender is constrained. At time 1325, intermediary computing device 100 can instruct resource tracking computing device 600, which can be used as an intermediary-intermediary resource tracking system, to set a constraint on a resource owned by an intermediary using intermediary computing device 100. At time 1330, resource tracking computing device 200 can send a ready-to-transfer receipt to intermediary computing device 100. The ready-to-transfer receipt can also be sent by, for example, intermediary computing device 100 or by resource tracking computing device 200 to intermediary computing device 710. At 1335, intermediary computing device 710 can instruct resource tracking computing device 720, which can be used as an intermediary-recipient resource tracking system, to set a constraint on a resource owned by an intermediary using intermediary computing device 710. At time 1340, resource tracking computing device 720 can send a ready-to-transfer receipt to intermediary computing device 710 and to intermediary computing device 100. At time 1345, intermediary computing device 100, which can be used as a trusted system in or related to the transfer chain, can determine from the ready-to-transfer receipts that all resources to be transferred are constrained and can send a signed message to resource tracking systems 200, 600, and 720 and to intermediary computing device 710. At 1350, intermediary computing device 710 can send execution instructions to both resource tracking computing devices 600 and 720, and intermediary computing device 100 can send execution instructions to resource tracking computing device 200. Resource tracking computing devices 100, 600, and 720 can perform respective transfers, where resource tracking computing device 720 transfers the constrained resource from the intermediary using intermediary computing device 710 to the recipient, resource tracking computing device 600 transfers the constrained resource from the intermediary using intermediary computing device 100 to the intermediary using intermediary computing device 710, and resource tracking computing device 200 transfers the constrained resource from the sender to the intermediary using intermediary computing device 100.In 1355, the resource tracking computing device 720 can send a notification of completion of the resource transfer to the recipient computing device 1100. At time 1360, the intermediary computing device 100 can notify the sender computing device 300 of the completion of the transfer.

[0162] Figure 13BAn example sequence suitable for a resource transfer system is shown in accordance with implementations of the disclosed subject matter. The transfer chain can have two intermediary computing devices, intermediary computing device 100 and intermediary computing device 710. The constraint placed on the resource in the transfer chain can be the receipt of a receipt (e.g., a pre-agreed signature message) from the recipient computing device 1100. At time 1310, the sender computing device 300 can send a constraint authorization to the intermediary computing device 100. At time 1315, the intermediary computing device 100 can instruct the resource tracking computing device 200, which can be used as a sender-intermediary resource tracking system, to place a constraint on the resource owned by the sender. The instruction can include the constraint authorization from the sender computing device 300. At time 1320, the intermediary computing device 100 can receive a ready-to-transfer receipt from the resource tracking computing device 200, which indicates that the resource of the sender has been constrained. At time 1325, the intermediary computing device 100 can instruct the resource tracking computing device 600, which can be used as an intermediary-intermediary resource tracking system, to place a constraint on the resource owned by the intermediary using the intermediary computing device 100. At time 1330, the resource tracking computing device 200 can send a ready-to-transfer receipt to the intermediary computing device 100. The ready-to-transfer receipt can also be sent by, for example, the intermediary computing device 100 or by the resource tracking computing device 200 to the intermediary computing device 710. At 1335, the intermediary computing device 710 can instruct the resource tracking computing device 720, which can be used as an intermediary-recipient resource tracking system, to place a constraint on the resource owned by the intermediary using the intermediary computing device 710. At time 1341, the resource tracking computing device 720 can send a ready-to-transfer receipt to the intermediary computing device 710 and to the recipient computing device 1100. At time 1346, the recipient computing device 1100 can determine from the ready-to-transfer receipt received from the resource tracking computing system 720 that the resource to be transferred to the recipient has been constrained and can infer that all other resources in the transfer chain are constrained. The recipient computing device 1100 can send a receipt (e.g., a pre-agreed signature message) to the resource tracking systems 200, 600, and 720 and to the intermediary computing devices 100 and 710. At 1350, the intermediary computing device 710 can send an execution instruction to both the resource tracking computing devices 600 and 720 and the intermediary computing device 100 can send an execution instruction to the resource tracking computing device 200.The resource tracking computing devices 100, 600, and 720 can each perform a respective transfer, where the resource tracking computing device 720 transfers the escrowed resource from the intermediary using the intermediary computing device 710 to the recipient, the resource tracking computing device 600 transfers the escrowed resource from the intermediary using the intermediary computing device 100 to the intermediary using the intermediary computing device 710, and the resource tracking computing device 200 transfers the escrowed resource from the sender to the intermediary using the intermediary computing device 100. In some implementations, the recipient computing device 1100 can send execution instructions to the resource tracking computing system 720. In 1355, the resource tracking computing device 720 can send a notification of completion of the resource transfer to the recipient computing device 1100. At time 1360, the intermediary computing device 100 can notify the sender computing device 300 of the completion of the transfer.

[0163] In some implementations, the prepared transfer receipt from the resource tracking computing system 720 can be sent directly to or forwarded by the recipient computing device 1100 to a third party to which the recipient computing device 1100 delegates responsibility. The escrow condition for the resource in the transfer chain can be the receipt of the receipt from the third party. The third party can send the receipt to the resource tracking computing devices 100, 600, and 720, and the intermediary computing devices 100 and 710. The receipt can be, for example, a cryptographically signed message with pre-agreed content. In some implementations, the receipt can be evidence of the occurrence of some event, such as the shipment or delivery of a physical item that can be part of the transfer chain or outside of the transfer chain. In some implementations, the recipient can delegate responsibility to the resource tracking computing device 720 or the intermediary computing device 710. For example, the resource tracking computing device 720, upon receiving instructions from the intermediary computing device 710 to escrow the intermediary's resources, can send out a receipt to cause the transfer to be performed. The intermediary computing device 710, upon receiving the prepared transfer receipt from the intermediary computing device 710, can send out a receipt to cause the transfer to be performed.

[0164] The receipt sent out by the recipient computing device 1100 or the third party to which responsibility is delegated can be sent immediately to all appropriate systems in the transfer chain. For example, the recipient computing device 1100 can send the receipt to the resource tracking computing devices 100, 600, and 720, and the intermediary computing devices 100 and 710. The receipt can be passed along the chain sequentially. For example, the receipt can be sent from the recipient computing device 1100 to the resource tracking computing device 720, which can perform its resource transfer and pass the receipt to the intermediary computing device 710, which can in turn send the receipt to the resource tracking computing device 600, and so on.

[0165] Figure 14 An example configuration suitable for a resource transfer system is shown in accordance with implementations of the disclosed subject matter. The transfer chain can have two intermediary computing devices, intermediary computing device 100 and intermediary computing device 710, and can be without a trusted system. At time 1410, sender computing device 300 can send a constraint authorization to resource tracking computing device 200. At time 1415, intermediary computing device 100 can instruct resource tracking computing device 200, which can be used as a sender-intermediary resource tracking system, to set a constraint on a resource owned by the sender as authorized by the constraint authorization. At time 1420, intermediary computing device 100 can receive a ready-to-transfer receipt from resource tracking computing device 200, which indicates that the resource of the sender has been constrained. At time 1425, intermediary computing device 100 can instruct resource tracking computing device 600, which can be used as an intermediary-intermediary resource tracking system, to set a constraint on a resource owned by an intermediary using intermediary computing device 100. At time 1430, resource tracking computing device 200 can send the ready-to-transfer receipt to intermediary computing device 100. The ready-to-transfer receipt can also be sent by, for example, intermediary computing device 100 or by resource tracking computing device 200 to intermediary computing device 710. At time 1435, intermediary computing device 710 sends an execution instruction to resource tracking computing device 720, which can be used as an intermediary-recipient resource tracking system. At time 1440, resource tracking computing device 720, which can have performed a resource transfer from an intermediary using intermediary computing device 710 to a recipient upon receiving the execution instruction from intermediary computing device 710, can send a transfer confirmation receipt to intermediary computing device 710. The transfer confirmation receipt can also be sent to resource tracking computing device 600. Resource tracking computing device 720 can also send a notification of completion of the resource transfer to recipient computing device 1100. At time 1445, intermediary computing device 710 can send an execution instruction to resource tracking computing device 600. At time 1450, resource tracking computing device 600, which can have transferred the constrained resource from an intermediary using intermediary computing device 100 to an intermediary using intermediary computing device 710, can send a transfer confirmation receipt to intermediary computing device 100. The transfer confirmation receipt can also be sent to resource tracking computing device 200. At time 1455, intermediary computing device 100 can send an execution instruction to resource tracking computing device 200. At time 1460, resource tracking computing device 200, which can have transferred the constrained resource from the sender to an intermediary using intermediary computing device 100, can send a transfer confirmation receipt to intermediary computing device 100. At time 1465, intermediary computing device 100 can notify sender computing device 300 of the completion of the transfer.

[0166] Figure 15An example configuration suitable for a resource transfer system is shown in accordance with implementations of the disclosed subject matter. A transfer chain can include more than two intermediary institution computing devices and can be absent a trusted system. For example, the transfer chain can include intermediary institution computing device 1500. At time 1510, intermediary institution computing device 1500 can instruct resource tracking computing device 200, which can serve as an intermediary-intermediary resource tracking system, to set a constraint on a resource owned by an intermediary using intermediary institution computing device 1500. Intermediary institution computing device 1500 can instruct the constraint after, for example, receiving a ready-to-transfer receipt from another resource tracking system that can have set a constraint on a resource owned by a sender or by another intermediary using an intermediary institution computing device immediately preceding intermediary institution computing device 1500 in the transfer chain. At time 1515, resource tracking computing device 200 can send the ready-to-transfer receipt to intermediary institution computing device 100, either directly or through intermediary institution computing device 1500 or through a system that can serve as coordinator 400. For example, if intermediary institution computing device 100 is a coordinator 400 of the transfer chain, intermediary institution computing device 100 can receive the ready-to-transfer receipt directly from resource tracking computing device 200. At time 1520, intermediary institution computing device 100 can instruct resource tracking computing device 600, which can serve as an intermediary-intermediary resource tracking system, to set a constraint on a resource owned by an intermediary using intermediary institution computing device 600. At time 1525, resource tracking computing device 600 can send the ready-to-transfer receipt to intermediary institution computing device 710, either directly or through intermediary institution computing device 100 or through a system that can serve as coordinator 400. At time 1530, intermediary institution computing device 710 can send an execution instruction to resource tracking computing device 720, which can serve as an intermediary-recipient resource tracking system. At time 1535, resource tracking computing device 720, which can have performed a resource transfer from an intermediary using intermediary institution computing device 710 to a recipient upon receiving the execution instruction from intermediary institution computing device 710, can send a transfer confirmation receipt to intermediary institution computing device 710, either directly or through a system that can serve as coordinator 400. The transfer confirmation receipt can also be sent to resource tracking computing device 600. Resource tracking computing device 720 can also send a notification of completion of the resource transfer to recipient computing device 1100. At time 1540, intermediary institution computing device 710 can send an execution instruction to resource tracking computing device 600. At time 1545, resource tracking computing device 600, which can have transferred the constrained resource from an intermediary using intermediary institution computing device 100 to an intermediary using intermediary institution computing device 710, can send a transfer confirmation receipt to intermediary institution computing device 100, either directly or through a system that can serve as coordinator 400.The transfer confirmation receipt can also be sent to the resource tracking computing device 200. At time 1550, the intermediary computing device 100 can send execution instructions to the resource tracking computing device 200. At time 1555, the resource tracking computing device 200, which can have transferred the constrained resource from the intermediary using intermediary computing device 1500 to the intermediary using intermediary computing device 100, can send the transfer confirmation receipt to the intermediary computing device 1500 either directly or through the intermediary computing device 100 or through the system that can act as the coordinator 400. At time 1560, the intermediary computing device 1500 can send execution instructions to the resource tracking computing device between the intermediary computing device 1500 and the sender computing device 300 or other intermediary computing devices in the transfer chain before the intermediary computing device 1500. This causes the transfer of the resource to the intermediary using intermediary computing device 1500. If the sender computing device 300 is immediately before the intermediary computing device 1500 in the transfer chain, the transfer can be complete. Otherwise, the immediately preceding intermediary computing device can receive the transfer confirmation receipt, which can then be sent to another resource tracking system, and so on until the transfer is complete.

[0167] Figure 16 An example configuration suitable for a resource transfer system is shown in accordance with implementations of the disclosed subject matter. The transfer chain can include a guaranteed minimum transfer and a lockout timeout regarding constraints placed on resources. For example, a guaranteed minimum transfer 1610 can be a transfer of resources from a sender to an intermediary using intermediary computing system 100 that occurs if a transfer from the sender to a recipient fails. The guaranteed minimum transfer 1610 can be higher than a guaranteed minimum transfer 1620, which can be a transfer of resources from an intermediary using intermediary computing device 100 to an intermediary using intermediary computing device 710 that occurs if a transfer from the sender to a recipient fails. In this way, if the transfer ultimately fails, both intermediaries can receive compensation for the time their resources were constrained, preventing a malicious sender from intentionally initiating a transfer that will fail, as the sender will still transfer some resources with the failed transfer.

[0168] The lockout timeout 1625 can be a period of time during which the resource tracking computing device 200 constrains resources owned by intermediaries using intermediary institution computing devices 100 before those resources are released without transfer of those resources by the intermediaries. The lockout timeout 1625 for intermediaries using intermediary institution computing devices 100 can be longer than the lockout timeout 1635 for intermediaries using intermediary institution computing devices 710. This can ensure that a malicious sender cannot lock resources owned by intermediaries indefinitely, as a transfer will fail if the lockout timeout expires and the constrained resources are released. Expiration of the lockout timeout can also cause a guaranteed minimum transfer to occur.

[0169] Figure 17A An example configuration suitable for a resource transfer system according to implementations of the disclosed subject matter is shown. A transfer chain between a recipient and a sender can include parallel paths. For example, the transfer chain can involve a first path including intermediary institution computing device 100, resource tracking system 600, and intermediary institution computing device 710, and a second path including intermediary institution computing device 1700, resource tracking system 1720, and intermediary institution computing device 1740. The total value of resources transferred to the recipient can be allocated between these paths in any suitable manner, so long as the value of resources transferred from participants using intermediary institution computing device 710 and from participants using intermediary institution computing device 1740 collectively amounts to the total value that the sender wants the recipient to receive.

[0170] Figure 17BAn example configuration suitable for a resource transfer system is shown in accordance with implementations of the disclosed subject matter. A transfer chain between a recipient and a sender can be circular. For example, a transfer chain can involve a forward path including resource tracking computing device 200, intermediary computing device 100, resource tracking system 600, intermediary computing device 710, and resource tracking computing device 720, and a reverse path including resource tracking computing device 1720. Resources can be transferred from a sender using sender computing device 300 to a recipient using recipient computing device 1100 through the forward path and from the recipient to the sender through the reverse path. For example, resource tracking computing device 1720 can be a ledger of a stock economy business. The sender can use dollars to cause the recipient to receive euros through the forward path. Using the reverse path, the recipient can transfer stock shares to the sender. A condition for resources set in a circular transfer chain can be, for example, receiving a message from a trusted participant, receiving a receipt indicating that a destination transfer is complete for a participant, or receiving a receipt from sender computing device 300 or a third party delegated responsibility by sender computing device 300. Recipient computing device 1100 can function the same as intermediary computing devices in a non-circular transfer chain, and sender computing device 300 can function the same as a sender computing device at the beginning of a non-circular transfer chain and a recipient computing device at the end of a non-circular transfer chain. For example, sender computing device 300 can initiate a transaction and set a first constraint on resources of the sender at resource tracking computing device 200 in a transfer chain. If the condition is receiving a receipt from sender computing device 300, sender computing device 300 can also receive a last prepared transfer receipt in the transfer chain from resource tracking computing device 720, which indicates that the recipient has set a constraint on resources to be transferred to the sender. Sender computing device 300 can send out a receipt that can cause the release of the constraint on the resources constrained in the transfer chain, allowing transfers to be performed on both the forward and reverse portions of the transfer chain. If the condition is destination transfer complete, recipient computing device 100 can function the same as a last intermediary computing device in a non-circular transfer chain and can cause a transfer of resources on resource tracking computing device 720 to the sender to be performed once recipient computing device 1100 receives a prepared transfer receipt from resource tracking computing device 720. Recipient computing device 1100 can also cause a transfer to be performed on resource tracking computing device 720. In some implementations, resource tracking computing device 720 can belong to a shipper of tangible goods, and the resource transfer can be a delivery of the tangible goods to the sender.

[0171] Figure 18AAn example process suitable for a resource transfer system in accordance with implementations of the disclosed subject matter is shown. In 1800, an offer request can be sent. For example, a sender can send an offer request using sender computing device 300, where the offer can include an indication of a resource transfer that the sender wants to make to a recipient. The offer request can include, for example, a type and amount of resource that the sender wants to send, a type and amount of resource that the recipient should receive, an identity of a resource tracking computing device 200 that the sender has a pool of the type of resource that the sender wants to send, an identity of a resource tracking computing device 200 that the recipient has a pool of the type of resource that can receive the resource to be transferred to the recipient, or any other suitable parameters, including, for example, a minimum guaranteed transfer level, a lockout timeout, and a transfer cost or fee that the sender will accept in the offer. The offer request can be sent to any suitable computing device or system to obtain an offer and set up a transfer chain for the sender's transfer.

[0172] In 1802, an offer can be received. For example, sender computing device 300 can receive an offer that can represent a cost of a transfer chain that can be used to implement the transfer that the sender requested an offer for. The offer can represent, for example, any transfer costs or fees associated with any intermediary computing devices 100 that returned an offer for a transfer chain to participate in, a guaranteed minimum transfer, and a lockout timeout. The offer can or can not represent the identity of the intermediary computing devices 100 and their associated intermediaries, and can or can not represent the type and amount of resource that can be transferred between intermediaries in the transfer chain. If the sender's request for an offer represents a specific amount of resource or a value of resource that the recipient will receive, the offer can represent the amount of resource that the sender must transfer. The offer can include a proposed transfer from the sender to a first intermediary in the transfer chain.

[0173] In 1804, conditions of the proposed transfer from the sender to the first intermediary in the offer can be verified to be receiving a signed message or a destination transfer completion. For example, the sender computing device 300 can analyze the offer to determine conditions that place constraints that can be authorized by the sender on resources that the sender possesses that are to be transferred out. If the conditions of the constraints that must be satisfied before the constrained resources are transferred out are that a signed message is received from a trusted system by the resource tracking computing device 200 that constrains the resources, a signed message is received from the recipient computing device 1100 that can be a receipt that includes content of a pre-agreement or that can be verified using a one-way function based on a previously received derivation value, or evidence that a destination transfer occurred on another resource tracking computing device such as the resource tracking computing device 600 (e.g., a transfer confirmation receipt, etc.), the sender computing device 300 can verify these conditions and the flow can proceed to 1806. Otherwise, the flow can proceed to 1810, where in 1810, the offer can be rejected.

[0174] In 1806, a constraint authorization can be sent. For example, the sender computing device 300 can send a constraint authorization to the resource tracking computing device 200. The constraint authorization can be used as an authorization for the transfer of the transfer chain set in the offer received by the sender computing device 300. The constraint authorization can allow the resource tracking computing device 200 to place constraints on resources in the pool of resources (e.g., the pool of resources) that the sender possesses. The type and amount of resources to be constrained and the participant that the resources are to be transferred to when the conditions of the constraints are met can be specified in the constraint authorization. The resource tracking computing device 200 can also receive a proposed transfer of the type and amount of resources, the conditions of the transfer of the constrained resources, and the participant that the resources are to be transferred to, and the constraint authorization can simply represent that the proposed transfer of the resources can be constrained.

[0175] In 1808, a notification of the transfer to the recipient can be received. For example, the sender computing device 300 can receive a notification in any suitable form that the resources have been transferred to the recipient as requested by the sender in the offer request. The sender computing device 300 can receive, for example, a transfer confirmation receipt generated in the case that the last resource tracking computing device in the transfer chain (e.g., the resource tracking computing device 720) implements a transfer of the resources from the last intermediary to the recipient.

[0176] In 1810, the offer can be rejected. For example, sender computing device 300 can determine that the conditions that must be satisfied before the resource subject to the transfer are neither a signed message received from a trusted system by resource-constrained resource tracking computing device 200 nor evidence of a destination transfer, such as a transfer confirmation receipt, occurring on another resource tracking computing device (e.g., resource tracking computing system 600). This can indicate that the sender's resource can be transferred without guaranteeing that the recipient received or will receive the resource that the sender wishes to transfer to the recipient, making the transfer chain in the offer risky and unreliable. The sender can reject the offer.

[0177] Figure 18B An example process suitable for a resource transfer system according to implementations of the disclosed subject matter is shown. In some implementations, the transfer can use a temporary consensus network. In 1805, after receiving an offer as in 1804, the conditions of the proposed transfer from the sender to the first intermediary in the offer can be verified to be an approval of the transfer by the temporary consensus network. For example, sender computing device 300 can analyze the offer to determine the conditions set on the constraints of the owned resource to be transferred out that would be authorized for the sender. If the conditions that must be satisfied before the resource subject to the transfer are a signed statement received by resource-constrained resource tracking computing device 200 from 1 / 3 of the member nodes of the temporary consensus network indicating that these member nodes reached a quorum to approve the transfer, then sender computing device 300 can verify these conditions and the flow can proceed to 1807. Otherwise, the flow can proceed to 1810, in which the offer can be rejected.

[0178] In 1807, a request for a trust list can be received. For example, sender computing device 300 can receive a request for its trust list from the initiator of the transfer, where the trust list can include systems or nodes trusted by the sender. The initiator can be any system that can have initiated the transfer (e.g., sent a request for an offer), such as sender computing device 300 itself, recipient computing device 1100, an intermediary computing device in the transfer chain, or coordinator 400, among others.

[0179] In 1809, the trust list and confirmation can be sent. For example, sender computing device 300 can send the trust list to the initiator along with a confirmation that sender computing device 300 will participate in the transfer chain. The sender can not have or maintain its own trust list, and instead can send the trust list on its behalf by, for example, resource tracking computing device 200.

[0180] In 1811, after sending the constraint authorization as in 1806, a statement can be received that indicates that the provisional consensus network approved the transfer. For example, the sender computing device 300 can receive a signed statement from more than 1 / 3 of the member nodes of the provisional consensus network that indicates that the transfer was approved. The sender computing device 300 can receive the signed statement from the initiator, or from a member node if the sender computing device 300 is the initiator. If the sender computing device 300 is the initiator, the signed statement can be sent to other systems in the transfer chain, including the recipient computing device 1100, the intermediary computing device, and the resource tracking computing device. The signed statement can also be, for example, a receipt from the receiving computing device 1100 or a system of a party to whom the recipient delegated responsibility. The receipt can be signed by a member node of the provisional consensus network and time-stamped.

[0181] Figure 19 An example process suitable for a resource transfer system according to implementations of the disclosed subject matter is shown. In 1900, a proposed transfer can be received. For example, the resource tracking computing device 200 can receive a proposed transfer from any suitable computing device or system, such as the coordinator 400. The proposed transfer can indicate a type and amount of resources in a resource pool (e.g., resource pool 242) to be constrained, conditions for the constraint, and a resource pool (e.g., resource pool 242) to which the resources are to be transferred upon satisfaction of the constraint conditions and receipt of an execution instruction.

[0182] In 1902, a determination can be made as to whether a constraint authorization exists. For example, the resource tracking computing device 200 can determine whether a constraint authorization was received from a sender that can own the resources tracked by the resource pool 242 that the proposed transfer indicates should have a constraint placed on them. If a constraint authorization exists, the flow can proceed to 1910. Otherwise, if a constraint authorization does not exist, the flow can proceed to 1904.

[0183] In 1904, the transfer can be stored. For example, in the absence of a constraint authorization, the resource tracking computing device 200 can not be able to place a constraint on the resources in the resource pool 242 as indicated in the proposed transfer. The resource tracking computing device 200 can store the proposed transfer (e.g., pending transfer 246) in the memory 240 while waiting for a constraint authorization.

[0184] In 1906, a proposed transfer receipt can be sent. For example, the resource tracking computing device 200 can send the proposed transfer receipt to any appropriate computing device or system, such as the coordinator 400. The proposed transfer receipt can indicate that the resource tracking computing device 200 received a proposed transfer, but does not yet have the appropriate constraint authorization and stores the proposed transfer as a pending transfer 246 while waiting for the constraint authorization. The proposed transfer receipt can be used by, for example, the coordinator 400 to indicate to the sender computing device 300 that a constraint authorization is still needed before the transfer can proceed.

[0185] In 1908, a constraint authorization can be received. For example, the resource tracking computing device 200 can receive a constraint authorization for the pending transfer 246 from the sender computing device 300. The constraint authorization can be an indication that the resource tracking computing device 200 can place a constraint on the resources owned by the sender that are tracked by the resource pool 242.

[0186] In 1910, a constraint can be placed on the resources to be transferred. For example, the resource tracking computing device 200 that received the constraint authorization from the sender computing device 300 can place a constraint on the resources owned by the sender in the resource pool 242. The type and amount of resources that are constrained and the constraint conditions can be based on the proposed transfer received by the resource tracking computing device 200. For example, if a constraint is placed on the resources in a resource pool, such as the resource pool 644, that tracks the resources owned by the intermediate party, a lockout timeout can be applied to the constraint. The constraint can also include an indication of other parameters associated with the constraint, such as the resource pool to which the resources are to be transferred, and the computing device or system from which execution instructions to implement the resource transfer can be received, among others. The constraint can prevent the constrained resources from being transferred or moved until, for example, the sender satisfies the constraint conditions, the lockout timeout expires, or the transfer fails or is canceled. In the event of a lockout timeout expiration or other transfer failure, the constraint can be released, but a portion of the resources can still be constrained and transferred to the intermediate party as part of a guaranteed minimum transfer.

[0187] In 1912, a ready-to-transfer receipt can be sent. For example, resource tracking computing device 200 can send a ready-to-transfer receipt to any appropriate computing device or system, such as coordinator 400 or intermediary computing device 100, indicating that a constraint has been placed on a resource in resource pool 242. The ready-to-transfer receipt can be used as evidence that a constraint has been placed and can include, for example, an indication of the type and amount of resource that is constrained, the participant to which the constrained resource belongs, the participant to which the resource is to be transferred, the proposed transfer with which the resource is associated that is being constrained, and any other appropriate information related to the ready-to-transfer on resource tracking computing device 200. The ready-to-transfer receipt can be used by, for example, intermediary computing device 100 to indicate that intermediary computing device 100 can place a constraint on a resource at resource tracking system 600 or can perform a resource transfer to a recipient at resource tracking system 600. The ready-to-transfer receipt can ensure to intermediary computing device 100 that the resources it needs for a source transfer are constrained and available so that intermediary computing device 100 can make a destination transfer.

[0188] In 1914, a message that satisfies a constraint condition can be received. For example, if a trusted system exists or is involved in a transfer chain, a condition related to a constrained resource in resource pool 242 at resource tracking computing device 200 can be receiving a signed message from a trusted system. Resource tracking computing device 200 can receive a signed message from a trusted system, which can be, for example, coordinator 400 or any other computing device or system in the transfer chain, and determine that the condition related to the constrained resource has been satisfied. If no trusted system exists, a condition related to a constrained resource in resource pool 242 can be receiving evidence that a destination transfer has occurred for which the transfer of the constrained resource will be a source transfer. Resource tracking computing device 200 can receive, for example, a transfer confirmation receipt generated by resource tracking computing device 600 when a resource transfer is completed that can be a destination transfer for a source transfer of a resource from resource pool 242. For example, resource tracking computing device 600 can have transferred a resource owned by an intermediary to a recipient or a second intermediary.

[0189] In 1916, an execution instruction can be received. For example, the resource tracking computing device 200 can receive an instruction that the resource tracking computing device 200 should implement a transfer of the constrained resource from the resource pool 242 to the resource pool 244. The execution instruction can be received from a computing device or system used by a participant to which the constrained resource is to be transferred or from which the constrained resource is to be transferred. For example, the resource tracking computing device 200 can receive an execution instruction from the intermediary computing device 100 to implement a transfer of the resource to the intermediary used by the intermediary computing device 100. The resource tracking computing device 720 can receive an execution instruction from the intermediary computing device 710 to implement a transfer of the resource from the intermediary used by the intermediary computing device 710 to the recipient.

[0190] In 1918, the resource can be transferred. For example, the resource tracking computing device 200, having received a message that the conditions related to the constrained resource have been met and an execution instruction from a computing device of a participant that is to send the resource or a participant that is to receive the resource, can automatically transfer the constrained resource according to the proposed transfer. For example, the resource tracking computing device 200 can cause the amount of resources 524 of the resource pool 242 to decrease by the amount of the constrained resource and can cause the amount of resources 1024 of the resource pool 244 to increase by the same amount. This can cause the ownership of the constrained amount of resources to be transferred from the sending participant to the intermediary. The transfer of the constrained resource by the resource tracking computing device 200 can be conclusive based on receiving a message that the conditions related to the constrained resource have been met and an execution instruction from a computing device of a participant that is to send the resource or a participant that is to receive the resource. Once the message and the execution instruction are received, the resource tracking computing device 200 can implement the transfer without any opportunity for interruption or cancellation. This can ensure to all participants in the transfer chain that once the constraints related to the resources to be transferred to these participants have been met, there is little risk that the resources will not be transferred to these participants due to malicious action by some other participant in the transfer chain.

[0191] In some instances, the resource tracking computing device can transfer a resource that has not been escrowed. For example, the resource tracking computing device 720 can transfer a resource from an intermediary of the intermediary institution computing device 710 to a recipient. The intermediary institution computing device 710 can not send an escrow authorization to the resource tracking computing device 720 and can send an execution instruction of the transfer after receiving a ready-to-transfer receipt from the resource tracking computing device 600. The ready-to-transfer receipt can indicate that a source transfer on the resource tracking computing device 600 is ready for a destination transfer on the resource tracking computing device 720. Since the transfer on the resource tracking computing device 720 is the last transfer in the chain, the resource tracking computing device 720 can not have a source transfer of its own and thus can proceed with the execution instruction indicated by the intermediary institution computing device 710.

[0192] In 1920, a transfer confirmation receipt can be sent. For example, the resource tracking computing device 720 can send a transfer confirmation receipt to any appropriate computing device or system in the transfer chain, including, for example, the intermediary institution computing device 710. The transfer confirmation receipt can confirm that the transfer of the resource successfully occurred. The transfer confirmation receipt can be used by its recipient as evidence of the completion of the destination transfer, satisfying a condition related to the escrow of the resource at another resource tracking computing device. For example, the intermediary institution computing device 710 can receive a transfer confirmation receipt that confirms the transfer of the resource from the intermediary using the intermediary institution computing device 710 to the recipient on the resource tracking computing device 720. This transfer confirmation receipt can be used by the intermediary institution computing device 710 to satisfy a condition related to the escrow of the resource at the resource tracking computing device 600 belonging to the intermediary using the intermediary institution computing device 100. By sending the transfer confirmation receipt and the execution instruction to the resource tracking computing device 600, the intermediary institution computing device 710 can cause the escrowed resource to be transferred to the intermediary, compensating the intermediary for the resource transferred by the intermediary to the recipient.

[0193] Figure 20AAn example process suitable for a resource transfer system in accordance with implementations of the disclosed subject matter is shown. In 2000, a request for a quote can be received. For example, intermediary institution computing device 100 can receive a request for a quote that can have been sent directly from sender computing device 300 or distributed by, for example, coordinator 400. The request for a quote can represent the participant to which the intermediary using intermediary institution computing device 100 will transfer resources, the participant from which the intermediary using intermediary institution computing device 100 will receive resources, the resource tracking computing device at which the transfer will occur, the type and value of the resource that will be involved in both transfers, and any parameters related to the transfer such as a guaranteed minimum transfer, a transfer fee or cost, and a maximum acceptable value for a lockout timeout. The request for a quote can include only information related to the participant adjacent to intermediary institution computing device 100 in the transfer chain and can not necessarily include information related to the sender or the recipient or other intermediary participants from or to which the intermediary using intermediary institution computing device 100 will not transfer resources.

[0194] In 2002, a quote can be sent. For example, intermediary institution computing device 100 can send a quote to the computing device or system from which the request for a quote was received. The quote, for example, can include the terms or parameters with which the intermediary institution computing device 100 will participate in the transfer chain. These terms or parameters, for example, can be a transfer cost or fee that the intermediary institution computing device 100 requires in exchange for participating in the transfer chain, a minimum guaranteed transfer, and a lockout timeout. The transfer cost or fee can be represented in any suitable manner, such as a percentage of the value of the resources transferred to the intermediary or a fixed amount of any resource type.

[0195] In 2004, a proposed transfer can be received. For example, intermediary institution computing device 100, after accepting the quote, can receive a proposed transfer from any suitable computing device or system, such as coordinator 400. The proposed transfer can represent the participant to which the intermediary using intermediary institution computing device 100 will transfer resources as the destination transfer of the proposed transfer; and the participant from which the intermediary will receive resources as the source transfer of the proposed transfer; the type and amount of resources in each transfer; the resource tracking computing device at which the transfer will occur; and any conditions of constraints placed on the resources constrained for the transfer.

[0196] In 2006, it can be determined whether the constraints on the resource for the source transfer in the proposed transfer are the same as the constraints on the resource for the destination transfer. For example, intermediary computing device 100 can determine that the proposed transfer indicates that the constraints on the resource for the source transfer and the destination transfer are both receiving a signed message from a trusted system, and thus the constraints on the source transfer and the destination transfer are the same. The constraints on the resource for the source transfer and the destination transfer can also be receiving a receipt of a signed message from receiver computing device 1100, which can be a pre-agreed receipt. For example, the receipt satisfying the constraints can also be provided by a third party, as delegated by the receiver. The third party can be, for example, resource tracking computing device 720, a third party notary, a service that generates receipts confirming shipment of tangible goods, or any other suitable party. If the source transfer and the destination transfer have the same constraints, the flow can proceed to 2016. Otherwise, the flow can proceed to 2008.

[0197] In 2008, it can be determined whether the constraints on the resource for the source transfer in the proposed transfer are evidence of completion of the destination transfer. For example, intermediary computing device 100 can determine that the proposed transfer indicates that the constraints on the resource for the source transfer are evidence of completion of the destination transfer received from resource tracking computing device 600 in the form of a transfer confirmation receipt. Resource tracking computing device 600 can be responsible for the destination transfer of the resource from an intermediary using intermediary computing device 100 to another intermediary or a receiver. If the constraints on the source transfer are evidence of completion of the destination transfer, the flow can proceed to 2010. Otherwise, the flow can proceed to 2022, in which the proposed transfer can be rejected.

[0198] In 2010, a transfer confirmation receipt can be received. For example, intermediary computing device 100 can receive a transfer confirmation receipt from resource tracking computing device 600. The transfer confirmation receipt can be evidence of completion of the destination transfer, in which the resource is transferred from, for example, resource pool 644 owned by an intermediary using intermediary computing device 100 to resource pool 642 owned by, for example, a receiver or by another intermediary. The intermediary computing device can have sent execution instructions to resource tracking computing device 600, for example, to implement the transfer of the resource to the receiver, or resource tracking computing device 600 can have received the execution instructions from intermediary computing device 710.

[0199] In 2012, a transfer confirmation receipt can be sent. For example, intermediary computing device 100 can send the transfer confirmation receipt received from resource tracking computing device 600 to resource tracking computing device 200. The transfer confirmation receipt can satisfy the constraints on the resource constrained at resource tracking computing device 200, for example, in resource pool 242 owned by the sender.

[0200] In 2014, an execution instruction can be sent. For example, the intermediary computing device 100 can send an execution instruction to the resource tracking computing device 200. The execution instruction can cause the resource tracking computing device 200 to implement a source transfer for the intermediary computing device 100, transferring the encumbered resource from the resource pool 242 owned by the sender to the resource pool 244 owned by the intermediary using the intermediary computing device 100. This can cause the ownership of the encumbered resource to be transferred from the sender to the intermediary. Since the encumbrance condition for the resource in the resource pool 242 can have been satisfied by receiving the transfer confirmation receipt sent by the intermediary computing device 100, the resource tracking computing device 200 can automatically perform the transfer upon receiving the execution instruction.

[0201] In 2016, an encumbrance authorization can be sent. For example, the intermediary computing device 100 can send an encumbrance authorization to the resource tracking computing device 600. The encumbrance authorization can authorize the resource tracking computing device 600 to set an encumbrance on a resource tracked in the resource pool 644 owned by the intermediary using the intermediary computing device 100. The type and amount of the encumbered resource, the condition of the encumbrance, and the participant to which the resource will be transferred once the encumbrance condition is satisfied can be indicated in the encumbrance authorization, or can have been indicated in the proposed transfer to the resource tracking device 600. The encumbrance condition for the resource can be receiving a signed message from a trusted system. The encumbered resource is intended to be transferred to the recipient or to another intermediary as a destination transfer for the intermediary computing device 100.

[0202] In 2018, an encumbrance condition satisfaction receipt can be received. For example, the intermediary computing device 100 can receive a signed message from a trusted system (e.g., the coordinator 400, etc.) that can exist or be involved in the transfer chain, a pre-agreed signed message from the recipient computing device 1100, or a receipt from some third party delegated by the recipient to generate the receipt. The signed message can be signed with an encryption private key that the intermediary computing device 100 can verify with a corresponding public key. The trusted system can send out the signed message when it receives a prepared transfer receipt, for example, from all resource tracking computing systems in the transfer chain.

[0203] In 2020, an execution instruction can be sent. For example, intermediary computing device 100 can send an execution instruction to resource tracking computing device 200. The execution instruction can cause resource tracking computing device 200 to implement a source transfer for intermediary computing device 100, transferring the constrained resource from the resource pool 242 owned by the sender to the resource pool 244 owned by the intermediary using intermediary computing device 100. This can transfer ownership of the constrained resource from the sender to the intermediary. Since the constraint condition for the resource in resource pool 242 can have been satisfied by receiving the signed message from the trusted system, resource tracking computing device 200 automatically makes the transfer upon receiving the execution instruction. Resource tracking computing device 200 can receive the signed message at the same time as intermediary computing device 100, or intermediary computing device 100 can forward the signed message to resource tracking computing device 200.

[0204] In 2022, the transfer can be rejected. For example, if the constraint condition for the resource of the source transfer is neither receiving a signed message from a trusted system nor receiving evidence of completion of the destination transfer, intermediary computing device 100 can reject the transfer.

[0205] Figure 20B An example process suitable for a resource transfer system according to implementations of the disclosed subject matter is shown. In some implementations, the transfer can use a temporary consensus network. In 2007, after determining in 2006 that the constraint condition for the resource of the source transfer in the proposed transfer is the same as the constraint condition for the resource of the destination transfer, a request for a trust list can be received. For example, intermediary computing device 100 can receive a request for a trust list from an initiator of the transfer that can include systems or nodes trusted by the intermediary. The initiator can be any system that can have initiated the transfer, such as sender computing device 300, recipient computing device 1100, intermediary computing device 100, or some other intermediary computing device in the transfer chain, or coordinator 400, etc., that sent out a request for an offer.

[0206] In 2009, the trust list and confirmation can be sent. For example, intermediary computing device 100 can send the trust list to the initiator along with a confirmation that intermediary computing device 100 will participate in the transfer chain. The intermediary can not have or maintain its own trust list, and the trust list can be sent on its behalf by, for example, resource tracking computing device 200.

[0207] In 2011, after sending the constrained authorization as in 2016, a statement can be received that indicates that the provisional consensus network approved the transfer. For example, the intermediary computing device 100 can receive a signed statement from more than 1 / 3 of the member nodes of the provisional consensus network that indicates that the transfer was approved. The signed statement can be received by the intermediary computing device 100 from the initiator or from a member node in the case that the intermediary computing device 100 is the initiator. If the intermediary computing device 100 is the initiator, the signed statement can be sent to other systems in the transfer chain, including the sender computing device 300, the recipient computing device 1100, the intermediary computing device, and the resource tracking computing device. The signed statement can be used to release the constraints on the resource to be transferred to the intermediary, for example, allowing the resource tracking computing device 200 to follow the execution instructions sent as in 2020 and transfer the resource constrained by the sender to the resource pool of the intermediary using the intermediary computing device 100. The signed statement can also be, for example, a receipt from the receiving computing device 1100 or a system of a participant to whom the recipient delegated responsibility. The receipt can be signed by a member node of the provisional consensus network and time-stamped.

[0208] Figure 21 An example process suitable for a resource transfer system according to implementations of the disclosed subject matter is shown. In 2102, an initiator, which can be, for example, a sender computing device 300, a recipient computing device 1100, or an intermediary computing device such as the intermediary computing device 710, or a coordinator 400, can collect trust lists from any stakeholder system in the transfer chain. The transfer can have been requested by the initiator, or the initiator can be a coordinator 400 that can set up the transfer chain on behalf of, for example, a sender computing device 300 or a recipient computing device 1100 that requested the transfer. Stakeholders can be, for example, the sender, the recipient, and any intermediary in the transfer chain that can constrain a share in the transfer. For example, the trust lists can be collected from the sender computing device 300, the recipient computing device 1100, and any intermediary device in the transfer chain. If a stakeholder does not have or maintain its own trust list, the trust list can be provided on behalf of the stakeholder by, for example, the resource tracking computing device. The resource tracking computing device can provide a trust list on behalf of a stakeholder with which the resource tracking computing device performed a resource transfer as part of a transaction. The trust list of a stakeholder can specify systems or nodes that can approve a transfer with the trust of the stakeholder.

[0209] In 2102, the initiator can compute the intersection of the trust lists collected from the stakeholder systems. The intersection of the collected trust lists can include nodes that appear on all of the collected trust lists. The intersection nodes of the trust lists can become member nodes of the provisional consensus network.

[0210] In step 2104, the initiator can contact the stakeholder systems in the transfer chain to request that the stakeholder systems set constraints on resources to be used in the transaction. The constraints can be set to be released when deciding on the temporary consensus network. The constrained resources can be, for example, funds in any currency or cryptocurrency, or any other economic resources including natural resources, commodities, goods, art, artifacts, collectibles, or other valuable items, etc. The resources can be constrained at the resource tracking computing devices in the transfer chain.

[0211] In 2105, the initiator can receive responses from the stakeholder systems indicating whether the stakeholders agree to participate in the transfer chain, and can confirm successful constraints on the resources to be transferred by the stakeholders. The responses can include, for example, a signed statement of readiness to transfer generated by the resource tracking computing devices in response to receiving the constraint authorization, thereby confirming both the participation of the stakeholders and the successful constraints on the resources to be transferred. The responses can also be, for example, a receipt from the receiver or a system of a participant to which the receiver has delegated responsibility. The receipt can be, for example, a signed statement from the receiver with contents of pre-agreement from the receiver that can be sent by the receiver in response to receiving a receipt of readiness to transfer from the last intermediary computing device in the transfer chain. The existence of the receipt can confirm that the resources to be transferred are successfully constrained. The individual stakeholders can still send responses to the initiator agreeing to participate in the transfer, or the receipt from the receiver can serve as the agreement of the stakeholders to participate, since the receipt confirms that the stakeholders have constrained the appropriate resources to participate in the transfer.

[0212] In step 2106, it can be determined whether all the stakeholders agree to participate in the transaction. If all the stakeholders agree to participate, the flow can proceed to 2107, in which the transfer can attempt to commit or execute. Otherwise, the flow can proceed to 2113, in which the transfer can be aborted.

[0213] In step 2107, the initiator can provide proof that all the stakeholders have constrained the resources to be used in the transfer to the member nodes of the temporary consensus network. The proof can be, for example, a signed receipt such as a receipt of readiness to transfer from the stakeholder systems or from the resource tracking computing devices that constrained the resources. The proof can also be, for example, a receipt from the receiver or a system to which the receiver has delegated responsibility, such as a signed message of pre-agreement contents sent to the initiator in the case where the last intermediary in the transfer chain sends a receipt of readiness to transfer to the receiver.

[0214] In step 2108, the member nodes can agree that the transfer is successful. This can approve the transfer. The member nodes of the temporary consensus network can determine that the transfer is successful and approve the transfer based on the constraints on the resources and any other appropriate criteria. For example, if all the resources required for the transfer are demonstrably constrained under the conditions that the temporary consensus network's decision is, then the transfer can be successful because once the temporary consensus network signals that the constraints can be released, each of the stakeholders in the transaction can receive the appropriate resources to enable the transfer of the resources on the resource tracking computing devices in the transfer chain. The proof of the constraining of the resources can be a prepared transfer receipt. The prepared transfer receipt can be time-stamped and can need to be ready before some deadline or timeout for the transfer to be approved by the temporary consensus network expires. The proof can also be a receipt from the recipient or a system of a participant that the recipient delegated responsibility to. Such a receipt can not include any details of the transfer itself and the member nodes can consider the existence of the receipt as proof that the appropriate constraints were set to enable the successful completion of the transfer. If, for example, due to late submission, loss, forgery, or other untrustworthy prepared transfer receipt or receipt from the recipient, the temporary consensus network does not agree that the transfer is successful and thus does not approve the transfer, then the transfer can time out and be aborted as in step 2113.

[0215] In step 2109, the initiator can request cryptographic signed statements from the member nodes regarding the decision outcome of the temporary consensus network.

[0216] In step 2110, the initiator can receive from the member nodes a minimum number of cryptographic signed statements regarding the decision outcome of the temporary consensus network. The minimum number can be 1 / 3 of the number of member nodes in the temporary consensus network. If a receipt from the recipient is provided to the member nodes, the cryptographic signed statements can be receipts from the recipient that can be signed by the member nodes and time-stamped with the time the member nodes received the receipt.

[0217] In step 2111, the minimum number of cryptographic signed statements from the member nodes regarding the decision outcome of the temporary consensus network can be presented by the initiator to the stakeholder system. The cryptographic signed statements can prove to the stakeholder system that the transfer is successful and approved and that the conditions regarding the constrained resources in the transfer chain have been satisfied by the protocol of the temporary consensus network.

[0218] In step 2112, the stakeholders can execute or commit the transfer. The stakeholder system can issue any required instructions to any resource tracking computing devices in the transfer chain. The resource tracking computing devices can release the constrained resources based on the decision of the ad hoc consensus network, and the resource tracking computing devices can perform the appropriate transfer of the now released resources between resource pools on the resource tracking computing devices, such that the resources are transferred from the sender as a whole to the recipient, and in the case of a circular transfer chain, back to the sender, completing the transfer.

[0219] In step 2113, the initiator can wait for a timeout. There can be some set period of time in which the ad hoc consensus network will attempt to reach a quorum of transfer success and approval. The initiator can wait for this period of time until a timeout is reached.

[0220] In step 2114, the member nodes can reach an agreement that the transfer was not successful. If the ad hoc consensus network cannot reach a quorum of transfer success and approval before the timeout is reached, then the transfer can not be successful.

[0221] In step 2115, the initiator can request cryptographic signed statements from the member nodes regarding the decision of the ad hoc consensus network.

[0222] In step 2116, the initiator can receive from the member nodes a certain minimum number of cryptographic signed statements regarding the decision of the ad hoc consensus network. This minimum number can be 1 / 3 of the number of member nodes in the ad hoc consensus network.

[0223] In step 2117, the minimum number or more of cryptographic signed statements from the member nodes regarding the decision of the ad hoc consensus network can be presented by the initiator to the stakeholder system. The cryptographic signed statements can prove to the stakeholder system that the transaction was not successful due to the ad hoc consensus network not reaching a quorum of approval of the transfer.

[0224] In 2118, the stakeholders can roll back the transaction. Since the transaction was not successful, the stakeholder system can release the constraints on any resources constrained on any resource tracking computing devices, resetting the resource pools on the resource tracking computing devices to a pre-transfer state.

[0225] Embodiments of the presently disclosed subject matter can be implemented in and used for a variety of component and network architectures. Figure 22is an example computer system 20 suitable for implementing embodiments of the presently disclosed subject matter. The computer 20 includes a bus 21 that interconnects major components of the computer 20, such as the following: one or more processors 24; memory 27, such as RAM, ROM, or flash RAM; an input / output controller 28; and a fixed storage 23, such as a hard drive, flash storage, or SAN device. It will be understood that other components, such as a user display, such as a display screen via a display adapter, user input interfaces and associated user input devices, such as a keyboard, mouse, or touchscreen, and other components known in the art for use in or in connection with general purpose computing systems, can or can not be included.

[0226] The bus 21 enables data communication between the central processor 24 and the memory 27. The RAM is generally the main memory into which the operating system and application programs are loaded. The ROM or flash memory can contain, among other code, the Basic Input-Output system (BIOS) which controls basic hardware operation such as interaction with peripheral components. Application programs residing in the memory 27 are typically loaded from a computer readable medium such as the fixed storage 23 and / or the memory 27, an optical disk drive, or an external memory interface, etc.

[0227] The components shown can be integral to the computer 20, or can be separate and accessed through other interfaces. Other interfaces, such as a network interface 29, can provide connectivity to remote systems and devices via telephone links, local or wide area networks, or other communication links, etc. For example, as Figure 23 As shown, the network interface 29 can enable the computer to communicate with other computers via one or more local area networks, wide area networks, or other networks.

[0228] Many other devices or components (not shown) can be connected in a similar manner, such as document scanners, digital cameras, or auxiliary, supplemental, or backup systems, etc. Conversely, all of the components shown as part of the computer can not be present, or can be different from those shown. For example, the computer can be a stand-alone system, or it can be a distributed system with components in different physical locations. Figure 22 The components shown can be interconnected in different ways from those shown. For example, Figure 22 The operation of the computer shown is readily understood by those of ordinary skill in the art, and it will not be discussed in detail in this application. The code to implement the present application can be stored in a computer readable storage medium, such as one or more of the memory 27, the fixed storage 23, a remote storage location, or any other storage medium known in the art.

[0229] Figure 23An example configuration according to embodiments of the disclosed subject matter is shown. One or more clients 10, 11, such as local computers, smart phones, tablet computing devices, and remote services, can connect to other devices via one or more networks 7. The networks can be local networks, local area networks, the Internet, or any other appropriate communication network, and can be implemented on any appropriate platform including wired and / or wireless networks. The clients 10, 11 can communicate with one or more computer systems, such as a processing unit 14, a database 15, and a user interface system 13. In some cases, the clients 10, 11 can communicate with the user interface system 13, which can provide access to one or more other systems, such as the database 15 or the processing unit 14. For example, the user interface 13 can be a user-accessible web page that provides data from one or more other computer systems. The user interface 13 can provide different interfaces to different clients, such as a human-readable web page to a web browser client 10, and a computer-readable API or other interface to a remote service client 11. The user interface 13, database 15, and processing unit 14 can be part of an integrated system, or can include multiple computer systems that communicate via a private network, the Internet, or any other appropriate network. The processing unit 14, for example, can be part of a distributed system such as a cloud-based computing system, search engine, or content delivery system, which can also include or communicate with the database 15 and / or the user interface 13. In some configurations, the analysis system 5 can provide backend processing, such as pre-processing of stored or acquired data by the analysis unit 5 before delivery to the processing unit 14, database 15, and / or user interface 13. For example, the machine learning system 5 can provide various predictive models or data analysis to one or more other systems 13, 14, 15.

[0230] The above description has been presented for the purpose of illustration and description. It is not intended to be exhaustive or to limit embodiments of the disclosed subject matter to the precise forms disclosed. Many modifications and variations are possible in light of the above teaching. These embodiments were chosen and described in order to explain the principles of embodiments of the disclosed subject matter and their practical application, thereby enabling others skilled in the art to adopt these embodiments and various embodiments with various modifications as are suited to the particular use contemplated, without departing from the scope of the embodiments of the disclosed subject matter.

Claims

1. A computer-implemented method performed on a data processing apparatus, the computer- implemented method comprising the steps of: receiving an instruction to transfer a first quantity of a first resource type from a first resource pool to a second resource pool, wherein the first resource pool comprises a first register on a blockchain ledger, the second resource pool comprises a second register on the blockchain ledger, and the blockchain ledger is distributed among a plurality of computing devices; receiving an instruction to set a constraint on a second quantity of the first resource type in the first resource pool, wherein a condition of the constraint is receipt of an indication that a transfer has been approved by a provisional consensus network; receiving an authorization to set the constraint on the second quantity of the first resource type in the first resource pool; in response to receiving the authorization, setting the constraint on the second quantity of the first resource type in the first resource pool to create a constrained second quantity of the first resource type, wherein the constrained second quantity of the first resource type cannot be transferred from the first resource pool until the constraint is released; receiving a message that satisfies the condition of the constraint, wherein the message that satisfies the condition of the constraint comprises an indication that the provisional consensus network approved the transfer; receiving an instruction to perform the transfer of the first quantity of the first resource type from the first resource pool to the second resource pool; and in response to receiving the message that satisfies the condition of the constraint and the instruction to perform the transfer, releasing the constraint on the constrained second quantity of the first resource type, causing a first register associated with the first resource type in the first resource pool to decrease by the first quantity, and causing a second register associated with the first resource type in the second resource pool to increase by the first quantity. The provisional consensus network comprises a plurality of member nodes.

2. The computer-implemented method of claim 1, wherein, The indication that the provisional consensus network approved the transfer comprises a declaration from a threshold number of member nodes that the provisional consensus network approved the transfer.

3. The computer-implemented method of claim 2, wherein, The threshold number of member nodes is one-third of a number of member nodes.

4. The computer-implemented method of claim 3, wherein, The provisional consensus network approves the transfer in the event that a quorum number of member nodes judge that the transfer is approved based on one or more prepared transfer receipts or receipts from a specified party.

5. The computer-implemented method of claim 3, wherein, The quorum number is two-thirds of the number of member nodes.

6. The computer-implemented method of claim 5, wherein, The member nodes of the provisional consensus network are nodes that are common to a trust list from systems in a chain of transfers.

7. The computer-implemented method of claim 2, wherein, Releasing the constraint on the second quantity of the first resource type, causing the first register associated with the first resource type in the first resource pool to decrease by the first quantity, and causing the second register associated with the first resource type in the second resource pool to increase by the first quantity is deterministically performed upon receiving the message that satisfies the condition of the constraint and the instruction to perform the transfer, and cannot be aborted.

8. The computer-implemented method of claim 1, wherein, 9. A computer-implemented method performed on a data processing apparatus, the computer- implemented method comprising the steps of: receiving a request for a trust list from an initiator of a transfer; ​ sending the trust list to the initiator or sending instructions to the resource tracking system to send the trust list to the initiator; receiving, from the initiator, a request to authorize setting a constraint on a first quantity of a first resource type in a first resource pool, wherein the first resource pool comprises a first register on a blockchain ledger and the blockchain ledger is distributed among a plurality of computing devices; sending an authorization that enables setting a constraint on the first quantity of the first resource type in the first resource pool, wherein a condition of the constraint is receipt of an indication that the transfer has been approved by a provisional consensus network; sending, to the initiator, a confirmation to participate in the transfer; receiving, from the initiator, a message comprising an indication that the provisional consensus network approved the transfer; and in response to receiving the message comprising the indication that the provisional consensus network approved the transfer, releasing the constraint on the first quantity of the first resource type subject to the constraint, causing the first register in the first resource pool associated with the first resource type to decrease by the first quantity.

10. The computer-implemented method of claim 9, wherein, further comprising the steps of: in response to receiving the message comprising the indication that the provisional consensus network approved the transfer, sending instructions to perform a transfer of a second quantity of a second resource type from a second resource pool to a third resource pool.

11. The computer-implemented method of claim 10, wherein, further comprising the steps of: sending the message comprising the indication that the provisional consensus network approved the transfer to release the constraint on the second quantity of the second resource type.

12. The computer-implemented method of claim 9, wherein, further comprising the steps of: prior to receiving the request for the trust list, receiving proposed transfers comprising a source transfer and a destination transfer.

13. The computer-implemented method of claim 9, wherein, the provisional consensus network comprises a plurality of member nodes.

14. The computer-implemented method of claim 13, wherein, the indication that the provisional consensus network approved the transfer comprises a declaration from a threshold number of member nodes that the provisional consensus network approved the transfer.

15. The computer-implemented method of claim 14, wherein, the threshold number of member nodes is one-third of a number of member nodes.

16. The computer-implemented method of claim 14, wherein, the provisional consensus network approved the transfer in a case where a quorum number of member nodes judged to approve the transfer based on one or more prepared transfer receipts or receipts from a designated participant.

17. The computer-implemented method of claim 16, wherein, the quorum number is two-thirds of the number of member nodes.

18. The computer-implemented method of claim 10, wherein, the member nodes of the provisional consensus network are nodes common to trust lists from systems in a chain of transfers.

19. A computer-implemented method performed on a data processing apparatus, the computer- implemented method comprising the steps of: sending a request for a trust list to a plurality of stakeholder systems in a chain of transfers comprising a plurality of stakeholder systems and a plurality of resource tracking systems; receiving a trust list for each of the plurality of stakeholder systems in the chain of transfers; determining an intersection of nodes on the received trust lists to generate a provisional consensus network; sending a request to each stakeholder system of the plurality of stakeholder systems in the transfer chain with a destination transfer to request that the stakeholder system set a constraint on a specified amount of a specified resource type in a specified resource pool at a specified resource tracking system of the plurality of resource tracking systems, wherein the specified resource pool comprises a specified register on a blockchain ledger and the blockchain ledger is distributed among a plurality of computing devices; receiving confirmation that the stakeholder system set the constraint, wherein the confirmation comprises a prepared transfer receipt generated by each resource tracking system of the plurality of resource tracking systems in the transfer chain or a receipt from a specified participant; receiving confirmation from each stakeholder system in the transfer that the stakeholder system consents to participate in the transfer; sending the prepared transfer receipt or the receipt from the specified participant to a member node of the ad hoc consensus network; receiving a statement from at least a threshold number of member nodes of the ad hoc consensus network that the ad hoc consensus network approves the transfer; and sending the statement from the at least threshold number of member nodes of the ad hoc consensus network to the stakeholder systems, wherein, in response to receiving the statement that the ad hoc consensus network approves the transfer, releasing the constraint on the specified amount of the specified resource type that is constrained, causing the specified register in the specified resource pool associated with the specified resource type to decrease by the specified amount.

20. The computer-implemented method of claim 19, wherein, The plurality of stakeholder systems comprises a sender, a recipient, and at least one intermediary.

Images