Hive Keychain to your backend: Hive RPC and Engine APIs

Every balance, every Hive Engine token, every transfer that Hive Keychain shows you is already public — it sits on the Hive blockchain and on the Hive Engine sidechain, served by a fleet of JSON-RPC nodes anyone can call. The wallet's job is narrower than a banking app's: hold the user's posting and active keys behind PIN and biometrics, and sign the operations the user authorizes. The integration question is two parts. First, how to read the same account state your user sees inside the app, from your own backend. Second, when you need that user to act — transfer, delegate, power up — how to ask Keychain to sign without ever touching the keys yourself.

Bottom line: nothing in this integration depends on getting credentials out of Keychain. Reads come from the public chain; writes ride a signing protocol Keychain already implements. Our build is the wrapper that makes both pieces look like a single, typed account API to your service.

Where the account actually lives

The wallet UI is a window onto two distinct chains. HIVE and HBD balances, voting power, vesting shares, posts, transfers, follow graphs — those live on the Hive Layer 1, which is reachable through any public hived node. Hive Engine tokens (the long tail of community currencies, SPS, LEO, BEE, SWAP.HIVE wrappers, NFT contracts) live on a separate consensus layer that watches L1 for custom_json operations and stores its state in MongoDB-backed contract tables. An integrator pulling a unified account view has to query both.

Surface	Where it originates	What an integrator does with it
HIVE and HBD liquid balances	`condenser_api.get_accounts` on a Hive L1 node	Wallet view; pay-in / pay-out reconciliation
Hive Power (HP) and vesting shares	`get_accounts` + `get_dynamic_global_properties` for the VESTS→HP rate	Governance weight, eligibility, lock-up reporting
Resource credits (`rc_manabar`)	`rc_api.find_rc_accounts`	Throttling, UX guards before a broadcast
Account history (transfers, delegations, votes, rewards)	`account_history_api.get_account_history`	Ledger export, accounting, audit trails
Hive Engine token balances and stakes	`contracts.tokens.balances` via `api.hive-engine.com/rpc/contracts`	Multi-token portfolio, taxable-event reporting
HE delegations and pending unstakes	`contracts.tokens.delegations`, `pendingUnstakes`	Reward-share dashboards, cashflow forecasting
Posts, comments, rewards authored	`condenser_api.get_discussions_by_author_before_date` or HiveSQL	Content analytics, payout tracking

Routes onto the chain and the signing bridge

Four authorized paths, each with a real reason to exist.

Hive L1 JSON-RPC

The dependable read path. Several public endpoints — api.hive.blog, api.openhive.network, api.deathwing.me — expose the full condenser/database/account-history surface with no auth. We pick a redundant set and add lag detection; if your volume warrants it we provision a dedicated hived with the account_history plugin enabled so you get unrestricted history and predictable latency. Effort: low. Durability: high — the JSON-RPC schema is part of consensus, not a vendor product, so it does not get deprecated under you.

Hive Engine sidechain RPC

The same shape, a different chain. api.hive-engine.com/rpc/contracts answers find / findOne queries against contract tables — tokens/balances, market/buyBook, nft/instances, and so on. Each token carries its own precision (number of decimals) in tokens/tokens, which the wrapper has to look up before formatting balances. Effort: low. Durability: stable; the sidechain has been live for years but is operated by the Hive Engine team, so we mirror critical reads where the customer needs that posture.

keychain-sdk (web dApp signing)

Published on npm as keychain-sdk, this is the standardized handshake the Keychain browser extension speaks. Your dApp calls requestTransfer, requestBroadcast, requestSignBuffer, or requestSignTx; the SDK posts to the extension, the user confirms inside Keychain, the SDK returns the signed result. The same SDK can target the mobile wallet when the user has it installed and your dApp runs in a browser. Effort: medium (we author the dApp-side wiring, error handling, and the wallet-not-installed fallback).

Mobile deep-link / app-to-app signing

For native iOS or Android integrators, Keychain Mobile exposes an inter-app signing intent so another app can request a broadcast without ever seeing the keys — the wallet pops up, the user authenticates, the calling app gets the result back. This is the route we use when the integrator is itself a mobile app. Effort: medium-to-high depending on platform and on whether the host app is React Native, Flutter, or fully native.

The route we usually point first-time integrators at is the Hive L1 RPC plus Hive Engine RPC for everything read-only, then keychain-sdk for the moments the user actually needs to sign. That keeps the integrator's backend stateless about keys, which is the whole point of a wallet like this.

What gets handed back at the end

An OpenAPI specification for the wrapped read endpoints — one typed call per account view, no raw JSON-RPC bleeding into your service.
A runnable Python or Node service that calls condenser_api, account_history_api, and the Hive Engine RPC, then normalizes the two into a single per-account schema.
A dApp adapter wired against keychain-sdk for the operations you need (transfer, custom_json, delegation, power up/down, sign-buffer for login).
For mobile hosts, deep-link / intent wiring and a documented fallback path when the wallet is not installed.
A test pack against either a throwaway Hive account or a private hived testnet, including lag and rate-limit scenarios.
Interface documentation that names the things that bite: VESTS↔HP conversion uses live global properties; Hive Engine token decimals are per-token; get_account_history indices count down, not up.
Operational guidance — which public nodes to use, when to mirror Hive Engine, when to run your own hived, and how to detect a node that has fallen behind irreversibility.

A read against the chain

Illustrative — confirmed during the build for one account. Reads the L1 state, the Hive Engine balances, and returns a single object.

import httpx

HIVE_RPC = "https://api.hive.blog"
HE_RPC   = "https://api.hive-engine.com/rpc/contracts"

def _rpc(url, method, params, rid=1):
    return httpx.post(url, json={
        "jsonrpc": "2.0", "method": method, "params": params, "id": rid,
    }, timeout=8.0).json()["result"]

def get_account_state(username: str) -> dict:
    acct = _rpc(HIVE_RPC, "condenser_api.get_accounts", [[username]])[0]
    gprops = _rpc(HIVE_RPC, "condenser_api.get_dynamic_global_properties", [])

    # VESTS -> HP uses the live ratio; do not cache it as a constant
    vests = float(acct["vesting_shares"].split()[0])
    total_vests = float(gprops["total_vesting_shares"].split()[0])
    total_hive  = float(gprops["total_vesting_fund_hive"].split()[0])
    hp = vests * (total_hive / total_vests)

    he_balances = _rpc(HE_RPC, "find", {
        "contract": "tokens", "table": "balances",
        "query": {"account": username},
    }, rid=2)

    return {
        "hive_liquid": acct["balance"],          # "12.345 HIVE"
        "hbd_liquid":  acct["hbd_balance"],      # "0.000 HBD"
        "hive_power":  round(hp, 3),
        "rc_manabar":  acct.get("rc_manabar"),
        "engine_tokens": [
            {"symbol": t["symbol"],
             "liquid": t["balance"],
             "staked": t["stake"]}
            for t in he_balances
        ],
    }

And the signing side, in a web dApp asking Keychain to broadcast a HIVE transfer:

import { KeychainSDK } from "keychain-sdk";

const keychain = new KeychainSDK(window);

if (!(await keychain.isKeychainInstalled())) {
  // wallet-not-installed fallback: deep-link to the install page, or surface a
  // QR import path; never silently swallow this branch.
  return promptInstall();
}

const signed = await keychain.requestBroadcast({
  username: "alice",
  operations: [["transfer", {
    from: "alice",
    to:   "bob",
    amount: "1.000 HIVE",
    memo: "invoice 42",
  }]],
  method: "Active",
});
// signed.result is the broadcast result; the active key never left Keychain.

Three integration shapes we see

Portfolio tracker. Read-only. The user supplies one or more Hive usernames; the service merges L1 balances, HP, RC, and Hive Engine token holdings into a single dashboard. No signing, no keychain-sdk, no consent question.
Tipping / payout button in a web product. Your site asks the user to log in by signing a buffer with their posting key, then later asks Keychain to broadcast a transfer. Keys never leave the wallet; your backend records the signed proof and the resulting transaction id.
Accounting export for an HE-based game or DAO. A scheduled job pulls account_history and the relevant Hive Engine contract tables, classifies each operation (transfer in, stake, unstake, reward, market trade), and ships CSV/Parquet into the customer's data warehouse.

Things we account for during the build

VESTS to HP is a moving rate. The wrapper recomputes it against get_dynamic_global_properties on each call rather than caching a constant — that is the same reason Keychain Mobile re-derives HP at refresh and not from a stored ratio. Cached values drift visibly within minutes.
Hive Engine token decimals are per-token. SWAP.HIVE has 8 decimal places, plain HIVE has 3, SPS has 3, BEE has 8. We pull the precision from tokens/tokens before formatting any balance, so SWAP.HIVE never gets rendered as if it were L1 HIVE in a customer report.
Node lag is a silent failure mode. A public RPC can serve a balance that is correct for a block 30 seconds behind tip. We query two nodes and compare last_irreversible_block_num; mismatches above a threshold flip the wrapper to a backup node and emit a metric.
Signing always runs through Keychain. The broadcast paths drive keychain-sdk on web and the app-to-app intent on mobile, so the host service never holds posting or active keys — the wallet keeps them PIN- and biometric-encrypted on device and signs inside its own process.
Hive Engine reads are not consensus-final. The sidechain has its own block production; we surface the HE block height alongside any balance so downstream code can decide whether a payout is settled enough to act on.

