Alchemy Explained: Blockchain APIs, Compute-Unit Pricing and Operational Risks

Alchemy is a blockchain developer-infrastructure company. Its services let applications read blockchain data, submit transactions and use additional data and wallet tools without building every supporting system themselves. It is not the consensus network being queried, and its developer API key is not the private key controlling a user's cryptocurrency.

The distinction matters because hosted infrastructure can simplify development while introducing operational dependencies. A working API does not prove an application's contracts are safe, and a stalled API response does not necessarily mean the underlying blockchain has stopped.

Who is behind Alchemy, and what customers use it for

Alchemy was founded by Nikil Viswanathan and Joe Lau. Its company materials describe a developer platform spanning blockchain access, data and application-building tools. This is the infrastructure company Alchemy, not the separate payments business Alchemy Pay.

The official Alchemy platform is aimed at developers and organizations building products that interact with blockchains. Potential uses include wallets, transaction interfaces, analytics applications and services that need notifications when specified on-chain activity occurs.

A small application might use a hosted endpoint to query a balance. A larger system might need historical data, indexing, transaction submission, webhooks and support commitments. These are different workloads, so the company should not be evaluated through a single advertised request count.

RPC access, indexed data and notifications do different jobs

A remote procedure call, or RPC, asks a node-facing service to perform a defined operation. That might mean reading a block, checking a balance or submitting an already signed transaction. The blockchain still determines whether a submitted transaction is valid and when it is included.

Indexed APIs organize information in a form applications can use more directly, such as token holdings or historical transfers. They can save a developer from scanning and maintaining the same dataset independently, but they introduce questions about indexing delay, completeness and how particular fields are defined.

Webhooks reverse the interaction: instead of continually polling, an application receives a notification when matching activity is detected. The receiving system still needs to authenticate messages, handle retries and avoid applying the same business action twice.

These differences are easier to see against Ethereum's underlying network model. An infrastructure provider offers access and processing around the chain; it does not replace the chain's rules with a customer-service promise.

Compute units are not a raw count of requests

Alchemy bills much of its platform usage through compute units, or CUs. Different API operations carry different weights, so one request is not necessarily equivalent to another. A lightweight lookup and an expensive historical query can consume different amounts.

That creates two separate planning questions. Monthly consumption affects the bill, while throughput limits affect how much work the application can request during a short interval. An application can fit inside a monthly allowance and still hit a burst limit during a busy launch.

Developer teams should estimate costs using their actual mix of methods, retry behavior and peak load. Multiplying visitors by an arbitrary average request cost can be a useful early sketch, but it is not a substitute for measuring the application once its workflow is defined.

Published prices as of October 16, 2026

Alchemy's pricing page listed a Free plan with 30 million CUs per month and a Pay As You Go rate of $0.525 per million CUs when checked on October 16, 2026. The paid plan's published terms charge for all usage under that plan, rather than automatically subtracting the Free plan's allowance.

For a hypothetical application consuming 120 million billable CUs, that usage rate produces $63 before additional services or capacity charges. The arithmetic is an illustration of the published unit price, not a quote for a complete application.

Additional peak capacity, specialized data delivery, gas sponsorship and premium support can have separate pricing. Enterprise arrangements may use custom terms. A team should therefore check the specific product and plan rather than assuming the base CU rate includes every feature shown on the website.

Blockchain transaction fees are separate again. An API subscription can pay for the infrastructure handling a request while the submitted transaction still needs network gas. The fee guide explains that distinction.

API keys require controls even when they do not hold coins

An application API key can authorize consumption of a paid service. Exposing it can allow someone else to exhaust limits or increase costs even when the key cannot directly spend wallet funds. Administrative access keys can carry a different and potentially broader set of privileges.

Alchemy documents allowlists and scoped access controls. Teams should understand their limits: a domain restriction is not equivalent to keeping a backend secret private, and controls designed for one deployment pattern may not address another. Separate applications and environments can help limit the scope of an accidental disclosure.

The developer must also distinguish infrastructure authentication from transaction signing. Reading public data or relaying a signed transaction is different from adopting a wallet-management service that participates in key handling. Each additional product needs its own assessment of who can authorize actions and recover access.

Hosted infrastructure does not remove outage planning

A production application should decide what it does when requests time out, responses disagree or a provider reaches a limit. Blindly repeating every operation can create confusing user experiences or excessive traffic. Retrying a transaction submission also requires understanding whether the original transaction may already have reached the network.

Independent providers or a self-operated node can offer alternative access, but failover is not simply switching a URL and assuming identical behavior. Services can differ in indexing, supported methods, error handling and their view of the latest chain state.

The problem becomes more layered with Layer 2 networks. A provider can successfully return a sequencer's recent state while a transaction remains at an earlier settlement stage. Applications need confirmation policies appropriate to the underlying network, not merely an HTTP success response.

Privacy and dependence deserve a place in the budget

A hosted service can observe requests sent to it, including address queries and connection information. Blockchain data being public does not make every application's usage pattern public by necessity. Teams should examine the provider's data terms and avoid sending unnecessary sensitive information.

Vendor-specific APIs can speed development while increasing migration work later. A sensible design identifies which features are standard and which depend on proprietary indexing or service behavior. Exportability, monitoring and clear internal documentation can matter as much as the initial integration effort.

Alchemy can reduce the operational work of connecting an application to blockchains. It cannot decide the application's threat model, protect an exposed recovery phrase or guarantee an economically correct contract. The appropriate evaluation combines measured workload costs, required features, data handling and a credible plan for what happens when any dependency fails.