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

1.5.2

Overview

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

Notes for Gateway runners

Caution

It is MANDATORY to upgrade to v1.5.2 Gateway before upgrading node to v1.2.0 version (bottlenose protocol version support).

Warning

There will be one more upcoming release (v1.6.0). It will be required to update Gateway to that version before bottlenose protocol version will be enacted on network.

Possible upgrade scenarios

If you're upgrading from v1.5.1 Gateway version

Tip

This release doesn't contain any database migrations. It's safe to just upgrade your 1.5.1 Gateway version to 1.5.2

If you're upgrading from v1.4.4 or older Gateway version

Caution

This release MUST NOT be upgraded onto your existing Network Gateway installation as it has an incompatible database schema. There’s no database migration available. What it means is that this release MUST be deployed with an empty (wiped out) database. This will result in a lengthy (approx. 4 - 16 hours depending on your infrastructure) process of resynchronization. During the resynchronization majority of the GW API endpoints will not be available.

What’s new?

• Fixed broken Core API SDK

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

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

1.5.1

Overview

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

This release MUST NOT be upgraded onto your existing Network Gateway installation as it has an incompatible database schema. There’s no database migration available. What it means is that this release MUST be deployed with an empty (wiped out) database. This will result in a lengthy (approx. 4 - 16 hours depending on your infrastructure) process of resynchronization. During the resynchronization majority of the GW API endpoints will not be available.

Warning

There will be one more upcoming release (probably v1.6.0). It will be required to update Gateway to that version before bottlenose protocol version will be enacted on network.

What’s new?

Caution

Breaking Changes:

• Changed ordering of the collection returned by the /state/key-value-store/keys endpoint. Entries are no longer ordered by their last modification state version but rather by their first appearance on the network, descending.
• Property total_count of the /state/key-value-store/keys endpoint is no longer provided.
• Renamed state.recovery_role_recovery_attempt property from timed_recovery_allowed_after to allow_timed_recovery_after returned from /state/entity/details when querying for access controller.

• Fixed broken ledger state lookup (at_ledger_state) when using epoch-only constraint and given epoch did not result in any transactions at round 1.
• Fixed broken (missing) package blueprint & code, and schema pagination in the /state/entity/details endpoint.
• Fixed unstable package blueprint and code aggregation where changes could overwrite each other if they applied to the same blueprint/package within the same ingestion batch.
• Fixed validator public key and active set aggregation where unnecessary copy of the key was stored on each epoch change.
• Fixed pagination of the /state/validators/list endpoint where incorrect cursor was generated previously.
• Fixed invalid date-time format for some entity state properties (most notably access controllers and their recovery_role_recovery_attempt.allow_timed_recovery_after.date_time property) that was dependent on OS-level locale setup.
• Added ng_workers_global_loop_duration_seconds and ng_workers_node_loop_duration_seconds histogram metrics measuring the time it took to process a single iteration of a given worker.
• Changed MVC controller and action names. It has no effect on the API itself, but alters prometheus controler and action labels.
  • StateKeyValueStoreController.Items renamed to StateKeyValueStoreController.KeysPage,
  • StateNonFungibleController.Ids renamed to StateNonFungibleController.IdsPage,
  • StatisticsController.Uptime renamed to StatisticsController.ValidatorsUptime,
  • StateController renamed to StateEntityController,
  • ValidatorStateController renamed to StateValidatorsComponent.
• Upgraded to .NET 8:
  • Upgraded runtime and libraries
  • Dockerfiles no longer specify custom app user as it comes built-in with official base images.
  • Removed now-obsolete or no-longer-needed code.
  • Prometheus integration exposes new built-in metric httpclient_request_duration_seconds_bucket for all registered HTTP clients.
• Reworked internal data aggregation mechanism to ease up maintenance burden.
• Reworked KVStores storage and changed API surface of this area to improve overall performance.

API Changes

