System and Method for Collaborative Consensus Protocols

This application claims priority to U.S. provisional patent application Ser. No. 63/572,044, filed on Mar. 29, 2024. Priority to the provisional patent application is expressly claimed, and the disclosure of the provisional application is hereby incorporated herein by reference in its entirety and for all purposes.

This present disclosure relates generally to digital protocols, and more specifically, but not exclusively, to a collaborative consensus protocol for automating contract settlement and enforcement between counterparties through automated, verifiable agreements via direct peer-to-peer communication and cryptographic verification of inputs, operations, and outputs.

In today's increasingly interconnected and complex business landscape, establishing trust, transparency, and efficiency in contractual settlement and enforcement between counterparties is paramount. Traditional manual processes for contract settlements, involving the exchange and reconciliation of inputs, calculations, and outputs, are plagued by inefficiencies, risk, and the potential for disputes and enforcement actions. These challenges are particularly prevalent in industries involving frequent settlement, dynamic data sources, and/or complex settlement terms.

To address these issues, various approaches have been proposed, including blockchain-based smart contracts and decentralized applications (DApps). While these solutions offer trustless execution and immutable record-keeping, they often suffer from scalability limitations and high costs associated with achieving global consensus across a decentralized network.

The manual reconciliation of contracts between counterparties is a time-consuming, error-prone process that often leads to disputes, delays, and inefficiencies. In industries like energy, where contracts involve complex calculations based on dynamic data sources, the challenges of manual reconciliation are particularly acute. Counterparties must exchange inputs, perform calculations, and verify outputs to ensure that both parties have an identical understanding of the agreed-upon terms. Beyond energy and payments, these same complications exist for all commodities, and in regulatory compliance and quality assurance, healthcare, insurance, lending, logistics, and other industries where a system of automated verification, serialization, and peer-to-peer agreement are valuable.

Existing solutions to automate contract settlement and/or enforcement, such as blockchain-based smart contracts, offer trustless execution and immutable record-keeping. However, these solutions require costly global consensus mechanisms to achieve agreement across a decentralized network. The usage of global consensus mechanisms is costly because all members of the global consensus—not just the members of the contract—must receive the data and run calculations upon it, for each settlement step in the process. As a result, the scalability and cost challenges associated with blockchain networks, whether public or private, limit their applicability in real-world scenarios where automated settlements and enforcement are valuable.

In view of the foregoing, a need exists for an improved system and method for automating contract settlement and enforcement between counterparties to overcome the aforementioned obstacles and deficiencies of conventional manual reconciliation, verification, and generic smart contract technology.

It should be noted that the figures are not drawn to scale, and that elements of similar structures or functions are generally represented by like reference numerals for illustrative purposes throughout the figures. It also should be noted that the figures are only intended to facilitate the description of the preferred embodiments. The figures do not illustrate every aspect of the embodiments described and do not limit the scope of the present disclosure.

Currently available contract enforcement systems are difficult to scale and have limited real-time settlement functionality. A collaborative consensus protocol enables automated, verifiable agreement between counterparties without the need for a blockchain or global consensus. Using a collaborative consensus protocol systemshown in, achieves this result. Leveraging peer-to-peer communication, cryptographic signatures, and iterative verification processes, the collaborative consensus protocol streamlines contract enforcement while maintaining a high degree of trust, transparency, and efficiency, without divulging sensitive information to a central authority.

The disclosed systemcomprises at least two client devices, such as a first client deviceand a second client deviceas shown in. The client devicescan communicate bidirectionally with each other without a centralized server. In some embodiments, with reference to, a coordination servercan assist the client deviceswith the initial connection by aiding each counterparty in being able to have the necessary information to be able to find and communicate, across the Internet (or other medium), appropriately.

By using client devicesandowned by each counterparty and not a separate, central entity, each counterparty's sensitive data related to the contract, such as the rate of expense per unit of energy or the amount of energy consumed, is maintained in a secure and private manner without exposure to entities outside of the contractual agreement. Although shown and described as counterparties to a contract in exemplary embodiments, the client devicesandcan represent multiple parties to a contract as desired (e.g., clients, suppliers, consumers, and so on).

