github radixdlt/babylon-gateway v1.7.0
1.7.0

latest releases: v1.8.2, v1.8.2.rc1, v1.8.1...
pre-release2 months ago

Overview

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

Upgrade scenarios

Caution

it is required to deploy on empty database. There are no database migration available to migrate database schema.

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.

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.

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.

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.

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

Don't miss a new babylon-gateway release

NewReleases is sending notifications on new releases.