Blockchain infrastructure

Blockchain infrastructure
for Web3 and crypto products

Private nodes, RPC endpoints, monitoring, security and scaling for Bitcoin, Ethereum, TON, Solana, Polygon, BNB Chain and other networks — a managed access layer instead of a separate platform team for every protocol.

4
Networks in production
16 ms
Median response
99.99%
Endpoint uptime
9
Regions

The stack behind one address

One endpoint, four layers of operations

live
  1. Your applicationyour side

    timeouts, retries, reorgs

  2. rpc.settla.net/sol/mainnet
  3. operated by Settla
    1. Endpoint

      key, limits, environments

    2. Routing

      pool health, rotation

    3. Nodes

      full and archive, upgrades

  4. Solana network

    a slot every 0.4 s

    302,847,119

Access protocols · HTTP · WS · gRPC

Components

Blockchain infrastructure components

Blockchain infrastructure includes more than a node server. Production systems need endpoints, monitoring, access control, upgrades, capacity planning and failure handling.

  • Nodes

    Full or archive clients for supported mainnets and testnets.

    full · archive

  • Endpoints

    HTTP, WebSocket and network-specific interfaces for applications.

    HTTP · WebSocket · gRPC

  • Monitoring

    Head lag, method checks, errors, latency and resources.

    head lag · p95 · error rate

  • Operations

    Updates, capacity planning, incident response and recovery.

    upgrades · capacity · on-call

The boundary runs through the endpoint

Settla operates

  • Node sync and health
  • Client software upgrades
  • Rotation and draining
  • Capacity planning
endpoint

Your application handles

  • Timeouts and retries
  • Rate limit handling
  • Chain reorganisations
  • Idempotent operations

Monitoring and security

A node returns 200 while lagging behind the chain

An availability check sees a live process, an open port and a valid response. It does not see lag at all — worse, a stalled node answers faster than a healthy one, because it has nothing to catch up on. Switch the check and watch what the client receives meanwhile.

both nodes in sync

Pool behind /sol/mainnetSolana · a slot every 0.4 s

  • sol-fra-01eu-centralHTTP 200302,847,181in sync
  • sol-ams-01eu-westHTTP 200302,847,181in sync

The client read stale state for 16 s

  • network blocks
  • no new blocks
  • 26 s window
0
Node lag, slots
current
Client state age
0%
Requests to the stale node
2 / 2
Nodes in rotation
  • Check height and finality

    Local height is compared against an independent source, not against itself. Alongside it go control RPC methods, error rate, p95/p99 and free resources.

  • A threshold, not the first miss

    One second behind the chain is a hiccup, not an outage. A node leaves rotation on a threshold: 15 slots, roughly 6 s on this network.

  • An alert points to a runbook

    A notification without a runbook only records the problem. On-call needs the next step, not a description of what happened.

Access control is the other half of the job

Credentials per environment
Separate keys for production, staging and local development, with rotation and usage audit.
Least privilege
IP and domain restrictions where they are supported, plus protected secret storage.
Wallet keys stay with you
Private keys are never handed to a node provider without a separately justified custody architecture.

Scaling

Scaling Web3 workloads

Scaling starts with splitting the load, not with adding nodes: indexers, user reads and transaction writes must not compete for one quota.

One quota for everything

A backfill drains the limit, and a transaction waits in line behind it.

  • User reads
  • Transaction writes
  • Indexers and backfill

Lanes separated

Each lane gets its own limit, its own cache and its own queue.

  • User readscache safe reads
  • Transaction writesreserved quota
  • Indexers and backfillqueue and cap heavy methods
  • User reads

    Balances, statuses and history in the interface. Numerous, small and mostly safe to cache.

    eth_call · getBalance

  • Transaction writes

    A rare but critical lane — the first one to suffer when someone else drains the quota.

    eth_sendRawTransaction

  • Indexers and backfill

    Background work with heavy methods. It needs volume, not milliseconds.

    eth_getLogs · trace_block

  • Several nodes and health-aware routing

    Growth adds nodes, and routing accounts for their health — the health measured by block height rather than by HTTP status.

  • A reorg is not an application error

    A block you already read may stop being part of the chain. Finality differs between networks, so retries have to be idempotent.

Choosing a model

Self-hosted vs managed infrastructure

Both models work. The difference is not reliability but who carries the on-call rota and what the next network costs to launch.

Control

01
Self-hosted
Full OS and network control
Managed provider
Agreed service configuration

Operations

02
Self-hosted
Customer team, around the clock
Managed provider
Provider handles core node operations

New networks

03
Self-hosted
A new deployment project
Managed provider
Connect an available endpoint

Cost

04
Self-hosted
Servers, engineers, on-call, redundancy
Managed provider
A plan or a custom configuration

Best fit

05
Self-hosted
Special requirements and a mature platform team
Managed provider
Product focus and faster multichain access

Blockchain infrastructure for business

Blockchain infrastructure for business is not a one-time setup but an operational layer that performs reliably around the clock. Companies integrating blockchain into payment flows, custodial services or compliance pipelines need predictable infrastructure.

Agreed limits
Isolated endpoints per environment and request ceilings known in advance, not discovered during an outage.
Clear upgrade procedures
Client upgrades and network hard forks follow a plan instead of arriving as a Friday surprise.
Documented incident protocols
Lag monitoring, response processes and post-incident reviews instead of a chat thread.

Use cases

Use cases for Web3 products

The same access layer serves products with very different load — from a wallet making a dozen calls per screen to an indexer reading history for months.

  • Wallets and payment products

    Several networks in one interface: balances, transfers, statuses and credit notifications.

    Learn more
  • CEX/DEX and deposit systems

    Deposit and withdrawal monitoring, where a data mismatch costs money directly.

    Learn more
  • DeFi, NFT, gaming and smart contracts

    Reading state, calling contracts and broadcasting transactions from the application.

    Learn more
  • Explorers, indexers and analytics

    Full history of blocks, logs and traces for dashboards and investigations.

    Learn more
  • Compliance and risk analytics

    Address screening, flow tracing and corporate reporting.

    Learn more

Getting started

Blockchain infrastructure for Web3 applications

Start from business-critical operations and application SLOs: which data is read, how quickly transactions must be sent and what event loss is acceptable.

A provider handles node operations, but responsibility remains shared: the application must handle timeouts, rate limits, reorgs and retries correctly. This approach produces more resilient crypto infrastructure than relying on a single supposedly infallible endpoint.

  1. Name the critical operations

    What actually breaks for the user when an answer arrives a second late — or never arrives.

  2. Fix the networks and methods

    Networks, environments and methods including the heavy ones: both limits and cost follow from that list.

  3. Decide on depth

    Whether you need archive and tracing. That is a separate class of nodes, not a checkbox in a plan.

  4. Describe failure behaviour

    Timeouts, retries, fallback routing and reorg handling live in application code.

FAQ

Blockchain infrastructure FAQ

Infrastructure shouldn't be the thing slowing you down.

Free to start. No credit card required.