Reference · Reference
Compatibility and availability
Choose an integration by its complete path: client version, transaction or RPC shape, runtime dispatch, configuration and destination behavior. Singularity's shared account model makes composition possible, but a familiar language, method name or SDK namespace does not establish compatibility with an entire external ecosystem.
For a first reproducible result, use the offline transaction example in quickstart. For a live application, use Check HILSA readiness or Inspect a transaction with the specific endpoint and release gates below. This reference records observations; the linked guides give the procedure.
Package and endpoint observations
The npm registry was rechecked on 8 September 2026 at 00:44 UTC. These are dated observations, not floating installation promises:
| Component | Checked-in source | Observed public package |
|---|---|---|
@0xsingularity/web3.js | 0.3.0 | Latest 0.2.0; 0.3.0 absent |
@0xsingularity/cli | 0.4.0, depending on SDK ^0.3.0 | Latest 0.3.0; 0.4.0 absent |
| Rust runtime crate | 1.0.0 | Package version alone does not identify the execution protocol or build features |
A refresh at 01:42 UTC returned the same latest tags: CLI 0.3.0 and SDK 0.2.0. The absence checks in the table are from 00:44 UTC.
Registry sources: CLI metadata, SDK metadata. Source manifests: SDK, CLI.
The public SDK 0.2.0 and CLI 0.3.0 installed in a disposable directory during this run. Node.js 22.22.2 ran the examples. The CLI package's Node 18 declaration was weaker than its resolved Ink dependency's Node 20 requirement. The source 0.4.0 CLI was inspected through an existing local build; its successful execution does not establish a fresh npm-resolvable source installation.
Read-only probes of https://rpc.entropytoorder.xyz produced:
| Probe | Observation |
|---|---|
getVersion, 8 September 00:20 UTC | Runtime 1.0.0, release build 25d9ca433d1bf85aafa5bc567ae8a9091e203feb, features cuda, cuevm, mimalloc |
getHealth | JSON-RPC -32005: persistent-store drain halted and block production stopped |
getSlot | 431998, unchanged from the earlier 7 September probe |
getGenesisHash, earlier probe | 48e8a6FHB3CANQetLYE83frAu5zUy12uBiE75bdq5tYo |
eth_chainId, earlier probe | 0x454f, decimal 17743 |
| HILSA attestation, 8 September 00:19 UTC | -32012, with a protocol-v8 durable-interop safety-pause explanation |
| HILSA catalog/head/feed, earlier 00:19 UTC checks | 51 catalog entries; sampled Ethereum and Cosmos Hub heads disconnected; empty feed transport/chain lists |
Latest repeat, 8 September 01:44 UTC: getHealth, getVersion, getGenesisHash, hilsa_chainCatalog, hilsa_chainHead, hilsa_feedStatus, hilsa_getAttestation | All seven returned HTTP 200 containing JSON-RPC -32000, Upstream error (HTTP 521); no current node version, identity or HILSA availability could be read |
The earlier -32012 HILSA error said observer/CILS reads remained available while roots, proofs, attestations, outbox, mint, unlock and withdrawal routes fail closed because epoch transitions and authenticated state sync do not yet share a canonical durable-root contract. This is an observed deployed response, not a claim that this checkout implements protocol v8 or that every listed method was individually probed. The inspected checkout declares protocol 5.
The later upstream failure does not establish that the earlier safety pause was resolved or that observer reads remain reachable.
No live transfer, deployment, bridge settlement or validator join was completed in this run. Recheck health, progress and the exact method before using the service. The SDK constant singularity-mainnet is a configured cluster name; the name itself is not evidence of an operational support level.
Source links point to the repository's public GitHub form. Anonymous access returned 404 during this run. Readers may need repository access until publication is resolved; the prose describes the mechanisms without requiring those links.
Execution compatibility by environment
| Environment | Implemented path and useful contract | Boundary that affects adoption |
|---|---|---|
| SVM | Solana-style transaction/account interfaces, native programs, loaders and BPFCC GPU execution | Accepted bytecode versions, syscalls, account permissions and budgets must be checked; this is not blanket Solana feature parity |
| EVM | CuEVM execution and Ethereum-style RPC over shared account state | GPU/runtime build requirements, value conversion and host-precompile routing differ from a standalone Ethereum node |
| WASM | Wasmtime native host ABI with declared accounts, fuel and shared-journal integration | Native ABI is not a complete drop-in CosmWasm environment; host helpers and production linker differ |
| Move | Module publication/invocation and shared-state adapters | Exact module/function encoding and installed native functions matter; not an Aptos/Sui API clone |
| ZK | Specific cryptographic/native verification and RPC helpers | It is not a general sixth application language or a generic cross-VM target |
| Bombil | Sixth VM-level financial environment; native command admission and sealed resident-CUDA artifact boundary | Ordinary executor construction has no resident runtime; installation seam is test-only, simulation and arbitrary mixed-program transactions are rejected |
Bombil is the current name of One Book/OneBook. Existing onebook_*, eto_oneBook*, ONEBOOK_PROGRAM_ID and the onebook CLI namespace retain their exact spellings. Exact names and errors are in the Bombil reference, and its architectural position is established in the VM chapter; renaming does not complete runtime provisioning or release gates. Source: design intent, installation seam, admission.
For exact environment contracts, use SVM, EVM, WASM, Move and ZK. Particularly consequential limits include:
- EVM uses the CuEVM path; no general CPU EVM fallback is supplied by a CPU node build. Native SING balances use lamports, while Ethereum interfaces use wei; nonintegral or overflowing conversions are rejected where required.
- Loader compatibility does not imply every upstream RPC method or feature activation exists.
- WASM's CosmWasm support files do not establish that the production linker supplies standard CosmWasm storage imports or dispatches every returned message.
- A generic cross-VM target list is narrower than the runtime architecture map. Neither Bombil nor ZK becomes an arbitrary nested target simply by appearing in that map.
HILSA: distinguish evidence, application reads and settlement
HILSA is a central capability for making local decisions from supported foreign evidence and carrying authorized effects outward. Its strongest architectural benefit is a shared, deterministic evidence view that applications can query with explicit minimum verification and finality requirements. Different source chains and deployment configurations do not necessarily achieve the same class.
| Layer | Source capability | Required integration evidence |
|---|---|---|
| Catalog | Chain IDs, families and class ceilings | Actual installed verifier, trusted anchor/registry and committed head; a ceiling is not an achieved class |
| Consensus-facing reads | Chain head, interop snapshot, processed deposit and local withdrawal records | Declared accounts, freshness/business binding, sufficient achieved classes |
| General foreign storage | Consensus ReadQuery::Subtree is reserved and returns unsupported | Do not present it as arbitrary synchronous remote storage access |
| RPC proof verification | Caller-supplied account/storage proof verification for a specific supported root-binding profile | Correct chain, admitted root, proof format and minimum policy; this does not fetch a foreign RPC proof |
| Re-execution | Bounded registered EVM transfer replay profile | Complete witness and expected root agreement; not arbitrary foreign contract execution |
| Outbound messages | HUWM/outbox encoding, root/proof and destination gateway mechanisms | Enabled deterministic outbox, canonical roots, destination validator trust and application execution |
| Asset settlement | Deposit admission, local mint/burn/withdrawal records, EVM vault and relay mechanisms | Configured route, custody contract, authentic source evidence, durable local state and successful foreign receipt |
The current proof helper supports direct admitted MPT roots for Arbitrum, Base and Optimism and a block-header binding for BNB. It does not thereby verify Ethereum beacon-to-execution linkage or every catalog chain's storage. Source: read variants, RPC proof handler, root-binding profiles.
The ordinary executor's outbox flag is disabled, and several RPC write helpers intentionally reject rather than building arbitrary transactions. The deployed safety pause is an additional, independently observed limitation. A valid local burn or a gateway's message-accepted event is not synonymous with recipient payment or application execution.
Use the HILSA hub, verified reads, cross-chain writes and interface reference to select the complete path. The alternatives chapter compares this model with LayerZero, Wormhole, Axelar, Hyperlane, CCIP, IBC and adjacent settlement approaches by reader job.
Client and RPC compatibility
The SDK reexports upstream Solana client types and adds chain configuration, transaction packing, wallet and extension-RPC helpers. Those layers have different limits. A larger runtime transaction limit does not automatically enlarge every upstream instruction serializer; serializeUnchecked also does not verify signatures for the caller.
Generic RPC namespaces enumerate methods from a bundled manifest. They are not negotiated server capabilities. Some HILSA methods use object params while the generic CLI and namespace facade construct arrays. Use the exact method contract, rather than assuming a generated friendly name adapts parameters.
WebSocket subscriptions are process-local notification mechanisms. Reconnect and reconcile state after disconnection or lag; do not treat every subscription as a durable event log. HTTP acceptance is not transaction execution, and a finalized receipt may precede local fsync. See RPC, WebSocket and SDK contracts and transaction lifecycle.
What constitutes a usable path
Before depending on a capability, establish one named combination of:
- An installable client version and the actual command/API it exposes.
- An identified node build, features, configuration and chain identity.
- A reachable, advancing service with the relevant dispatch and state provisioned.
- A representative successful execution plus the important failure case.
- For foreign effects, destination verifier/custody configuration and an observed destination result.
This is a practical acceptance sequence, not a demand to test unrelated features. For a read-only HILSA strategy, validate its precise admitted evidence and policy. For a BPF application, validate its loader, syscalls and account semantics. For a validator upgrade, use deployment and recovery gates. Keep performance claims tied to the measured workload.