System Accounts

A few accounts were created at genesis (block 0, and block 1 for steem.dao) and follow rules no ordinary account has. Three hold the genesis allocation: two stake allocations and the treasury. The others are placeholders inherited from Hive's code. This page explains what each account is for, what the protocol allows it to do, and how to verify it.

At a glance

VESTS are Pixa Power, the staked form of PIXA. On this chain 1 VESTS has stayed worth almost exactly 1 PIXA since genesis (Chain Parameters).

Genesis allocation

Block 0 created 100,000,000 VESTS, backed by 100,000,000 PIXA in the vesting fund, plus 245,098.039 PXS (figures and sources):

There was no liquid PIXA at genesis, no airdrop and no mining. All liquid PIXA since then has come from three sources:

• per-block issuance
• stake that left these accounts and was powered down
• PXS converted into PIXA

These balances were written straight into the initial state (database_init.cpp:386-421). No operation records them, so tools that rebuild balances by adding up operations will not see them.

Restricted accounts: pixa.rex and pixa.team

The protocol locks both allocation accounts down to one job: holding stake and handing it out.

What they can do

• Transfer VESTS directly to another account. This is a transfer operation with a VESTS amount, and no other account can send one (hive_operations.cpp:245). The stake arrives in the recipient's Pixa Power at once, along with matching voting mana and Resource Credits. Its weight in witness and proposal votes matures over the 30-day delayed-voting period (hive_evaluator_transfer.cpp:287-341).
• Update their own keys and metadata with account_update or account_update2.

What they cannot do. Every other operation fails with This account is restricted to VESTS transfers only. That includes:

• liquid transfers
• powering up or down
• delegation
• savings
• claiming rewards
• posting
• voting on content
• witness votes and proxies
• custom_json

The check runs before any operation is applied. Any operation that requires either account's authority is rejected, including when that authority is nested inside another required authority (database.cpp:2762-2810).

Consequences

• The genesis stake does not vote. Neither account can vote for witnesses or on DPF proposals. Stake gains a voice only after it leaves these accounts, and only after its 30-day maturity.
• Stake leaves only by direct transfer. Neither account can power down.
• Anything else sent to them is stuck. PIXA, PXS or rewards sent to either account can never be moved out. Do not send them funds.
• The 3-of-3 multisig is a setup, not a rule. Genesis set it on the owner, active and posting authorities, so three separate signers must approve each action. The signers can change the arrangement with account_update, because the protocol does not enforce 3 of 3. The memo key is a single key.

What each allocation is for

These are commitments stated by the operator. The protocol does not enforce them, but anyone can check the outflows on chain.

The treasury: pixa.omnibus

pixa.omnibus holds the Decentralized Pixa Fund (DPF).

It has no keys. Genesis created it without keys, and hardfork 24, applied at block 1, locked it (database_hardfork.cpp:576-587). Locking empties its owner, active and posting authorities. No person, company or foundation can sign for it.

How money comes in

• A share of issuance. Every block it receives the DPF's share of new issuance, converted to PXS at the median feed (Chain Parameters).
• PIXA sent to it. This is converted to PXS at once.

How money goes out. It only pays proposals:

• Once an hour it pays active proposals in order of their votes.
• Payouts stop at a daily budget of 1% of the treasury balance.
• Proposals ranked below the return proposal (id 2 on this chain) receive nothing. That proposal sends its pay straight back to the treasury.
• Proposal votes are cast with Pixa Power.

It holds PXS only. PIXA sent to it is converted into PXS at once, and no one can stake on its behalf. Proposals are paid from its PXS balance.

Don't confuse it with the Foundation. The Pixa Omnibus Foundation is a legal entity: the protocol's steward. It holds no keys to this account.

steem.dao is the name of Steem's original treasury, which the inherited code still recognises. It was created, empty and locked, when hardfork 21 ran at block 1. Any balance that reaches it is moved to pixa.omnibus in the same block (database.cpp:1283-1310).

initminer

initminer produced the chain's first blocks and was the only witness at genesis. It started with no balance and earned Pixa Power by producing blocks, 45,515.494253 VESTS by 2026-10-08. Today it is an ordinary account; it remains registered as a witness but was not among the 8 scheduled on 2026-10-08 (condenser_api.get_witness_schedule).

Placeholders inherited from Hive

Operational accounts

Some accounts matter to the project but follow ordinary rules.

Check them yourself

Shellrpc() { curl -s -X POST https://api.pixagram.com -H 'Content-Type: application/json' \
  -d "{\"jsonrpc\":\"2.0\",\"method\":\"$1\",\"params\":$2,\"id\":1}"; }

# Balances and keys of every account on this page
rpc condenser_api.get_accounts '[["pixa.rex","pixa.team","pixa.omnibus","steem.dao","initminer","null","temp","miners","steem","pixa"]]'

# Proposals the treasury pays, including the return proposal
rpc database_api.list_proposals '{"start":[""],"limit":50,"order":"by_creator","order_direction":"ascending","status":"active"}'

The public endpoint returns pxs_balance. A node queried directly returns hbd_balance.

Notes for developers

• Transfers look like ordinary transfers. VESTS transfers from the restricted accounts appear in history as plain transfer operations with a VESTS amount, for example "1000.000000 VESTS". They emit no virtual operation.