One chain, shared state, supported runtimes

An application may need Solidity contracts, a WASM module and Move resources to work together. Singularity puts these runtimes over shared accounts with one consensus order. Supported calls across them can read each other's pending updates and commit or roll back as one transaction.

Open the architecture diagram · Explore components and relationships

For example, a WASM call increments an EVM counter, then a Move call reads that pending value and increments it again. Both updates become committed state only when the enclosing transaction succeeds. If it fails, the child writes roll back. The composition fixture traces this sequence, including the Move native adapter it explicitly installs. Each runtime direction requires its implemented adapter, compatible arguments and declared account authority.

HILSA brings foreign-chain evidence into that local decision. An application can require an accepted foreign fact with a particular verification and finality class before it acts. External settlement follows its own completion path; sharing local state does not make an operation on another chain atomic.

Bombil is the financial execution environment. Its VM-level design puts orders, matching and accounting on common state alongside the other runtimes. Resident CUDA installation remains gated in the inspected source, and Bombil's command path is not yet part of generic cross-VM composition.

Choose the help you need now:

The central model: accounts first, runtimes as adapters

Consensus supplies the agreed order of work. Runtime adapters apply their own execution rules within that order, and shared accounts hold the results. This gives the application one state history across its supported runtimes. The transaction journal keeps a child call's writes pending until the enclosing operation succeeds. Consensus and execution, shared journal.

An account has a native balance in lamports, arbitrary data bytes, an owning program, an executable flag, and rent-epoch metadata. Instructions identify accounts and the signer/writable permissions they receive. Runtime-specific state—such as EVM code and storage, Move resources, or WASM storage—is represented through adapters over this common foundation.

This does not make every account a universally writable object. Ownership, authenticated principals, declared account scope, signer permissions, and writable permissions still constrain changes. Sharing storage removes a storage boundary; it does not remove authorization. Account model, transaction authority.

The runtime families have different jobs:

Bombil is the public name for One Book / OneBook. Existing code and interfaces retain names such as ONEBOOK_PROGRAM_ID, onebook, and eto_oneBook*. The design places Bombil at VM level; the inspected dispatch still requires a sealed resident CUDA implementation and rejects execution when it is absent. The name change does not remove that gate. VM design, dispatch gate.

“Supports a runtime” is not shorthand for “runs every application from the corresponding ecosystem unchanged.” The compatibility reference separates bytecode, framework, transport, tooling, and deployment claims.

A concrete composition

In the counter example, each call needs a view that includes accepted work from earlier calls in the same transaction. Publishing the first update directly to canonical state would make a later parent failure too late to undo it.

The transaction context supplies that behavior: an immutable initial snapshot, a speculative journal, a frame stack, authenticated authority, and shared compute accounting. Child effects belong to the enclosing transaction. A parent checkpoint restores speculative state on failure; execution metadata and consumed compute have their own lifetimes.

The repository's composition fixtures install small counter/reverter programs and exercise this pattern. They are local engine acceptance evidence, not a claim that a public deployment or a downloadable application has passed the same scenario. See cross-VM composition for the exact fixture, prerequisites, and rollback boundary. Journal ownership, context state.

The node around those calls

The responsibilities are deliberately distinct:

• Admission decodes and verifies submitted transactions before queueing them.
• Consensus decides an ordered block payload.
• Execution applies that payload's deterministic success and failure semantics.
• State and persistence hold the account view and recoverable disk history.
• RPC and subscriptions present local state and receipt observations to clients.

A returned transaction identifier proves neither successful execution nor completed disk persistence. Likewise, a node reporting an old slot can still be halted. Consensus, execution, and durability explain those distinctions at their canonical homes.

External data crosses a different boundary

HILSA brings verified external-chain information into local committed state. Its universal-read interface returns the value together with verification and finality classes, and rejects a read that cannot meet the caller's minimum trust requirements. Contract reads do not consult a live HTTP feed or process-local observer cache during execution.

This is different from cross-runtime composition. A locally atomic call cannot make a remote bridge unlock atomic with its own transaction. External settlement still has verification, relay, availability, and replay-protection requirements. HILSA reads, cross-chain writes, and the asset bridge describe those separate trust and completion conditions. Committed read contract.

Choose the depth you need

The offline lesson verifies serialization and tamper rejection with a published SDK. It does not execute transfers. The public endpoint was unhealthy during the dated September 7–8, 2026 checks; consult current readiness checks and the availability record before a live integration.

These chapters describe the inspected working tree, which includes changes beyond its Git HEAD. Repository links locate source files and may require access; anonymous access returned 404 during this run. Package versions and the observed deployed build are recorded separately in the compatibility reference. Neither source presence nor a passing fixture establishes a public support commitment.