NEAR RPC Providers: Archival Data and Dedicated Hosting Compared

Which NEAR RPC provider should you use?

For most teams, the first decision is not which company to choose.

It is whether you actually need an archival endpoint, a dedicated node, or only reliable shared JSON-RPC access.

If you are building a wallet interface, account dashboard, ordinary smart-contract frontend or early-stage application that mostly reads current state and submits transactions, a managed shared endpoint is normally the efficient starting point.

If you need to query old blocks, old chunks, historical contract state, prior account changes or data that a standard node has garbage-collected, archival access becomes a hard requirement rather than a premium convenience.

If your application continuously backfills history, runs large indexers, services an exchange or processes enough traffic that shared limits materially affect reliability, dedicated infrastructure becomes a separate purchasing decision.

NOWNodes is relevant for teams that want NEAR inside a broader multichain infrastructure account and prefer request-based managed access with a path toward higher plans or dedicated deployments.

GetBlock is a similar multichain option with shared plans priced through compute units and a broader dedicated-node platform.

Chainstack is particularly interesting where the team values deployment flexibility because its platform combines Global Nodes, dedicated infrastructure, self-hosted orchestration and flat-fee node options across supported networks.

QuickNode deserves a place in an archival comparison because the official NEAR RPC provider directory currently marks it as offering archival nodes on both Mainnet and Testnet.

FASTNEAR is another useful network-specific alternative, particularly for developers who want a NEAR-focused endpoint and ecosystem tooling.

The official NEAR archival RPC can also serve as an independent reference source for historical queries, although its documented rate limits make it unsuitable as an automatic substitute for production capacity.

If NEAR is only one chain inside a larger backend, compare the broader operational model using TokenToolHub's multi-chain node hosting research. If your main decision is whether to move from pooled infrastructure to isolated capacity, the dedicated versus shared RPC node guide provides the infrastructure-level comparison before you apply it specifically to NEAR.

NEAR's RPC model changes what archival access means

NEAR is not an Ethereum JSON-RPC clone.

Its native JSON-RPC interface reflects the network's own account model, sharding architecture, smart-contract execution system and receipt-based transaction flow.

Applications query blocks, chunks, accounts, access keys, contract state and transaction outcomes through NEAR-specific methods.

The core interface includes methods such as block, chunk, query, changes, gas_price, status, send_tx and tx.

Historical state therefore means more than keeping old block headers.

An application may need an old account state.

It may need contract state as of a particular block.

It may need a chunk containing the original transaction and receipts.

It may need historical state changes for an indexer.

It may need the transaction plus all asynchronous receipts that followed from it.

A provider that can return an old block but cannot serve the state or receipt evidence required by your application may still be insufficient.

Current state and archival state are different products

A current-state query can use finality: "final" to ask for a finalized view of an account or contract.

That request does not require the server to retain years of chain history.

By contrast, a query pinned to an old block_id may require data the standard node has already garbage-collected.

The NEAR RPC documentation explicitly identifies UNKNOWN_BLOCK and UNKNOWN_CHUNK as situations where an old block or chunk may no longer be present and recommends archival infrastructure for historical data.

This distinction is one of the most important procurement checks in the entire guide.

Do not ask a provider whether it "supports NEAR."

Ask whether the exact endpoint you are buying supports the oldest block, account state, change query and transaction receipt you need.

Archival reads must be tested separately from current-state reads

The simplest NEAR RPC test is often a status call.

It confirms that the endpoint exists and is answering.

That says very little about whether the service can power an indexer or historical analytics system.

The next common test is a query request using view_account against finality: "final".

This establishes whether the provider can return finalized current state for the selected account.

Again, it does not establish archive depth.

Historical capability should be tested with an explicit old block_id.

The block method can query a block by height or hash.

The chunk method can query a historical chunk.

Contract and account queries can also reference a particular block rather than the newest finalized state.

If the provider's underlying node has already garbage-collected the requested data, the call can fail even though the endpoint works perfectly for present state.

