1.9.2

Overview

This is the v1.9.2 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.

Bug fixes

• Fixed a HTTP 500 response issue when querying the /state/entity/details endpoint with the native_resource_details: true opt-in for:
  • a validator's LSU resource address when the validator was never active.
  • a pool's unit resource when the pool had no contributions.
• Added support for pre-allocated, non-persisted accounts in the /state/account/page/resource-preferences and /state/account/page/authorized-depositors endpoints.
• Fixed a typo in the value StoryOnlyForUserTransactionsAndEpochChanges (replacing Story with Store) for the configuration entries DataAggregator__Storage__StoreTransactionReceiptEvents and DataAggregator__Storage__StoreReceiptStateUpdates. It now supports both values:
  • StoreOnlyForUserTransactionsAndEpochChanges
  • StoryOnlyForUserTransactionsAndEpochChanges

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.2 on dockerhub, for the following images:

• radixdlt/babylon-ng-database-migrations
• radixdlt/babylon-ng-aggregator
• radixdlt/babylon-ng-gateway-api

1.9.1 (Cuttlefish)

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 and cuttlefish-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 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.1 on dockerhub, for the following images:

• radixdlt/babylon-ng-database-migrations
• radixdlt/babylon-ng-aggregator
• radixdlt/babylon-ng-gateway-api

1.9.0 (Cuttlefish)

Please update to 1.9.1 for compatibility with Cuttlefish.

1.9.0 - Release Candidate 2

This build has been replaced with v1.9.0.

1.8.2

Overview

This is the v1.8.2 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

You must deploy on an empty database. There are no database migrations available to update the schema and data. It is not possible to migrate data, as the bug we are fixing in this release is related to missing entries in the database.

Bug fixes

• Fix processing multiple changes to single non fungible id data (NonFungibleResourceManagerDataEntrySubstate) in one batch. It might result in
  • Wrong data stored and returned from the /state/non-fungible/data endpoint.
  • Not tracking properly that non fungible id got deleted, which might lead to returning an invalid location of non fungible id. Affected endpoints are
    • /state/non-fungible/location
    • And all endpoints that return non fungible vault content
      • /state/entity/details
      • /state/entity/page/non-fungibles/
      • /state/entity/page/non-fungible-vaults/
      • /state/entity/page/non-fungible-vault/ids

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.8.2 on dockerhub, for the following images:

• radixdlt/babylon-ng-database-migrations
• radixdlt/babylon-ng-aggregator
• radixdlt/babylon-ng-gateway-api

1.8.1

Overview

This is the v1.8.1 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

You must deploy on an empty database. There are no database migrations available to migrate the database schema and data.

Breaking changes

Caution

• Manifest addresses are no longer indexed in the /stream/transactions endpoint for failed transactions. Affected filters:
  • manifest_accounts_withdrawn_from_filter
  • manifest_accounts_deposited_into_filter
  • manifest_badges_presented_filter
  • manifest_resources_filter
  • accounts_with_manifest_owner_method_calls
  • accounts_without_manifest_owner_method_calls
• Changed ordering of entity metadata. Entries are no longer ordered by their last modification state version but rather by their first appearance on the network, descending. Affected endpoints:
  • /state/entity/metadata
  • /state/entity/page/metadata
• Changed ordering of fungible and non fungible resources. Entries are no longer ordered by their last modification state version but rather by their first appearance on the network, descending. Affected endpoints:
  • /state/entity/details
  • /state/entity/page/fungibles/
  • /state/entity/page/non-fungibles/
• Changed ordering of vaults when using vault aggregation level. Entries are no longer ordered by their last modification state version but rather by their first appearance on the network, descending. Affected endpoints:
  • /state/entity/details
  • /state/entity/page/fungibles/
  • /state/entity/page/fungible-vaults/
  • /state/entity/page/non-fungibles/
  • /state/entity/page/non-fungible-vaults/
