Get the QUAI balance of an address on Quai Network. Quai is a sharded network where every address belongs to a specific zone (e.g. cyprus1, paxos2); this tool resolves the correct zone automatically from the address itself, so you never need to specify a shard yourself. Returns the balance in both raw wei and formatted QUAI. Read-only: no gas, signing, or private key required.

Fetch a block from a specific Quai Network chain. Quai is a hierarchy of Prime, Region, and Zone chains, so a block number alone is not globally unique -- you must also say which chain to read from (e.g. "cyprus1" for a zone, "cyprus" for its region, or "prime"). Accepts a block number (decimal or 0x-hex), a block hash (0x + 64 hex chars), or a tag ("latest", "earliest", "pending"). If you only have an address and need its zone, call resolve_zone first.

Look up a transaction on Quai Network by its hash and return its details (from, to, value, gas, status) plus the receipt when available. Also reports which zone/shard the transaction landed on -- Quai resolves this automatically from the hash itself, so you do not need to know it in advance.

Determine which Quai Network shard/zone a given address belongs to, purely by inspecting the address (no network call). Quai uses location-based addressing: every address encodes both its zone (e.g. cyprus1, paxos2, hydra3) and its ledger (Quai account-based, or Qi UTXO-based) in its bytes, and only works within that zone. Use this before get_balance, get_transaction, or call_contract if you need to explain or confirm which part of the network an address or transaction belongs to.

Perform a read-only call (an eth_call equivalent) against a deployed EVM contract on Quai Network and return the decoded result. Provide the contract address, an ABI fragment array containing at least the method being called, the method name, and its arguments. The zone is resolved automatically from the contract address. This never sends a transaction, spends gas, or requires a key -- it works for view/pure methods, and simulates (without broadcasting) state-changing ones. It cannot actually change on-chain state; for that, the not-yet-available send_transaction tool will be needed.

Search a small curated index of Quai Network developer documentation -- sharding model, location-based addressing, the quais SDK, network endpoints, wallets, faucet, contracts -- and get back relevant snippets with links to the official docs. Use this to explain a Quai concept, find the right doc page, or clarify terminology (e.g. what a 'Zone' or 'Qi ledger' is). This is an offline index, not a live web search, so for anything it doesn't cover, say so and point at docs.qu.ai directly rather than guessing.

Quote a conversion between Quai's two native ledgers: QUAI (account-based, EVM) and Qi (UTXO-based, like Bitcoin -- this is Quai's own built-in swap, not a third-party DEX. Returns the current on-chain rate for converting a given amount in one direction, as of the latest block in the given zone. This is read-only and doesn't move anything -- to actually convert QUAI into Qi, send_transaction to a Qi-ledger address (it detects this automatically and shows the same estimate in its preview). Converting Qi into QUAI is not supported by this server yet: Qi is UTXO-based and needs a different kind of wallet (one that scans and manages unspent outputs) than the single-key wallets this server currently stores.

Generate a brand-new Quai (QUAI-ledger) private key and address, and store it encrypted under a name and password -- this is a custodial store: the tool remembers the wallet, you don't have to pass a raw key around again. The private key is encrypted at rest with the standard Ethereum/Web3 V3 keystore format (scrypt + AES-128-CTR + MAC, the same scheme geth and MetaMask use) and written to disk with owner-only file permissions; it is never returned in this tool's output and never logged. Because Quai addresses are location-aware, this 'grinds' (retries with fresh randomness) until the address falls in the zone you ask for (default: cyprus1). Use send_transaction with this wallet's name and password to actually spend from it. By default this ALSO creates a paired Qi-ledger wallet under the same name and password (see pairQiWallet) in the same zone, so a QUAI -> Qi conversion always has somewhere to land that you can actually check and spend from -- set pairQiWallet to false to skip that and only create the QUAI wallet.

Import an existing Quai private key into this server's encrypted wallet store, under a name and password, so it can be used with send_transaction without passing the raw key around again. Uses the same standard Ethereum/Web3 V3 keystore encryption as create_wallet (scrypt + AES-128-CTR + MAC), written to disk with owner-only file permissions. The private key you pass in is used once to encrypt and is never returned or logged. Whichever zone the key's address belongs to is detected automatically -- Quai addresses can't be moved between zones.

