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 indexesaffected_global_entities
for the transaction tracker and the consensus manager entity types.- Changed
variant_id
ofProgrammaticScryptoSborValueEnum
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
andAccountDepositSettingsUpdate
, i.e. empty transactions with onlylock_fee
instruction.
API Changes
- Added support for the missing
message
andflags.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
ofProgrammaticScryptoSborValueEnum
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 thedapp_two_way_links
opt-in is enabled.- Brand-new
two_way_linked_*
properties on thedetails
property of the Resources, Accounts, Packages and other global entities. - See https://docs.radixdlt.com/docs/metadata-for-verification#metadata-standards-for-verification-of-onledger-entities for detailed specification.
- Brand-new
- Added support for the Native Resource Details in the
/state/entity/details
endpoint, returned when thenative_resource_details
opt-in is enabled.- Introduced a new
native_resource_details
property on thedetails
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.
- Introduced a new
- 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 theentities
table with more generic collection implementation usingcorrelated_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
toentities
table. Which contains list of all mutable non fungible data fields for non fungible resource entities. - New
ledger_transaction_markers
type with theevent_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: