Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
CPSR.cloud provides granular access to the auction data, which is more convenient than parsing the results of the state_get_auction_info Casper RPC API method, through the following APIs:
For example, fetching account delegations can be done with the following API request:
Often, when looking at the fiat value of a native token amount, we want it to be converted using the rate that was relevant at the moment when the corresponding action happened. CSPR.cloud REST API provides the possibility to do so when requesting data having the timestamp property and when it's semantically acceptable To learn more, visit the page.
In the example below, we include the USD to CSPR rate in the account delegation rewards response by calling the rate with the USD currency ID as the argument in the includes query param:
Fungible tokens are one of the most used abstractions implemented on blockchains. CSPR.cloud allows dApp developers to focus on the core logic of their applications by tracking the token activity on the Casper Network for compatible tokens and providing APIs to query that data. CSPR.cloud provides a possibility to:
Below is an example, that demonstrated fetching list of tokens owned by an account. Note, that we are about the contract package using the includes query parameter.
CSPR.cloud REST API provides the possibility to include related entities in responses. An entity is called related if its identifier is present among the requested entity's properties. For example, the entity is related to the entity because the latter has a deploy_hash property identifying the deploy that produced the action. Not all related entities can be included in responses; the ones that can are listed in the "Optional properties" section for the corresponding entity or endpoint page.
Related entities are included the same as other , using the includes query param. For the related entity to be added to the response, its name has to be specified in the list of includes.
Including related entities makes it possible to fetch the required data in one request, simplifying the integration and reducing latency, which is especially useful when processing paginated responses. Continuing the and example, one may need to know the deploy caller account when processing the NFT Action data. By including the Deploy object in the NFT Action response, all the required information can be received in just one API call instead of requesting the deploy data for each NFT action in the list:
Accounts on Casper Mainnet and Testnet networks have the possibility to self-identify themselves in a decentralized with the smart contract. Many validators and contract owner accounts provide information about themselves to increase trust on the network.
CSPR.cloud REST API allows including account information to simplify the integration with the standard for dApps developers. Typically, account info standard data can be included in responses that contain account identifiers like account hashes or public keys.
In the example below, we'll include validator account info data in the account delegations API response. To demonstrate the possibility of , we'll request only the owner name and logo properties of the account info object.
CSPR.cloud indexes and normalizes on-chain data to improve developers' experience when building on the Casper Network. Below are examples that demonstrate some of the possibilities CSPR.cloud offers. For the full list, please see the API reference pages.
Receive related entities in a single response to minimize the number of network requests needed to load the data
Include CSPR rates that were relevant at the moment of a transfer, contract call, or reward creation
Include account info information provided by the account owner in the responses that contain account identifiers
Query granular pieces of the auction data that interest you, like all account delegations or a list of the current era validators
Query fungible token data relevant to your dApp
Query NFT movements and ownership from CSPR.cloud while focusing on the core business value of your application
Check aggregated historical contract costs to provide your users with better pricing
Translate account hashes to the corresponding public key for accounts that were observed on the network
Translate account main purses to the account public keys to better trace the fund movements
Subscribe to contract-level events the contracts from your dApps emit to track and aggregate the off-chain state for a better user experience
Non-fungible tokens, or NFTs, became one of the most popular use cases in the current blockchain world. CSPR.cloud keeps track of all NFT contracts compatible with the CEP-47 and CEP-78 NFT standards on the Casper Network. CSPR.cloud provides a possibility to:
and more
Moreover, CSPR.cloud not only tracks on-chain NFT data but also fetches the off-chain metadata for you, which can be particularly slow when the metadata is stored on IPFS. Below is an example that demonstrated fetching NFT tokens for the CasperPunks contracts, which is a CEP-78 smart NFT contract that stores the token metadata on IPFS:
Note the offchain_metadata property, which contains the off-chain token metadata.
Similarly to "de-anonymizing account hashes", CSPR.cloud can also "de-anonymize" account purses which can be used as the only transfer source or destination parameter. Let's have a look at transfers that happened in this deploy for example.
The to_account_hash was not specified in the transfer parameters. Let's "de-anonymize" it by including the to_purse_public_key optional property:
Note the to_purse_public_key property that was added in the second response. It contains the public key that corresponds to the account having the to_purse as its main purse. Please check Transfer Optional Properties to learn about all the optional data that can be included in the Transfer API responses.
While accounts are known to be recognized by their public keys, internally on-chain, they are uniquely identified by fixed-length accounts hashes derived from those public keys. Because of that, in certain contexts, we may know the account hash but not the public key. CSPR.cloud maintains the mapping between account hashes and the corresponding public keys to be able to "de-anonymize" the former when needed by requesting the public key as an optional property.
Let's have a look at the Transfer API, for example. The Transfer object only provides the recipient account hash:
Let's "de-anonymize" the recipient of the transfer above by including the to_public_key optional property:
Note the to_public_key property that was added in the second response. It contains the public key that corresponds to the account hash specified in to_account_hash. Please check Transfer Optional Properties to learn about all the optional data that can be included in the Transfer API responses.
CSPR.cloud REST API provides the possibility to resolve CSPR.name names either directly by calling the CSPR.name Resolution API or by including CSPR.name names as optional properties.
At the moment of writing this page (August 27th, 2024), the CSPR.name is not launched yet. That's why we added a test CSPR.name for the Faucet account to allow developers to implement and test their CSPR.name integration before the launch.
Direct CSPR.name to account hash resolution can be done using the Get CSPR.name resolution API and is recommended for the situations when you receive the name outside CSPR.cloud and want to resolve it to the corresponding account hash:
In situations, when you want to resolve account hashes to the corresponding CSPR.name names, in most of the cases it's possible to do by requesting CSPR.name as optional property in the includes query parameter:
If you want to find the primary CSPR.name for an account, you can include it in the Get account API:
Web3 comes with a new storage architecture dApps have to embrace. In traditional Web2 applications, users don't interact with the storage directly. It's typically hidden behind the API layer.
Blockchain is data storage that provides data we can trust, and that trust requires no middleman between the users and the changes in the data. In this setup, dApps have to observe the on-chain activity to display the relevant state to the end users. While this can be done by polling the network state using the CSPR.cloud REST API or CSPR.cloud Casper Node, CSPR.cloud is also prepared to assist dApps developers with observing the on-chain activity with its Streaming API.
To demonstrate it in action, let's create an NFT contract using the Testnet version of CSPR.studio and observe its activity on the network. Navigate to the My NFT collections page and create a new collection. To listen to the contract-level events emitted by our contract, we'll need to know its hash. Copy the hash of the deploy that created your NFT collection on the last step of the collection creation process and query the contract it deployed to the network using the Contract REST API:
Knowing the contract hash, we can subscribe to the contract-level events emitted by our newly created contract using the Contract-level events Streaming API. For this example, you'll need to install the wscat NPM utility.
Now, let's go back to CSPR.studio and mint an NFT. Once the mint deploy is executed on the network, our WebSocket connection will receive a message containing the Mint event data, as well as the token data encoded as a JSON string:
Note the extra property that provides technical information, such as deploy_hash, event_id, and the deploy execution transform_id, which can be used to link the event data to the corresponding deploy properly.
