On this page
Ankr supplies infrastructure that applications use to communicate with blockchains. Its current documentation centers on RPC access, application programming interfaces, staking services and chain infrastructure. Its role is to provide the access layer between blockchain networks and the applications built on them.
The service behind an application
A wallet may need a balance, a game may need an NFT ownership check and a trading application may need to submit a signed transaction. Each task requires access to blockchain data or a node. Ankr provides remote procedure call, or RPC, endpoints that developers can use instead of maintaining every node themselves.
That arrangement lowers an application team’s infrastructure burden, but it introduces dependencies. Endpoint availability, rate limits, historical-data coverage and accurate responses all affect the experience. Access to many chains is useful only when the specific methods a developer needs are supported reliably.
Where the ANKR token fits
ANKR is distinct from the blockchain assets that Ankr’s services help people access. Ankr’s tokenomics documentation describes a supply of 10 billion ANKR. The token has an infrastructure-related role rather than representing ownership of a conventional cloud company.
Token staking is also different from buying a service subscription. Ankr documents a mechanism for delegating ANKR to full-node providers. Full nodes serving application requests do a different job from the consensus validators that produce or attest to blocks on proof-of-stake chains.
Do not confuse three kinds of staking
Ankr offers multiple staking products. Staking ANKR concerns the ANKR token and its provider mechanism. Delegating a chain’s native asset concerns that chain’s validator rules. Liquid staking involves receiving a token representing a staking position, which may then be used elsewhere.
A return displayed for one product cannot be transferred to another. The underlying asset, reward source, unstaking process and smart contracts can all differ. Ankr’s documentation should therefore be read at the product level, rather than treating the word staking as a single promise.
Liquid staking adds another layer
A liquid staking token can allow a holder to transfer or use a position while the underlying asset remains staked. Its exchange price may nevertheless differ from the value eventually obtainable through redemption. Liquidity in a trading pool is not the same as immediate access to the underlying asset.
Using that token in a lending market or another decentralized application adds the second application’s contracts and liquidation rules. The combined position may contain risks that are absent from simply holding ANKR or from directly delegating a native coin.
Assess infrastructure and token economics separately
An application can benefit from Ankr infrastructure without its users knowing which provider is serving requests. That makes customer demand and technical reliability relevant measures of the service. Neither measure alone establishes how much value accrues to a token holder.
Useful questions include which services require ANKR, how rewards are funded, what expenses providers incur and what conditions apply when withdrawing a stake. A fixed token supply does not settle those questions. It also does not prevent existing holdings from becoming available for sale.
Practical checks before using an Ankr product
Developers should review authentication, supported chains, request limits and fallback providers for their chosen endpoint. A successful balance lookup is not a full reliability test. Applications handling money need error handling when a provider is slow, unavailable or returns data from an unexpected chain.
Token holders should identify the precise asset and network before approving any contract. ANKR, ankrETH and other branded staking receipts are not interchangeable. Ankr’s infrastructure business and the economics of a particular token position should be evaluated separately.
A provider is not the application itself
Ankr can deliver infrastructure to an application without controlling that application’s contracts or user accounts. If an application fails, identifying the responsible layer matters: the endpoint may be functioning while the contract is defective, or the contract may work while the interface is unavailable. An infrastructure partnership should therefore never be treated as a security endorsement of every application using it. The same distinction applies to tokens that an application displays through an Ankr data service.