radixdlt/babylon-gateway v1.9.0.rc1 on GitHub

Overview

This is the v1.9.0 release for the Gateway. API docs are on Redocly here: https://radix-babylon-gateway-api.redoc.ly/

License

The Babylon Gateway code is released under the Radix License. Binaries/Executable components are licensed under the Radix Software EULA.

Upgrade scenarios

Caution

If you are upgrading from a Gateway running v1.8.1 or older, you must deploy on an empty database. There are no database migrations available to migrate the database schema and data.

Tip

If you are upgrading from a Gateway running v1.8.2, it is safe to deploy on top of the existing database. There are compatible migrations that will upgrade the database schema and data.

Tip

If you continue running v1.8.2 after enacting the cuttlefish protocol version on the network, the gateway's data aggregator will stall and stop processing transactions. However, this will not result in data corruption. To resume transaction processing, simply deploy v1.9.0 on your gateway.

What’s new?

Added support for the cuttlefish protocol version.

API Changes

Added a new /transaction/subintent-status endpoint to check the status of a transaction subintent.
Added two new optional fields to the /transaction/committed-details endpoint: subintent_details and child_subintent_hashes, which provide information about transaction subintents if present.
Added a new /transaction/preview-v2 endpoint to preview transactions. This supports V2 transactions and beyond. If you still need to preview V1 transactions, use the /transaction/preview endpoint instead.

Database changes

New ledger_finalized_subintents table that stores information about subintent status.
New UserV2 ledger transaction type discriminator in the ledger_transactions table.
New ledger_transaction_subintent_data table that stores additional information about the transaction's subintents.

Note to Integrators

Please note that the Babylon Core API on the Node is more powerful than on Olympia.

Integrators looking to prepare for the Radix Babylon launch should start by considering if running their own node and using the Core API would work instead of running a Gateway and using the Gateway API.

Please see the guide for integrators here.

Running just a node is simpler than running a node and Gateway, and the Core API has a "long term support" section of the API, designed for tracking fungible balances and accounts, which is guaranteed to be compatible with mainnet launch - enabling integrators to prepare for mainnet launch immediately.

Docker Images

This release is available as tag v1.9.0 on dockerhub, for the following images:

radixdlt/babylon-gateway v1.9.0.rc1 1.9.0 on GitHub