v1.10.3

Overview

This is the v1.10.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.9.2 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.10.0 or newer, it is safe to deploy on top of the existing database. This release contains only changes to API surface.

What’s new?

• Added a new configuration parameter, GatewayApi__SlowRequestLogging__RequestBodyLogLimit (default 2048), which controls the body log limit for slow requests.
• Added a new configuration parameter, GatewayApi__SlowRequestLogging__SlowRequestThreshold (default 250ms), which controls the threshold at which a request is considered slow and logged.

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

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

v1.10.2

Overview

This is the v1.10.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.9.2 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.10.0 or newer, it is safe to deploy on top of the existing database. This release contains only changes to API surface.

Bug fixes

• Fixed the 500 status code returned from /transaction/committed-details or /stream/transactions when the receipt_events or detailed_events opt-in was set to true, and an event with a recursive type of at least depth 3 was returned (e.g., a tuple nested inside a tuple nested inside another tuple).

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

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

v1.10.1

Overview

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

This release contains only hotfix to the 1.10.0 release.

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.9.2 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.10.0, it is safe to deploy on top of the existing database. This release contains only changes to API surface.

Bug fixes

• Fixed the 500 status code returned from /state/entity/details when querying multiple pre-allocated, non-persisted entities in a single request.

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

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

v1.10.0

Warning

If you are upgrading from 1.9.2 or older please use v1.10.1
This is due to bug spotted in 1.10.0 and addressed in 1.10.1 release.

Overview

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

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.

Bug fixes

• Fixed two bugs in two-way links returned from /state/entity/details:
  • If one end of the link pointed to an entity without a corresponding metadata key, it was incorrectly considered a valid two-way link.
  • Fixed invalidation after removing a metadata entry on one end. Previously, the link was still considered valid even after the metadata entry was removed.

API Changes

• New filters are supported on the /stream/transactions endpoint:
  • transaction_status_filter - Allows filtering by the transaction commit status (Success, Failure, All). Defaults to All.
  • balance_change_resources_filter - Allows filtering to transactions which included non-fee related balance changes for all provided resources. Defaults to []. We recommend integrators use this instead of the manifest_resources_filter in most instances.
• Improved the performance of the /extensions/resource-holders/page endpoint.
• Added a new, detailed events model that provides more in-depth insights and additional context, allowing you to work with events more effectively. It is returned when the detailed_events opt-in is enabled for the /stream/transactions and /stream/transactions endpoints. The existing events property is now deprecated, and we advise switching to the new detailed events model.
• Added two new endpoints that allow querying for entities that have ever used a requirement (resource or non-fungible global ID) in their access rules (blueprint authentication templates, owner roles, or role assignments).
  • /extensions/entities-by-role-requirement/lookup – allows querying by multiple requirements.
  • /extensions/entities-by-role-requirement/page – allows querying and paginating by a single requirement.
• The manifest_classes of the transaction manifest in the /stream/transactions endpoint have been adjusted slightly. Notably:
  • The General classification has been expanded to permit validator stake/unstake/claim actions and pool contribute and redeem actions.
• Added a new endpoint /extensions/implicit-requirements/lookup for resolving implicit access rule requirements (https://docs.radixdlt.com/docs/advanced-accessrules#implicit-requirements).
• Added blueprint link support
  • dApp details
    • auto_link_blueprints property added to two_way_linked_dapp_details.entities.items if entity is package and has any auto link blueprint defined.
  • Linked entity changes
    • Update to two_way_linked_dapp_address previously it returned only direct links, right now it resolves to direct_linked_dapp_address if it exists; otherwise, it falls back to blueprint_linked_dapp_address.
    • New property direct_linked_dapp_address returns verified direct two-way link to the dApp address, if available.
    • New property blueprint_linked_dapp_address returns verified blueprint two-way link to the dApp address, if available.

Database changes

• New entries added to the ledger_transaction_markers table for each resource whose balance (excluding fee-related changes) was modified in a transaction. Each resource balance change will be represented by an entry with the resource_balance_change discriminator and the resource's entity_id.
• Removed transaction_type.round_update from the ledger_transaction_markers table. This should reduce database size and slightly improve the performance of the /stream/transactions endpoint.
• A new index IX_ledger_transaction_markers_resource_balance_change has been added to the ledger_transaction_markers table.
• A new index IX_ledger_transactions_receipt_status_state_version has been added to the ledger_transactions table.
• Replaced the IX_resource_holders_entity_id_resource_entity_id_balance index with the IX_resource_holders_resource_entity_id_balance_entity_id index on the resource_holders table.
• New outer_object_entity_id column in the entities table, which holds the outer object entity id (e.g resource entity id for vaults and consensus manager entity id for validators).
• New receipt_event_emitter_entity_ids column in the ledger_transaction_events table, which holds the emitter entity ids for transaction events.
• Added a new entities_by_role_requirement_entry_definition table that stores information about entities that have ever used a requirement (resource or non-fungible global ID) in their access rules.
• Added a new implicit_requirements table to store data necessary for resolving implicit access rule requirements.

What’s new?

• Added a new configuration parameter, GatewayApi__Endpoint__EntitiesByRoleRequirementLookupMaxRequestedRequirementsCount, which sets the limit (default 50) on the number of requirements that can be queried using the /extensions/entities-by-role-requirement/lookup endpoint.
• Added a new configuration parameter, GatewayApi__Endpoint__ImplicitRequirementsLookupMaxRequestedRequirementsCount, which sets the limit (default 100) on the number of implicit requirements that can be queried using the /extensions/implicit-requirements/lookup endpoint.

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

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

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