HILSA and the interoperability landscape

Choose HILSA when foreign-chain context should become shared execution state for an application on Singularity. Its distinctive model is to ingest evidence, commit the resulting facts once, and let supported VM interfaces read that context locally with explicit verification and finality requirements. This can simplify applications that need several components to make decisions against the same accepted foreign context.

Choose an on-demand query system when the job is to request remote contract data from an existing application elsewhere. Choose messaging when the job is to trigger a destination application. Choose a settlement route when the required result is spendable assets at the destination. Those jobs overlap, but their completion and trust conditions differ.

This comparison covers LayerZero, Wormhole, Axelar, Hyperlane, Chainlink CCIP and IBC, plus asset-focused and intent-based approaches where they change the decision. Primary documentation was refreshed on 8 September 2026. Protocol descriptions establish mechanisms; a particular chain pair still needs deployed contracts, configured verification, operational delivery and a successful integration test.

Use this page to choose an integration model. Once HILSA fits the need, follow the readiness task; use the integration reference for exact requests and VM interfaces.

Start with the result you need

These are starting points, not mutually exclusive product categories. HILSA also contains outbound messaging and asset-settlement mechanisms. Conversely, lzRead and Wormhole Queries mean that neither LayerZero nor Wormhole should be described as “messaging only.”

Explore the reader jobs.

Where HILSA offers a different application model

A shared local view instead of a query for each use

HILSA's universal-read interface reads committed accounts from the previous block. It does not call an RPC provider, poll a feed or consult wall-clock time during the contract read. A value travels with its verification and finality classes, and the common reader rejects a value below either requested minimum.

For a settlement-aware application, a concrete current use is to inspect a chain head and the consumed status of an attributed deposit before continuing local accounting. Several supported VM components can use the same committed context. That avoids an application-specific asynchronous request merely to reread an already-ingested fact. This is an architectural consequence, not a measured latency or cost advantage. Read contract and supported queries, minimum-class enforcement.

The conditions are important to the design: the feed must cover the fact, the snapshot must be fresh enough, and its verification must satisfy the application. Current queries cover chain heads, the interop snapshot, deposit consumption and local withdrawal records. Arbitrary account/storage subtrees are reserved and return UnsupportedKey. A shared Singularity snapshot also does not mean every foreign chain was observed at one simultaneous instant.

Evidence policy is visible to the application

HILSA distinguishes re-executed state, consensus-oriented verification, proof of work, federated observation, quorum observation and threshold custody. Finality is a second axis. This lets an application reject a weaker fact rather than quietly treating every input as equally “verified.” The ordering is HILSA's policy vocabulary, not a universal ranking of other protocols' security. Trust types.

A class label alone is insufficient source authentication. Current observer feeders sign Hilsa-canonical statements under an anchored observer set. The generic certificate engine verifies its own domain-separated statement; that is not automatically the source chain's native certificate format, even when its returned enum is ConsensusVerifiedCert. The Ethereum module also has a separate native SSZ/BLS attestation path that requires anchored fork/domain context. Distinguish the configured artifact path and registry from the catalog's intended ceiling. Observer feed contract, certificate preimage, native Ethereum verification.

Supplied proofs extend the facts that can be checked

HILSA also implements hilsa_proveRead, an RPC verifier for caller-supplied EVM account and storage proofs. It checks direct admitted Merkle-Patricia roots for Arbitrum, Base and Optimism. For BNB, it first binds a supplied block-header preimage to the admitted block hash, then uses the header's state root. This can authenticate an account balance or storage slot without trusting the caller's asserted value. RPC verifier, root profiles.

The client must obtain the proof; HILSA does not fetch it from a foreign RPC or maintain every source chain's full state tree. Verification inherits the admitted head's anchor, registry and achieved class. It cannot upgrade an observer-derived root into native consensus evidence. The Ethereum beacon-to-execution-root link is not implemented in this helper, and the in-consensus ReadQuery::Subtree remains unsupported. This is a useful proof-checking interface, distinct from lzRead's query/response and Wormhole Queries' signed results. See exact proof inputs.

Re-execution can test state validity as well as agreement

HILSA's CILX instruction can replay an eligible payload during ordered block execution and escalate the committed head only after reproducing the expected state root. This is a meaningful distinction from simply obtaining more signatures over a statement.

The current consensus registry includes the deterministic EVM value-transfer profile, not arbitrary EVM contracts or every foreign VM. It requires a full-state witness and a commitment that is itself the reproduced world-state root. Beacon-block-root and derived-output-root bindings are rejected. Missing engines or out-of-profile input do not earn the Reexecuted class. Consensus replay registry, binding checks.

This supports a bounded advantage: an application can require independently replayed state where that profile and binding are available. It does not support a claim that HILSA currently re-executes arbitrary Ethereum mainnet, rollup, Solana or Bombil workloads.