In some embodiments, contract settlement serves to verify and reconcile financial data; however, the disclosed systems and methods can be applied to any dataset that requires cross-verification, such as ensuring identical datasets exist among counterparties, or comparing similar or related datasets from various sources to measure accuracy, monitor compliance or determine completeness. Contract execution and verification extends to payments and many data-driven agreements, where any deviations in inputs and outputs affect contract enforcement.

In some embodiments, the collaborative consensus protocol leverages direct peer-to-peer communication between counterparties to establish automated, verifiable agreement on contractual terms, inputs, operations, and outputs. The benefit of leveraging peer-to-peer communication-especially over encrypted channels (e.g., Hypertext Transfer Protocol Secure (HTTPS))—allows for the information exchanged between the parties to be kept private from competitors or other parties that, from the perspectives of the contracted parties, should not be able to view the information of or related to the contract. To facilitate this communication, counterparties know each other's node identifier (e.g., email address or other unique identifier) and public keys (pubkeys) ahead of time. In some embodiments, this information, along with the location of the coordination server, is exchanged out-of-band (e.g., via outside communication methods such as email or phone). To establish connection, counterparties agree to use the coordination server, which servermaintains a mapping (e.g., such as a hash map) of node identifiers (e.g., email and/or public keys) to the up-to-date domain name records for counterparties. This simplifies the process of finding and connecting with their counterparty's valid server.

illustrates an exemplary data flow of the coordination serverinitializing communication between a first client device(a consumer device) and a second client device(a supplier device). In some embodiments, connection data for other clients is cached locally for a predefined duration (e.g., 60 seconds) to allow for dynamic updates to DNS configurations without requiring manual reconfiguration. Upon expiration of the cache, the client device queries the coordination server for the latest connection information, ensuring continued connectivity with minimal administrative overhead. In alternative embodiments, the system operates without a coordination server, relying instead on statically configured connection parameters defined manually on each client device.

In a preferred embodiment, each client deviceacts as both a supplier and a consumer, enabling cascading, multiparty contractual relationships. For example, a single party operating the first client device(user A of the client device) may be receiving services or goods from another party operating the second client device(user b of the client device). Simultaneously, user B may also act as a consumer in a separate agreement with a user C, operating a separate client device(not shown). This structure allows for a serial chain of contracts, in which obligations flow downstream, and payments or verifications flow upstream.

This configuration supports multiparty collaborative consensus, whereby a single contractual input or data point (e.g., metered usage or delivered quantity) can trigger a series of independently verified, yet interconnected, settlements across multiple parties. Each link in the contractual chain independently performs validation, signature verification, and output reconciliation, ensuring data integrity and consistency without requiring global consensus. This model facilitates dynamic, trust-minimized coordination across multiple stakeholders, such as in supply chains, energy markets, or financial consortia, where parties may be both consumers and suppliers at different layers of a value chain.

In some examples, the consumer deviceprovides the coordination serverwith the counterparty's node identifier (e.g., the email and pubkey of the user of the supplier device) to request the domain information of the supplier device. The coordination serverprovides the appropriate domain information to enable the supplier deviceto provide information and communicate directly to the consumer device

Exemplary data structures maintained by each client deviceare shown in. With reference to, the data stored in these data structures (e.g., tables) can be identified by a universally unique identifier (UUID) of the contract, which UUID matches between counterparties to ensure an auditable transaction record.

In alternative embodiments, a decentralized peer-discovery mechanism is implemented to further enhance the protocol's robustness and accessibility. This mechanism allows for the mapping of the node identifiers and pubkeys to their related domain name records without the out-of-band exchange of said node identifiers emails and pubkeys discussed above. For example, in some embodiments, instead of a coordination server, the mapping of node identifiers and pubkeys to their related domain name records can be implemented using magnet servers, bitcoin transactions to store information in a distributed way, gossip protocols, etc.