• Changed ordering of non fungible ids. Entries are no longer ordered by their last modification state version but rather by their first appearance on the network, descending. Affected endpoints:
  • /state/entity/page/non-fungible-vault/ids
  • /state/entity/details (when using non_fungible_include_nfids opt-in)
  • /state/entity/page/non-fungibles/ (when using non_fungible_include_nfids opt-in)
  • /state/entity/page/non-fungible-vaults/ (when using non_fungible_include_nfids opt-in)
• Existing non fungible vaults with no items will no longer return items: null and will return an empty array items: [] instead, as we do in all other collections. Affected endpoints:
  • /state/entity/page/non-fungible-vault/ids
  • /state/entity/details (when using non_fungible_include_nfids opt-in)
  • /state/entity/page/non-fungibles/ (when using non_fungible_include_nfids opt-in)
  • /state/entity/page/non-fungible-vaults/ (when using non_fungible_include_nfids opt-in)

What’s new?

• New configuration options DataAggregator__Storage__StoreTransactionReceiptEvents, and DataAggregator__Storage__StoreReceiptStateUpdates for the data aggregator to configure if a transaction's receipt events and receipt state updates should be stored in the database. It is meant to be used by gateway runners who want to reduce their database size. Keep in mind that when disabled, the corresponding properties will be missing on a response from both the /stream/transactions and the /transaction/committed-details endpoints. You can save significant space by using StoryOnlyForUserTransactionsAndEpochChanges and only excluding round change transactions, which aren't typically read from the /stream/transactions endpoint.
  • Possible values:
    • StoreForAllTransactions (default) - will store data for all transactions.
    • StoryOnlyForUserTransactionsAndEpochChanges - will store data for user transactions and transactions that resulted in epoch change.
    • StoreOnlyForUserTransactions - will store data only for user transactions.
    • DoNotStore - will not store any data.

Bug fixes

• Added missing total_count property to /state/validators/list response.
• Fix /transaction/account-deposit-pre-validation for uninstantiated pre-allocated accounts. It no longer returns error with code 404 Entity not found.
• Restored missing round update transactions from the /stream/transactions endpoint.

API Changes

• Restored previously removed total_count property to /state/key-value-store/keys endpoint.

Database changes

• Refactored multiple aggregates. Queries follow a similar strategy as key value stores and utilize _entry_definition, _entry_history, and _totals_history tables to return data
  • Metadata
    • Removed entity_metadata_aggregate_history table.
    • New entity_metadata_entry_definition table, which holds information about all the metadata keys ever created for a given entity.
    • Renamed entity_metadata_history to entity_metadata_entry_history, replaced entity_id and key columns with entity_metadata_entry_definition_id. Holds history of given metadata key at a given state version.
    • New entity_metadata_totals_history table, which holds total counts of metadata per entity.
  • Resource globally aggregated
    • Removed entity_resource_aggregate_history table.
    • New entity_resource_entry_definition table, which holds information about all resources which have ever been held by a given global entity.
    • New entity_resource_balance_history table, which holds the sum of globally aggregated resource held by a global entity at a given state version.
    • New entity_resource_totals_history table, which holds total count of different resources under a given global entity at a given state version.
  • Resource vault aggregated
    • Removed entity_resource_aggregated_vaults_history and entity_resource_vault_aggregate_history tables.
    • New entity_resource_vault_entry_definition table, which holds information about vaults of a given resource held under a given global entity.
    • New entity_resource_vault_totals_history table, which holds total count of all vaults of a given resource held under a given global entity at a given state version.
  • Vault content
    • New non_fungible_vault_entry_definition table, which holds information about non fungible held by a given vault.
    • New non_fungible_vault_entry_history table which holds history of given non fungible inside vault.
    • Renamed entity_vault_history to vault_balance_history. Holds information about vault content (amount of fungibles or count of non fungible ids inside vault) at a given state version.
  • Key value store
    • New key_value_store_totals_history table, which holds total count of all keys under a given store at a given state version.
