HILSA · Explanation
HILSA — foreign-state intelligence and cross-chain settlement
HILSA lets Singularity programs act on verified information from other chains. The application sets how strongly the evidence must be verified and how final it must be before acting. Supported VM components read the same accepted evidence from a committed local snapshot.
Imagine a treasury receiving a deposit from another chain. Its rule is concrete: “Increase this local position only after the intended deposit is recorded and the attributed source head meets our evidence policy.” HILSA exposes the chain-head and processed-deposit queries needed to express that condition. The application binds the source, deposit identity and age requirements; the common reader enforces its minimum verification and finality classes. A weaker fact is rejected instead of silently becoming an acceptable input. Implemented queries and policy gate, minimum checks.
Several local components can reuse that committed fact in their own decisions. HILSA also supplies outbound intent and proof mechanisms to connect a later withdrawal to the local decision. Funds are settled only when the destination action completes. This treasury example is an integration design; execution across independent chains remains asynchronous.
Why this fits Singularity
Singularity places several execution environments over shared accounts. HILSA extends the information available to those environments: source-chain commitments, registry commitments, bridge records, and outbound messages can participate in a local state transition.
Within block H, the universal-read contract uses the committed snapshot from H - 1. Its answer does not depend on a fresh HTTP request, a feeder's process-local cache, or a validator's clock. Applications comparing several available facts therefore use one local snapshot. This does not mean the foreign chains reached their heads simultaneously, or that the snapshot contains every foreign account. Read contract, committed snapshot.
Bombil, the current name for OneBook, is the financial VM-level environment in this shared runtime architecture. HILSA supplies a natural architectural input for financial decisions and external settlement. That relationship is not evidence of a released Bombil/HILSA strategy engine: Bombil dispatch is gated, and exact host interfaces must be checked separately.
Explore HILSA's product and trust boundaries.
Choose the job you need
| Your job | Start here | What the current source supports |
|---|---|---|
| Check whether an endpoint exposes the evidence your application needs | Check HILSA readiness | A read-only diagnostic task with explicit blocked outcomes; no funded transaction required |
| Decide whether to accept a foreign fact | Verified reads | Chain heads, interoperability snapshots, processed deposit status, and local withdrawal records with explicit trust classes |
| Check an EVM account or storage proof | HILSA proof interfaces | Caller-supplied MPT verification against supported admitted roots; the caller obtains the proof |
| Settle an asset withdrawal | Writes and settlement, then asset bridge | A configured relay can broadcast vault unlocks; admission, signing, custody, and destination conditions remain separate |
| Deliver a general external instruction | Writes and settlement | Durable outbox/proof primitives; the current gateway verifies and emits an event, while arbitrary destination execution needs an adapter |
| Integrate an SDK, RPC, or VM | HILSA interfaces | Exact method families, schemas, committed versus process-local surfaces, and missing integration boundaries |
| Choose between interoperability designs | HILSA and the alternatives | A job-based comparison with LayerZero, Wormhole, Axelar, Hyperlane, Chainlink CCIP, IBC, and adjacent asset/intent approaches |
The in-consensus subtree query remains unsupported, but HILSA has a separate useful RPC capability: hilsa_proveRead verifies caller-supplied account/storage MPT proofs. Arbitrum, Base and Optimism use directly admitted roots; BNB requires a supplied block header that hashes to the admitted commitment. A client can use this to check a balance or storage value against a known root without trusting the asserted value. Proof handler, supported root bindings.
The node does not fetch that proof from an external RPC, and valid branch bytes do not improve the admitted root's trust class. This helper also lacks Ethereum beacon-to-execution-root linkage. Applications needing on-demand remote calls should compare the query offerings in the alternatives chapter; RPC proof verification and a contract's committed universal read are distinct interfaces.
Verification is an application decision with an evidence trail
A successful read returns a value together with a verification class and a finality class. The common read function checks both requested minimums and returns a trust-downgrade error instead of silently serving a weaker fact. The taxonomy distinguishes re-execution, full or certificate verification, work verification, federation, observation quorums, and custody thresholds. These classes are protocol policy categories; an enum name alone does not establish the actual provenance of a feed.
That last distinction matters in the present implementation. Observer builders sign HILSA-specific statements. The cert-native module's canonical vote is a HILSA-domain hash, not a universal parser for every named chain's native certificate. Native proof-of-work and specific native verification code also exist, but each requires its matching artifacts and correctly provisioned anchor. Consumers need to inspect the active verifier, authority registry, artifact format, and finality policy together. Trust types, observer pipeline, certificate preimage.
HILSA also implements a deterministic re-execution path. Its consensus registry currently admits the CPU EVM transfer profile; that is narrower than replaying arbitrary EVM contracts or every supported VM. The advantage is an explicit path for checking execution rather than trusting only a claimed output. The condition is that the supplied witness, root binding, and transaction all fall within the registered profile. Consensus re-execution registry.
Where the design is distinctive
HILSA is particularly relevant when your application lives on Singularity and needs to combine foreign evidence with local shared-state execution. Common committed reads and centrally enforced minimum classes can reduce the amount of per-application plumbing needed to obtain a consistent local decision input. Proofs, registries, and outbound records also give a settlement workflow concrete objects to audit.
That is a different integration choice from adding general messaging to an application that remains entirely on existing chains. LayerZero offers configurable DVNs and lzRead; Wormhole offers signed Queries; Hyperlane offers application-selected verification modules; IBC can use chain-specific light clients. Their capabilities and deployment paths deserve comparison on the actual job. The alternatives chapter explains when each model fits and where HILSA's strongest advantages depend on activation or additional integration work.
From source to a usable integration
The inspected repository contains verifier, state, proof, VM projection, relay, and destination-contract implementations. The general outbox starts disabled in the normal executor, and the destination gateway does not yet perform arbitrary application calls. A catalog entry or SDK method name is therefore insufficient to establish a working route.
At 00:19 UTC on 8 September 2026, the public attestation probe returned -32012, describing a protocol-v8 durable-interop safety pause while observer/CILS reads remained available. The response named roots, proofs and settlement routes as affected; those routes were not each separately exercised. This deployed observation is distinct from the inspected protocol-5 checkout. A later probe at 01:44 UTC returned upstream HTTP 521 errors across the seven read-only requests, including health and attestation. Start with the readiness task and dated availability record.
For adoption, identify the exact artifact producer and anchor, the node build and activated handler, the query or message format, and the destination contract and authority configuration. Then test a complete route with its failure cases. The compatibility and availability reference records dated release and endpoint observations; it does not infer deployment from source presence.