What Are Crypto Nodes? A Block Producer's Explanation

A wallet shows a transfer as sent, and the person on the other end says nothing arrived. When that happens, the explanation is almost always about nodes: which one the wallet talked to, what that node checked, and what happened between that node and the block producer. A blockchain is a network of programs agreeing with each other, and nodes are those programs.

We run nodes for a living. RORO operates EOS Support, which has been a Top-21 block producer on Vaulta (formerly EOS) since 2023 and provides public API and peer-to-peer endpoints alongside its producer infrastructure. So this is a practical explanation, written from the operator's side of the fence.

A node is a program, not a machine

A node is software that keeps a copy of the chain's state and checks every new piece of data against the protocol's rules before passing it on to its peers. On Bitcoin that's typically Bitcoin Core. On Ethereum it's an execution client paired with a consensus client. On Vaulta and other Antelope chains it's nodeos, from the Spring release line.

The same binary can play very different roles depending on how it's configured. That's the first thing worth understanding, because "run a node" means wildly different amounts of work depending on which role you mean.

Full nodes download every block and re-execute every transaction in it to build the current state. They don't trust anybody's claim that a block is valid; they check it themselves. This is what gives a public chain its integrity. If a producer published an invalid block, every full node would reject it.

Archive nodes are full nodes that also keep historical state, so you can ask what an account's balance was at block 40 million rather than just now. On Ethereum this is a separate mode with much larger storage needs. On Antelope chains the equivalent job is usually done by a node with the state history plugin feeding an external indexer, which is what explorers and analytics tools sit on.

Light clients keep block headers and request proofs for the specific data they care about. They verify a lot less, but they can run on a phone or inside another chain, which is why they matter for wallets and for trust-minimized bridges.

Validator or producer nodes do the extra job of proposing blocks and taking part in consensus. On Ethereum these are validators backed by staked ETH. On Vaulta they're block producers elected by token holders. Either way, these nodes hold signing keys, and that changes how you have to run them.

API nodes serve requests from wallets and applications: push this transaction, read this table, look up this account. P2P nodes (sometimes called seed nodes) exist mainly to relay blocks and transactions between other nodes. In a well-run setup, neither of these is the same machine as the producer.

What a node does with your transaction

Here's what happens on an Antelope chain when a wallet submits a transfer. The broad shape is similar elsewhere, but the details are specific to how Vaulta works.

The wallet signs the transaction locally and sends it to an API node. That node checks that the signatures satisfy the permission the action requires (Antelope accounts have named permissions like owner and active, each with its own keys and thresholds). It checks that the transaction hasn't expired and that the account has enough CPU, NET and RAM to pay for it. Then it executes the transaction speculatively against its own copy of the state. If any of that fails, you get an error straight back, and nothing reaches the network.

If it passes, the node relays the transaction over the peer-to-peer network until it reaches the producer whose turn it is. The producer executes it again, includes it in a block and signs that block. Every other node that receives the block re-executes the transactions in it and checks the producer's signature. Under Savanna, the consensus upgrade that brought fast finality to Vaulta, a set of finalizers then votes on blocks with dedicated BLS keys, and once two thirds plus one of them agree, the block is final and can't be reverted.

That's why "the wallet said it worked" and "it's on chain" are different statements. The API node accepted the transaction. Whether it ended up in a final block is a separate fact you check afterwards, which is one reason we built transaction visibility so directly into Blocksfinity. For more on the verification step itself, see our post on how blockchain transactions are verified.

How Vaulta picks its producers

Vaulta uses delegated proof of stake. Token holders stake and vote for up to 30 producer candidates, with votes weighted by stake. The top 21 by votes form the active schedule and take turns producing blocks: a block every half second, 12 blocks in a row per producer, then the next one in line. Candidates ranked below 21 are standby producers. They keep their infrastructure running so they can step in if votes shift.

