JSON-RPC — Solana-Compatible

QoreChain provides a Solana-compatible JSON-RPC interface through its SVM (Solana Virtual Machine) runtime, enabling existing Solana tooling and SDKs to interact with QoreChain natively.

SVM transaction submission is currently disabled

As of chain version v3.1.89 (22 August), following an incident, the SVM execution lane is disabled network-wide for transaction submission — any transaction returns code 11, "SVM module is disabled". This applies network-wide, not just at the public read-only endpoints. Read-style methods in the table below (e.g. getBalance, getAccountInfo) respond normally on the public endpoints, but do not attempt a live integration that submits SVM transactions until the lane reopens — this is a compile-time disable, not a runtime parameter, so it cannot be turned back on by a governance vote; it's expected to stay off until an external audit clears it.

Connection

Transport	Address
HTTP (own node)	`http://127.0.0.1:8899`
HTTPS (public, mainnet, read-only)	`https://svm.qore.host`
HTTPS (public, testnet, read-only)	`https://svm-testnet.qore.host`

The JSON-RPC server is started by qorechaind start and is enabled by default, listening on 127.0.0.1:8899. It is configured via a [svm-rpc] section in app.toml (enable + address). A freshly started node already serves this interface — no extra process is required. The public endpoints are read-only (transaction submission is disabled at the edge).

note

As of chain version v3.1.82, the SVM interface serves the account's native QOR balance — the same unified funds visible on the Cosmos and EVM interfaces — denominated in lamports (9 decimals; 1 uqor = 1,000 lamports). See Native QOR on the SVM Interface.

Methods

Method	Parameters	Description
`getAccountInfo`	`pubkey` (base58 string)	Returns account data, owner, lamports, and executable flag
`getBalance`	`pubkey` (base58 string)	Returns the native-QOR balance in lamports for the given public key
`getSignaturesForAddress`	`address` (base58 string)	Returns transaction signatures involving the address (deposit detection)
`getSlot`	none	Returns the current slot number
`getMinimumBalanceForRentExemption`	`dataLength` (integer)	Returns the minimum balance for rent exemption given data size
`getVersion`	none	Returns the node software version
`getHealth`	none	Returns node health status (`"ok"` if healthy)
`getBlockHeight`	none	Returns the current block height
`getLatestBlockhash`	none	Returns a recent blockhash and `lastValidBlockHeight`
`getRecentBlockhash`	none	Legacy form of `getLatestBlockhash`
`getFeeForMessage`	`message` (base64)	Returns the fee for a message (lamports)
`getMultipleAccounts`	`pubkeys` (array)	Returns several accounts in one call
`getProgramAccounts`	`programId` (base58)	Returns the accounts owned by a program
`getTokenAccountsByOwner`	`owner`, filter	Returns token accounts for an owner
`getTokenAccountsByDelegate`	`delegate`, filter	Returns token accounts for a delegate

Methods outside this list, such as getEpochInfo, return -32601 method not found (checked against https://svm.qore.host and https://svm-testnet.qore.host, 23 October 2026, and getEpochInfo again on the testnet on 7 November 2026). Testnet, v3.2.7: getGenesisHash is answered (it returned 6Z9pa53SwiprqiAoNCqqUdj5c3C4P1zRw31gQVnF4Czj on 7 November 2026) and getVersion also reports qorechain-chain-id, qorechain-cluster (the Wallet Standard chain id, solana: followed by the first 32 characters of the genesis hash) and qorechain-genesis-hash. The same identity is served over REST at GET /qorechain/svm/v1/cluster_info (see REST / gRPC Endpoints). On mainnet (v3.2.6) getGenesisHash still answers -32601 and getVersion has only solana-core and feature-set (checked 7 November 2026). SVM stays switched off: this identity lets a wallet recognise the cluster, it does not enable transactions. Since v3.2.2 base58 addresses in the RPC and gRPC queries must be canonical and bounded in length; a malformed one is refused. getTransaction is accepted but currently answers with an envelope that has no result field, so do not rely on it. The slot reported by getSlot tracks the chain's block height.

Response Format

All responses follow the JSON-RPC 2.0 specification. Responses that reference on-chain state include a context object with the current slot:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "context": {
      "slot": 123456
    },
    "value": { ... }
  }
}

Examples

getAccountInfo

Request:

curl -X POST http://localhost:8899 \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "method": "getAccountInfo",
    "params": [
      "4Nd1mBQtrMJVYVfKf2PJy9NZUZdTAsp7D4xWLs4gDB4T",
      { "encoding": "base64" }
    ],
    "id": 1
  }'

Response:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "context": {
      "slot": 123456
    },
    "value": {
      "data": ["AQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=", "base64"],
      "executable": false,
      "lamports": 1000000000,
      "owner": "11111111111111111111111111111111",
      "rentEpoch": 0
    }
  }
}

getBalance

Request:

curl -X POST http://localhost:8899 \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "method": "getBalance",
    "params": ["4Nd1mBQtrMJVYVfKf2PJy9NZUZdTAsp7D4xWLs4gDB4T"],
    "id": 2
  }'

Response:

{
  "jsonrpc": "2.0",
  "id": 2,
  "result": {
    "context": {
      "slot": 123456
    },
    "value": 1000000000
  }
}

getVersion

Request:

curl -X POST http://localhost:8899 \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "method": "getVersion",
    "params": [],
    "id": 3
  }'

Response:

{
  "jsonrpc": "2.0",
  "id": 3,
  "result": {
    "solana-core": "1.18.0-qorechain",
    "feature-set": 0
  }
}

The version string 1.18.0-qorechain indicates compatibility with the Solana 1.18.0 RPC interface running on the QoreChain SVM runtime.

@solana/web3.js Integration

Existing Solana applications can connect to QoreChain by pointing the Connection object to the local SVM endpoint:

import { Connection, PublicKey, LAMPORTS_PER_SOL } from "@solana/web3.js";

const connection = new Connection("http://127.0.0.1:8899", "confirmed");

// Check version
const version = await connection.getVersion();
console.log("Node version:", version["solana-core"]);

// Get balance
const pubkey = new PublicKey("4Nd1mBQtrMJVYVfKf2PJy9NZUZdTAsp7D4xWLs4gDB4T");
const balance = await connection.getBalance(pubkey);
console.log("Balance:", balance / LAMPORTS_PER_SOL);

// Get slot
const slot = await connection.getSlot();
console.log("Current slot:", slot);

// Get account info
const accountInfo = await connection.getAccountInfo(pubkey);
if (accountInfo) {
  console.log("Owner:", accountInfo.owner.toBase58());
  console.log("Executable:", accountInfo.executable);
  console.log("Data length:", accountInfo.data.length);
}

Notes

Address format: SVM accounts use base58-encoded public keys (standard Solana format), not the qor1 Bech32 prefix used by the native Cosmos SDK modules.
Cross-VM bridging: To move assets between EVM and SVM runtimes, use the Cross-VM module (x/crossvm). See the Transaction Commands for crossvm call syntax. The SVM lane is disabled and MsgCrossVMCall is switched off on mainnet, so this is reference only today.
Program deployment: Deploy BPF programs via the CLI (qorechaind tx svm deploy-program) or programmatically through the SVM runtime.
Compute budget: The SVM runtime enforces a compute budget of 1,400,000 compute units per transaction by default. This is configurable via module parameters.

Connection​

Methods​

Response Format​

Examples​

getAccountInfo​

getBalance​

getVersion​

@solana/web3.js Integration​

Notes​

Connection

Methods

Response Format

Examples

getAccountInfo

getBalance

getVersion

@solana/web3.js Integration

Notes