Overview
This is the v1.9.1
release for the Gateway, and allows the Gateway to handle the Cuttlefish protocol update (part 1 and part 2), including the V2 transaction format.
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.1
on your gateway.
What’s new?
- Added support for the
cuttlefish
andcuttlefish-part2
protocol versions.
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
andchild_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 theledger_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.1
on dockerhub, for the following images: