Glossary

Use these terms consistently when describing what happened to a transaction or foreign-chain effect. In particular, accepted, executed, finalized, durable and settled describe different boundaries.

Jump to product and execution, state and authority, transaction stages, HILSA and settlement, or tools and readiness. For the connected mental model, start with the system overview.

Product and execution

Term	Meaning in this project
Singularity	The shared-account blockchain runtime and its client/operator ecosystem. Source paths and historical interfaces often retain ETO names.
ETO / etovm	Repository, binary, RPC-prefix and historical project identifiers. Preserve their exact spelling in commands and wire methods.
SING	Native token denomination. One SING is one billion lamports. An Ethereum-style interface may express the corresponding balance in wei.
VM / execution environment	A boundary that interprets a program or command under particular execution rules and connects its effects to shared state. It does not imply a separate chain or account database.
SVM	Solana-style account/instruction execution, including native programs and compatible BPF program routes. Compatibility is defined by the implemented loader, syscall and transaction contracts.
BPFCC	The in-tree BPF compiler/runtime machinery used by the supported GPU program-execution path. A compilation artifact still has to pass admission and execution checks.
EVM / CuEVM	Ethereum-style execution and its GPU engine. The surrounding node adapts addresses, value units, storage and RPC to the shared state model.
WASM	Wasmtime execution with the project's native host ABI. It is not synonymous with full CosmWasm compatibility.
Move	Module/resource execution using the implemented publication and call encoding, with explicitly installed native bridges.
ZK	The project's specific zero-knowledge/cryptographic verification surfaces. A supported verifier does not imply an unrestricted nested VM target.
Bombil	The current public name of One Book/OneBook: a VM-level financial state machine alongside the other execution environments. Current native admission expects a sealed resident-CUDA execution source; the ordinary production construction does not install it.
One Book / OneBook / `onebook`	Legacy Bombil names retained in modules, feature flags, CLI namespaces, program IDs and RPC manifests. They refer to Bombil's implementation lineage, not a separate seventh environment.
Native program	A program ID dispatched to node-implemented logic instead of loading user bytecode. It still has transaction, authority and state rules.
Cross-VM composition	A supported call or workflow spanning environments through an ordered transaction context. It is bounded by declared accounts, privilege checks, budgets and available targets.
Workflow	A bounded sequence of supported operations with declared inputs and output references. Local atomic workflow execution is different from asynchronous cross-chain settlement.

Start with the runtime map. Bombil's architecture belongs in its VM chapter; exact legacy names and activation errors are in the Bombil reference.

State, authority and persistence

Term	Meaning
Account	A keyed record carrying balance, data, owner program, executable state and related metadata. VM adapters interpret that data without creating unrelated canonical databases.
Owner	The program authority controlling an account's data under runtime rules. It is not necessarily the human or keypair beneficially owning an asset.
Signer	A key whose transaction signature or explicitly derived/delegated authority permits a particular action. Reading an account does not grant signing authority over it.
Writable account	An account declared writable in the transaction/call scope. This is necessary but not sufficient authority to modify any field. Ownership and program-specific checks still apply.
PDA	Program-derived address. An address derived from seeds is not automatically controlled by an ordinary private key; signing rules require the correct program context and seeds.
UTH	Universal Token Header: the shared token metadata/balance representation interpreted by supported adapters. Its owner/mint/amount fields are distinct from the outer account's owner and native lamport balance.
Capability	A scoped permission object used by identity/delegation mechanisms. Scope, budget, nonce, expiry and lineage/revocation rules constrain use; it is not blanket account authority.
StateChangeSet	Staged account updates and deletions to publish at a defined execution boundary. A helper returning a changeset does not itself prove that the changes are durable.
Transaction journal / overlay	The ordered working view that exposes earlier local writes to later instructions and permits rollback before publication. Child failure does not refund already consumed compute.
MVCC	Multi-version concurrency control. Speculative work reads versions and validates conflicts before its result becomes ordered state. Retry/accounting rules prevent speculative work from becoming duplicate committed effects.
QMDB	The persistent database/state machinery behind the account view. Its asynchronous drain and recovery metadata create a distinct durability boundary.
Canonical account hash	A commitment to the full canonical account map sampled at a height. Compare like heights; it is not simply the last changed-account diff.
WAL	Write-ahead log. Ordered persisted records support recovery before or alongside database application. Complete records, checksums, versions and sync ordering matter.
Durable height	The height proven by the node's persistence protocol, rather than merely the latest reported or finalized height.
Snapshot	A captured state representation plus the metadata needed to interpret/recover it. An account snapshot, storage-volume snapshot and HILSA interop snapshot are different objects.

The shared-state chapter owns the persistence model. Assets and identity explains UTH and capabilities. Source anchors include token header, changesets and WAL.

Transaction and consensus stages

Term	Meaning
Accepted / admitted	A submission passed the relevant ingress checks or reached a mempool. It may still fail, expire, be deferred or never finalize.
Executed	The runtime evaluated the instructions and produced a result. A failed execution can consume compute and fees without publishing application writes.
Finalized	The consensus/execution pipeline recognized the result at its finality boundary. This is not identical to every node's disk sync or a foreign destination's finality.
Durable	Persisted under the local recovery contract. The finalized head can lead the durable head.
Sequencer	The configured node role that orders/proposes execution work in the described topology. It does not independently override the validator quorum.
Validator	A consensus participant that verifies and participates under the selected engine/membership rules. CLI “CPU node” mode is a readonly mode, not CPU consensus execution.
Readonly replica	A node applying the supported replicated state path without voting or serving as an execution validator. Reachability does not prove it has caught up.
Simplex	The primary consensus-engine path documented here. Experimental alternative engine code does not establish equivalent deployment support.
Epoch	A consensus interval used for membership/stake/reward transitions. The stored epoch and configured rules must agree across the relevant fleet.
Protocol version	An identifier for consensus-visible semantics carried in control-plane and release information. The current helper's compatibility window is not an enforced Simplex block wire gate.
Receipt	A recorded execution result: success/error, consumed compute, fee and related metadata. Receipt visibility alone is not a local fsync acknowledgement.

Follow transaction lifecycle, consensus and finality and validator lifecycle for the transitions rather than treating these labels as interchangeable.

HILSA and foreign effects

HILSA is Singularity's foreign-evidence and interoperability system: it admits supported foreign-chain facts into local state, exposes reads with explicit evidence requirements, and supplies mechanisms for outgoing messages and asset settlement. Its useful distinction is the common local evidence view. The achieved trust and settlement path still depend on the verifier, registry, activation and destination. Begin at the HILSA hub.

Term	Meaning
CIL	Consensus Ingestion Layer, the implementation vocabulary around admitting foreign artifacts/evidence. Existing `cil` RPC/module names belong to the HILSA surface.
CILS account / committed chain state	The persisted admitted state for a foreign chain, distinct from an observer daemon's latest local observation.
Observer	A process or signer reporting external data. An observed head does not become consensus-native evidence merely because observers agree on it.
Artifact	Encoded evidence or an execution result consumed by a verifier. Its bytes, domain, anchor, limits and ownership determine what it proves. Bombil CUDA artifacts and HILSA foreign evidence serve different purposes.
Verification class	HILSA's evidence-strength category: reexecuted, consensus-verified-full, consensus-verified-cert, work-verified, consensus-federated, quorum-observed, or custody-threshold. The last is a custody assumption, not source-consensus verification.
Finality class	How settled the source evidence is under its model: finalized, justified, optimistic or work-based. This is independent of verification class. A coarse work ranking does not enforce a requested chainwork threshold by itself.
Class ceiling	Catalog maximum for a chain/profile. It does not assert that an installed adapter or current head has achieved that strength.
Trusted anchor	An accepted starting commitment, header, committee or registry from which verification continues. Its installation and replacement authority are part of the trust model.
Registry	Verification participants, keys or policy configuration for a domain. The source-chain verifier registry, Singularity validator registry and destination gateway's validator set are different registries.
Re-execution	Recomputing a supported transition from a bounded witness and checking its resulting commitment. The registered transfer profile is narrower than arbitrary foreign application replay.
Interop snapshot	A committed local account containing chain, registry and outbox commitments for the preceding block. It is one local view of admitted evidence, not simultaneous foreign-chain finality.
Interop root / attestation	A root opening and certificate binding commitments to a signed domain/block. Destination acceptance also requires the correct signer set, threshold and replay rules.
HUWM	HILSA Universal Write Message, the outbound message envelope. Emitting one does not by itself call the destination application.
Outbox	Stored outbound messages and corridor nonces. Availability requires the deterministic outbox and downstream proof/delivery path to be enabled.
Corridor nonce	A sequence number for a destination route, distinct from an owner's account nonce and a bridge deposit nonce.
Deposit processed	A local bridge tracker has consumed a deposit nonce. Bind its bridge chain and attributed HILSA chain correctly; the boolean alone is not a foreign proof.
Withdrawal	A local authorized debit/burn and outward intent/event. It is not yet proof of destination payment.
Settlement	The relevant destination effect has been accepted/executed under its rules, such as an actual vault payout. Signature collection, root acceptance, broadcast and transaction confirmation are separate milestones.
BridgeVault / gateway	Destination contracts with different jobs: custody payout versus authenticated message/root acceptance. A gateway event need not execute an arbitrary recipient call.

Verification terminology is grounded in HILSA class definitions, read contracts and snapshot timing. For alternatives with materially different meanings of verification and delivery, use the interoperability comparison.

Tools and readiness

Term	Meaning
Public CLI	`@0xsingularity/cli`, invoked as `singularity` or `sing`.
Rust operator utility	`eto-cli`, a distinct source binary with different units and incomplete write/demo paths.
SDK	`@0xsingularity/web3.js`, the Solana-client wrapper and project-specific helpers. Source and published versions can differ.
RPC manifest	A client-side inventory of method names, not a server capability negotiation.
Implemented	A behavior exists in inspected source. It may still be gated or unreachable through an ordinary node.
Released	Available in a named installable artifact. A source version bump alone does not establish it.
Observed	Seen on a named endpoint/environment at a recorded time. An observation is not a timeless availability guarantee.
Tested	Exercised by a specified check under specified conditions. Source inspection and a successful build are different evidence.

For exact commands, units and version differences, use CLI reference, fees and limits and compatibility and availability.