LayerZero: application-configured messaging and on-demand reads

Best fit: an application wants configurable cross-chain channels, or wants remote reads returned to its existing contract.

LayerZero applications configure verification per source/destination channel through required DVNs and an optional threshold of additional DVNs. Each DVN may use its own verification method. Reaching the configured threshold permits the message to be committed to the destination endpoint; execution is a subsequent step. It is inaccurate to describe all LayerZero deployments as one fixed committee or to assume every DVN uses the same trust model. LayerZero security stack.

lzRead extends that system with requests specifying remote data and block/time context. DVNs obtain data from target-chain archival nodes and may run map/reduce processing before a response returns through the endpoint to the requesting application's _lzReceive. This is a real foreign-state query capability, broader than HILSA's currently implemented ReadQuery variants for arbitrary contract reads. lzRead mechanism.

The choice is therefore about ownership of context: HILSA makes covered facts reusable shared chain state; lzRead makes a query/response part of the application's workflow. LayerZero gives applications direct security-stack selection. HILSA's minimum-class selection operates within the chain's configured feeds and verification paths. For deployment, inspect the specific endpoint, read channel, libraries, DVNs and executor configuration, not just the LayerZero name.

Wormhole: Guardian messaging plus query responses

Best fit: an application wants Wormhole's message ecosystem or Guardian-attested data without originating a cross-chain query transaction.

Wormhole messaging uses VAAs signed by its Guardian network. The current security documentation describes a 13-of-19 signature threshold. Destination verification checks that certificate, while the application must bind the accepted source emitter and message meaning. Choosing a lower consistency level can expose messages to source reorganization consequences. Guardian governance and the installed Guardian set remain part of the trust boundary. Guardian security, VAA semantics.

Wormhole Queries uses an off-chain query server: an application requests data, Guardians fetch and sign matching results, and the application submits the response for contract verification. Supported query types include eth_call by block, timestamp or finality, plus Solana account and PDA queries. The hosted Query Proxy currently requires a beta API key; that access policy is distinct from the cryptographic checking of its response. Hosted access prerequisites. Queries flow, query methods.

HILSA's difference is the common committed context and shared minimum-class gate at execution, rather than treating each query response as application-supplied data. Wormhole already answers the remote-read job; the comparison should turn on query coverage, Guardian assumptions, access, response freshness and application validation. Neither a valid VAA nor a valid HILSA outbox proof by itself proves that a destination business action completed.

Axelar: routed application calls and token services

Best fit: an application wants general calls, calls with tokens, or interchain token infrastructure across connected chains.

Axelar GMP requires deployed gateways and a destination executable application. Its network routes a source call into approval and destination execution. The security model includes Axelar's proof-of-stake network and the relevant chain verification/gateway path; applications can add their own limits and authorization checks. GMP and prerequisites, network security.

Amplifier matters to this comparison: chain integration is modular, with verifier and prover contracts that an integrator may customize, alongside a gateway and relayer. Its documented testnet/mainnet path includes governance proposals. That is chain-integration configurability, which differs from an individual application's per-message minimum-class choice. Do not treat Axelar as incapable of adding new verification mechanisms. Amplifier integration.

HILSA is distinctive when the application's main work is local computation over shared foreign context. Axelar's documented primary interface is routed cross-chain execution and asset services. A remote read can be built as an application interaction, but that is a different workflow from a local read of HILSA's existing snapshot. Compare the exact gateway, verifier/prover set, gas service and destination executable for the chosen route.

Hyperlane: recipient-selected verification

Best fit: an application or new chain needs substantial control over its messaging verification and deployment.

Hyperlane's recipient can use the Mailbox's default Interchain Security Module (ISM) or choose an application-specific module. Prebuilt modules can be configured, composed through aggregation or replaced with custom logic. A routing policy can select different verification requirements, including according to message content. This is strong application-level flexibility, not one mandatory universal validator set. ISM model.

The relayer calls Mailbox.process with the message and verification metadata. The Mailbox asks the recipient's ISM to verify, then calls recipient.handle; delivered-message tracking prevents replay. A deployed Mailbox, appropriate ISM, valid metadata, destination gas and receiver implementation are all necessary. Mailbox execution.

HILSA provides a common read and evidence policy for contracts on Singularity. Hyperlane exposes the verification program itself to recipient choice. Those are different control points: minimum verification/finality thresholds do not make HILSA's current ingress equivalent to an arbitrary per-application ISM. HILSA's shared-state benefit is strongest when several local components should inherit one accepted view; Hyperlane suits applications that want to own the message verification policy across their selected chains.

Chainlink CCIP: messaging and programmable asset delivery

Best fit: an application wants arbitrary data, token transfers or combined token-and-data delivery through supported CCIP routes.

