This document is a high-level system overview of CrossCall's infrastructure components; and will briefly discuss each component's purpose, function, and usage.
Figure 1a CrossCall API and Protocol API interaction
Figure 1b CrossCall API - Protocol API callgraph
Figure 1a shows how protocols interact with CrossCall. Protocols include actors such as bridges, liquidity aggregators, price matching aggregators, and multi-chain marketplaces. The components in this interaction can be generalized as the CrossCall API and the Protocol API.
The Protocol API composes transaction calldata to be executed as well as specifies the target, target chain, signer, and execution cost requirements. The Protocol API will have the user sign and submit data from CrossCall API.
CrossCall API runs a simulation on would-be transactions. The results of this simulation will estimate the cost for validation, execution, suggested bid, and base gas fee. CrossCall API will return, the sum total of these costs, a request for the signer to lock funds and a userop. Once signed and submitted to CrossCall API, the lock request and userop will be validated and added to the CrossCall Mempool.
Client Validation: CrossCall API - Client Interaction
Figure 2a CrossCall Client validates message to add to CrossCall Mempool
Figure 2b CrossCall Client callgraph
Figure 2a shows the process by which the CrossCall Client ensures funds are locked and the userop is signed. Similar to ERC4337 bundlers, the userop needs to be validated by the client before merging the message into the mempool. However, there are two key differences: (1) the lock request needs to be executed on an RPC for the origin chain and then validated; and (2) the transaction simulation is validated in an environment where the execution cost and paymaster calls are executed as pre-userop.
The CrossCall Client validates the userop in the context of a solver fronting the Hyperlane costs to the CrossCall Paymaster and to the SCW. After the CrossCall Client finishes validating the lock amount, lock deadline, and userop, the full message including lock info, calldata, and execution cost will be merged to the CrossCall Mempool.
Figure 3a Solver finds a message on the CrossCall Mempool and executes it on-chain
Figure 3b Solver - Paymaster callgraph
Figure 3a shows how a Solver who join the CrossCall solver network executes a message from the CrossCall Mempool.
Note: validation for merging a message to the CrossCall Mempool does not ensure a successful userop bundle at execution time, therefore it is expected that the Solver re-validates the userop bundle before execution.
The Solver acts as liquidity provider directly for the signer. The operation is executed atomically as a three part bundle, in order : (1) overpaying CrossCall Paymaster to execute on Hyperlane; (2) add execution cost + validation gas + execution gas to the signer's smart contract wallet (SCW); and (3) the signer's signed userop.
Because the bundle is executed atomically, the CrossCall Paymaster call to Hyperlane is entirely deterministic.
Figure 4a shows the CrossCall Paymaster and how it utilizes Hyperlane. The preOp and postOp utilize the overpaid funds to ensure the Hyperlane message including userop and tx.origin data is successfully submitted to the Hyperlane Mailbox. At the end of the postOp the CrossCall Paymaster will redeposit stake used to the EntryPoint and send any residual ETH to the tx.origin.
Once the message is confirmed on the Hyperlane Network, a Hyperlane Validator will pickup and execute the message on the Hyperlane Mailbox to directly execute the handle function on the signer's Escrow contract.
Figure 5a The user's escrow handles the Hyperlane message to payout the solver.
Figure 5b User Escrow - Solver payout callgraph
Figure 5a shows how Hyperlane Mailbox executes the handle function on the signer Escrow contract. The Escrow will validate the hashed data and payout funds to the solver. The payment includes the estimated user costs + the signer original bid.
