Recently, the AltVMs project Catalyst, which looks like a MEME UI at first glance, has been launched on the mainnet. However, after reading the official technical documents, it is found that it is not simple. It aims to be a multi-chain interoperability liquidity solution connecting EVM, SVM, MoveVM and BTC network, and belongs to the intent transaction track. How to understand it? I will briefly summarize a few highlights:

1) Intentional transaction projects do not overemphasize the technical complexity of "cross-chain", but are more concerned with the execution and result realization of cross-chain intention orders. Users initiate orders on the "source chain", and the Solver executes the order according to the order description. As long as the Romote chain can be verified/proven the validity of the transaction, it can be included in the order exchange scope.

Therefore, although such projects also fall into the category of “chain abstraction” from the perspective of liquidity aggregation characteristics, 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. It can connect multiple isomorphic or heterogeneous clients (altVMs) and only follows a "provable" logic. Common cross-chain intention transactions mainly include:

  1. Transactions between EVM chains, such as from Ethereum to Base chain, are managed by the contract system throughout the process. The user signs the transaction order -> Solver Claim order and provides collateral -> The source chain locks the user's authorized assets -> The Solver completes the order execution on the target chain through the oracle contract -> After the execution is completed, the user's locked assets are released and settled.
  2. Transactions from EVM chain to other VM chains (SVM, MoveVM, etc.) also fall into the category of automated execution of isomorphic chains based on smart contracts. However, it is necessary to implement a provable verification mechanism on the non-EVM chain, establish corresponding oracles and verification contracts, and the logic of signing, locking, executing, and settling other 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 solution because Bitcoin cannot implement smart contract management. The user first collects the reverse order provided by the real Solver --> the real Solver signs the reverse order --> the user claims the order and obtains the assets on the VM chain --> the user actively initiates a transfer transaction to a specific address within a limited time --> completes the status verification through Bitcoin SPV light client verification to complete the entire transaction process.

It is simplest when EVM chains have the same virtual machine processing environment. Other isomorphic chains that support smart contracts require a specific cross-chain proof mechanism. The more complex ones are mainly transactions involving Bitcoin, which require the use of SPV client verification logic, and special processing is required in aspects such as oracles and asset locking.

3) After matching and executing transaction orders based on a provable mechanism, it is necessary to consider the efficiency of fund use, sharing management mechanism, Oracle oracle optimization, etc.

For example, the rules for locking and releasing funds will directly affect the efficiency of funds. CrossCats allows users to lock assets only for a short period of time (minimize lockup) during actual transactions without pre-locking liquidity funds, so as not to sacrifice the efficiency of fund use as much as possible.

For example, CrossCats has designed a multi-level payment release scheme to balance efficiency and risk. In addition, it also adopts three release schemes: source chain optimistic payment, target chain verification, and underwriting mechanism:

Optimistic payment assumes that the transaction status is executed normally, releases funds first, and then ensures security through pre-pledged assets and dispute challenge windows; target chain verification requires the Romote chain to provide proof to the source chain; the underwriting mechanism transfers part of the order responsibility to other participants to improve matching efficiency.

above.

As I said in a previous comment on the reversal of Tornado’s sanctions, as on-chain privacy solutions are resolved, intent-based transactions will be a new narrative track with potential rapid growth.

In this process, achieving cross-chain circulation of assets is only the foundation. How to optimize the loss and efficiency in cross-chain asset transactions, how to resist the timeliness of Oracle price feeds under market fluctuations, how to enrich transaction execution logic and improve automation experience, etc. are all difficult problems that intention transactions need to challenge.