For Hive and Steem developers

If you already know Hive, Steem or another Graphene-family chain, dblurt will feel familiar in several places, but the safest path is to treat Blurt as its own chain and dblurt as its own SDK.

This page gives orientation, not a mechanical compatibility matrix. Exact method signatures belong in the API reference.

What transfers well

Several mental models carry over:

Familiar concept	Blurt / dblurt orientation
Accounts	Blurt accounts remain Layer 1 identities with authorities, balances, metadata and social/content relationships.
Operations	Transactions still contain ordered operations such as votes, comments, transfers, account updates and custom JSON payloads.
Authorities	Owner, active, posting and memo roles remain useful, but you should still verify the required authority per operation.
Witnesses	Witnesses remain Layer 1 block producers and governance participants.
Custom JSON	Social actions such as follow, mute and reblog are represented as custom_json conventions.
Account history	Historical and virtual operations remain important for audits, rewards and indexers.

Start with the Blurt mental model if any of those concepts are unclear in Blurt-specific terms.

What you should not assume

Do not copy assumptions from another chain or SDK without checking Blurt and dblurt directly.

Do not assume	Use instead
Hive/Steem RPC method coverage is wrapped one-for-one	Use client.condenser, client.database, client.accountHistory, client.blockchain, client.nexus, or the raw client.call(api, method, params) escape hatch.
A helper exists because another SDK has it	Check the API reference or use client.call() for unwrapped RPC methods.
Resource Credits are the normal transaction-cost model	Blurt uses explicit fees. Do not present RC as the main user cost model.
Nexus data is Layer 1 consensus data	Treat Nexus as Layer 2 indexed/social data; validate against Layer 1 when the decision is security-sensitive.
A historical operation type is currently accepted by mainnet	Check deprecations and current Layer 1 behavior. Some compatibility helpers remain callable but are deprecated.
Browser signing is safe because the SDK can run in browsers	Browser key custody has separate security risks. Prefer wallet-mediated signing when possible.

API surface translation

Use this map when porting an integration or checking where a familiar workflow belongs.

If you are looking for...	Start with...	Notes
Chain properties, accounts, content, witnesses, proposal reads	client.condenser	Common Layer 1 query workflows.
Appbase-style database calls	client.database or client.call('database_api', method, params)	dblurt intentionally does not wrap every database method.
Block ranges and operation scans	client.blockchain	Higher-level iteration helpers over Layer 1 blocks and operations.
Account or virtual operation history	client.accountHistory and client.condenser.getAccountHistory()	Choose by parameter shape and workflow.
Ranked posts, profiles, communities, notifications	client.nexus	Nexus is Layer 2 indexed/social infrastructure.
Follow, mute, reblog, community subscription actions	social operation builders and client.broadcast helpers	These build custom_json operations.
Content publishing	content builders such as buildPostOperation() plus broadcast helpers when you are ready to sign.
Raw method not wrapped by the SDK	client.call(api, method, params)	Prefer this over inventing a helper name.

Porting checklist

When moving code from a Hive/Steem integration:

1. Reconfirm the RPC namespace and method. If dblurt does not wrap it, use client.call() with the Blurt RPC method shape.
2. Reconfirm operation support. Operation interfaces may exist for history compatibility even when a current-chain workflow is deprecated.
3. Reconfirm authorities. Use posting for social operations where valid, active for financial/account-management operations, and owner only when the operation requires it.
4. Reconfirm asset handling. Preserve symbol and precision with Asset; do not convert asset strings into plain JavaScript numbers for signing-critical logic.
5. Reconfirm Layer 1 vs Nexus. Use Layer 1 for consensus-sensitive state and Nexus for indexed/social discovery.
6. Reconfirm broadcast retry behavior. A timeout after broadcast is ambiguous; keep the transaction id and check status where available instead of blindly retrying side-effectful submissions.

Deprecated compatibility surfaces

Some APIs remain callable for compatibility but should not be presented as current Blurt workflows.

Examples include:

• BroadcastAPI.accountWitnessProxy() — current Blurt Layer 1 rejects witness proxies after hardfork 0.8;
• BroadcastAPI.claimAccount() and BroadcastAPI.createClaimedAccount() — current Blurt Layer 1 rejects claimed-account tickets after hardfork 0.2;
• Nexus.listPopComunities() — historical misspelling retained in favor of listPopCommunities().

See Deprecations for the current lifecycle policy.

Recommended learning path

If you know the ecosystem but not this SDK, use this order:

1. Choose your path
2. Layer 1 and Nexus Layer 2
3. Accounts and authorities
4. Read chain data
5. Broadcast safely
6. API reference

The goal is not to relearn every blockchain concept. The goal is to avoid carrying the wrong assumptions into Blurt-specific code.