radixdlt/babylon-gateway v1.0.0-rc3

Babylon (v1.0.0-rc3)

on GitHub

Overview

This is a v1.0.0 release candidate for the Gateway. There will likely be another build before mainnet launch next week, but we are not expecting any changes to the Gateway API schema. API docs are on Redocly here: https://radix-babylon-gateway-api.redoc.ly/

If updating your zabanet gateway, 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-rc3 on dockerhub, for the following images:

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

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.