Use several historical checkpoints

One old block is not enough to characterize retention.

Choose several checkpoints.

Use one from a recent period.

Use one from several months earlier.

Use one from the oldest period your product must support.

Then query the block and at least one account or state primitive associated with that period.

If you need complete history, test close to genesis-era data rather than assuming an "archive" label means every historical state transition is available.

Document the exact error when a request fails.

An UNKNOWN_BLOCK response can indicate that the block is invalid or has been garbage-collected.

An UNKNOWN_CHUNK response can similarly indicate that the requested chunk is not present on that server.

A provider gateway may wrap those errors differently.

Your integration should preserve enough of the provider response to distinguish "not found on this endpoint" from a malformed request.

{
  "jsonrpc": "2.0",
  "id": "history-test",
  "method": "block",
  "params": {
    "block_id": 100000000
  }
}

Repeat the same call against the standard endpoint and the provider's archival endpoint if the service exposes them separately.

That test establishes whether the upgrade actually changes historical reach.

Historical state is more demanding than historical headers

An analytics workload can require contract state as it existed at an old block.

That is different from merely retrieving the block header.

A provider comparison should therefore include a historical query method.

For example, an application may use view_account, view_access_key, view_state or a read-only contract method against a specific historical block.

Not every use case requires that depth.

But if historical state is part of your product, it must be tested before the endpoint is purchased.

NEAR finality settings change the meaning of a successful response

NEAR applications have more than one possible threshold for deciding that data is ready to use.

A dashboard can accept a responsive optimistic result.

An accounting system may need finalized state.

A cross-chain settlement system may need the transaction and every resulting receipt, including refunds, to be finalized.

The RPC interface makes this distinction explicit.

For ordinary state reads, a request can use finality: "final".

For transaction workflows, current NEAR RPC methods provide a more granular execution model through wait_until.

The modern send_tx and tx methods accept this field.

The default is currently EXECUTED_OPTIMISTIC.

That default is useful for ordinary applications because it waits until the transaction and non-refund receipts have executed without requiring the entire result to be finalized.

It is not automatically the right choice for every financial workflow.

This table changes how RPC latency should be benchmarked.

Comparing one provider's send_tx response at NONE with another provider's response at FINAL is meaningless.

The calls answer different questions.

Record the execution milestone in every latency test.

Use the lowest finality level that satisfies the actual risk

A user interface displaying "transaction submitted" does not need to wait for the same state as an accounting ledger recording irreversible settlement.

Waiting for excessive finality everywhere increases latency without necessarily improving the user experience.

Waiting for too little can create false certainty.

The correct design separates the states.

A UI can show submitted.

Then included.

Then executed.

Then finalized if the workflow requires it.

The backend can continue monitoring even after the frontend has moved on.

Receipt retrieval is a core NEAR-specific provider test

NEAR execution is asynchronous.

A transaction can create an action receipt.

That receipt can execute on another account.

The execution can produce additional receipts.

A cross-contract call can therefore involve a chain of execution outcomes rather than one atomic transaction object that tells the complete business story.

This is why transaction monitoring should not stop at the parent transaction hash when the application needs to understand what actually happened.

The current tx method returns transaction status and execution outcomes.

The experimental transaction-status method can additionally expose the full set of receipts associated with the transaction.

The experimental receipt method can retrieve an individual receipt by its receipt ID.

These methods are especially useful for debugging complicated smart-contract interactions.

Because experimental interfaces can change more readily than stable methods, an application should isolate them behind its own adapter and avoid making the entire product dependent on an undocumented response assumption.

What a receipt-aware test should establish

Use a controlled Testnet contract interaction that creates at least one receipt.

Submit the transaction.

Query it through tx.

Record the transaction outcome and receipt outcome IDs.

If your product needs deeper debugging, test the experimental receipt methods against the same transaction.

Verify that the provider returns the expected receipt data.

Then query the same transaction through your secondary provider.

