Technical Spotlight: Contract-Based Transactions
Programmable transactions, especially atomic transactions are a key feature of digital payment platforms, that reduce counterparty risk by ensuring that all parties meet their obligations and no party risks losing assets due to counterparty default.
Contract-Based Transactions are Knox’s method of introducing controlled programmability into payments. Knox Networks approach separates the programmability layer from the asset transfer layer that lives within the Transaction Validator Service (see white paper).
Why Contract-Based Transactions?
Designed with financial institution (FI) needs in mind, Contract-Based Transactions reduce costly errors and limit exposure to counterparty failures. All assets are transferred atomically: if any party fails to deliver on any of their commitments then all assets remain with their original owner. Contract-Based Transactions facilitate compliance by allowing institutions to enforce regulatory and business requirements (e.g. Sanctions/AML checks, any other business rule) during a negotiation phase, before any transfer of assets takes place.
A Contract-Based Transaction fulfills the transfer of assets specified in a successfully negotiated Contract. Contracts help create diverse transactions that cover a wide range of use cases, including atomic multi-party and multi-asset settlements (link to PvP, link to DvP), cross border payments, escrow, etc., and support industry recognized techniques such as Hashed Timelock Contracts (HTLCs).
Contracts
Contracts in the Knox system are a set of Commitments made between Participants in the Contract together with Conditions applicable (e.g. a Timeout).
Contracts are proposed by an Originator, who proposes a set of Commitments and Conditions for the Contract. Signed confirmations are then gathered from all the Participants of a Contract, which will then have the Contract proceed into the Finalization phase.
Commitments
A Commitment is a Participant’s agreement to transfer a specified amount of an asset type to another Participant — e.g. Alice agrees to pay Bob $100. The Originator broadcasts the contract (including all proposed commitments) to all Participants in a contract, including those Participants that solely receive assets.
Conditions
Conditions are checks that determine whether a Contract should continue, and can include common checks such as time checks, balance checks, or more complicated conditions such as information provided via Oracles.
Example of a Contract Flow
The stages through which a Contract Based Transaction goes are illustrated below using a example contract representing a cross border remittance from Alice in USD to Bob in EUR, via a Foreign Exchange Provider.
Contract Proposed
Alice proposes a Contract where Alice would send 100 USD to the FX Provider, and the FX Provider would send 90 EUR to Bob, all to be completed before September 1, 2023.
Alice signs the proposal and waits for confirmation from the FX Provider and Bob. The FX Provider and Bob decide individually whether to accept or reject the proposal.
Contract Successfully Negotiated and Commitments Confirmed
If the FX Provider and Bob accept the proposed contract they apply their signatures indicating acceptance. This contract is then sent to the Transaction Validator, which confirms it has received the contract and asset transfer may commence. If any of the parties rejects the proposed contract then the contract is considered Abandoned, and no asset transfer is attempted. Parties may then propose a new contract if required.
Asset Transfer Commences as a Part of Contract Fulfillment
The Transaction Validator now starts tracking the fulfillment of commitments and the timeout. In the example below Alice has sent in the file-based digital asset for 100 USD to the Transaction Validator corresponding to her commitment while FX Provider’s fulfillment of commitments is awaited. The Timeout has not yet expired.
Contract Based Transaction Successfully Completed
FX Provider sent in the 90 EUR to the Transaction Validator before the timeout expired and all commitments are determined to be met. The Transaction Validator performs a double spend check and applies its signature to all assets in the transaction. As result all assets are now Atomically transferred. Participants are informed of the successful completion of the contract and they can retrieve their newly received assets. 100 USD is received by FX Provider and 90 USD is received by Bob. If the double spend check failed, none of the assets would be transferred and participants would be informed that the transaction has failed.
Timed Out — Assets are Reverted
In this case FX Provider did not honor its commitment in time, and the timeout expired. The Transaction Validator does not apply its signature and simply informs all participants that the Contract Based Transaction has failed and that their assets if any are still owned by them.
Summary of the Phases in a Contract Based Transaction Flow
This showcases a walkthrough of a simple contract, but Contract-Based Transactions can involve more parties and more asset types (including securities, or other assets) to support more complicated use cases.
Conclusion
With this modular approach to transactions and and asset transfer, Contract-Based Transactions are able to be simple yet robust in design and implementation. Contract-Based Transactions can fill a variety of financial use cases, from simple two-party swaps up through complex, cascading n-party securities and currency swaps.
It is important to note that Contract Based Transactions support HTLCs and Timeouts by including them as their own condition to the contract. However, HTLCs are not strictly needed for atomic swaps that are within one Knox ledger. Even with a failed HTLC, retrieval of assets is implicit and safe on a Knox ledger, and does not require a revocation key. Support for HTLCs allows the Knox ledger to support an institution which is participating in a multi ledger contract with an HTLC tying things across ledgers.
Knox’s Contract Based Transactions are designed to support application of AML and CFT/Sanctions checks, allowing banks to apply these checks before accepting to be a participant in a transaction.
