Recently, this AltVMs project Catalyst, which at first glance seems to have a MEME UI style, has launched its mainnet. However, reviewing the official technical documentation reveals that it is not simple. It aims to provide a multi-chain interoperability liquidity solution connecting EVM, SVM, MoveVM, and the BTC network, and falls under the intent-based trading track. How should it be understood? I summarize a few highlights simply:

1) Intent-based trading projects do not overly emphasize the technical complexity of 'cross-chain', but instead focus on the execution and outcome of cross-chain intent orders. Users initiate orders on the 'source chain', and the Solver executes the 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 scope.

Therefore, although such projects also fall under the category of 'chain abstraction' in terms of liquidity aggregation characteristics, it would be more appropriate to directly define Catalyst as a cross-chain AMM automated trading system.

2) CrossCats is the latest cross-chain bridge product launched by Catalyst, capable of connecting various homogeneous or heterogeneous clients (altVMs), and it only follows one 'provable' logic. Common cross-chain intent trading mainly includes:

  1. Transactions between EVM chains, such as from Ethereum to Base chain, are managed throughout 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 via oracle contracts -> After execution, the user's locked assets are released and settled.

  2. Transactions from EVM chains to other VM chains (SVM, MoveVM, etc.) also fall under the category of automated execution based on smart contracts for homogeneous chains, but require a provable verification mechanism to be implemented on non-EVM chains, establishing corresponding oracles and verification contracts. The logic for signing, locking, executing, and settling orders is similar to transactions between EVM chains.

  3. Transactions between Bitcoin and VM chains, such as from Bitcoin to Ethereum or Solana, require a Pseudo Solver handling solution since Bitcoin cannot implement smart contract management. Users first collect reverse orders provided by real Solvers -> The real Solver signs the reverse order -> Users claim the order and obtain assets on the VM chain -> Users actively initiate transfer transactions to a specific address within a limited time -> Complete state verification of the entire transaction process through Bitcoin SPV lightweight clients.

Transactions between EVM chains with the same virtual machine processing environment are the simplest. Other homogeneous chains that support smart contracts require a specific cross-chain proof mechanism. More complex transactions mainly involve Bitcoin, which requires the use of SPV client verification logic, and special handling in the oracle and asset locking stages.

3) After implementing the matching execution of transaction orders based on a provable mechanism, it is necessary to consider capital utilization efficiency, share management mechanisms, oracle optimizations, etc.

For example, the rules for locking and releasing funds will directly affect capital efficiency. CrossCats allows users to lock liquidity funds only briefly during actual trading processes (minimizing lock-in), without the need to pre-lock assets, in order to maximize the efficiency of capital use.

For example, CrossCats has designed a multi-level payment release plan to balance efficiency and risk. Additionally, it employs three release plans: source chain optimistic payments, target chain verification, and underwriting mechanisms.

Optimistic payments assume 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 some order liabilities to other participants to enhance matching efficiency.

That's all.

As I mentioned in my previous comment on the overturning of Tornado's sanctions, as on-chain privacy solutions are resolved, intent-based trading will be a potentially rapidly growing narrative new track.

In this process, achieving cross-chain circulation of assets 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 the trading execution logic to enhance automation experience are all challenges that intent-based trading needs to tackle.