The goal is not to calculate a fictional provider "accuracy score."

The goal is to prove that the methods required by your application actually work on the exact endpoint you intend to deploy.

A reproducible NEAR RPC provider test methodology

A useful provider comparison should use one controlled workload against every candidate.

Do not compare marketing claims alone.

Do not compare latency from different continents and call it infrastructure performance.

Do not claim archival coverage when only a latest-state request was tested.

Do not call a transaction successful when only the broadcast step completed.

Build a small fixture that exercises the four capabilities the application actually needs: current reads, historical reads, execution evidence and submission.

Keep the network path controlled

Latency measurements depend on geography.

A Frankfurt endpoint called from Lagos is not directly comparable with a Singapore endpoint called from Singapore.

A home broadband connection is not an infrastructure benchmark.

For meaningful measurements, run the test from one controlled cloud region against every provider.

Then repeat from the region where your real backend will run.

Record DNS time, connection setup, server response and total round-trip duration if the test tooling allows it.

Do not publish latency numbers that combine provider performance with an uncontrolled editorial network path.

Label unavailable tests instead of guessing

If you do not have access to a NOWNodes NEAR archive configuration, mark archival historical-state testing unavailable.

If a GetBlock NEAR dedicated archive deployment requires custom provisioning, do not infer its performance from Ethereum dedicated-node marketing.

If a Chainstack NEAR dedicated configuration cannot be selected in the current console, confirm it before describing it as a live self-service deployment.

If a provider does not expose a documented receipt method, record the limitation.

Infrastructure research gains credibility by preserving unresolved states rather than forcing every row in a comparison table to look complete.

NOWNodes for NEAR Protocol

Chainstack for NEAR workloads

GetBlock for NEAR Protocol

QuickNode as an archival comparison point

NEAR public and ecosystem RPC options

The official NEAR documentation maintains a provider directory containing public endpoints, commercial providers and archival availability.

This is unusually useful for a buyer because it creates a network-maintained reference point rather than forcing every comparison to begin with vendor marketing.

The list currently includes FASTNEAR, NEAR's own public infrastructure, 1RPC, All That Node, Ankr, BlockPI, dRPC, GetBlock, Intear, Lava Network, NodeReal, NOWNodes, QuickNode, Tatum, ZAN and several other options.

Not all of these services provide archival nodes.

Not all provide public endpoints.

Not all have the same free-tier limits.

That variation is precisely why the network directory should be used as a starting point, not as a final ranking.

The official archival endpoint is valuable for verification

NEAR currently provides public archival RPC infrastructure for Mainnet and Testnet.

The documentation describes it as severely rate limited.

That makes it particularly useful as an independent reference source.

Suppose your commercial provider returns UNKNOWN_BLOCK for a block you believe should exist.

A query through the official archival endpoint can help determine whether the problem is the block identifier or the commercial provider's retention.

Suppose an older chunk cannot be retrieved.

The public archival endpoint provides another place to validate the request.

This is a strong research and debugging role.

It is not the same as a production SLA.

FASTNEAR is useful for NEAR-focused infrastructure

FASTNEAR operates public NEAR RPC endpoints and maintains ecosystem-specific tooling.

The official provider table currently identifies its archival offering as paid-only.

It also maintains a public dashboard that compares response times across multiple NEAR endpoints.

For teams that care primarily about NEAR rather than multichain vendor consolidation, a network-specialized provider can deserve more attention than a generic infrastructure brand.

Use modern transaction submission methods deliberately

Current NEAR RPC documentation recommends send_tx and tx for new integrations.

This matters because many older tutorials still use broadcast_tx_async or broadcast_tx_commit.

Those older methods are retained for backward compatibility.

They provide less explicit control over the execution milestone at which the RPC call should return.

New applications should model transaction state explicitly.

Build the transaction.

Sign it in the application's trusted signing environment.

Send the base64-encoded signed transaction through send_tx.

Choose the wait_until state appropriate to the business requirement.

