Layer 1 and Nexus Layer 2
The most important dblurt documentation boundary is the difference between Blurt Layer 1 and Nexus Layer 2.
Layer 1 records canonical chain events and state.
Nexus indexes and presents application-friendly social views.If you remember only one rule, remember that Nexus helps applications discover and present data; it does not replace Layer 1 consensus truth.
Why this distinction exists
Blockchain applications often need two different kinds of data:
- canonical chain state, such as account balances, authorities, blocks and signed operations;
- application-friendly social views, such as ranked feeds, profiles, communities and notification lists.
Raw Layer 1 RPC APIs are the right source for the first category. Indexed Layer 2 APIs are often better for the second category.
dblurt exposes both because Blurt applications commonly need both.
Blurt Layer 1
Blurt Layer 1 is the consensus chain. It is responsible for:
- blocks and irreversible history;
- transactions and operations;
- account state and authorities;
- balances and assets;
- witnesses and governance;
- virtual operations and protocol-derived effects.
Typical dblurt surfaces:
| Surface | Use it for |
|---|---|
client.condenser | common chain reads: accounts, content, witnesses, history-compatible calls |
client.database | appbase database methods such as config/version/account lists |
client.accountHistory | account and block operation history envelopes |
client.blockchain | high-level block and operation iteration |
client.broadcast | signed Layer 1 transaction workflows |
client.call | unwrapped JSON-RPC methods |
Use Layer 1 when correctness depends on canonical chain state.
Nexus Layer 2
Nexus indexes and exposes social/query views that are more convenient for applications than raw chain data.
Typical client.nexus use cases:
- ranked feeds;
- account post lists;
- post/discussion views;
- communities and subscriptions;
- profile summaries;
- notifications and unread counts;
- referral account views.
Nexus data is application-friendly. It can be the right surface for discovery and UI flows, but it has indexer semantics and should be treated as Layer 2.
Trust and freshness
Layer 1 and Nexus have different trust questions.
| Question | Prefer |
|---|---|
| What is this account's authority? | Layer 1 |
| Can this key sign a posting action? | Layer 1 authority data |
| What is the current liquid balance? | Layer 1 |
| What posts are trending in a tag? | Nexus |
| What communities match a topic? | Nexus |
| What exact operation was included in a block? | Layer 1 |
| What profile metadata should my social UI show? | Nexus, with Layer 1 validation if security-sensitive |
When a workflow starts with Nexus discovery and ends with a security-sensitive action, validate the relevant Layer 1 state before signing or broadcasting.
Helper routing examples
Read canonical account state
const accounts = await client.condenser.getAccounts(['beblurt']);
const account = accounts[0];Read ranked social posts
const posts = await client.nexus.getRankedPosts({
sort: 'trending',
limit: 10,
tag: 'blurt',
observer: null
});Use Nexus to discover, Layer 1 to verify
A social app might use Nexus to find a post in a ranked feed, then use Layer 1 helpers to read the canonical content object or active votes when exact chain state matters.
Nexus ranked feed -> choose author/permlink -> Layer 1 content/vote read if neededAPI symbols
Compatibility policy for Nexus helpers
New code should prefer typed option objects for pagination-heavy Nexus helpers because they make filters, cursors and observer semantics explicit.
Historical positional Nexus signatures remain legacy-supported. They are not deprecated at this time.
The misspelled listPopComunities helper remains supported for backward compatibility but is deprecated in favor of listPopCommunities.
See Deprecations for lifecycle policy and API reference for exact overloads.
Common mistakes
- Treating Nexus as the source of consensus truth.
- Using a ranked feed result as proof of chain finality.
- Assuming a profile/community view has the same trust model as account authority data.
- Showing exact API parameter tables in concept docs instead of linking to the API reference.