Architecture

This page draws the whole network from a reader's browser down to the witnesses, names every program in the path and who runs it, and follows the data through them. Chain Architecture explains the same parts from a developer's seat; Run a Node and Run an API Node say how to run them. This page is about how they are deployed today.

The stack

Three tiers, with a different kind of trust in each:

Nothing in the third tier touches consensus. A reader with a hived of their own needs none of it (Chain Architecture).

The six public nodes

The app ships this list and, on first start, times all six and keeps the fastest that answers (Account Settings). The names and regions are the app's (constants.js:94-137); the last column is from each witness's registration on chain.

Five of the six addresses are the URLs the witnesses registered on chain (condenser_api.get_witnesses_by_vote, 2026-10-08).

All six run the pixagram-node stack (Run an API Node) and answered identically on 2026-10-05; on 2026-10-08 pixarex.net did not accept a connection from the network used for the check (JSON-RPC Surface). On 2026-11-03 all six answered and reported version 1.30.1 (database_api.get_version). Each node is one machine with the whole stack; there is no load balancer in front of the six and no shared database between them. Their hived processes find each other and the witnesses over P2P.

The witness nodes

A witness runs hived with the witness plugin, loads only the plugins block production needs, keeps its signing key in config.ini, and runs a price-feed program that publishes the PIXA price of a Big Mac every hour (Become a Witness; pixa.org's node operator guide). The program reaches out to the index, to PIXA's market, to exchange-rate services and, once at start-up, to a service that locates the server's address. On 2026-11-03, 21 witnesses were scheduled, all on 1.30.1; on 2026-10-08 there were 8, all on 1.30.0 (condenser_api.get_witness_schedule, get_witnesses_by_vote). The live list with each witness's last block is on the witness status page, a static page that reads the public API from the browser.

A witness node is not an API node: it answers no public calls, and the five witnesses who also serve the public run a second, separate stack for that.

How data flows

A reader opens the home page

1. The browser loads the app, a static site, from pixagram.com.
2. The app picks a public node and calls bridge.get_ranked_posts (20 posts), condenser_api.get_accounts for the authors and get_dynamic_global_properties (Feed and Discovery).
3. Caddy terminates TLS, Jussi routes the social call to Hivemind and the chain calls to hived, and renames fields on the way back (JSON-RPC Surface).
4. Hivemind answers from PostgreSQL, where HAF wrote the blocks and Hivemind's own tables hold the scores; hived answers from its state.
5. Artworks arrive inside the posts, as data URIs; an image inside a blog post is a link, loaded through the image proxy (Pixel Art On Chain).

A user publishes an artwork

1. The app builds a comment operation with the image in the body and signs it in the browser with the posting key (Transaction Lifecycle).
2. It sends condenser_api.broadcast_transaction to the chosen node. Caddy, Jussi, hived; hived checks it and relays it over P2P.
3. The next scheduled witness includes it in a block, within 3 seconds.
4. Every hived, including the API nodes', applies the block. HAF writes it into PostgreSQL; Hivemind indexes it a few seconds later; the account-history plugin stores it once the block is irreversible.
5. The artwork appears in Newer at once from Hivemind, and in Hottest and Trending as it is voted.

A user signs up

1. The app generates keys in the browser; only the public keys leave it.
2. It sends them to the account service, a program the operator runs, which pays the creation fee, broadcasts account_create and delegates a little Pixa Power to the new account (Create an Account).
3. The account exists once that transaction is in a block; the app logs the user in with the keys it generated.

Sign-up is the one everyday action that depends on a Pixagram-run server. Anyone with PIXA can open an account without it, with account_create or an account ticket (Operations Reference).

What is where

What this architecture does not have

Recorded so that the planned pages of this section start from the facts.

• No monitoring or alerting shared across operators. Each operator watches their own node; the witness status page shows missed blocks for everyone to see.
• No published backup or disaster-recovery procedure for the API nodes beyond the replay from the block log that the stack supports (Run a Node).
• No load balancing or failover among the six nodes except what the app does itself.
• No capacity figures. No benchmark of the public nodes has been published (Style Guide on the retired "300,000 TPS" claim).
• No testnet reachable by the public.

Compared with Hive

Sources

• Deployment code: pixagram-node at commit 4a271e8 (docker-compose.yml, jussi/nginx.conf, ssl-proxy/Caddyfile); witness at commit 704a68f; bigmac-feed v1.3.0 and witness-status.
• App at commit ca1d157: the node list, constants.js:94-137; the services it calls, through Search, Create an Account and Pixel Art On Chain.
• Live network, 2026-10-08: condenser_api.get_witness_schedule (8 scheduled), get_witnesses_by_vote (versions and URLs), get_dynamic_global_properties on five of the six nodes; the witness status page. 2026-11-03: get_witness_schedule (21 scheduled), get_witnesses_by_vote, and database_api.get_version on all six nodes.
• Hive: developers.hive.io node lists, read 2026-10-05.