List every wallet stored in this server's encrypted wallet store, both QUAI-ledger (create_wallet/import_wallet) and Qi-ledger (create_qi_wallet/import_qi_wallet): name, ledger, address, and zone for each. No password is needed -- addresses are stored in the clear alongside the encrypted key/mnemonic, only spending requires the password. Use this to find the walletName to pass to send_transaction, get_qi_balance, or convert_qi_to_quai.

Send QUAI from a wallet in this server's encrypted store to a recipient address. Because Quai is sharded, the recipient may be in a different zone than the sender; if so, this is an external transaction (ETX) and is handled automatically by the network, just with slower finality than a same-zone send. If the recipient is a Qi-ledger address instead of a QUAI-ledger one, this is instead a QUAI -> Qi conversion (Quai's native "swap" between its two ledgers) -- the preview will say so and estimate what you'll receive in Qi (see get_conversion_rate for a quote without sending). This tool ALWAYS requires two calls: first without "confirm" (no password needed yet) to get a preview -- amounts, zones, estimated gas, a confirmationToken; then again with confirm: true, that same confirmationToken, and the wallet's password, to actually decrypt the key, sign, and send. The password is only ever used in-memory for that one call and is never stored or logged.

Generate a new Qi-ledger wallet (Quai's UTXO-based ledger, distinct from the account-based QUAI wallets create_wallet makes) and store it encrypted under a name and password. Use this so a QUAI -> Qi conversion (see send_transaction / get_conversion_rate) has somewhere real to land that this server can later check the balance of and convert back to QUAI with convert_qi_to_quai -- without a Qi wallet, converting into Qi sends it somewhere you may have no way to use again. Internally this is an HD (mnemonic-based) wallet, since Qi requires deriving addresses and scanning unspent outputs rather than a single keypair; only the mnemonic is encrypted at rest (same V3 keystore scheme as create_wallet: scrypt + AES-128-CTR + MAC), and it is never returned in this tool's output. Tip: create_wallet can create one of these automatically alongside a new QUAI wallet (pairQiWallet, on by default) -- use this tool directly only when you want a standalone Qi wallet or a different zone/name.

Import an existing Qi-ledger wallet from its BIP-39 mnemonic phrase into this server's encrypted store, under a name and password. Same encryption as create_qi_wallet (only the mnemonic is encrypted at rest, never the phrase itself in this tool's output). The receiving address for the given zone is re-derived deterministically from the phrase.

Check the Qi balance of a wallet created with create_qi_wallet or import_qi_wallet. Unlike get_balance (QUAI), this needs the wallet's password: Qi is UTXO-based, so checking a real balance means reconstructing the wallet from its mnemonic and asking the network for its unspent outputs, not just reading a stored public address. Returns both the total and spendable balance (spendable excludes still-immature/locked outputs). Funds received via a payment code (see send_qi) are NOT included unless you pass the sender's payment code in counterpartyPaymentCodes -- those addresses are pairwise-derived between the two payment codes and can't be discovered any other way.

Convert Qi held in a wallet created with create_qi_wallet/import_qi_wallet into QUAI, sent to a QUAI-ledger address. This is the other half of Quai's native ledger swap (see get_conversion_rate and send_transaction's QUAI -> Qi path). Same two-step pattern as send_transaction: first call without "confirm" for a rate-quote preview (no password needed yet); then again with confirm: true, the same confirmationToken, and the wallet's password to actually spend. The preview cannot verify the wallet's Qi balance without the password (Qi requires reconstructing the wallet to check), so a confirm may still fail with insufficient funds even after a clean preview -- that failure is reported plainly, nothing is lost or retried silently.

Get the reusable BIP-47 payment code for a Qi wallet -- this is what you hand someone so they can send you Qi via send_qi, the same way you'd hand out an address, except a payment code is not itself an on-chain address: it derives a fresh one behind the scenes for each sender. Requires the password because deriving it needs the wallet's BIP-47 key material from its mnemonic. Purely local -- no network call.

Send Qi from a wallet created with create_qi_wallet/import_qi_wallet to a recipient's BIP-47 payment code (see get_qi_payment_code) -- not a plain address. Qi peer-to-peer transfers work this way for privacy: a payment code is a reusable identifier from which a fresh address is derived for every send, rather than reusing one static address. Sender and recipient can be in different zones (destinationZone). Same two-step pattern as send_transaction and convert_qi_to_quai: preview first (no password needed) to see a confirmationToken, then confirm: true with that token and the wallet password to actually sign and send. The preview cannot verify the wallet's Qi balance (that needs the password), so a confirm can still fail with insufficient funds even after a clean preview.