Accounts and authorities
Blurt accounts are not just names. They hold state and authorities that define which keys or accounts can authorize actions.
You should understand authorities before signing or broadcasting anything with dblurt.
Accounts
A Blurt account is a Layer 1 identity and state container. Depending on the RPC method, account data may include:
- account name;
- balances;
- vesting shares;
- posting/active/owner authorities;
- metadata;
- voting mana or related chain state;
- recovery and governance fields.
Read account state from Layer 1 when correctness matters:
const accounts = await client.condenser.getAccounts(['beblurt']);
const account = accounts[0];Nexus profile data may enrich social UI, but Layer 1 account authority data is the source for signing decisions.
Authorities
An authority describes which keys or accounts can approve actions.
| Authority | Typical use | Documentation rule |
|---|---|---|
| owner | recovery and highest-risk account control | avoid in normal app flows |
| active | value-moving or account-management actions | use only when required |
| posting | social actions such as votes/comments where supported | prefer for social workflows |
| memo | memo encryption/decryption | not a transaction authority |
The safest application uses the least powerful authority that can perform the intended action.
Least privilege
Least privilege means:
- do not ask for an active key when a posting key is enough;
- do not ask for an owner key in normal application flows;
- do not treat a memo key as authorization to broadcast;
- warn users when a high-privilege key is being used for a low-privilege workflow;
- validate authority assumptions before broadcasting.
What the SDK can validate
dblurt includes authority-validation primitives for posting-key workflows.
They can answer questions such as:
- does this key satisfy this authority object?
- does this key satisfy the account's posting authority?
- is the key actually an active or owner key being used where posting would be safer?
- does delegated posting authority satisfy the threshold?
Conceptually:
key + Layer 1 authority data -> validation resultThe validation helpers do not broadcast, store private keys or replace application policy.
What the SDK cannot decide for you
Applications remain responsible for:
- storing keys safely;
- choosing whether to accept a high-privilege key;
- presenting confirmations to users;
- enforcing business or moderation policy;
- deciding which RPC endpoints are trusted;
- handling ambiguous broadcast failures.
dblurt can provide protocol-shaped evidence. Your application decides what to do with it.
Authority and operation examples
| Operation family | Typical authority |
|---|---|
| vote/comment/social custom JSON | posting |
| transfer | active |
| account management | active or owner depending on operation |
| memo encryption/decryption | memo key, not broadcast authority |
Always verify the exact operation before signing. If a guide does not state the authority, treat that as missing documentation rather than permission to guess.
Private key handling
Do not hard-code private keys in examples, source code or tests.
Use environment variables, encrypted storage, wallet integrations or user-controlled signing flows:
import { PrivateKey } from '@beblurt/dblurt';
const rawKey = process.env.BLURT_POSTING_KEY;
if (!rawKey) {
throw new Error('Set BLURT_POSTING_KEY before signing');
}
const key = PrivateKey.fromString(rawKey);Browser signing is especially sensitive because XSS, malicious extensions or compromised dependencies can access key material handled by the page.