HILSA writes and settlement

HILSA's write model lets a local application commit an outbound instruction that a destination can verify. That separates the decision made on Singularity from the work completed on another chain. A committed message proves intent; destination execution or an asset unlock proves the resulting action.

This is useful for a strategy that reads foreign evidence, changes a local position, and requests settlement elsewhere. The application can retain a durable correlation between its local decision and the later destination result. It must still handle delivery delays, rejection, and incomplete settlement. Verified reads explains the input side; the funding carry example shows why both sides matter.

This page explains the completion boundaries. Use Check HILSA readiness for endpoint diagnostics and the HILSA integration reference for exact RPC contracts.

There are two concrete implementations to distinguish:

The general outbox has an executor activation gate. The asset relay has an implemented transaction broadcaster, but new recognized withdrawals remain disabled at mempool admission unless explicitly enabled. Neither source path establishes a publicly available settlement service.

The public attestation probe on 8 September 2026 at 00:19 UTC returned -32012, describing a protocol-v8 durable-interop safety pause affecting roots, proofs and settlement routes while observer/CILS reads remained available. This was a deployed response, distinct from the inspected protocol-5 checkout; every named route was not individually probed. Check the availability record before attempting a live corridor.

Explore the write and settlement boundaries. Local commitment, delivery, and destination success are separate milestones.

Stable identity connects local intent to delivery

An outbound corridor is a per-destination sequence. Emission reads its next nonce from shared account state, checks that the message account does not already exist, and prepares two updates: advance the corridor and write the message. A repeated destination/nonce cannot overwrite an earlier message. A disabled outbox, unknown destination, overflow, or corrupt corridor fails emission.

The general message wraps application data in a versioned HUWM envelope. Its fields are:

Bombil is a VM-level environment, but these origin tags do not establish a Bombil send interface. The existing name and dispatch mapping is in Bombil.

The stored CILM account and the corridor belong to the CIL product program. The reporter folds committed outbound records into the outbox subtree. General messages and product burn-and-send records use the same proof structure; their payload formats differ. The former has the HUWM envelope, while the latter carries owner, mint, and amount.

The pure emit helper returns a change set. emit_via_state instead applies the pair directly, in fixed key order, restoring earlier writes if a later write fails. That pairwise protection is not evidence that an arbitrary enclosing VM call can later trap and roll back every side effect. Use the transaction path's actual journaling contract when composing a send with other operations. Emission and envelope source.

Inclusion proof and destination behavior are separate checks

A message proof includes enough data to recompute its leaf and fold a Merkle branch to the outbox root. The opening then binds that subtree to the signed interoperability root, which also commits the Singularity block/state and other HILSA subtrees.

The inspected HilsaGateway.executeMessage performs these checks in order:

1. Recompute the interoperability root from the supplied opening.
2. Require the message's destination to match the gateway's configured HILSA chain ID.
3. Recover sorted, nonduplicated validator signatures and require strictly more than two thirds of configured stake weight.
4. Recompute the leaf from the supplied message and verify its branch.
5. Consume the (destination, nonce) replay key and emit MessageExecuted.

The signature digest is an EIP-191 wrapper over the root. The gateway's validator weights and chain identifier are owner-configured. A valid proof therefore depends on the destination's configured authority set as well as the source commitment. A proof server alone cannot replace either check. Gateway implementation.

Crucially, the event is the implemented terminal action. The function does not decode HUWM and call its dest_address. An integration that needs a destination swap, loan repayment, or contract invocation must supply and review that execution adapter, including source authorization, payload schema, replay scope, revert behavior, and payment for execution. Treating the word “executed” in an event name as proof of an arbitrary application call would skip this boundary.

Asset withdrawal has a concrete broadcaster

The bridge withdrawal relay assembles the destination call to processUnlock(uint256,address,address,uint256,bytes[]). With ETO_BRIDGE_RELAYER_KEY configured, it obtains the relayer's pending account nonce, estimates fees and gas, adds 20% gas headroom, signs an EIP-1559 transaction, sends it through the destination RPC, and polls its receipt.

A sent transaction returns Broadcast while still unconfirmed. Only a successful receipt returns Confirmed; missing keys, RPC failures, and reverts leave the withdrawal unlatched for retry. This implementation exists even though older comments still call the broadcaster a stub. Actual send and polling path.

The destination vault verifies an unlock digest bound to the destination chain ID, vault address, withdrawal nonce, token, recipient, and amount. It requires sorted distinct signatures from its configured validator membership and the configured count threshold. This count-based threshold is different from the gateway's stake-weighted root certificate. After replay and input checks, it marks the nonce processed and performs the native or token transfer within the same destination transaction. A reverted transfer also reverts that transaction's state changes. Vault unlock implementation.

For a real integration, validate the deployed vault address, membership, threshold, guardian powers, balance, token behavior, RPC, relayer funding, and receipt finality policy. See asset bridging for deposit verification and custody.

Activation, retries, and recovery

The normal TurboExecutor constructor initializes cil_outbox_enabled to false. The inspected assignments enabling it occur in tests. The existence of the boot-time ETO_CIL_ENABLED reader does not prove production executor activation: execution receives an explicit bit so validators do not decide state transitions from independently read environments. Executor construction.

Bridge admission is a separate control. ETO_ALLOW_WITHDRAWALS_WITHOUT_RELAY accepts 1, true, or yes, ignoring case and surrounding whitespace. It defaults to false and is latched once. Setting a relayer key alone does not enable this admission gate. It recognizes native bridge instructions and top-level EVM bridge calls; it cannot statically detect every nested WASM or Move withdrawal. This gate controls local proposal admission, not whether a validator executes an already ordered withdrawal. Admission implementation and scope.

The broadcaster records the destination transaction hash by chain and withdrawal nonce. Subsequent retries normally poll that transaction instead of paying for a duplicate unlock. With ETO_HILSA_STATE_DIR, it also writes withdrawal_broadcasts.json through a temporary file and rename; without it, the ledger is memory-only. The send occurs before the record, and persistence errors are not propagated. This is useful restart recovery, not a crash-proof exactly-once broadcast guarantee. Destination replay protection remains essential. Broadcast ledger.

General outbox accounts are retained indefinitely. Acknowledgement-based pruning and TTL expiration are declared future policies, not active cleanup. Applications also need their own settlement status: a source record, gateway event, or sent transaction is insufficient to label a cross-chain business operation complete.

What would establish a complete integration

Use source tests to examine envelope round trips, destination validation, nonce allocation, disabled emission, and product burn-and-send failure handling. The EIP-1559 broadcaster has encoding tests; gateway and vault tests belong to the EVM contract suite. These tests were inspected for this documentation run; no funded withdrawal or destination transaction was executed.

A useful integration acceptance case is: commit one intent, retain its identity across restart, submit the exact proof or unlock authorization to the configured destination, observe the intended destination effect, and repeat delivery to verify replay handling. Add failure cases for a wrong destination, stale authority set, malformed branch, insufficient quorum, and a reverted destination transfer. The alternatives guide explains how this division of verification and execution compares with other interoperability systems.