A Bitcoin node is a computer running Bitcoin software that downloads the ledger, checks every block and transaction against the network's rules, and passes valid data to other nodes. Full nodes accept nothing on trust: they reject anything that breaks the rules, however much computing power produced it. For a company, a node is a tool for independent verification, and whether to run one depends on how the company holds its bitcoin.
What a Bitcoin node does
A full node performs four jobs:
- Validates. It checks that every transaction is properly signed, spends only unspent outputs, and creates no more bitcoin than allowed.
- Stores. It keeps a copy of the blockchain, or a recent portion of it, and the current set of unspent outputs.
- Relays. It passes valid transactions and blocks to its peers.
- Serves. It answers queries from wallets about balances and transactions.
Because every node checks independently, there is no central authority deciding what is valid. If a miner produced a block that paid itself too much, nodes would reject that block and it would be worthless. This is the practical reason Bitcoin's 21 million supply cap holds.
Types of Bitcoin node
Not every piece of Bitcoin software is a full node. The distinctions matter when a provider says it "runs its own infrastructure".
| Type | What it holds | What it checks | Typical user |
|---|---|---|---|
| Archival full node | Entire history since 2009 | Every rule, every block | Custodians, exchanges, analytics firms |
| Pruned full node | Recent blocks plus the current state | Every rule, every block | Companies wanting verification with less storage |
| Light client | Block headers only | Proof of work, not full rules | Mobile wallets |
| Third-party API | Nothing locally | Relies on the provider | Many apps and dashboards |
A pruned node validates exactly as strictly as an archival one. It simply discards old block data after checking it.
Who decides the rules?
Developers write software. Miners produce blocks. But nodes choose which software to run and so which rules to enforce. A change to Bitcoin's core rules only takes effect if the economic majority of nodes, particularly those run by exchanges, custodians and large holders, adopt it.
This is why changing Bitcoin is slow and deliberate, and why no single party controls it. The same principle explains why the 2017 dispute over block size ended with the original rules intact: node operators, not miners, decided which chain they would recognise. We explore the security side in how mining secures the network.
What running a node involves
Running a node is not demanding by enterprise IT standards.
- Hardware. A standard server or small dedicated machine. Storage for a full archive runs to several hundred gigabytes and grows over time; a pruned node needs far less.
- Bandwidth. The first download of the full history is large. After that, ongoing traffic is moderate.
- Software. The reference implementation is open source and widely used. Updates should go through normal change management.
- Time. The initial synchronisation can take from hours to days depending on hardware.
- Security. The node should sit in a controlled network segment. It does not need to hold keys.
The node itself does not hold private keys or funds. It is a verification and communication tool. Keys stay in the separate signing set-up, whether that is a custodian's platform or the company's own hardware.
Should a company run a Bitcoin node?
It depends on the custody model.
Probably not needed when:
- All bitcoin is held with a qualified custodian whose infrastructure is covered by audit reports.
- Holdings are modest and the company has no in-house technical capacity.
Worth considering when:
- The company uses self-custody or collaborative multisig, where its own software builds and checks transactions.
- It wants to verify custodian statements and incoming deposits independently.
- It wants privacy: querying a third-party service reveals which addresses a company is interested in.
- It runs proof of reserves checks or wants to monitor its own addresses without relying on outside data.
If you rely on your custodian's systems, ask how many independent nodes they run, which software versions, and whether their audit reports cover node infrastructure.
Practical uses for a corporate node
A node can be useful even alongside a custodian:
- Watch-only monitoring. Load the extended public key into node-backed software to track balances without exposing keys.
- Deposit verification. Confirm incoming transfers and confirmation counts directly from the ledger before releasing cash in a trade.
- Reconciliation. Pull transaction data for month-end matching from your own source rather than a provider's API.
- Fee estimation. Read the mempool directly to set fee rates, rather than relying on a provider's estimate.
Limits to keep in mind
A node verifies the ledger. It does not tell you who owns an address, whether a counterparty is reliable, or whether a custodian's liabilities match its assets. It also adds a system to maintain, patch and document. For many companies, the right answer is to require strong node practices from their custodian rather than to run their own.
If a company does run one, treat it like any other production system. Give it a named owner, include it in patching and change management, log its availability, and document how it is used in the reconciliation process. A node that quietly falls out of sync is worse than no node, because it can give false comfort. A short runbook covering restarts, upgrades and what to do if the node disagrees with a provider's data is enough for most organisations.
How The Bitcoin World helps
We help companies decide whether independent verification is worth the operational overhead, and specify node requirements for custodians in due diligence. Custody, execution and settlement are carried out by licensed third-party institutions. See our custody architecture service.