CCIP provides a common interface for messaging and several token-pool mechanisms, including burn/mint and lock/release patterns. Its current architecture describes a Role DON running Commit and Executing OCR plugins, with source observations committed and then delivered for destination execution. These are roles within the same network, not two independently operated DONs by definition. CCIP overview, current off-chain architecture.

The current documentation explicitly says the automated off-chain Risk Management Network role is no longer active in current deployments. It retains an on-chain emergency safeguard and describes rate limits, token attestations and monitoring; optional validation is described as future evolution. Older comparisons that assume an always-active independent RMN need updating. Current RMN status.

HILSA offers covered foreign facts as local shared state and exposes evidence/finality minima. CCIP's documented primary job is message and programmable asset delivery, with application receiver policy and token-pool administration. Do not infer general lzRead-style queries from the fact that other Chainlink products provide data. For a concrete deployment, inspect the supported route, pool mode, receiver, gas/execution limits and configured safeguards.

IBC: client-verified state and packet semantics

Best fit: connected chains can maintain appropriate light clients and applications need proof-backed packet delivery with acknowledgements and timeouts.

IBC uses client state and consensus roots to verify remote membership/nonmembership proofs. Its trust depends on the particular client algorithm, initialization, update and misbehavior rules, and source consensus. It is a direct counterexample to a blanket claim that every HILSA alternative relies only on an external observer committee. IBC client architecture.

IBC v2 simplifies packet routing around client identifiers and application payloads. Counterparty configuration still matters. Destination packet verification, application acknowledgements and proof-backed timeouts give the sender explicit lifecycle outcomes; a verified packet does not erase application errors. IBC v2 specification. The Eureka deployment described by Cosmos connects Ethereum and Cosmos using an Ethereum client on the Hub and SP1 proofs of Tendermint light-client verification on Ethereum. That is a named integration, not evidence that every chain already has the required client. Eureka architecture.

HILSA's architectural benefit is integrating foreign context with Singularity's local multi-environment execution and, for the supported profile, independently replaying a state transition. IBC already provides authenticated remote-state proofs; it should not be reduced to a token bridge. Compare client coverage, anchor/update assumptions, proof availability and application packet semantics against HILSA's actual feed and query coverage.

Asset rails and intents solve adjacent problems

If the requirement is specifically native USDC movement, Circle CCTP is relevant. Its burn/attest/mint route relies on Circle's attestation service and destination verification. The current technical guide also describes general message transport and hooks, so “token-only” is too absolute for its underlying machinery. Hook data is opaque to the core protocol; integrators own its execution and recovery. This is an issuer-centered settlement choice, not a substitute for an arbitrary shared foreign-state database. CCTP technical guide.

Intent systems instead let a user specify an outcome for solvers to fulfill. The current ERC-7683 defines a solver-facing resolver interface that translates protocol-specific order payloads into a common representation; it does not itself select one foreign-consensus verifier or guarantee liquidity on a route. A solver may use messaging or asset rails underneath. Compare its fill guarantees, settlement verification and failure behavior with the desired outcome, rather than adding an “intents” checkbox beside a light client. ERC-7683.

Check the destination before claiming settlement

HILSA's local outbox and its destination contracts also have distinct completion semantics:

• The general outbox builds durable message accounts and corridor nonces, but the inspected executor initializes generic emission disabled.
• HilsaGateway.executeMessage checks an attested root, opening, destination and Merkle branch, consumes the nonce and emits an event. It does not call the arbitrary payload's target contract. Its validator-set updates are owner-controlled; automatic registry handoff is described as future work.
• BridgeVault.processUnlock is a separate asset path: it checks a configured signer quorum and replay guard, then actually transfers the native asset or token. The EVM withdrawal relay now contains real transaction broadcast and receipt polling, but requires a configured funded relayer. An old “broadcast stub” comment is superseded by that code.

Outbox construction, emission default, gateway verification and event, gateway administration, vault transfer, relay submission.

These source paths do not establish a live supported corridor. On 8 September 2026 at 00:19 UTC, the public HILSA attestation probe returned -32012, describing a protocol-v8 durable-interop safety pause. The response said observer/CILS reads remained available while durable roots and settlement routes failed closed. The checkout declares protocol 5, and the probe did not individually exercise every named route. A later read-only probe at 01:44 UTC returned upstream HTTP 521 errors across health, catalog, head, feed and attestation requests. Neither observation establishes a working route. Use the dated availability record and readiness task before choosing a live integration.

HILSA's strongest supported positioning is shared, explicitly qualified foreign context with supplied-proof checking and a path to bounded state re-execution, integrated with local composition. Its case is strongest when those capabilities match the application's actual facts and execution profile. Use verified reads to design that policy and cross-chain writes to establish the complete destination outcome.