Flow of operations

Before diving into the specification and documentation, we recommend reviewing the high-level diagrams below to gain some familiarity with the functionality of the Rosetta APIs.

The Rosetta APIs are organized into two distinct categories, the Data API and the Construction API. The Data API retrieves data from a blockchain network. The Construction API constructs and submits transactions to a blockchain network.

Data API

Construction API

Unlike traditional SDKs, Construction API implementations are fully stateless, can perform construction offline (when metadata like an account nonce is pre-fetched), and never have access to private key material.

Simplified Flow using a Higher-Level Interface

Many developers may not have security constraints that dictate that construction must occur offline, or that they use their own detached signer (making the previously described flow much more cumbersome than other transaction construction and signing SDKs).

Fortunately, it is possible (and encouraged) to build higher-level interfaces on top of these low-level endpoints to simplify development for integrators. For example, an interface developer may wish to automatically fetch metadata during their call to construct a transaction so users would not even know there are multiple interactions occurring. One could also provide a signing library with their higher-level interface so users do not need to use a detached signer. Here is an example of a simplified flow:

Why build a higher-level interface on this Construction API instead of using existing SDKs? Any interface built on top of the Construction API could support the construction of transactions on any blockchain that supports Rosetta with no modification. For example, you can build a Coinbase Wallet SDK service that works with any blockchain.