New Developments for Project TXA

This week, we asked our developers to shed some light on what they’re working on next for Project TXA. Here’s what they said.

As the first cryptocurrency project to create a truly decentralized network in which cross-chain transactions can be settled with high speeds, Project TXA is constantly pushing the envelope on what can be built in a blockchain environment through the hybrid decentralized exchange (hDEX) framework. Our goal is simple: architect a system that keeps trading profits in the community without sacrificing trader experience. We are charging forward to meet that goal and bring you the best trading experience ever built.

This week, we asked our developers to shed some light on what they’re working on next for Project TXA. Here’s what they said:  

Medium-Term Targets:

1. Bonded Data Availability
To facilitate a high throughput of settlement data, SDPs construct merkle trees containing many signed state updates from the Participating Interface, and then report a single hash representing the merkle root of the tree. In order for SDPs to construct the merkle tree, and generate fraud proofs in cases where the data violates constraints, the system needs assurance that the Participating Interface is consistently publishing signed state updates. Without access to this un-hashed data, it's not possible to validate a submitted merkle root.

This can be achieved by using a bonded data availability contract on a high-throughput app-chain that's secured by a public blockchain (e.g. Polygon Supernet). The smart contract requires the Participating Interface to submit signed state updates as calldata. It will perform some basic validation on the data, record the time at which the update was submitted, and keep track of the latest sequence number of reported state updates. Since the signed state updates are only stored in calldata, they use less gas than if they were written to storage, but should still be reliably available to SDPs or any interested parties with access to a node on the app-chain. Additionally, the Participating Interface must post a token bond in the smart contract. If the Participating Interface fails to publish signed state updates within a pre-determined time-period, an auditor can call the smart contract to slash the bond. This same contract can be used by SDPs to report proof of PI fraud, so long as there is a mechanism for securely relaying data from other blockchains to the app-chain.

2. Optimistic Blockchain Interoperability
Participating Interfaces propose a ledger that references assets deposited across multiple blockchains supported by the DSL. A single base chain can be used to receive settlement reports from SDPs. In order to catch the entire range of fraud cases, SDPs must track deposits across all blockchains supported by the DSL. To prove fraud that requires details of a deposit from another chain, the deposit data must be securely relayed from the other chain to the base chain. This can be done using one or more (preferably multiple) protocols (e.g. Hyperlane, Chainlink CCIP, Synapse Protocol etc) so long as the protocol allows a smart contract on one chain to receive data from a smart contract on another chain. Unlike bridging, which requires every single token deposit to be communicated from one chain to another, this approach optimistically assumes that a deposit referenced by the Participating Interface is valid, and relies on SDPs to relay the minimum amount of data needed to prove fraud if necessary.

Long-Term Targets:

1. Validating Orderbook Operation with Zk-Proofs
The current TXA protocol enforces trade-based constraints on all Participating Interfaces that operate an orderbook. It ensures that all trades are the result of trader-initiated orders by verifying signatures, that the parameters of all trades match the parameters of the orders, and that the resulting balances after each trade are correct. It prevents double-spending and prevents any entity other than the trader from having control over funds. However, it does not provide certain guarantees with regards to orders such as fair sequencing. Validating orderbook operation requires significantly higher data throughput. This can potentially be achieved by representing orderbook logic via arithmetic circuits and validating updates on-chain using zero-knowledge proofs.

2. Extensible State Updates
The current TXA protocol defines the absolute minimum amount of types of state updates that are necessary to facilitate spot-trading of ERC20-compatible tokens and native cryptocurrencies at high-speeds without releasing custody of assets to a centralized entity. The protocol can be expanded to support other types of markets or assets by defining new state updates, along with the rules for how they must be processed and how a validator can generate a fraud proof if constraints are violated. TXA governance can then define sets of supported state update types, and Participating Interfaces can choose which set of state updates to support.


As you can see, our developers are looking ahead to see what they can design into the backend of Project TXA that will help the hDEX achieve its rightful position as the most powerful, capable, convenient, and secure trading experience – all wrapped up into one.

New to Project TXA and wanting to learn what it’s all about? Be sure to follow us on Twitter to catch the latest updates and join our Discord community to meet the team and make friends. We love to give crypto to our community, and staying active on our Twitter and in our Discord server are the best ways to be the first in line.  

Welcome to Project TXA, where cryptocurrency evolves.