Skip to content

Releases: radixdlt/babylon-gateway

1.7.3

26 Sep 16:08
@PawelPawelec-RDX PawelPawelec-RDX
v1.7.3
b669d46
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.

Choose a tag to compare

View all tags
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:

Loading

1.7.2

17 Sep 11:53
@PawelPawelec-RDX PawelPawelec-RDX
v1.7.2
522c1ef
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.

Choose a tag to compare

View all tags
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.
  • 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:

Loading

1.6.3

06 Aug 12:00
@PawelPawelec-RDX PawelPawelec-RDX
v1.6.3
e0f6ea4
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.

Choose a tag to compare

View all tags
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:

Loading

1.6.1

21 May 09:57
@PawelPawelec-RDX PawelPawelec-RDX
v1.6.1
ef98035
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.

Choose a tag to compare

View all tags
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:

Loading

1.5.2

14 May 09:16
@PawelPawelec-RDX PawelPawelec-RDX
v1.5.2
6026a3e
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.

Choose a tag to compare

View all tags
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:

Loading

1.5.1

09 May 12:44
@PawelPawelec-RDX PawelPawelec-RDX
v1.5.1
ef7ed0d
This commit was signed with the committer’s verified signature.
krzlabrdx
GPG key ID: 4981EE42DAE78C0D
Verified
Learn about vigilant mode.

Choose a tag to compare

View all tags
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:

Loading

1.4.4

27 Mar 13:34
@PawelPawelec-RDX PawelPawelec-RDX
v1.4.4
d1bb35b
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.

Choose a tag to compare

View all tags
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:

Loading

1.4.3

06 Mar 15:24
@PawelPawelec-RDX PawelPawelec-RDX
v1.4.3
88ef362
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.

Choose a tag to compare

View all tags
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:

Loading

1.4.1

27 Feb 16:01
@PawelPawelec-RDX PawelPawelec-RDX
v1.4.1
2054f06
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.

Choose a tag to compare

View all tags
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:

Loading

1.4.0

09 Feb 09:30
@PawelPawelec-RDX PawelPawelec-RDX
v1.4.0
9760898
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.

Choose a tag to compare

View all tags
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:

Loading