💡What we do

X Protocol - The Underlying Cross-Chain Protocol

XProtocol is a cross-chain protocol of Xbridge that supports AMP. In the context of EVM or other blockchains, AMP can be deemed as bytecode generated from encoding user interactions with Calldata in the smart contracts. For example, it could be a token transfer request from a user or a swap request from a decentralized exchange (DEX). Broadly speaking, AMP consists of one or more complex Calldata oriented towards smart contracts, which are machine-readable bytecodes. In AMP-supported cross-chain protocols, it represents the cross-chain transmission of arbitrary messages. Unlike messages transmitted within a single blockchain, cross-chain messages are executed only after being sent from source chain to the target chain.

Typically, the data validation of cross-chain protocols primarily focuses on the target chain. They relay users’ cross-chain requests from the source chain to the target chain through off-chain trusted relayers. Then, verifiers submit proofs to the target chain for validation through specific validation algorithms, i.e. executing users’ requests on the target chain. The biggest drawback of this approach is that users’ requests need to wait for validation on the target chain before execution. The waiting time depends on the execution time of the cross-chain relayers and verifiers, severely affecting users’ outcomes on the target chain. Especially when users expect specific arbitrage opportunities on the target chain, the delay in execution closes the window for users to profit.

Therefore, this protocol adopts a fundamentally different data validation approach. We introduce the concept of intent-centricity, decoupling the execution side or solver from the platform on the target chain. In typical token cross-chain transfer scenarios, cross-chain bridges usually release funds from the platform’s liquidity pool to users. In this protocol, however, this process is completed by the solver.

XProtocol - Detailed flow

The steps are as follows:

1. The user writes the cross-chain intent and locks tokens in the Proof contract on the source chain.

2. The Solver resolves the solution that meets the intent off-chain. To achieve sufficient decentralization, the Solver not only integrates with the platform but also can access through third-party permissionless integrations.

3. The platform collects and verifies all Solver solutions, selects the optimal one, and executes it in the Gateway contract on the target chain.

4. The Solver’s solution generates a hash, serving as part of the Commitment data to be verified.

5. The Relayer forwards the Commitment to the Proof contract on the source chain, i.e. the contract where the user locks tokens in Step 1.

6. The Verifier obtains the Commitment, calculates the Proof off-chain, and submits it to the Proof contract on the source chain. Once the proof is validated, the tokens are unlocked and delivered to the Solver.

In Step 1-3, users complete the entire cross-chain interaction process. In token cross-chain transfer scenarios, users can receive tokens on the target chain in Step 3. This process enhances the cross-chain experience by eliminating delays caused by Relayers transmitting data to the target chain for verification.

Based on zero-knowledge proof (ZKP) mechanisms, verifiers can prove on the source chain that the Solver has fulfilled the user’s intent without revealing the specific Solver solution. If Relayers attempt fraud by forging solver solutions, the generated Commitment hash will not match, and incorrect Commitment Hashes will be identified as errors by Verifiers.

Relayer operations require a decentralized consensus layer. and we have chosen EigenLayer’s Restaking technology for this consensus layer. If Relayers attempt to transmit fraudulent data, they will be penalized by deducting the corresponding staked tokens, known as the Slashing mechanism.

Step 4-6 can use ZKPs to further enhance security, details as follows:-

• The Solver’s solution generates a hash using cryptographic algorithm, serving as part of the Commitment data for the ZKP.

• The Relayer forwards the Commitment to the Proof contract on the source chain, i.e. the contract where the user locks tokens in Step 1.

• The Verifier obtains the Commitment, calculates the ZKP off-chain, and submits it to the Proof contract on the source chain. Once validated, the tokens are unlocked and delivered to the Solver.

Overall, the platform acts as a matching engine between user intent and Solver. Viewing user intents as auction items and Solvers as bidders, the platform serves as the auction house, responsible for finding the optimal market price for auction items (i.e. cross-chain intents). In other words, by limiting the role of the cross-chain platform to only act as an auction house and decentralizing other modules, the protocol aims to build a fully decentralized cross-chain protocol. In extreme cases, even if the official cross-chain service ceases operation, third parties can quickly and easily establish roles similar to this platform based on the protocol to manage user intent requests.