Persist the transaction hash.

If the response times out before the selected execution milestone, query the transaction through tx rather than assuming it failed.

A timeout is not proof of transaction failure

This principle is important across blockchain infrastructure.

The client can lose its connection after the server broadcasts the transaction.

The server can reach its own request deadline while the chain continues processing.

A higher wait_until level can take longer than a frontend's HTTP timeout.

If the application responds to every timeout by constructing and signing a new transaction, it can create duplicate economic actions.

Persist enough transaction information to query the original transaction first.

Use a lower wait state and poll when client deadlines are short

NEAR documentation explicitly notes that higher wait_until levels can take several seconds.

Where the client timeout is short, one pattern is to submit with a lower milestone and then poll tx for the stronger finality requirement.

This can produce a responsive user experience without weakening the backend's eventual settlement standard.

{
  "jsonrpc": "2.0",
  "id": "submit",
  "method": "send_tx",
  "params": {
    "signed_tx_base64": "BASE64_SIGNED_TRANSACTION",
    "wait_until": "EXECUTED_OPTIMISTIC"
  }
}

For a settlement process requiring every receipt and refund to finalize, the same transaction can later be queried using wait_until: "FINAL".

A practical archival test for NEAR providers

Before paying for a history-sensitive plan, create a short test matrix.

Choose an old block height that you know exists.

Choose an account that existed around that time.

Choose a historical contract whose read-only state can be queried at an old block if your use case requires contract history.

Choose one known transaction hash and sender account.

Then test the same data against every provider.

Test 1: current finalized block

{
  "jsonrpc": "2.0",
  "id": "current-block",
  "method": "block",
  "params": {
    "finality": "final"
  }
}

This establishes basic current-chain access and gives you the finalized height used as a reference point.

Test 2: historical block

{
  "jsonrpc": "2.0",
  "id": "old-block",
  "method": "block",
  "params": {
    "block_id": 100000000
  }
}

If the provider cannot retrieve the block, determine whether the endpoint is non-archival or whether the chosen block height is incorrect.

Test 3: current account state

{
  "jsonrpc": "2.0",
  "id": "account",
  "method": "query",
  "params": {
    "request_type": "view_account",
    "finality": "final",
    "account_id": "example.near"
  }
}

Record the returned block height, balance, locked amount and storage usage.

Test 4: transaction finality

{
  "jsonrpc": "2.0",
  "id": "tx-status",
  "method": "tx",
  "params": {
    "tx_hash": "KNOWN_TRANSACTION_HASH",
    "sender_account_id": "sender.near",
    "wait_until": "FINAL"
  }
}

This establishes whether the provider can return the transaction at the execution milestone required by your workflow.

When dedicated NEAR infrastructure is worth paying for

Dedicated infrastructure should solve a measurable problem.

It should not be purchased because "dedicated" sounds more professional.

A shared endpoint is often the right solution for a normal dApp.

The provider absorbs node maintenance.

Traffic from many customers shares a managed fleet.

The customer pays a comparatively low recurring fee.

The trade-off is that throughput limits, request quotas and infrastructure configuration are controlled by the provider.

Dedicated provisioning changes that relationship.

Resources are reserved for one customer or one workload.

The team can often obtain more predictable performance.

Providers can expose stronger IP restrictions, custom regions, custom retention or specialized monitoring.

Billing may move from per-request usage toward compute and storage.

Sustained load is a stronger signal than occasional spikes

A traffic spike does not automatically justify a dedicated node.

Good shared infrastructure is designed to absorb bursts within its limits.

The stronger signal is sustained traffic that repeatedly approaches rate limits.

If the application spends significant engineering effort caching around RPC quotas, reducing necessary calls or maintaining several shared plans, isolated infrastructure may become easier to operate.

Historical backfills can justify isolation

An indexer rebuilding several years of NEAR history can generate a very different traffic pattern from a user-facing wallet.

It may perform continuous sequential block reads.

