Skip to main content

Glossary

CrossCall Components​

CrossCall API​

CrossCall's forward-facing API interface. Protocols send transaction calldata and target information (chain, address, cost). The CrossCall API simulates the transaction, wraps it into a userop, calculates total transaction cost, and returns a lock request and userop for the protocol to sign. The signed data is forwarded as a blob to the CrossCall Client.

CrossCall Client​

CrossCall's backend infrastructure responsible for lock request execution and userop validation. Currently comprises a private bundler and relayer. Expected to scale to a reward-based model with permissionless bundlers and relayers.

CrossCall Mempool​

CrossCall's private mempool storing executable blobs. Each blob contains a proposed bid, execution cost, and signed userop. Solvers read blobs and execute them as ERC-4337 userop bundles on the destination chain.

CrossCall Paymaster​

CrossCall's ERC-4337 paymaster. During preOp, it validates the userop and decodes the paymasterAndData field, then constructs the Hyperlane payout message bound to the solver's address. During postOp, it pays the Hyperlane IGP, redeposits used stake to the EntryPoint, and returns residual ETH to the solver.

// PaymasterAndData field (generated by CrossCall API)
struct PaymasterAndData {
    address paymaster;
    address owner;
    uint256 chainId;
    address asset;
    uint256 amount;
}

Hyperlane Components​

Hyperlane Mailbox​

The core Hyperlane contract. On origin chains it accepts outbound messages; on destination chains it delivers messages to target contracts by calling their handle function. CrossCall uses the Mailbox to deliver solver payout instructions from the destination chain back to the origin chain.

Hyperlane Mailbox docs →

Hyperlane IGP (Interchain Gas Paymaster)​

Quotes and collects the native currency cost required to process a Hyperlane message on the destination chain. The CrossCall Paymaster quotes the IGP cost in preOp and pays it in postOp — ensuring the Hyperlane message is only submitted if the userop succeeds.

Hyperlane IGP docs →

Hyperlane Validator​

Validators in the Hyperlane network process transactions and relay messages to destination chains. Once a CrossCall payout message is confirmed on the Hyperlane network, validators deliver it to the signer's Escrow contract.

Hyperlane Validators docs →

Hyperlane Handler​

The handle(uint32, bytes32, bytes) function that target contracts implement to receive Hyperlane messages. The signer's Escrow implements this interface to receive and validate solver payout instructions.

Hyperlane Handler docs →

Escrow Components​

Escrow​

Every signer has a create2-derived Escrow address. The Escrow is a lightweight ERC-1967 proxy that tracks locked and unlocked token balances. Only locked funds are used for solver payouts. When the Escrow receives a Hyperlane handle message, it validates the hash and executes the payout to the solver.

Escrow Factory​

The factory contract that initializes a signer's ERC-1967 Escrow using create2. The Escrow address is deterministic and can be computed before deployment.

function createEscrow(
    bytes memory _initializer,
    bytes32 _salt
) external returns (address proxy) {
    bytes memory deploymentData = abi.encodePacked(
        type(EscrowProxy).creationCode,
        _ESCROWIMPL
    );
    bytes32 salt = _calcSalt(_initializer, _salt);
    assembly ("memory-safe") {
        proxy := create2(0x0, add(deploymentData, 0x20), mload(deploymentData), salt)
    }
    if (proxy == address(0)) revert();
    assembly ("memory-safe") {
        let succ := call(gas(), proxy, 0, add(_initializer, 0x20), mload(_initializer), 0, 0)
        if eq(succ, 0) { revert(0, 0) }
    }
    return proxy;
}

Escrow Simpleton​

The current logic contract deployed behind the Escrow ERC-1967 proxy.

General Terms​

TermDefinition
SignerThe user or protocol authorizing a call intent
SolverThe actor that executes the signer's userop and is repaid via Hyperlane
SCWSmart Contract Wallet — the signer's ERC-4337-compatible account on the destination chain
UserOpERC-4337 User Operation — the signed transaction object submitted to the EntryPoint
EntryPointThe ERC-4337 singleton contract that validates and executes userops
Call IntentThe combination of ExecutionData + UserOperation that a signer authorizes
Executable BlobA call intent packaged for the CrossCall Mempool, including bid and cost data
LockFunds held in the signer's Escrow authorized for a specific solver payout