Where this sits under MiCA and the Travel Rule

Hive Keychain is non-custodial. The wallet software does not take possession of customer assets, so under MiCA's December 2024 framework it sits outside the Crypto-Asset Service Provider perimeter that governs custodial wallets and exchanges. That posture matters in three concrete places.

Read-only integrations (balances, history, account state) operate on public chain data and need no per-user consent in the AIS sense — the integrator decides whose accounts to display in their product, and that product's privacy notice is the relevant artifact.
Broadcast integrations sign with the user's own keys inside the wallet. The integrator never holds spending authority, which keeps the integrator off MiCA's CASP register for that flow alone. We document this posture and the user-consent UX in the deliverable.
If the integrator is itself a CASP — an exchange or custodial venue receiving from a Keychain-controlled address — the FATF Travel Rule still binds the CASP side. MiCA's transfer-of-funds regulation requires CASPs to assess whether a self-hosted wallet is owned or controlled by the customer before crediting transfers over €1,000, and to collect originator/beneficiary information regardless of size. We map that interface on the CASP side; the wallet itself is not the obliged entity.

Outside the EU, we substitute the local equivalent during onboarding — FinCEN's MSB regime in the US, VARA's rulebook in the UAE, and so on. The studio operates under NDA where needed and logs each authorized step.

Sources and review notes

Checked against the Hive developer portal, the keychain-sdk and Keychain Mobile repositories, the Hive Engine API reference, and current EU MiCA / Travel Rule guidance. Specific deep links:

OpenBanking Studio integration desk · reviewed 2026-05-29.

Questions integrators ask about Hive Keychain

Which Hive RPC node should our service point at, and what happens if it falls behind?

Public nodes such as api.hive.blog, api.openhive.network, and api.deathwing.me each expose the same condenser_api/database_api surface; we wire your service to query two in parallel and compare last_irreversible_block_num so a single slow node does not quietly serve stale account state. If your traffic justifies it, we set up a dedicated hived instance with the account_history plugin enabled — a private node, full operation history, and no rate-limit shared with the rest of the ecosystem.

On Hive Engine, why is an HE token balance not just another row on the same account as HIVE and HBD?

Hive Engine is a smart-contract sidechain that watches the L1 for custom_json operations and keeps its own state — the tokens contract holds the balances table, the market contract holds order books. Your backend reads HIVE/HBD/HP from a Hive L1 node and reads HE token balances from api.hive-engine.com/rpc/contracts; we normalize the two into one per-account schema so the consumer never has to track which chain a symbol belongs to.

Keychain Mobile keeps the private keys on the user's phone — what does our app actually call?

For reads, public chain state — you do not need anything from Keychain to query an account's balances, history, or token holdings. For writes, you ask Keychain to sign on the user's behalf: on web that is the keychain-sdk handshake (requestBroadcast, requestTransfer, requestSignBuffer); on mobile it is a deep-link / app-to-app intent the wallet implements. The user authorizes the signature with PIN or biometrics inside Keychain, and your service receives the resulting signed transaction or signed message back.

App profile — Hive Keychain

Mobile wallet for Hive blockchain accounts. Stores posting, active, memo and owner keys behind a PIN and biometric lock on the user's device, decrypting them only at the moment of signing. Imports accounts via private key entry or QR transfer from the Keychain browser extension. Surfaces voting power, HIVE/HBD balances, Hive Engine token balances, delegations, and operation history; broadcasts transfers, delegations, power up/down, and Hive Engine operations on the user's authorization. Open source under the MIT licence; source at github.com/hive-keychain/hive-keychain-mobile. Android package com.mobilekeychain per its Play Store listing.

Pricing closes the brief. Source-code delivery for the Hive Keychain integration starts at $300 — the Python or Node service, the OpenAPI specification, the keychain-sdk adapter, the test pack and the interface documentation, paid only after you have read the diff and run it against a real Hive account. If you would rather not host, our pay-per-call hosted API gives you the same surface as endpoints we operate, no upfront fee. Either path closes inside 1–2 weeks. Tell us the integrator app and which slice of the Hive account you need at contact, and we will cost it from there.