It may retrieve every chunk.

It may inspect transaction and receipt outcomes.

It may repeat historical state queries while building derived datasets.

A shared compute-unit plan can become expensive or rate-limited under that pattern.

A dedicated archival server may provide better throughput economics if the workload runs continuously.

Calculate the break-even point from real data rather than assuming dedicated is automatically cheaper.

Compliance can make the decision independent of traffic

A financial institution may need IP allowlisting.

It may need a fixed ingress path.

It may need infrastructure in a particular region.

It may need account-level isolation that a generic public gateway cannot provide.

Those requirements can justify dedicated infrastructure even when the request volume is modest.

For a broader comparison of those trade-offs, review TokenToolHub's dedicated and shared RPC node analysis.

NEAR RPC provider pricing requires a workload model

Provider pricing cannot be compared responsibly by putting monthly fees in one column and choosing the smallest number.

The units differ.

NOWNodes advertises monthly requests.

Chainstack uses request units for shared infrastructure and compute plus storage for dedicated nodes.

GetBlock uses compute units for shared RPC.

Other providers use API credits, requests per second, daily limits or hybrid models.

The official NEAR provider documentation explicitly warns that free-tier figures are reported in the units each provider publishes and are therefore not directly comparable.

A valid cost model starts with your application.

Shared and dedicated endpoints should be benchmarked differently

A shared endpoint represents a managed service.

The provider may route requests across several backend nodes.

Traffic may be geographically balanced.

One customer does not necessarily know which physical node answered each request.

This is usually beneficial.

Failover and maintenance can happen without changing the customer's URL.

A dedicated node represents more direct ownership of capacity.

It can provide more predictable resource availability but can also expose the customer to the health of a smaller set of servers unless the provider adds redundancy.

Benchmarking should reflect that difference.

Shared endpoint tests

• Measure ordinary response latency across a representative method mix.
• Measure the published RPS limit under authorized test conditions.
• Check rate-limit response behavior.
• Test endpoint continuity during ordinary application load.
• Check whether historical requests use the same gateway.
• Check how overage or extra compute is billed.

Dedicated-node tests

• Record the physical region and selected resource configuration.
• Verify whether the node has one instance or a redundant topology.
• Measure sustained throughput, not a short burst alone.
• Verify retention or archive configuration directly.
• Test recovery after node restart or maintenance.
• Verify whether storage growth changes the monthly invoice.
• Confirm whether provider-level failover falls back to shared infrastructure.

Never load-test a public shared endpoint without authorization.

The official NEAR provider documentation explicitly cautions against load testing shared public infrastructure.

Performance tests should run against infrastructure you operate or a provider endpoint whose operator has authorized the workload.

An archival RPC is not automatically an indexer

Historical node data and indexed application data solve different problems.

An archival node makes old protocol data queryable.

An indexer organizes that data for application-specific search.

Suppose you need every transaction that interacted with a particular contract over two years.

A raw archival RPC gives you the historical building blocks.

You may still need to iterate through blocks, chunks and execution outcomes to construct the dataset.

An indexing service can pre-process those relationships and expose them through a query-optimized API or database.

Do not purchase an archive node assuming it automatically provides every account-history or analytics query your product will eventually need.

Likewise, do not assume an indexer can replace native RPC for contract-state reads, transaction submission or every protocol method.

Large applications often use both layers.

Migration and exit constraints matter before you integrate

NEAR's native JSON-RPC interface gives teams a useful portability advantage.

If the application uses standard methods directly, moving from one provider to another can often begin with an endpoint change.

That does not make providers perfectly interchangeable.

Historical retention differs.

Gateway error formats differ.

Batch-query support can differ.

Rate limits differ.

Experimental method exposure can differ.

Provider-specific indexing products can differ dramatically.

Keep an internal RPC adapter

Do not scatter provider URLs and authentication logic throughout application code.

Use one infrastructure layer that exposes the NEAR operations your product actually needs.

