Transaction Engine

Knova has implemented a system that separates the programmability layer (Contract negotiation) from the asset transfer layer (Contract fulfillment). A Contract-Based Transaction fulfills a transfer of assets stipulated in a successfully negotiated Contract. Automation is added on top of this as part of the Transaction Engine. Contracts help to create modular transactions that cover a wide range of use cases, including:

• Atomic multi-party and multi-asset settlements (such as PvP, DvP)
• Cross-border payments
• Escrow
• Exchange trades
• Netted settlements
• Treasury management and wallet rebalancing

Contract-Based Transactions reduce costly errors, improve revenue opportunities, 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 will be retained by their original owner. The figure below shows a simplified view of a sample contract between two parties, Alice and Bob, during an FX conversion.

Contract Structure

Knova 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 Validator 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 Template

Knova uses the Resource Description Framework (RDF) data model to represent Contract-Based Transactions because it provides a flexible, interoperable, and semantically rich foundation for financial agreements. RDF allows us to define transaction data as linked, structured statements—connecting entities, obligations, permissions, and conditions in a graph format that machines can easily interpret and validate. This is especially powerful in environments where multiple parties, protocols, or institutions must understand and enforce the same contract logic with clarity and precision.

The transaction template itself is defined in RDF, a W3C machine-readable standard schema that describes parties, their relationships, and transaction parameters. This enables us to configure any number of participants, define asset types, and specify conditions governing each transaction. Because of this flexibility, Knova supports highly customizable transactions by simply calling an API with these RDF-based templates. Users can seamlessly send and receive funds, withdraw assets, execute trades, settle payments, place limit orders, and perform a wide range of financial operations.

By modeling transactions in RDF, Knova enables dynamic and composable contracts that can reference external ontologies, align with standards like FIBO (Financial Industry Business Ontology), and integrate across both traditional and decentralized financial systems. This structure enhances automation, auditability, and extensibility—making it easier to reason about complex state changes, regulatory compliance, and multi-actor workflows, while ensuring adaptability to diverse use cases. Below is a sample RDF-based transaction to illustrate how this works in practice.

Contract-Based Transactions in the Transaction Engine can also carry messages in any format (e.g., ISO 20022, NACHA) in line with the overall transaction. Knova eliminates the traditional separation between messaging and asset transfers, and messaging is available in line with the transaction.

Participants in the Knova 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 integrating DLTs over techniques such as HTLC mentioned above, this also allows easy integration with any traditional messaging interfaces and various systems expected in a modern institutional environment, using popular techniques such as message queues 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.

Knova's Contract-Based Transactions are executed by state machines (rather than EVMs or 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.

Knova’s Contract-Based Transactions allow for institution-specific adapters to be easily plugged in (e.g., an adapter that maps fields from Knova 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 Knova’s Digital Twins as a method of payment.

Asset Encumbrance with Contract-Based Transactions

A critical challenge in asset tokenization is ensuring that the tokenized representation of an asset cannot be simultaneously spent or utilized through its original, non-tokenized form. This lack of assurance creates risks related to double-spending and financial integrity. Additionally, ambiguity surrounding asset ownership, transfer rights, and associated limitations further complicates regulatory compliance and operational transparency. Without a clear mechanism to enforce asset constraints across systems, organizations face inefficiencies and potential legal and financial exposure.

To address these issues, Contract-Based Transactions atomically encumber assets upon issuance and release them upon redemption. This flexible, event-driven design enables seamless interoperability with any backend system at any stage of the transaction, ensuring that assets are properly locked, unlocked, and managed across both traditional systems and distributed ledger technologies (DLTs). The framework accommodates complex asset interactions, such as minting or burning, triggered by actions on other asset types, while streamlining workflows for issuance and redemption. Additionally, it supports customizable backend actions, including automated asset movements between accounts and real-time API interactions with external financial systems such as Real-Time Gross Settlement (RTGS) networks, custody services, omnibus FBO accounts, etc. Any updates directly done to the external systems are synced with Knova via the Interoperability Connectors mentioned above, e.g., webhooks for on-chain transfer status updates from a custody service.