With reference to, in a preferred embodiment, contracts are written in a serialized format, such as using a special JavaScript Object Notation (JSON) schema that captures the terms (e.g., the rate of dollars owed per unit of consumption, pass through charges, tax rates, demand charges, site capacity, etc.), inputs (e.g., amount of energy consumed, interest rates, dynamic prices, etc.), operations (e.g., mathematical formulas by which the terms and inputs evaluate to a final output, including summation and multiplication, but also estimating and filtering data based on thresholds), and outputs (e.g., invoice amount, calculation subtotals, payment amount, informational reports, etc.) of the agreement. Contracts written in a serialized format enable the contract information to be transferred between client devices and/or compared for equality—or specific differences—even in the case that client devices are using different implementations.

As shown in, the digital contract is loaded on the client device, in a state where it can be used by the application. In one embodiment, the digital contract is serialized to share information between the parties. Counterparty identifier, such as email, is part of the digital contract. In this embodiment, serialization occurs only when the digital contract needs to be sent/shared and signed, thus keeping the digital contract in a serialized state for the minimum time possible and reducing the potential the digital contract become out of date with what is stored.

Turning to, each counterparty imports the serialized contract into their machine (their client device), where it is deserialized into a machine-understandable representation for comprehension by the contract-execution code on the client device. The deserialization of the digital contract advantageously enables the client deviceto understand what values and information is present in the serialized form of the digital contract. The digital contract is deserialized to be accepted and readable by the counterparty. Serialization and deserialization ensure counterparties have identical copies of the digital contract at the time of signing. In some embodiments, JSON is used for serialization. However, one of ordinary skill in the art can appreciate that alternative methods of serialization and deserialization can be used, such as Protocol Buffers. These operations can be executed by software modules, including but not limited to autonomous AI agents, which process inputs to generate outputs based on the contract's terms.

As shown in, the raw serialized contract is signed against with the private key corresponding to the already-exchanged public key. Each counterparty has logged into their client deviceusing their account email. The account email is tied to a public key. The user signs (approves) the local version of the digital contract. The signing process, in a preferred embodiment, uses Elliptic Curve Digital Signature Algorithm (ECDSA). ECDSA takes an arbitrary piece of data (in this case, the serialized contract) as the “message” and a private key that is associated with the already-exchanged public key and produces a digital signature that represents agreement. In other embodiments, similar signature algorithms can be used, such as Schnorr. The signature can then be shared with their counterparty to prove agreement of the contract terms. By using ECDSA to verify the signature of the digital contract against the known public key of their counterparty using the serialized contract as the message for the signature verification, such as shown in, each party ensures that they have an identical copy of the contract, and thus identical understanding of the contract terms. Each digital contract points to specific counterparties. With the counterparty public key and matching signature, parties can validate the signatures match the digital contract using whatever agreed-upon digital signature algorithm that was used to generate the signature, such as ECDSA. The signatures are shared, in some embodiments, peer-to-peer, with the assistance of the coordination server. Verified signatures by both parties trigger start of contract settlement.

Turning to, contracts are serialized, exchanged, and cryptographically signed, ensuring that both parties have an identical understanding of the agreed-upon terms. By verifying the signature of the contract against the known public key of their counterparty, each party can be confident that their counterparty has the same contract. As shown in, assume a user A (using client device) would like to initiate a contract with user B (using client device). First, the client device of user A (client device) serializes the agreed contract terms into a digital contract file. A digital signature is created by signing the contract file with the private key of user A. The digital signature, along with user A's public key, is transmitted to user B (at client device), where the signature can be validated to ensure the signed contract matches the terms of what is stored on user B's device. Each party uses the other's public key to verify the contract's digital signature, ensuring both sides are working on an identical copy of the terms of the contract. Once verification succeeds, user B countersigns the contract with their private key and returns the signed signature to user A. Once exchanged, both client devicesstores a copy of the identical contract in their local memory, each signed by the counterparty, thereby formally establishing a mutually verifiable agreement.

Counterparties may need to implement a change to the contract terms. Depending on the scope of the change and/or counterparty agreement, changes may be made directly to the deserialized contract on each client device individually and thus do not require signatures. In other embodiments, changes may follow the same serialization, deserialization and signing process as the original digital contract agreement. In either embodiment the counterparties' confirmation of invoice amounts and/or approval of payment request amounts utilizing the collaborative consensus protocol guarantee the client devices are operating from the exact same digital contract.

