Article source: On-chain View
Recently, the AltVMs project Catalyst, which at first glance seems to have a MEME-like UI style, has launched on the mainnet, but a look through the official technical documentation reveals that it is not simple. It aims to create a multi-chain interoperability liquidity solution connecting EVM, SVM, MoveVM, and the BTC network, belonging to the intent-based trading track. How should we understand this? Here are a few highlights summarized:
1) Intent-based trading projects do not overly emphasize the technical complexity of 'cross-chain,' but rather focus on the execution and outcome realization of cross-chain intent orders. Users initiate orders on the 'source chain,' and the Solver executes orders based on the order description; as long as the Romote chain can verify/prove the validity of the transaction, it can be included in the order exchange range.
Therefore, although such projects belong to the category of 'chain abstraction' from the perspective of liquidity aggregation features, it would be more appropriate to directly define Catalyst as a cross-chain AMM automatic trading system.
2) CrossCats is the latest cross-chain bridge product launched by Catalyst, capable of connecting various homogeneous or heterogeneous clients (altVMs) and only following a single 'provability' logic. Common cross-chain intent transactions mainly include:
Transactions between EVM chains, such as from Ethereum to Base chain, are managed entirely by the contract system. Users sign transaction orders -> Solver claims the order and provides collateral -> Source chain locks the user-authorized assets -> Solver completes order execution on the target chain through the oracle contract -> After execution is completed, the locked assets are released and settled for the user.
Transactions from EVM chains to other VM chains (SVM, MoveVM, etc.) also fall within the category of automated execution of homogeneous chains based on smart contracts. However, it is necessary to implement a provable verification mechanism on non-EVM chains, establish corresponding oracles and verification contracts, and the logic for signing, locking, executing, and settling orders is similar to that of transactions between EVM chains.
Transactions between Bitcoin and VM chains, such as from Bitcoin to Ethereum or Solana, require a handling solution using a Pseudo Solver, as Bitcoin cannot manage smart contracts. Users first collect reverse orders provided by real Solvers -> Real Solvers sign the reverse orders -> Users claim the orders and obtain assets on the VM chain -> Users actively initiate transfer transactions to a specific address within a limited time -> The entire transaction process is completed through state verification using Bitcoin SPV light clients.
The simplest case is that EVM chains have the same virtual machine processing environment. Other homogenous chains supporting smart contracts require a specific cross-chain proof mechanism, and the more complex cases mainly involve transactions with Bitcoin, which require SPV client verification logic, along with special handling in oracle and asset locking processes.
3) After achieving the matching execution of transaction orders based on a provable mechanism, it is necessary to consider the issue of fund usage efficiency, sharing management mechanisms, optimizing Oracle oracle, and so on.
For instance, the rules for locking and releasing funds directly affect fund efficiency. CrossCats allows users to lock liquidity funds only briefly during actual transactions (minimizing locking), so as not to sacrifice fund usage efficiency as much as possible.
For example, CrossCats has designed a multi-level payment release solution to balance efficiency and risk. Additionally, it employs three release schemes: source chain optimistic payment, target chain verification, and underwriting mechanism.
Optimistic payment assumes that the transaction status is executed normally, releasing funds first, and then ensuring safety through pre-staked assets and a dispute challenge window. Target chain verification requires the Romote chain to provide proof to the source chain. The underwriting mechanism shifts part of the order blame to other participants to improve matching efficiency.
The above.
As I mentioned in a previous comment on the reversal of Tornado's sanctions, as on-chain privacy solutions are resolved, intent-based trading will become a potentially rapidly growing narrative track.
In this process, achieving cross-chain asset circulation is just the foundation. How to optimize losses and efficiency in cross-chain transactions, how to resist the timeliness issues of Oracle price feeds under market fluctuations, and how to enrich transaction execution logic to enhance the automated experience are all challenges that intent-based trading needs to tackle.