• Changed the MetadataInstantValue type and its array counterpart MetadataInstantArrayValue to clamp the value property within the RFC-3339 compatible date-time year range 1583 to 9999. Added a unix_timestamp_seconds property to these types to give the exact unclamped numerical timestamp value.
• Added role_assignments property to the StateEntityDetailsResponsePackageDetails. All global component details returned by the /state/entity/details endpoint contain role assignments now.
• Added owning_vault_parent_ancestor_address and owning_vault_global_ancestor_address properties to the response of the /state/non-fungible/location endpoint.
• Added new filter manifest_badges_presented_filter to the /stream/transactions endpoint which allows filtering transactions by badges presented.
• Added new opt-in component_royalty_config to the /state/entity/details endpoint. When enabled royalty_config will be returned for each component.
• Use strong type definition for the royalty_config property of package blueprint and general components details. This is a change to OAS definition only and does not impact returned data format.
• Introduced upper limit to the overall number of the filters used in the /stream/transactions endpoint, defaults to 10.
• Added new endpoint /state/account/page/resource-preferences which allows to read resource preferences for given account.
• Added new endpoint /state/account/page/authorized-depositors which allows to read authorized depositors for given account.
• Added new endpoint /state/package/page/blueprints returning paginable iterator over package blueprints.
• Added new endpoint /state/package/page/codes returning paginable iterator over package codes.
• Added new endpoint /state/entity/page/schemas returning paginable iterator over entity schemas.
• Added new endpoint /transaction/account-deposit-pre-validation which allows to pre-validate if deposits can succeed based on account deposit settings and badges presented, before submitting the transaction.
• Fixed wrong request validation logic for maximum number of items in /state/non-fungible/data, /state/non-fungible/data and /state/non-fungible/data endpoints.
• limit_per_page request parameter is no longer validated against *MaxPageSize API configuration parameters. In case requested limit exceeds API configuration maximum value is used. This change is meant to reduce clients need to understand and honor API configuration.

Database changes

• Added new BadgePresented to LedgerTransactionMarkerOperationType enum and started collecting transaction markers for badges presented in transactions.
• Column royalty_amount of component_method_royalty_entry_history table contains now the JSON payload representing the royalty amount without wrapping object.
• Changed schema area:
  • renamed schema_history table to schema_entry_definition,
  • introduced schema_entry_aggregate_history table that contains aggregate history of schema entries under given entity.
• Changed KVStore area:
  • dropped key_value_store_aggregate_history table altogether as we no longer keep track of aggregated KVStores,
  • introduced key_value_store_entry_definition table that defines each and every KVStore entry,
  • table key_value_store_entry_history references rows from key_value_store_entry_definition rather keys themselves.

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

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

1.4.4

Overview

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

This release MUST NOT be upgraded onto your existing Network Gateway installation as it has an incompatible database schema. There’s no database migration available. What it means is that this release MUST be deployed with an empty (wiped out) database. This will result in a lengthy (approx. 4 - 16 hours depending on your infrastructure) process of resynchronization. During the resynchronization majority of the GW API endpoints will not be available.

Tip

In the upcoming weeks we’ll release the next release which will also require full ledger resynchronization.

What’s new?

API Changes

• Improved performance of /stream/transactions endpoint when using the manifest_class_filter filter.

Database changes

• Replaced IX_ledger_transaction_markers_manifest_class_is_most_specific_~ index with two separate indexes IX_ledger_transaction_markers_manifest_class_is_most_specific (indexes is_most_specific = true only) and IX_ledger_transaction_markers_manifest_class (indexes all manifest classes).

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

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

1.4.3

Overview

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

Caution

To properly fix issue with missing key value store keys it is required to process all transactions from the begining. What it means is that this release MUST be deployed with an empty (wiped out) database. This will result in a lengthy (approx. 4 - 16 hours depending on your infrastructure) process of resynchronization. During the resynchronization majority of the GW API endpoints will not be available.

Tip

In the upcoming weeks we’ll release the next release (probably: 1.5.0) which will also require full ledger resynchronization.

What’s new?

• Properly indexes key value store keys in key_value_store_entry_history and key_value_store_aggregate_history tables. Previously it was possible that if the key was updated multiple times in one processed transaction batch some updates might not be indexed properly. This release fixes those issues and makes sure they are properly indexed and each change is properly returned from /state/key-value-store/keys and /state/key-value-store/keys endpoints.

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

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

1.4.1

Overview

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

To properly fix all data, specific order of deployment is required.

1. Upgrade Data aggregator and Gateway API image
2. Execute Database migrations

If that order is not preserved and migrations are executed before the data aggregator is deployed some invalid entries might slip in.

What’s new?

Bug fixes