• Changed receipt_state_updates in the ledger_transactions table to be nullable.
• Moved all receipt_event_* columns from the ledger_transactions table to a new separate ledger_transaction_events table.
• Renamed origin_type marker type to transaction_type (stored in the ledger_transaction_markers table), possible values:
  • User
  • RoundChange
  • GenesisFlash
  • GenesisTransaction
  • ProtocolUpdateFlash
  • ProtocolUpdateTransaction
• New transaction marker type epoch_change (stored in the ledger_transaction_markers table), entry for this marker indicates that this transaction resulted in an epoch change.

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.8.1 on dockerhub, for the following images:

• radixdlt/babylon-ng-database-migrations
• radixdlt/babylon-ng-aggregator
• radixdlt/babylon-ng-gateway-api

1.7.3

Overview

This is the v1.7.3 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.6.3 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 Gateway running v1.7.0, v1.7.1, or v1.7.2 it is safe to deploy on top of the existing database. There are compatible migrations that will upgrade the database schema and data.

What’s new?

This release fixes Data Aggregator stall on state version: 139553672 on the mainnet network.

Database changes

• Removed unique constraint from IX_account_resource_preference_rule_entry_history_account_enti~ index.

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.7.3 on dockerhub, for the following images:

• radixdlt/babylon-ng-database-migrations
• radixdlt/babylon-ng-aggregator
• radixdlt/babylon-ng-gateway-api

1.7.2

Overview

This is the v1.7.2 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.6.3 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 Gateway running v1.7.0 or v1.7.1, it is safe to deploy on top of the existing database. There are compatible migrations that will upgrade the database schema and data.

Node requirement

Warning

It is required to run a v1.2.3 node or newer for the new features to work. If you are connected to a node running v1.2.2 or older, the new radix_engine_toolkit_receipt feature will be ignored.

Breaking changes

Caution

Breaking Changes:

• /stream/transactions no longer indexes affected_global_entities for the transaction tracker and the consensus manager entity types.
• Changed variant_id of ProgrammaticScryptoSborValueEnum from numeric (type: integer) to string-encoded numeric (type: string) to make it compatible with the rest of the ecosystem.

What’s new?

• Fixed data aggregator processing time due to a missing database index.

Bug fixes

• Properly indexes manifest classes. Some transactions might have been previously misclassified as Transfer and AccountDepositSettingsUpdate, i.e. empty transactions with only lock_fee instruction.

Database changes

• Replaced relationship-related columns (*_entity_id) in the entities table with more generic collection implementation using correlated_entity_* columns.
• Replaced per-epoch validator emissions (validator_emission_statistics table) with their cumulative statistics (validator_cumulative_emission_history table).
• Added non_fungible_data_mutable_fields to entities table. Which contains list of all mutable non fungible data fields for non fungible resource entities.
• New ledger_transaction_markers type with the event_global_emitter discriminator. It represents the global emitter for each event.
• Added new unverified_standard_metadata_* tables. They hold some of the metadata entries using db-friendly (normalized) model. See https://docs.radixdlt.com/docs/metadata-standards
• Extended list of supported entity correlations in the entities table.
• Renamed values of the entity_relationship enum type.
• Added new resource_holders table. It keeps information about all holders of each fungible and non fungible resource.
• Added missing index on validator_cumulative_emission_history

API Changes

• Added support for the missing message and flags.disable_auth_checks properties in the /transaction/preview endpoint request.
• Added list of mutable non fungible data fields non_fungible_data_mutable_fields returned from /state/entity/details endpoint.
• New event_global_emitters_filter filter added to /stream/transactions endpoint. It allows filtering transactions by the global ancestor of an event emitter. For events emitted by a global entity it is going to be that entity, for internal entities it is going to be a global ancestor.
• Changed variant_id of ProgrammaticScryptoSborValueEnum from numeric (type: integer) to string-encoded numeric (type: string) to make it compatible with the rest of the ecosystem.
• Optimized /statistics/validators/uptime endpoint processing time.
• Added support for two-way linked dApps in the /state/entity/details endpoint, returned when the dapp_two_way_links opt-in is enabled.
  • Brand-new two_way_linked_* properties on the details property of the Resources, Accounts, Packages and other global entities.
  • See https://docs.radixdlt.com/docs/metadata-for-verification#metadata-standards-for-verification-of-onledger-entities for detailed specification.
