Contract-Based Transactions

Add in Programmability and Logic into Transactions

Knox Networks has implemented a system that separates the programmability layer (Contract negotiation) from the asset transfer layer (Contract fulfillment) that lives within the Transaction Validator Service. A Contract-Based Transaction fulfills a transfer of assets that is stipulated in a successfully negotiated Contract. Contracts help to create modular transactions that cover a wide range of use cases, including atomic multi-party and multi-asset settlements (PvP, DvP), cross-border payments, escrow, etc., and support industry-recognized techniques such as Hashed Timelock Contracts (HTLCs).

Contract-Based Transactions reduce costly errors, limit exposure to counterparty failures, and enforce compliance by allowing institutions to stipulate regulatory requirements before any transfer of assets takes place. All assets are transferred atomically: if any participant fails to deliver on any of their commitments then all assets retain their original owner.

The figure below shows a simplified view of a sample contract between two parties, Alice and Bob, in an FX transaction.

Simplified View of a Sample Two-Party Foreign Exchange (FX) Contract

Simplified View of a Sample Two-Party Foreign Exchange (FX) Contract

Contract Structure

Knox Contracts stipulate a series of Commitments and Conditions to be fulfilled by Participants. Here is a sample Contract flow:

  • A Contract Originator proposes a Contract to all other Participants. Any participant can decide to accept or reject a proposed Contract based upon their own criteria.
    • If a Contract is rejected, a newly proposed Contract can be created by any party.
  • All Participants sign the Contract as proof of agreement and acceptance.
  • Once a Contract is in place, each Participant submits the required assets corresponding to their Commitments, which are then locked (so the same assets cannot be double spent).
  • When all Commitments are in place (committing the respective assets to the new owner) and all Conditions are met, the Transaction Manager atomically completes the transfer of all assets.
    • If Participants do not submit their assets by the timeout Condition specified in the contract, the system atomically reverts ownership of previously locked assets to the original owners.
    • Examples of other Conditions besides timeouts include: AML/CFT/Sanctions checks, valid address checks, etc.
Sample Contract-Based Transaction Execution Flow

Sample Contract-Based Transaction Execution Flow

Contract-Based Transactions are also able to carry messages in any format (e.g., ISO 20022, NACHA) inline with the overall transaction. With Knox, the traditional separation between messaging and asset transfers is eliminated and messaging is available inline with the transaction itself.

Participants in the Knox system utilize Contract-Based Transactions via APIs to accomplish secure and complex transactions between multiple parties. Contract-Based Transactions are based on an event-driven architecture, and at every stage in the transaction lifecycle, various events are generated with their respective details.

In addition to being able to integrate to DLTs over techniques such as HTLC mentioned above, this also allows easy integration with any traditional messaging interfaces and any variety of systems expected in a banking environment, using popular techniques such as MQ or Webhooks. Based on the events, flexible business and regulatory logic can be inserted into the Contract to allow for complex and conditional execution of transactions.

Knox Contract-Based Transactions are executed by state machines (rather than EVMs or other equivalent smart contracting evaluators). There is no need to “encode” conditional statements or loops. Failure of transactions does not require complex steps to retrieve assets committed to the failed transaction. These are automatically reinstated to the last owner.

Conclusion

Knox Network’s Contract Based Transactions allow for bank specific adapters to be easily plugged in (e.g., an adapter that maps fields from Knox transactions to fields in an ISO 20022, MT or a FIX message for on-ramps/offramps to other systems). This maximizes the potential for programmability because any ecosystems that arise, whether DLT or traditional, can easily plug into using Knox Network’s FBDAs as a method of payment.


What’s Next