radixdlt/babylon-gateway v1.0.0

Babylon (v1.0.0)

on GitHub

Overview

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

If updating your gateway from any version prior to a v1.0.0 release candidate, then upgrading to this release will require a database wipe.

License

The Babylon Gateway code is released under the Radix License. Binaries/Executable components are licensed under the Radix Software EULA.

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

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

Mainnet Gateway

• The foundation Mainnet gateway will be available at https://mainnet.radixdlt.com after babylon launch.
• Swagger is available here: https://mainnet.radixdlt.com/swagger

Stokenet Gateway

• The Stokenet public gateway is here: https://babylon-stokenet-gateway.radixdlt.com/
• Swagger is available on the Stokenet gateway here: https://babylon-stokenet-gateway.radixdlt.com/swagger

RCNet v3.1 to v1.0.0 Migration Guide

Breaking changes

• Instead of returning only the event data payload from /stream/transactions and /transaction/committed-details, the event data is now a complex object, wrapping the data payload, but also containing the emitter and event name. This allows you to properly determine which entity emitted the event.

What’s new?

• Fixed epoch in from_state_version forward querying for migrated environments where lowest epoch number isn't 1.
• Fixed the validator_active_set_history table which contains data about validator active set history. It was wrongly attached to future epoch not current one.
• Pending transaction handling has been reworked, and /transaction/status returns some additional fields with a lot more information regarding the status of the intent and submitted payloads. Check out the intent_status and payload_status fields. Each status is also associated with a description to help developers understand the meaning of the returned status.
• For Gateway runners, we have added a few small improvements to metrics / logging, and minor bug fixes since v1.0.0-rc3