Skip to content

Releases: radixdlt/babylon-gateway

1.3.0

29 Jan 14:18
9836016

Choose a tag to compare

Overview

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

Notes for Gateway runners

  • This Gateway version must read from nodes running v1.1.0 or above. Please see upgrade strategies below
  • This Gateway version has required migrations. Ensure that radixdlt/babylon-ng-database-migrations:v1.3.0 is run before the Gateway application containers are updated. The minor database changes are described below.

Possible upgrade strategies:

  • If you require 100% uptime, first upgrade the Gateway to v1.2.5. Then upgrade the fullnodes to v1.1.0, then upgrade the Gateway to v1.3.0 (this version).
  • If you are happy to have some downtime, you can skip updating the Gateway to v1.2.5 and update the Gateway to v1.3.0 at the same time as updating the node to v1.1.0. Any overlap of incompatible versions will cause some downtime.

What’s new?

Adds support for protocol updates (in general) and the anemone update in particular.

API Changes

  • Adds support for a new transaction type (flash transactions) that occur during protocol updates.
  • Extends well known addresses returned from /status/network-configuration to include the transaction tracker address.
  • DEPRECATION - Obsoletes the vm_type, code_hash_hex and code_hex properties of StateEntityDetailsResponsePackageDetails in favor of the codes collection. With the upcoming protocol upgrade it will be possible to have multiple codes per package. The obsoleted properties will contain an effective copy of the first element of the new collection for backwards compability.

Database changes

  • Moves vm_type to package_code_history table from package in entity table.
  • Creates new package_blueprint_aggregate_history table which will hold pointers to all package blueprints.
  • Creates new package_code_aggregate_history table which will hold pointers to all package codes.

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

1.2.5

26 Jan 14:00
684f26b

Choose a tag to compare

Overview

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

What’s new?

  • Fixed broken (incompatible) Core API SDK

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

1.2.4

03 Jan 13:08
ed29ba6

Choose a tag to compare

Overview

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

What’s new?

  • Extended validator's data returned from /state/validators/list: added effective_fee_factor field which returns current fee_factor and optionally pending change.
  • Enable retries on transient database connectivity issues in gateway api.
  • Enable retries on core api calls in gateway api.
  • Optimized transaction balance changes; if available they're read from internal database, otherwise they use existing fallback mechanism

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

1.2.3

12 Dec 12:55
acde06f

Choose a tag to compare

Overview

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

What’s new?

  • Fixed exception thrown on empty validator set in the /state/validator/list endpoint.
  • 524 status code returned instead of 500 if request takes longer than configured timeout.
  • Validate if addresses provided in requests to API belong to network it is running on.
  • Fixed 500 status code returned from /transaction/submit when Transaction got committed before Gateway was able to store pending transaction node submission result. It'll return 200 status code from now on and log exception as information.

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

1.2.2

21 Nov 13:09
e2814b6

Choose a tag to compare

Overview

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

What’s new?

  • Fixed invalid foreign key between pending_transactions and pending_transaction_payloads tables.
  • Fixed package detail lookups to return all the blueprints and schemas.
  • Optimized transaction balance changes fetch time (parallelized).

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

1.2.1

06 Nov 13:30
ee88199

Choose a tag to compare

Overview

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

What’s new?

  • Fixed local development environment setup.
  • Fixed missing state property on non-global entity state details.

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

1.2.0

27 Oct 05:55
105d6c1

Choose a tag to compare

Overview

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

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

v1.0.0 to v1.2.0 Migration Guide

What’s new?

  • Fixed invalid HTTP status code on input validation failure.
  • Fixed epoch [+ round] based ledger state lookups.
  • Fixed non-persisted identity/account lookups.
  • Fixed vault collection ordering for newly ingested data. A database wipe might be required, see information below.
  • Added more strongly-typed OAS definitions for programmatic_json and types derived from the Core API.
  • Added resource_address to fungible and non-fungible vault entity details in the /state/entity/details endpoint.
  • Added new opt-in balance_changes to /transaction/committed-details returning resource balance changes for a given transaction.
  • Added new opt-in receipt_output to /stream/transactions, and /transaction/committed-details endpoints. Temporarily set by default to true, to allow client's migration.
  • Added vault-related details to lookups in /state/entity/details endpoint.
  • Changed default configuration value of MaxPageSize for endpoints to 100. Validate if max page size is higher than DefaultPageSize.
  • Optimized TransactionQuerier.GetTransactions not to fetch unnecessary data from underlying database.
  • Tuned documentation and constraints of various OAS type definitions.

1.1.0

17 Oct 11:59
e9ef480

Choose a tag to compare

1.1.0 Pre-release
Pre-release

Not recommended for public running

This release has an issue where resource summaries are not returned for uninstantiated pre-allocated accounts, so we do not recommend running this version. We will be releasing a new version next week with the v1.1.0 features and a few other fixes.


Overview

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

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

v1.0.0 to v1.1.0 Migration Guide

What’s new?

  • Fixed invalid HTTP status code on input validation failure.
  • Changed default configuration value of MaxPageSize for endpoints to 100. Validate if max page size is higher than DefaultPageSize.
  • Added new opt-in balance_changes to /transaction/committed-details returning resource balance changes for a given transaction.
  • Added new opt-in receipt_output to /stream/transactions, and /transaction/committed-details endpoints. Temporarily set by default to true, to allow client's migration.
  • Added vault-related details to lookups in /state/entity/details endpoint.
  • Optimized TransactionQuerier.GetTransactions not to fetch unnecessary data from underlying database.
  • Added strongly-typed OAS definition for programmatic_json.
  • Tuned documentation and constraints of various OAS type definitions.

1.0.1

10 Oct 09:45
1c80d17

Choose a tag to compare

Overview

  • Fixed missing RecordTopOfDbLedger observer call in LedgerTransactionsProcessor.
  • Fixed invalid response model for HTTP 400 Bad Request responses on input parameter validation failure.
  • Return 400 with validation error instead of 500 if from_ledger_state state_version is beyond known ledger tip.

License

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

Docker Images

This release is available as tag v1.0.1 on dockerhub, for the following images:

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

Please see 1.0.0 for the full release / install notes.

Babylon (v1.0.0)

27 Sep 15:08
a79a6ae

Choose a tag to compare

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:

Mainnet Gateway

Stokenet Gateway

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