Balance-changing operation support

The heart of any Rosetta API implementation is populating transaction operations. Most work of mapping network-specific abstractions to Rosetta abstractions occurs here. Depending on the type of operation, there are different expectations around an implementation's support.

Balance-Changing Operations

To be considered a "complete" implementation, the balance computed from all of an account's operations must equal the balance returned for an account by the /account/balance endpoint at the end of each block. If these balances do not match (often referred to as reconciliation) for any account, some clients will not be able to integrate with the blockchain you are working on.

Non-Native Operations

In blockchains with generic smart contracting, detailed parsing of operations can require contract-specific parsing logic. There is no expectation that a Rosetta Data API implementation can parse all deployed contracts with detail but it is expected that any balance changes that result from contract execution are represented (often referred to as tracing).

Non-Balance-Changing Operations

Frequently, blockchains have non-balance-changing operations (i.e. voting for a governance proposal or nominating validators in a PoS network). While there is no specific expectation for supporting operations that do not change balance, implementers are encouraged to include as many operations as possible in a Data API implementation as many developers will rely exclusively on your implementation to interact with the blockchain you are working on. If useful operations are not supported, they will not be able to perform those operations on the blockchain you are working on.