Trust boundaries

For every effect, identify who authorizes it, which bytes they authorize, which state is checked, and where enforcement occurs. Singularity shares state across environments; it does not remove program ownership, signing authority or the need to authenticate foreign evidence.

A useful application review follows one transaction from its signed message to its published account changes. A cross-chain review continues through the destination verifier and final effect. “Verified” is incomplete unless it names the fact and the trust root.

This explanation follows authority across local execution, foreign evidence and operations. To observe the local signed-byte boundary yourself, use the offline lesson. To diagnose an endpoint's HILSA evidence, follow the readiness task; exact parameters remain in the interface reference.

Signed bytes become scoped execution authority

Public transaction admission decodes an accepted wire format, resolves the relevant account references, checks required signatures and applies replay/blockhash rules. Execution must agree with admission on those rules. The canonical consensus Ed25519 module uses a shared ZIP-215 cofactored accept set for single and batch paths, with deterministic batch randomness derived from the input. This avoids using incompatible signature rules depending on which optimization ran; it is not a blanket proof that the entire node cannot diverge. See signature semantics.

The authenticated transaction establishes signer and writable sets. Cross-VM authority also records the declared account scope. A child receives constrained authority from its parent; it cannot turn an arbitrary account key into a signer or writable account merely by passing it to another VM.

An account's outer owner program controls permitted data mutation. A token's internal owner field identifies the token holder under that token contract. These are different checks. A recognizable UTH magic header in attacker-owned data is not an authentic balance. Applications must bind expected outer ownership, mint and holder relationships before relying on it.

The transaction context and assets/identity chapter explain how scope and authority are carried across adapters.

Local atomicity has an owner

A shared transaction journal exposes earlier writes to later instructions and supports checkpoint rollback. The enclosing transaction decides whether validated application writes publish. A block-owned write-claim registry prevents conflicting VM writers from silently overwriting an in-flight value; transaction-scoped claims allow deliberately ordered writes by frames belonging to the same transaction.

This is stronger than independently buffering each VM's writes and applying whichever finishes last. It still depends on every effect passing through the correct context and publication boundary. A direct shared-state helper, process-local cache update or external network call is not automatically rolled back with the account journal.

Examples that require this distinction:

• Ordinary failed application execution discards its writes, but consumed compute, charged fees and the permitted EVM nonce effect can survive.
• HILSA's direct outbox helper has its own write/undo logic. That alone does not prove a later WASM trap rolls it back; deterministic outbox activation remains gated.
• Bombil requires a sealed validator-local CUDA producer and ordered device-state reconciliation. A client cannot supply a fabricated device result as its transaction's proof of execution. The production engine installation remains gated.
• A successful local transaction cannot roll back an already executed foreign-chain payout.

See write-claim ownership, composition, Bombil and HILSA writes.

Delegated capabilities narrow permission

Identity capabilities provide explicit delegation rather than transferring unrestricted keys. The verifier checks canonical encoding, signature lineage, live ancestor status/generations, time validity, narrowed scope, proof of possession, nonce and budget constraints. A valid signature on a child token cannot override a revoked ancestor or expand a parent's allowed action.

The pure verifier returns an allowed debit description; the native operation must then update the derived budget/nonce accounts and move the authorized value. A receipt proves that recorded local transition. It does not prove an external agent performed useful work, or that an HTTP tool returned truthful output.

For an application such as a purchasing agent, review the actual recipient, amount units, budget lineage and nonce domain. Separate delegated tokens can share one budget; treating each as an independent allowance would defeat the intended constraint. Source: capability checks, state application.

HILSA trust begins before the proof

HILSA's useful contract is explicit evidence strength at the local read boundary. That contract depends on a provisioned verifier, authentic starting anchor/registry, correctly applied artifact and current head. It is not created by a catalog entry or an observer's self-description.

A persisted anchor authority can perform a sequenced reanchor. The instruction requires the existing owned chain-state account, the matching authenticated authority and a new receipt account; it enforces chain/family and sequence consistency. Those checks constrain the operation, but the authority still controls replacement of the trust anchor. Its key custody therefore belongs in the system's trust assumptions. See reanchor processing.

The generic certificate-native profile signs a particular domain/chain/epoch/height/block-hash digest. Its next_epoch_registry field is outside that digest and is copied into next state on the described transition; this path does not establish a fully authenticated arbitrary source validator-set handoff. Use the actual source-specific verifier and registry transition requirements rather than upgrading the profile's meaning from its name. See certificate bytes and transition and application.