• Added support for the Native Resource Details in the /state/entity/details endpoint, returned when the native_resource_details opt-in is enabled.
  • Introduced a new native_resource_details property on the details object when looking up fungible or non-fungible resource entities with the entity details endpoint. This property is present when the resource has a special meaning to native blueprints, and gives extra information about the resource. For example, it identifies pool units with their linked pool, and gives the redemption value for a single unit.
  • Includes unit redemption value for the Validator LSU token and the unit tokens of various Pools.
• Added new endpoint /extensions/resource-holders/page which returns information about all holders of the queried resource.
• Added opt_ins property to /transaction/preview request. Currently, there is only one option to use radix_engine_toolkit_receipt, it controls whether the preview response will include a Radix Engine Toolkit serializable
  receipt or not (defaults to false).

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.7.2 on dockerhub, for the following images:

• radixdlt/babylon-ng-database-migrations
• radixdlt/babylon-ng-aggregator
• radixdlt/babylon-ng-gateway-api

1.6.3

Overview

This is the v1.6.3 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.

Notes for Gateway runners

Warning

This release includes a required database migration which may take a minute or so to run, but does NOT require a resync from scratch. See this section of the readme for details on Gateway deployment order and migrations.

Database changes

• Removed the large non_fungible_id_store_history aggregate table. Queries for non fungible ids follow a similar strategy as key value stores and utilize _definition and _history tables to return data. Total supply and total minted/burned can be queried from the resource_entity_supply_history table.
• Renamed non_fungible_id_data table to non_fungible_id_definition.

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.6.3 on dockerhub, for the following images:

• radixdlt/babylon-ng-database-migrations
• radixdlt/babylon-ng-aggregator
• radixdlt/babylon-ng-gateway-api

1.6.1

Overview

This is the v1.6.1 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.

Notes for Gateway runners

Caution

It is MANDATORY to upgrade to v1.6.1 Gateway before bottlenose protocol version is enacted on network.

Caution

Gateway v1.6.1 is intended to work with 1.2.1 node version. Please make sure to upgrade node before upgrading gateway.

Upgrade scenarios

Tip

If you are upgrading from Gateway running v1.5.1 or later version it is safe to deploy on top of existing database. There are compatible migrations that will upgrade database schema.

Caution

If you are upgrading from Gateway running v1.4.4 or older it is required to deploy on empty database. There's no database migration available.

What’s new?

• Added support to run Gateway after enacting bottlenose protocol update.

API Changes

• Added well_known_addresses.locker_package address property to the /status/network-configuration endpoint response.
• Added a new endpoint /state/account-locker/page/vaults which allows to read all resource vaults for a given AccountLocker.
• Added a new endpoint /state/account-lockers/touched-at which allows to read last touch state version for a given collection of AccountLockers.

Database changes

• Added a new set of AccountLocker-related tables: account_locker_entry_definition, account_locker_entry_resource_vault_definition and account_locker_entry_touch_history.
• Added two new columns account_locker_of_account_entity_id and account_locker_of_account_locker_entity_id to the entities table filled for AccountLocker-related Vaults and KeyValueStores.
• Changed IX_entity_vault_history_vault_entity_id_from_state_version index to match all existing vaults rather non-fungible ones only.

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.6.1 on dockerhub, for the following images:

• radixdlt/babylon-ng-database-migrations
• radixdlt/babylon-ng-aggregator
• radixdlt/babylon-ng-gateway-api