For example, create internal functions for finalized block retrieval, current account state, historical state, transaction submission and transaction verification.

That adapter can switch between providers without forcing every business module to understand each provider's authentication scheme.

Preserve chain-native identifiers

Store block hashes.

Store block heights.

Store transaction hashes.

Store sender account IDs.

Store receipt IDs when they matter to your application.

Do not store only a provider-specific webhook ID or analytics-record ID.

The chain-native identifier is what allows you to reproduce evidence after changing providers.

Be cautious with proprietary convenience APIs

A provider-specific indexed endpoint can eliminate months of engineering.

That can be a rational dependency.

But the migration cost should be understood before the product grows around it.

If a proprietary endpoint becomes central, preserve enough raw NEAR evidence to rebuild the business record elsewhere.

Portability is not the goal at any cost.

Deliberate portability is.

Use an independent path for high-value transaction verification

A second provider is most valuable when it removes uncertainty.

You do not need to duplicate every ordinary frontend call across two providers.

That doubles cost and can create inconsistent results when the endpoints answer from slightly different chain heights.

Use redundancy where failure has material consequences.

For example, a payment backend can send ordinary reads to its primary provider while retaining a second endpoint for transaction-status verification.

If the primary provider times out after transaction submission, the application can query the known transaction through the secondary provider.

If both endpoints agree on the finalized result, operational confidence improves.

Historical redundancy can be separate from live redundancy

Your primary shared provider may be excellent for current state but lack deep history.

Your secondary historical provider may be slower but archival.

That can be an efficient architecture.

Not every provider needs to solve every layer.

The important requirement is that routing logic knows which endpoint is authoritative for which workload.

When running your own NEAR node becomes rational

Self-hosting gives you control.

It also gives you responsibility.

A managed provider handles node deployment, monitoring, maintenance, storage planning, software upgrades and much of the networking complexity.

A self-hosted nearcore deployment transfers those responsibilities to your team.

This can be justified when infrastructure itself becomes part of your competitive advantage or compliance perimeter.

Data sovereignty

A regulated organization may not want customer-linked query patterns leaving its own environment.

Running the node internally can reduce reliance on a third-party gateway.

The organization still needs to secure its own node and network perimeter.

Deterministic retention

If the application must guarantee that certain historical data remains available, operating the relevant infrastructure directly can remove ambiguity around provider retention policies.

This does not eliminate the engineering challenge of history.

It makes the challenge yours.

Sustained scale

A team performing hundreds of millions of reads can reach a point where owning capacity is cheaper than paying per request.

The break-even calculation needs to include cloud hardware, storage, network bandwidth, engineers, monitoring and incident response.

Raw cloud compute alone is not the true self-hosted cost.

Operational competence is part of the requirement

If no one on the team can diagnose synchronization issues, disk pressure, database problems or nearcore upgrades, self-hosting can create more risk than it removes.

A managed dedicated node can provide isolation without transferring every operational responsibility internally.

Security boundaries for NEAR RPC infrastructure

Most NEAR RPC reads expose public blockchain data.

Provider credentials still need protection.

An unrestricted API key can be abused to consume your quota or generate a large bill.

Infrastructure logs can also reveal which accounts and contracts your business monitors.

Keep production API keys server-side where practical.

Use domain restrictions, IP allowlists or scoped credentials when the provider supports them.

Separate development and production credentials.

Rotate exposed keys.

Monitor usage for unusual traffic patterns.

Signing keys are a separate security class

The RPC provider does not need your account's private key.

Construct and sign the transaction inside your own trusted environment.

Then send only the signed transaction payload to the RPC endpoint.

An infrastructure API key authorizes RPC usage.

A NEAR private key authorizes blockchain actions.

Do not treat them as equivalent secrets.

Where TokenToolHub fits in a NEAR workflow

TokenToolHub should not be inserted into a native NEAR workflow where its underlying analysis model does not apply.

The Transaction Decoder is designed for supported EVM networks and their Ethereum-compatible transaction model.