• Recreated key value store keys are properly returned from /state/key-value-store/keys and /state/key-value-store/data. Previously Gateway did not return keys that were deleted and then recreated. This release fixes existing data in the database and makes sure new ingested data is properly stored in the database.

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

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

1.4.0

Overview

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

Notes for Gateway runners

Caution

This release MUST NOT be upgraded onto your existing Network Gateway installation as it has an incompatible database schema. There’s no database migration available. What it means is that this release MUST be deployed with an empty (wiped out) database. This will result in a lengthy (approx. 4 - 16 hours depending on your infrastructure) process of resynchronization. During the resynchronization majority of the GW API endpoints will not be available.

Tip

In the upcoming weeks we’ll release the next release (probably: 1.5.0) which will also require full ledger resynchronization.

What’s new?

• Dropped internal balance_changes fallback mechanism. As of right now this information is ingested as part of regular transaction ingestion process.
• Reworked internal mechanism used to fetch network configuration. Is no longer stored in the underlying database and it is shared across all services.
• Reworked (partially) internal mechanism used to ingest ledger data by Data Aggregator to improve maintainability and simplify future extensions.
• Fixed state_version-based ledger state at_ledger_state/from_ledger_state constraints which could result in inaccurate lookups previously. Attempt to read from non-existent state version will result in HTTP 400 Bad Request. Previously the nearest state version would be used.

API Changes

• Return components effective role assignments only for assigned modules.
• Added new filters for the /stream/transactions endpoint: accounts_with_manifest_owner_method_calls, accounts_without_manifest_owner_method_calls and manifest_class_filter.
• Extended response models returned by /transaction/committed-details and /stream/transactions endpoints:
  • added manifest_instructions optional property and a corresponding opt-in for returning original manifest of user transactions,
  • added optional manifest_classes property: a collection of zero or more manifest classes ordered from the most specific class to the least specific one.
• Added permanently_rejects_at_epoch to /transaction/status response for pending transactions.
• Added new endpoint /state/key-value-store/keys/ that allows iterating over KeyValueStore keys.

Database changes

• Created new key_value_store_aggregate_history table which will hold pointers to all key_value_store keys.
• Dropped network_configuration table.
• Fixed component's method royalty aggregation, added missing component_method_royalty_aggregate_history table.
• Changed IX_validator_emission_statistics_validator_entity_id_epoch_num~ index to include proposals_made and proposals_missed columns in order to optimize /statistics/validators/update endpoint.

Deprecations

• Obsoleted incorrectly named access_rules_package in favor of role_assignment_module_package on NetworkConfigurationResponse.well_known_addresses. Obsoleted property will contain effective copy of the new one for backwards compability.

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

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

1.3.0

Overview

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

Notes for Gateway runners

• This Gateway version must read from nodes running v1.1.0 or above. Please see upgrade strategies below
• This Gateway version has required migrations. Ensure that radixdlt/babylon-ng-database-migrations:v1.3.0 is run before the Gateway application containers are updated. The minor database changes are described below.

Possible upgrade strategies:

• If you require 100% uptime, first upgrade the Gateway to v1.2.5. Then upgrade the fullnodes to v1.1.0, then upgrade the Gateway to v1.3.0 (this version).
• If you are happy to have some downtime, you can skip updating the Gateway to v1.2.5 and update the Gateway to v1.3.0 at the same time as updating the node to v1.1.0. Any overlap of incompatible versions will cause some downtime.

What’s new?

Adds support for protocol updates (in general) and the anemone update in particular.

API Changes

• Adds support for a new transaction type (flash transactions) that occur during protocol updates.
• Extends well known addresses returned from /status/network-configuration to include the transaction tracker address.
• DEPRECATION - Obsoletes the vm_type, code_hash_hex and code_hex properties of StateEntityDetailsResponsePackageDetails in favor of the codes collection. With the upcoming protocol upgrade it will be possible to have multiple codes per package. The obsoleted properties will contain an effective copy of the first element of the new collection for backwards compability.

Database changes

• Moves vm_type to package_code_history table from package in entity table.
• Creates new package_blueprint_aggregate_history table which will hold pointers to all package blueprints.
• Creates new package_code_aggregate_history table which will hold pointers to all package codes.

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

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

1.2.5

Overview

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

What’s new?

• Fixed broken (incompatible) Core API SDK

---

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

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