Likewise, DepositProcessed combines a local bridge nonce record with the caller's attributed HILSA chain. Applications must validate that chain mapping instead of letting an untrusted caller attach an unrelated stronger head. A foreign storage proof needs an authentic admitted root as well as valid branch bytes.

The verified-read chapter owns the exact policy behavior. Alternatives compares different trust and customization models without assuming that every other protocol uses one fixed verifier set.

Destination verification and custody are separate

A root/message gateway can authenticate an outbound message and prevent replay while still doing no arbitrary call to its encoded destination. A vault can enforce a payout signature threshold while holding assets under an administrator-controlled configuration. Neither is implied by the other.

The EVM HILSA gateway uses its configured stake-weighted signer policy for root acceptance. BridgeVault uses its own member-count threshold and pause/guardian controls for custody release. Verify the exact configured keys, threshold, chain/vault domain and replay nonce for the contract actually holding the funds. Do not substitute the source verifier registry or a fresh RPC validator list for a trusted destination configuration.

A broadcast transaction hash is not payment. Inspect the foreign receipt and finality, and reconcile the relay's retry state after failure. The retry ledger is not an exactly-once distributed transaction across local disk and a foreign mempool. Full mechanisms are in asset bridging.

Other native products have their own custody assumptions. In the inspected AMM, the pool's ordinary keypair is the token vault authority, so control of that key permits transfers outside the AMM logic. The presence of swap and slippage checks does not make that pool a trustless PDA-controlled vault. See native product boundaries.

Membership and replica data require their own evidence

Registry signatures authorize particular membership actions. Registration checks a signed stake account's current balance and records it, but that transition is not itself a complete escrow or slashable-stake mechanism. Heartbeats record an identity's signed height and build hashes; those fields do not remotely measure its executable or prove its claimed execution history. The promotion gate uses the recorded height together with an epoch delay. Registration dispatcher, heartbeat and promotion.

The inspected Eject path checks unique verified transaction signatures and a count threshold, but does not validate its evidence payload, establish active membership for every listed signer, or debit stake. The Slashed status must not be read as proof of a complete Byzantine-evidence adjudication and financial penalty. These implementation boundaries belong in an adoption review alongside the protected pinned sequencer. Eject transition, signature checks.

A read-only replica also has a narrower trust contract than an executing validator. Its bootstrap snapshot comes from the configured sequencer without quorum cross-check. Its metadata digest binds a claimed root but not the applied diff bytes. Ordered application and sender restrictions help constrain transport; they do not independently verify that source's account updates. Pending validators follow this source while synchronizing and stop the poller on promotion. Use validator lifecycle and state sync to identify the current stage. Replica trust and follow path.

Privileged interfaces and operational keys

Admin RPC requires a nonempty configured ETO_ADMIN_TOKEN and a matching caller token. Bearer authorization is preferred; legacy parameter forms remain accepted in the inspected implementation. Denial returns -32004. A method's presence in the CLI manifest does not authenticate the user, and a wildcard CORS policy is not authorization.

Keep admin and release credentials separate from transaction wallets, consensus identity, HILSA reanchor authority and destination custody keys. Each authorizes a different effect. Prefer header-based administrative authentication so credentials do not become ordinary JSON parameters. Source: admin authorization.

Node builds also define trust. bench-skip-verify and bench-preload are benchmark capabilities, not production acceleration settings. CPU signature verification is a valid verification implementation; skipping verification is a different behavior. The source gates the skip switch at compile time.

Release verification needs an actual pinned release signer: the updater skips detached-signature verification if its compiled public key is zero. Similarly, data recovered from a peer or archive needs authenticated provenance and a consistent height/epoch/commitment, not merely a file with the expected name. See deployment controls and recovery.

Rejection tests make the boundary observable

For a local application, exercise missing signer, readonly/undeclared account, wrong owner/mint, replay, budget exhaustion and a later-instruction failure after an earlier write. For HILSA, include weak/incorrectly attributed evidence, wrong anchor or signer set, stale sequence, malformed proof, duplicate delivery and failed destination execution.

These are targeted acceptance questions tied to the actual path. Existing capability, cross-VM, signature, bridge and contract tests were inspected during this documentation run; they were not all executed. Use validation strategy to select the narrow test target and compatibility to keep a source result separate from public availability.