The Token Safety Checker similarly analyzes supported EVM smart contracts.

Native NEAR uses a different transaction, receipt and WASM contract model.

Use the NEAR explorer, NEAR RPC methods and network-native tools for NEAR account, transaction and contract evidence.

If the same application also interacts with an EVM network supported by TokenToolHub, use TokenToolHub for that separate EVM-side investigation.

Clear network boundaries produce better evidence than pretending one scanner can accurately interpret every chain.

Disqualifiers for a NEAR RPC provider

NEAR RPC provider buyer checklist

Which NEAR infrastructure model fits which buyer?

Conclusion: choose NEAR RPC infrastructure by state depth, execution evidence and total operating cost

The most useful NEAR RPC providers comparison begins by refusing to treat every RPC request as the same workload.

A request for current finalized account state is not the same as a historical contract-state query.

A block lookup is not the same as a full archival backfill.

A transaction broadcast is not the same as finalized execution.

A parent transaction is not always the complete business outcome because NEAR can create asynchronous receipts.

A shared gateway is not operationally equivalent to a dedicated node.

The provider decision should preserve those differences.

Start with current state.

Run a finalized block request.

Run a finalized account query.

Call the contracts your application actually uses.

Confirm that the endpoint behaves correctly under the ordinary path.

Then test history independently.

Select old block heights.

Retrieve their blocks.

Retrieve chunks.

Query old state where your product depends on it.

Record when a standard endpoint stops answering and when the archival endpoint becomes necessary.

This creates a measurable definition of archival depth.

Do not accept a provider-wide archive marketing statement as proof that NEAR archival state is included in your plan.

Network-specific availability matters.

The official NEAR provider directory is particularly useful here.

It currently marks some providers as archival and others as non-archival.

NOWNodes and GetBlock both support NEAR RPC, but the official directory currently does not mark their standard NEAR endpoints as archival.

That does not mean the companies cannot provision a separate archival configuration.

It means the buyer should verify the exact product instead of assuming.

QuickNode is currently marked archival for NEAR Mainnet and Testnet, which gives it a clear role in a history-sensitive comparison.

FASTNEAR's archival offering is listed as paid-only.

NEAR's own archival RPC is public and useful for verification, but the documentation identifies it as severely rate limited.

Those differences should become test cases rather than marketing conclusions.

NOWNodes is attractive when the operational problem is broader than NEAR.

A team already using one infrastructure vendor for multiple networks can reduce API-key sprawl and vendor management.

Its current free NEAR entry point gives developers enough capacity to validate normal RPC compatibility before purchasing a larger plan.

If archive history becomes necessary, confirm the actual NEAR retention configuration before moving the workload.

Chainstack provides a different infrastructure model.

Its platform combines free shared access, paid request tiers, archive request units, dedicated-node compute and self-hosted orchestration across supported networks.

That breadth is useful to teams that expect their infrastructure model to evolve.

A project can begin with inexpensive shared access.

It can move toward greater isolation if traffic grows.

It can move toward flat-fee capacity when request billing becomes undesirable.

The important step is confirming how those platform-wide capabilities map to NEAR at the time you provision the service.

GetBlock is another credible multichain route.

Its shared service uses compute-unit billing.

Its dedicated product gives customers isolated infrastructure and broader customization options.

The company has also expanded archive support across selected chains.

NEAR archive availability should still be confirmed explicitly because archival rollout is network-specific and the current official NEAR directory does not mark its standard endpoint as archival.

That type of qualification is not a weakness in the comparison.

It is what prevents a buyer from paying for a feature that exists elsewhere in the provider catalogue but not on the chain they actually use.

Finality should be handled with the same precision.

NEAR's current transaction RPC makes execution milestones explicit.

A transaction can be queued.

It can be included in a block.

It can execute optimistically.

Its block can become final.

Its non-refund receipts can finish.

Eventually the transaction and every receipt, including refunds, can reach the FINAL milestone.

