Blockchain applications often need a reliable way to read network data, query smart contracts, retrieve balances and transactions, or broadcast transactions. One option is to run your own blockchain infrastructure. Another is to access nodes through a managed provider.
When using managed infrastructure, access may be shared across multiple customers or backed by dedicated capacity. These are infrastructure access models, not blockchain node types in the protocol sense.
Understanding the difference can help developers choose the right infrastructure for their application and understand when they need blockchain node data versus exchange market data from a provider such as CoinAPI.
What Are Blockchain Nodes?
Blockchain nodes are computers running blockchain software and participating in a blockchain network.
Depending on the blockchain and node configuration, they can verify blocks and transactions, maintain blockchain state, relay information to peers, expose RPC interfaces, or participate directly in consensus.
Transactions are propagated across the peer-to-peer network and processed according to the blockchain's protocol and consensus rules. They are not necessarily transmitted instantly to every node.
There are also several protocol-level node categories, depending on the network:
- Full nodes maintain and independently verify the blockchain data required by the protocol.
- Archive nodes retain additional historical state needed for certain historical queries.
- Light clients maintain less information and depend on other network participants for some data.
- Validator or mining nodes participate in block production or consensus, depending on the blockchain.
- RPC nodes expose interfaces applications can use to query blockchain data and submit transactions.
This is different from describing infrastructure as shared or dedicated.
Managed Node Access Models: Shared and Dedicated
When developers use a managed blockchain infrastructure provider, one of the important questions is how the underlying capacity is allocated.
Two common models are shared and dedicated infrastructure.
Some providers may also offer intermediate configurations sometimes described as semi-shared, private pools, reserved capacity, or similar terms. “Semi-shared” is not a universal industry category, so the exact meaning depends on the provider.
Shared Nodes
With shared node infrastructure, multiple customers use capacity managed by the same provider.
This is usually the easiest way to start because developers do not need to provision, synchronize, monitor, and maintain blockchain infrastructure themselves.
The trade-off is that access may be subject to shared capacity, quotas, concurrency limits, or other restrictions.
Dedicated Nodes
Dedicated node infrastructure reserves node capacity for a single customer or workload.
This can provide more predictable performance, higher API throughput, additional configuration options, and stronger workload isolation.
Dedicated does not mean the blockchain itself processes transactions faster or supports greater chain-level capacity. The advantage is at the infrastructure and API-access layer: requests can have dedicated resources, transaction submission may be more predictable, and applications may have higher or more consistent throughput.
Shared Nodes
Shared infrastructure can be an accessible starting point for applications that do not require dedicated capacity.
Pros of Using Shared Nodes
- Lower cost: Infrastructure costs are distributed across multiple customers, making shared access suitable for smaller applications, development, and testing.
- Less operational work: The provider typically handles node synchronization, infrastructure monitoring, software maintenance, and much of the underlying operations.
- Faster setup: Developers can usually connect to an endpoint rather than deploying and synchronizing their own blockchain node.
- Useful for moderate workloads: Shared infrastructure can be sufficient for balance queries, transaction lookups, contract calls, and other standard RPC workloads.
Cons of Using Shared Nodes
- Quotas and limits: Providers may apply limits to requests, concurrent connections, particular RPC methods, or burst traffic.
- Variable performance: Heavy activity across shared infrastructure can sometimes affect response times or available capacity.
- Less configuration: Developers generally have less control over node configuration, indexing, software versions, regions, and other infrastructure settings.
- Provider dependency: Availability and performance depend partly on the provider's infrastructure and operational practices.
The main concern is usually not that another customer can directly “compromise your node.” Properly designed managed infrastructure should isolate customers.
More realistic considerations include noisy-neighbor performance, rate-limit contention, isolation quality, credential security, and provider-side configuration.
Dedicated Nodes
Dedicated infrastructure is more appropriate when an application needs predictable capacity or additional infrastructure controls.
Pros of Using Dedicated Nodes
- Dedicated capacity: Resources are not shared with unrelated customer workloads.
- More predictable performance: Dedicated resources can provide more consistent RPC response times and request throughput.
- Greater configuration flexibility: Depending on the provider, customers may be able to select regions, archive capabilities, indexing options, networking configurations, or other infrastructure characteristics.
- Workload isolation: Dedicated infrastructure can provide stronger separation between customer workloads.
- Higher request throughput: Dedicated capacity can support demanding API workloads without relying on a shared resource pool.
It is important to distinguish this from changing blockchain consensus rules.
Running a dedicated node does not normally allow a user to customize transaction-validation rules on a public blockchain. Those rules are defined by the blockchain protocol. Running incompatible validation logic could cause the node to reject the canonical chain or effectively participate in a fork.
Cons of Using Dedicated Nodes
- Higher cost: Reserving infrastructure for a single customer generally costs more than shared access.
- Potential operational complexity: The amount of work depends on whether the node is self-hosted or managed.
- Technical requirements: More advanced configurations may require blockchain and infrastructure expertise.
A self-hosted dedicated node requires the user to manage infrastructure, synchronization, monitoring, upgrades, security, backups where applicable, and capacity planning.
A managed dedicated node is different. The provider may handle infrastructure maintenance, monitoring, software updates, and availability while the customer remains responsible for application integration, credentials, access policies, and usage.
What About Semi-Shared Nodes?
Some infrastructure providers may offer a middle ground between completely shared infrastructure and a dedicated node.
This could mean a smaller shared pool, reserved capacity, higher quotas, or partially isolated resources.
However, semi-shared node is not a standardized blockchain infrastructure category. Two providers using similar terminology may offer very different architectures.
Instead of choosing a service simply because it is described as “semi-shared,” compare the characteristics that actually matter:
- Request quotas
- Burst capacity
- Concurrent connections
- RPC method availability
- Geographic regions
- Archive access
- Workload isolation
- Latency
- Uptime commitments
- Support
- Pricing
These details provide a more useful comparison than the label alone.
Do You Need an Archive Node?
For some applications, the more important question is not shared versus dedicated but standard versus archive access.
An archive node retains historical blockchain state that may no longer be available through a standard full-node configuration.
This can matter for workloads such as:
- Historical account-state queries
- Historical smart-contract state
- Blockchain analytics
- Indexing
- Auditing and research
- Reconstructing historical on-chain conditions
Archive infrastructure can require significantly more storage and resources, so access and pricing may differ from standard RPC services.
If your application depends on historical state, check whether the provider supports the required archive methods and historical depth before choosing an infrastructure model.
Which Node Access Model Fits Your Workload?
The right infrastructure depends more on the workload than on the size of the company using it.
| Use Case | What to consider |
| Development and testing | Shared RPC access may be sufficient |
| Wallet balances and basic transaction lookups | Shared access with appropriate quotas |
| DeFi application backend | Reliability, latency, RPC methods, WebSocket support, quotas |
| Transaction broadcasting | Availability, latency, geographic region, reliable submission |
| Historical state analysis | Archive-node access |
| Blockchain indexing and analytics | Archive depth, throughput, storage and query volume |
| High-volume production application | Dedicated capacity, SLA, throughput and redundancy |
| Validator operations | Network-specific validator infrastructure rather than generic RPC access |
There is no universal rule that small projects should always use shared nodes and enterprises should always use dedicated nodes.
A small but latency-sensitive application may need dedicated infrastructure, while a large application with moderate read-only workloads may work well with scalable shared access.
What to Evaluate in a Managed Node Provider
Beyond the shared-versus-dedicated distinction, developers should consider several practical infrastructure characteristics.
Supported blockchains: Make sure the provider supports the networks and environments your application needs.
Protocols and methods: Check which JSON-RPC, HTTP, WebSocket, or blockchain-specific interfaces are available.
Archive access: Determine whether historical state is required and how far back queries can go.
Rate limits and quotas: Review requests per second, burst limits, concurrent connections, method-specific restrictions, and other usage controls.
Latency and regions: Applications that submit transactions or react to on-chain events may benefit from infrastructure close to their own systems or relevant network peers.
Availability: Production applications should review uptime commitments, redundancy, failover architecture, and SLA terms.
Security: API keys should be protected, rotated when compromised, and never exposed in client-side applications. Use IP allowlists, private networking, or other access controls where supported.
Blockchain Node Data vs. CoinAPI Market Data
This distinction is especially important for CoinAPI users.
Blockchain node infrastructure provides access to on-chain information such as:
- Blocks
- Transactions
- Account balances
- Smart-contract calls
- Events and logs
- Blockchain state
CoinAPI, by contrast, focuses on financial and exchange market data infrastructure.
Depending on the CoinAPI product, this includes:
- Trades
- Quotes
- Order books
- OHLCV
- Exchange rates
- Market metrics
- Reference data
- Bulk historical datasets
For example, if you need to query the state of an Ethereum smart contract at a particular block, you need appropriate blockchain infrastructure.
If you need historical ETH/USD trades, exchange order books, OHLCV, or standardized exchange rates, that is where CoinAPI Market Data API, Exchange Rates API, and Flat Files are relevant.
Some applications need both. A blockchain analytics platform might combine on-chain transaction information from node infrastructure with CoinAPI market data to add market prices, exchange activity, or historical valuations.
Choosing the Right Infrastructure
Shared and dedicated nodes solve different infrastructure problems, but the labels alone do not tell you which option is best.
Start with the actual requirements: the blockchain, RPC methods, historical depth, request throughput, latency, geographic region, availability, security, and budget.
And first determine what type of data you actually need.
If your application needs on-chain state, use suitable blockchain node infrastructure. If it needs cryptocurrency exchange market data, CoinAPI provides normalized real-time and historical data through products such as Market Data API, Exchange Rates API, and Flat Files.
Explore CoinAPI Market Data API to access trades, quotes, order books, OHLCV, and other cryptocurrency market data.
