Shared node infrastructure for top blockchains using JSON-RPC.
Retrieve blockchain data, balances, and transactions
Detailed blockchain history and transaction data for any address.
Access to full transaction data on all transactions & addresses
Full smart contracts metadata, including token symbols & token names
Dedicated nodes infrastructure for leading blockchains using JSON-RPC
Address validation, encoding & cryptographic tasks optimizations
Broadcast and verify transactions with real-time monitoring
Sync and manage HD wallets, keys and addresses
Precise blockchain transaction fee estimates based on transaction priority
Prepare EVM transactions, including token transfers
Access to full transaction data on all transactions & addresses
Real-time notifications for events on top blockchains. Response under 100ms.
Get access to unified market data using REST APIs from top crypto exchanges.
Test EVM transactions, optimize gas fees and identify security flaws
Every cryptocurrency wallet is composed of a public address and a private key. These keys are just a string of random numbers. The public address can be shared with other people and they can use it to send funds to it. The private key should never be shared, as the owner of the private key has access to the funds and can send them to other wallets.
Originally, blockchain generated a new private key and public key every time funds were to be sent to a Bitcoin wallet. This made it increasingly difficult to back up the wallet information, as users had to back up their Bitcoin wallets every time they received funds in them. Over time there were many attempts to improve this system, but the real breakthrough came with BIP32 (Bitcoin Improvement Proposal), which marked the creation of the Hierarchical Deterministic Wallets.
An HD Wallet automatically generates a structure of child private and public keys. This structure is hierarchical, as the name suggests since these keys are obtained from a single master – parent- seed (see image below). This solved the issue of users having to keep generating their own wallets. It also makes it easy to back up and restore backups, with the use of this single seed.
Every child key pair can define an xPub (Extended Public Key). As the name suggests, an Xpub doesn’t contain information about private keys, but only public ones. This means that an xPub will not give you access to the funds in a wallet, but the user can also view the child wallet’s addresses, transactions, and balances. You can think of it as a read-only view of a wallet. Although the Xpub doesn’t give you spending abilities, only to view wallet’s information, it’s highly risky to share the key with anyone.
After the adoption of SegWit, theBIP49 standard gave origin to the yPub. A yPub key is the same as an xPub key. However, it follows the new standard and has an address type P2SH-P2WPKH. yPub is for backward-compatible SegWit Wallets.
After the xPub and yPub, the newest Public Extended Key is zPub. Just as its predecessor the zPub follows the BIP49 standard, but the address type is P2WPKH. zPub is for native compatible SegWit wallets.
An easy way to differentiate between xPubs, yPubs and zPubs is that xPubs addresses always start with “1”, the yPub addresses always start with “3”, whilst zPub addresses always start with “bc1”.
Crypto APIs’ Blockchain APIs not only supports HD wallets but also allows you to create a random extended public key (based on your password), xpriv and wif.
Two other endpoints allow you to get the Change and Receive addresses associated with the xPub specified in the query.