These states have different latency.

They also support different business decisions.

A game interface can show progress early.

An accounting system should prefer stronger finalized evidence.

A cross-chain system should define carefully which NEAR execution state is sufficient before triggering activity elsewhere.

Provider benchmarks must use the same milestone.

Otherwise latency comparisons are meaningless.

Receipt handling deserves equal attention.

NEAR contract execution can fan out into asynchronous receipts.

A complex cross-contract interaction cannot always be summarized by the parent transaction alone.

If the application must debug execution or prove the complete result, test transaction and receipt retrieval deliberately.

Use stable RPC methods for core business logic where possible.

When experimental receipt methods are necessary, isolate them behind your own infrastructure adapter so a future API change does not spread through the entire application.

Dedicated hosting should be considered only after the workload is understood.

If the application is comfortably inside shared limits, there is little economic reason to buy isolated capacity.

If an indexer performs historical reads continuously, request-metered archive access can become expensive.

If an exchange regularly hits throughput limits, shared infrastructure may create operational friction.

If a regulated business needs fixed ingress, private topology or region control, dedicated hosting can become necessary regardless of traffic.

Measure those requirements.

Then compare them with the real price of dedicated compute and storage.

Do not forget the second endpoint.

High-value transaction workflows benefit from an independent verification path.

If the primary provider times out, query the transaction through another provider before constructing a replacement action.

If the primary provider cannot retrieve an old block, use an archival provider to determine whether the data is actually missing from the network or only from that endpoint.

Redundancy does not mean sending every request twice.

It means preserving the ability to resolve uncertainty.

Total cost is the final filter.

Count the provider plan.

Count archival traffic.

Count receipt and transaction-status calls.

Count redundant verification.

Count storage.

Count dedicated compute.

Count monitoring.

Count engineer time.

Count migration work.

A $49 plan can be expensive if it requires constant workarounds.

A dedicated node can be inexpensive if it replaces enormous per-request archive bills and saves engineering time.

A public endpoint can be perfect for a prototype and irresponsible for a payment business.

The correct answer changes with the application.

For broader infrastructure planning, compare this NEAR-specific methodology with TokenToolHub's multi-chain node hosting analysis, the dedicated versus shared RPC guide and the broader node hosting guide for blockchain developers.

For the actual purchase, keep the test chain-specific.

Run one current finalized block request.

Run one current account query.

Run multiple historical block requests.

Run one historical state query.

Retrieve a historical chunk.

Submit one controlled Testnet transaction.

Check it at the same wait_until milestone on every provider.

Follow its receipt outcomes if your application needs them.

Then calculate the cost of repeating that workload at production volume.

That is a more defensible purchasing framework than choosing whichever provider publishes the largest request number or the lowest entry price.

FAQs

References and primary documentation

• NEAR official RPC provider directory
• NEAR block and chunk RPC documentation
• NEAR account and contract query documentation
• NEAR transaction submission, finality and receipt documentation
• NEAR JSON-RPC documentation
• NOWNodes NEAR Protocol API documentation
• NOWNodes supported methods and network documentation
• NOWNodes current pricing and request allowances
• Chainstack platform documentation
• Chainstack current platform pricing
• Chainstack dedicated-node infrastructure
• Chainstack archive-data infrastructure
• Chainstack Unlimited Node infrastructure
• GetBlock current shared RPC pricing
• GetBlock shared node infrastructure
• GetBlock dedicated node infrastructure
• GetBlock supported blockchain node catalogue
• GetBlock archive mode documentation

RPC-provider pricing, archival availability, request limits, compute-unit weights, network support, experimental methods, dedicated-node configurations and service-level commitments can change. Verify the exact NEAR Mainnet or Testnet product before deployment. Test archival depth with known old blocks and state queries rather than relying on a generic archive label. For settlement-sensitive transactions, choose finality and receipt requirements according to the actual business risk. This guide is technical research and does not constitute financial, investment, custody or legal advice.