1.2.4

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:

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

1.2.3

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:

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

1.2.2

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:

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

1.2.1

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:

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

1.2.0

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:

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

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

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:

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

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

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)

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

Babylon (v1.0.0-rc3)

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.

RCnet v3.1 (Revision 4)

• fix /state/entity/details endpoint when querying for multiple components with same schema.

That release doesn't requires db wipe.

This release is available as tag rcnet-v3.1-r4 on dockerhub, for the following images:

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

Please see RCnet v3.1 (Revision 1) for the full release / install notes.