Twenty-one is a deliberate tradeoff. It's far fewer block producers than Ethereum has validators, which is a fair criticism on decentralization grounds. In exchange you get fast blocks with quick finality, and a set of operators who are publicly named and answerable to voters when something breaks. You can argue about whether that's the right balance. It is at least an explicit one.

The same 21 also matter for governance. System-level changes, including protocol upgrades and changes to system contracts, need approval from 15 of the 21 active producers through an on-chain multisig. So a producer is also casting votes on how the network evolves, which is part of why we take the role seriously.

What running a Top-21 producer actually involves

From the outside, producing blocks looks like keeping one server up. In practice it's a small operations team's worth of work, most of it invisible when things are going well.

Start with redundancy. A producer that misses its slot misses blocks, and voters notice. So you run more than one producer-capable node, in different locations, and you plan exactly how you'll switch between them. Having a spare is the easy bit. The hard bit is making sure two nodes never sign at the same time, because a double-signing producer is far worse than one that missed a round.

Keys are the next thing to get right. On Antelope, the block signing key that lives on the producer node is a separate key from the account's owner and active keys. The account keys, which control funds and can change registration, stay offline. The signing key can be rotated if a server is ever in doubt. Savanna added finalizer keys on top of that, BLS keys that sign finality votes, and the guidance from the Spring docs is strict: a unique key per producer-capable instance, never shared across hosts, with its safety file kept on local persistent storage.

Monitoring covers missed blocks, peer counts, head block lag, disk and memory pressure, and API latency. We'd rather hear about a problem from an alert at 3 a.m. than from another producer in a group chat the next morning.

Upgrades are a team sport. Protocol upgrades on Vaulta are activated by the producers together. That means testing new releases on testnets such as Jungle first, then agreeing on timing with the other producers and staying reachable during the switch. EOS Support was among the producers listed in the March 2025 network transition discussions, and that kind of coordination is a real part of the job. Exchanges feel upgrades too, and EOS Support's work has included technical assistance for major exchanges alongside that upgrade coordination.

Finally, most producers also serve the network: public API endpoints that wallets and dApps can use, and p2p endpoints that other nodes connect to. These get abused, so they need rate limiting and separate capacity from the producer itself.

And then there's everything around the infrastructure. Over roughly two years EOS Support closed more than 2,700 support tickets and published over 400 English articles, translated into nine languages. That isn't node operation in the narrow sense, but a network whose users can't get help doesn't stay healthy for long.

Costs and hardware, in general terms

We won't quote prices, since they move with providers and regions. The shape of the cost is more useful anyway.

A producer node on an Antelope chain cares more about single-core CPU speed than core count. It also wants generous RAM, because chain state is held in memory, and fast NVMe disks. History and indexing nodes need much more storage and grow every day. Bandwidth is modest per node but adds up once you serve public API traffic. Then double or triple everything for redundancy. The biggest line item, though, is usually people: someone has to be on call.

On Ethereum the profile is different: validators need far less CPU per node, but an archive node needs many terabytes of storage, and staking itself ties up 32 ETH per validator.

Should your business run its own node?

Usually not at first, and sometimes never.

For most applications, a reputable RPC provider (or several, with failover between them) is the right starting point. You get uptime and scaling without hiring for it. The case for running your own node gets stronger when you need data the providers don't index, when you're pushing enough traffic that rate limits or bills become a problem, when you don't want a third party seeing your query patterns, or when you're an exchange or custodian that has to verify deposits against a node you control. That last one isn't optional, in our view. If you credit user funds, you should be reading the chain yourself.

Running a producer or validator is a different decision altogether. It's an operational commitment, and on Vaulta it's a public one, with voters watching your missed-block count. We'd only recommend it to an organization that wants to take part in a network's governance and is ready to staff it.

A sensible middle ground for many teams is one self-hosted full node for verification, with providers handling the bulk of read traffic. If your team works on network infrastructure more broadly, our blockchain networks page describes the kind of work we take on.

If you're deciding whether to run your own nodes, or planning a producer setup, talk to us. We'll tell you honestly if a provider would serve you better.