Turning to, the collaborative consensus protocol streamlines the exchange and verification of invoices between counterparties by automating the process of proposing, verifying, and accepting draft invoices, such as via process. In some embodiments, each invoice is identified by a combination of the digital contract UUID and invoice ID. The process starts at processby the consumer deviceidentifying any elapsed settlement frames without a completed invoice. At process, a supplier (via supplier server) generates a draft invoice based on the agreed-upon contract. It does this by querying/polling previously agreed upon data sources for the input information. For example, in the energy and payments example, this can include, but is not limited to, acquiring interval meter data from advanced metering infrastructure (AMI) via secure internet protocols (e.g., HTTPS), retrieving locational marginal pricing (LMP) and tariff rate schedules from an independent system operator's (ISO) market data portal, and integrating real-time grid telemetry for settlement calculations. Each client device may integrate additional external data sources, such as weather forecasts, to provide real-time inputs to AI agents for decision-making. The calculation(s) for the invoice's outputs are performed by the client server (e.g., via contract execution software that takes the contract's agreed-upon parameters and the input information and evaluates to a set of output(s)). Such calculations may be performed by AI agents using predictive models or machine learning techniques to optimize the outputs. The outputs are then placed into a data structure referred to as an invoice, such as shown in. This invoice contains the output information from calculations performed for a given contract over a given settlement frame with externally gathered inputs. This output information, along with storage of input information can be later used for financial, operation, and audit purposes, such as shown in-I. In some embodiments, the output information includes amounts owed, settlement frame beginning and ending times, and storage of the input information for this invoice. In other embodiments, where contract execution does not involve financial settlement, output information includes operational metrics, audit logs, reports of data discrepancies, completion timestamps. Each dataset follows a contract-defined schema and is subject to the same cross-verification process as invoices.

At step, this invoice is then sent to the consumer (via consumer device), who generates their own local invoice using the specifications on the digital contract stored locally, described above. If the invoice values between the supplier and consumer devices match (decision block), the consumer deviceconfirms the invoice (process). In some embodiments, counterparties agree to a tolerance window, wherein the invoice amounts calculated by each device independently do not need to match exactly, but the outputs must fall within a specified and acceptable tolerance window. A tolerance window can be set on a per contract basis in the digital contract terms. Additionally and/or alternatively, the tolerance window can be defined relative to a maximum percentage difference, a maximum nominal amount difference, a combination of both, or defined by an AI agent.

If the invoice values do not match or fall outside the tolerance window (decision block), the consumer rejects the invoice (process), prompting the supplier to generate a new invoice. This is done based on the assumption—given the verified signature—that the two servers are both evaluating the input information in the same manner. Thus, if the output information for a given settlement frame is different between the servers, then the input information is different, and must be re-gathered by both parties. The requirement to regather the data assumes that the data was bad for either (or both) party because of data availability issues, data being altered, or other unknown issues. For example, the supplier communicates a failure to the consumer server, which determines whether the supplier number was low or high. Failures are stored in the general application log. Because the supplier failed, no invoice is saved for the time period, so when the standard flow runs again, it will see a missing invoice for the time period and attempt to recalculate. The process will not attempt future invoices until all periods have a verified invoice. Each contract has established settlement frames, invoices for each frame are stored in an invoice table (local on both client servers), and if there is a lapsed settlement frame without an invoice, the supplier starts with the oldest lapsed settlement frame. This iterative process continues until both parties agree on the settlement outputs, creating a verified invoice (automated redundancy). At step, once both invoices are confirmed, payment is transmitted from the consumer deviceto the supplier devicefor processing. In some embodiments, the digital contract may specify circumstances to seek alternative data sources. The digital contract terms determine the circumstances, timing and alternative data sources polled.

Turning to, similarly, the collaborative consensus protocol automates the exchange and verification of payment amounts between counterparties by proposing, verifying, and accepting draft payment requests, such as shown as process. Each successful payment can be identified by a combination of the Digital Contract UUID and Payment ID. In embodiments that do not permit partial payments, the consumer device can request a Draft Payment Request if the Invoice Table has an Invoice with no associated payment IDs in a pending or paid state. The processbegins at stepwhere the consumer deviceidentifies confirmed invoices with a remaining balance. At step, the supplier (via the supplier device) generates a draft payment request based on the agreed-upon invoice, which is then sent to the consumer (via the consumer device). The draft payment request may be generated or adjusted by an AI agent that considers real-time conditions, such as market fluctuations or usage patterns, to optimize the payment amount within the contract's constraints. This draft payment includes the amount owed and the payment method required to send the funds to the supplier. At step, the consumer (via the consumer device) verifies that the payment amount is less than the remaining unpaid balance in the invoice and within an appropriate tolerance window. Some embodiments allow for partial payment, while others require full payment. In some embodiments where currency exchange rate is a factor, a tolerance window could be acceptable and defined in terms of the exchange rate. If the payment values meet the criteria (decision block), the consumer accepts the payment draft request and makes the payment (step). The process of making a payment varies based on the payment method. When using the Lightning Network for Bitcoin payments, payment is effectuated by the consumer device requesting a Lightning Network invoice. Using external APIs, the Supplier (or its agent) sends an invoice for payment in Bitcoin. When utilizing ACH, the payment request is put in a pending status and payment instructions communicated to consumer, or consumer's agent via external API. This automated process reduces the risk of errors and streamlines the payment exchange between counterparties. Otherwise, the payment request is denied and deleted at step.

In embodiments supporting partial payments, such as shown in, the consumer device can sum all payments IDs in a pending or paid state and request a Draft Payment Request for the lesser of the invoice remaining balance or consumer's available funds.

The collaborative consensus protocol operates as a modular framework, ensuring that the validation and agreement processes are decoupled from the execution of financial transactions. This means that even in cases where a payment fails, is delayed, or is not required, the collaborative consensus process remains intact, having already established a verified and mutually agreed-upon contract state between counterparties.

By integrating payment execution within this framework, the protocol enables automated, trustless settlement across any payment rail that supports programmable execution. This modular architecture ensures that contract validation, dispute resolution, and financial settlement remain independent processes, allowing for seamless integration with existing financial infrastructure while preserving the integrity and auditability of contractual execution.

Payments can be stored on a separate table; each row has a required foreign key that points to a specific invoice. From that table, whether there are multiple payments tied to a single invoice is easily determined. There should only be one pending or successful payment per invoice. If there are no successful payments, or all have failed, then we create a new one. This step occurs prior to creating the draft payment request. In some embodiments where partial payments are permitted, a payment will be created when pending or successful payments summed up are less than the invoice amount. Payments may also use digital assets, including cryptocurrencies and stablecoins, stored in digital wallets, supporting secure and programmable transactions across diverse networked environments.

With reference to, the collaborative consensus protocol supports atomic payments, ensuring that each payment transaction is executed as an indivisible step-either completing successfully or failing entirely. While payments must be discreet transactions, the system allows for partial payments, enabling counterparties to incrementally settle outstanding balances. Unlike traditional payment methods, atomic payments do not have a “pending” state, meaning a transaction is always “unpaid”, “paid”, or “expired” (such as shown in). An unpaid invoice can only have two actions to change its state, being fully paid in its exact amount (through one or multiple payments), or with the elapsing of time, changing its state to expired.

In some embodiments, Lightning Network payments offer atomicity and instant settlement. Lightning Network payments typically include invoices with an expiration time (defined field in the invoice).

Turning to, partial payments are available in some embodiments. Partial payments allow consumers to make a payment toward an outstanding balance on one or more invoices that is less than the outstanding balance. In this embodiment, the consumer device defines a limit for spending when asking for a draft payment request, and will reject a draft payment request coming from their supplier device if it is greater than the defined limit.

In some embodiments, using a “pending” state enables other payment methods, such as the Automated Clearing House (ACH) and FedWire. Traditional payment methods have a pending state where payments have been initiated from consumer to supplier but have yet to complete or fail. This leads to a further complication that must be handled in the logic of the system to not retry pending payments, even though they have been initiated, but are yet to succeed. This embodiment includes a new conditional branch to determine if a payment is pending when considering creating a new payment for an existing invoice.

Turning to, an exemplary process for handling payments through an external banking network (e.g., ACH transfers) is shown. In this embodiment, after the consumer requests a payment via a bank transfer (via consumer device), the supplier devicegenerates a draft payment instruction (such as an ACH payment request) instead of a Lightning invoice. The consumer device(or its linked bank agent) initiates the payment through the banking network. Because such payments have a pending state (not instant), the system includes a conditional check: if a payment is already pending for a given invoice, no new payment request is generated until the first transaction clears. Once the bank transfer is confirmed (funds received) or a timeout occurs, the invoice status is updated accordingly.shows the additional steps and conditional branches for integrating non-instant, bank-mediated payments into the collaborative consensus protocol.

Turning to, one embodiment of a data flow for preparing audit reports of the collaborative consensus protocol ofis shown. The input information, calculations, invoice and payment amounts can be stored on the client device. Only data for verified invoices and payments is stored on the client device. Using internal APIs, all data stored on client device is accessible to user in detailed and summary reports. Because of collaborative consensus, calculations and invoice amounts on user reports will match the counterparty's reports for the same UUID. Because the counterparties had the same terms at signing and agreed on the invoice and draft payment request, we can infer they have the same contract.

each show an exemplary user interface illustrating various features of the collaborative consensus protocol of.shows an exemplary user interface for an overview dashboard, presenting a consolidated summary of any active digital contracts, current status, total amount owed, and other system data.illustrates one exemplary user interface for a contract overview, which shows a list of active digital contracts, including contract ID, current status, total amount owed, recent transactions, and usage metrics.shows an embodiment of an interface for viewing the terms of a contract, which is derived from the deserialized contract terms.shows an embodiment of an interface for viewing a selected contract, which is similar to the overview dashboard of, for a particular contract.each shows an exemplary user interface for various reporting tools (e.g., invoice and payments history, contract settlements, and additional data supporting the digital contract and associated transactions.

each show an exemplary embodiment of the system environment of the collaborative consensus protocol of.shows an exemplary dataflow across the system environment for payments made through the Lightning Network. In this embodiment, the client devices rely on a third-party server to communicate the exchange rate and payment instructions directly with the exchange server provider (e.g., a bitcoin exchange service provider).shows an exemplary dataflow in a system environment for payments made through the ACH network.

In some embodiments, the invoicing and payments modules have large degrees of flexibility and only one point of interaction: making payments when able and there is an outstanding balance on an invoice. By having large flexibility and low interaction between these two modules, invoicing and payments can be changed or updated independently. In some embodiments, it is possible to make changes to how invoices are calculated with no effect on how payments are performed. Likewise, in some embodiments, payments can be made via several different payment methods, all independently of how the invoice itself was calculated.

A game-theoretic analysis of the protocol's incentives and disincentives for cooperation demonstrates that it is in both parties' long-term interests to cooperate and adhere to the protocol. By providing quicker feedback and enabling near-real-time settlements, the protocol reduces the potential impact of cheating behavior by counterparties. The analysis highlights the reduced moral hazard and clear present value downside for cheating, making cooperation the rational choice for both parties. AI agents embedded in client devices can be programmed to follow cooperative strategies, enhancing adherence to the protocol and maximizing long-term payoffs. Self-enforcing mechanisms, supported by automated verification, promote cooperation by ensuring prompt enforcement of terms across any digital system.

A further analysis using an augmented caterpillar game to demonstrate the Nash Equilibrium of not cheating for both players:

To analyze the incentives for cooperation and non-cheating behavior, we can model the interaction between the two counterparties as an infinitely repeated game, known as the “Augmented Caterpillar Game.”

In this game, each player (counterparty) has two possible actions in each round (settlement period):

The payoffs for each player in a single round are represented by the following matrix:

Where:

Assuming that the players are rational and aiming to maximize their long-term payoffs, the following inequalities must hold for the game to be considered a Prisoner's Dilemma: