blurtd — Reference

The complete reference for the node: the consensus and chain model, node types and state, the JSON-RPC API surface, and how a node sits under the rest of the stack. For a gentle introduction, start with the Quick guide.

blurtd is the C++ node of the Blurt blockchain (blurt/blurt, Graphene/Steem lineage, heavy Boost + fc). It is the foundation the whole stack derives from. Chain parameters below are the stable ones; exact versions, hardforks, and operator specifics live in the repository and change over time, so this page avoids pinning transient numbers.

Consensus model

Blurt uses Larimer-style Delegated Proof of Stake (DPoS):

• Witnesses are elected block producers. Stakeholders vote for witnesses (weighted by vesting stake); the top set produces blocks in a schedule.
• Blocks are produced roughly every 3 seconds.
• The chain advances a last irreversible block (LIB): once enough witnesses have confirmed a block, it can no longer be reverted. Derived services (the wallet indexer, nexus-go) target the LIB so their data is not affected by short reorgs.
• A regent account holds a large but steadily decaying stake (to zero over two years) that can vote on witnesses and DAO proposals, without affecting circulating supply, inflation, or the reward pool.

Chain characteristics

• Tokens — BLURT is the liquid token; staked ("powered up") weight is held as VESTS (governance weight and reward shares are denominated in VESTS).
• No downvotes and no stablecoin (there is no SBD/BBD equivalent).
• Witness-controlled fees — acting on-chain costs BLURT. Every transaction pays a fee set by the witnesses: a flat fee per operation (operation_flat_fee × number of operations) plus a bandwidth component per kilobyte of transaction size (bandwidth_kbytes_fee), paid in BLURT. The rates are the witnesses' median chain properties, and the fee is charged in consensus. This fee — not a resource-credit system — is how Blurt bounds on-chain load and spam.
• Steem import — balances, usernames, and public keys were imported at genesis; content, follows, and profiles were not.

Fees, not Resource Credits

If you know Steem/Hive: Blurt does not use Resource Credits (RC) as a fee replacement. On Blurt, transacting costs a real BLURT fee set by the witnesses (flat-per-operation + per-kilobyte). The RC/mana code is inherited from the Graphene lineage and rc_api still exposes that state, but the economic gate on Blurt is the fee, not RC.

Node types and state

blurtd keeps chain state in a memory-mapped shared-memory state store and syncs blocks over a peer-to-peer protocol.

• A consensus node keeps the state needed to validate the chain and serve most reads.
• A full node additionally enables account_history_api to serve complete per-account operation history, which needs substantially more storage.

The state-store size and related tuning are set in config.ini. History depth, plugins enabled, and hardware needs follow from whether you run a consensus or a full node — see the repository for current recommendations.

JSON-RPC API

blurtd serves JSON-RPC 2.0 over both HTTP and WebSocket. An API is a named group of methods provided by a plugin; a node enables the APIs it wants to serve in config.ini.

The API namespaces available in the current tree:

Namespace	Purpose
database_api	accounts, content, votes, delegations, witnesses, global chain state
condenser_api	the classic aggregate API front-ends grew up on (read + broadcast_*)
account_history_api	per-account operation history (full nodes)
account_by_key_api	reverse lookup: public key → accounts
network_broadcast_api	submit signed transactions to the network
block_api	fetch blocks and block headers
chain_api	low-level chain/state access
rc_api	resource-credit / mana state (inherited RC plugin; not Blurt's cost model — see fees above)
rewards_api	reward-related queries
transaction_status_api	look up the status of a submitted transaction
tags_api, follow_api	tag/discussion and follow reads (social; see below)

Calling convention

Methods are addressed as namespace.method, or through the legacy call form:

// dotted
{ "jsonrpc": "2.0", "id": 1, "method": "condenser_api.get_accounts", "params": [["alice"]] }

// legacy "call" (api, method, params)
{ "jsonrpc": "2.0", "id": 1, "method": "call", "params": ["condenser_api", "get_accounts", [["alice"]]] }

APIs can be referenced by string identifier (recommended, robust against server config) or by numeric id (assigned in the order APIs are registered).

Access control

The node's RPC is typically bound to loopback and exposed only through a front proxy, or restricted by firewall — an operator concern, not a chain one. This is exactly where the RPC proxy sits: it fronts blurtd's API for the public.

How the stack uses it

• Reads — the RPC proxy routes consensus/chain reads (database_api, block_api, account_history_api, most of condenser_api, …) to blurtd, and routes the social subset (feeds, communities, discussions, follows) to nexus-go, which serves them from data it indexed from blurtd.
• Writes — all broadcast_* / network_broadcast_api calls go to blurtd; it validates and gossips the transaction to the network. No derived service ever accepts a write.
• Indexing — nexus-go and the wallet indexer tail blurtd's blocks to build their fast query stores; both target the last irreversible block.

Companion tools

• cli_wallet — the command-line wallet built alongside blurtd: manages keys and constructs, signs, and broadcasts transactions.
• Client libraries — the repository ships client libraries (blurtjs, dblurt) for building applications against the API.

Building and running

blurtd and cli_wallet build with CMake (make blurtd cli_wallet). A node is driven by a config.ini that selects the plugin/API set, the HTTP/WebSocket/P2P endpoints, and the state-store size, then syncs from seed peers. Because the operator details (recommended specs, seed lists, tuning) evolve with releases, follow the repository's current docs rather than any fixed snapshot.