Read-only vs broadcast
dblurt supports both read-only workflows and signed broadcast workflows. They should not be introduced at the same time.
The documentation learning path is intentionally read-only first.
Read-only workflows
Read-only workflows ask RPC endpoints for data. They do not require private keys and do not change chain state.
Examples:
- read current chain properties;
- load an account;
- inspect a block;
- read a post;
- query ranked Nexus posts;
- list communities;
- estimate vote value from public data.
Typical surfaces:
client.condenser;client.database;client.accountHistory;client.blockchain;client.nexus;client.read;client.toolsfor local calculations.
Read-only examples are the best first copy-paste path because they avoid key handling and irreversible effects.
Operation-building workflows
Operation builders create Layer 1 operation payloads without broadcasting them.
They are useful for:
- previews;
- tests;
- dry-run style UI;
- external signing;
- confirmation flows;
- building a transaction later.
Example:
import { buildPostOperation } from '@beblurt/dblurt';
const operation = buildPostOperation({
author: 'alice',
title: 'Hello Blurt',
body: 'Body text',
tags: ['blurt']
});This returns an operation. It does not sign and does not broadcast.
Broadcast workflows
Broadcast workflows prepare, sign and submit transactions to Blurt Layer 1.
They require:
- explicit user intent;
- the correct authority;
- private key handling;
- trusted endpoint strategy;
- confirmation of accounts, amounts, permlinks and memo text;
- error handling for ambiguous network failures.
Once accepted by the chain, broadcast transactions have real effects.
The three-stage safety model
Use this model in application design:
1. Read data
No key. No side effect.
2. Build operation
No key required. Preview exact payload.
3. Sign and broadcast
Key required. Real chain effect.Docs and examples should make clear which stage they are in.
Why README and getting started stay read-only
A landing page should help a developer succeed quickly without asking for secrets.
That is why the first-run path reads chain data and Nexus views but does not show copy-paste broadcast code. Broadcasting belongs in a safety-focused guide after the reader understands authorities.
Before broadcasting
Before calling client.broadcast, confirm:
- the user intended the action;
- the operation payload is correct;
- the required authority is known;
- the key satisfies that authority;
- high-privilege keys are avoided when possible;
- the endpoint list is trusted;
- the UI can handle success, failure and ambiguity.