Releases: radixdlt/babylon-gateway
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
andpending_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
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
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 thanDefaultPageSize
. - 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 inLedgerTransactionsProcessor
. - 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
infrom_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 theintent_status
andpayload_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
infrom_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 theintent_status
andpayload_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.
RCnet v3.1 (Revision 3)
- Fix event schema lookup in
/stream/transactions
and/transaction/committed-details
. - Add
non_fungible_id_location_history
table to improve NFID lookup performance. - Add missing index to
entity_vault_history
table to improve royalty vault lookup performance.
That release requires db wipe.
This release is available as tag rcnet-v3.1-r3 on dockerhub, for the following images:
radixdlt/babylon-ng-database-migrations
radixdlt/babylon-ng-aggregator
radixdlt/babylon-ng-gateway-api
Please see RCnet v3.2 (Revision 2) for the full release / install notes.
RCnet v3.1 (Revision 2)
- Fix incomplete entity type mapping.
- Fix non-fungible resource aggregation.
- Add key_json property to StateKeyValueStoreDataRequestKeyItem enabling JSON-based KVStore lookup.
- support remote schema assignment for generic (key value store, non fungible data) substitution.
That release requires db wipe.
This release is available as tag rcnet-v3.1-r2 on dockerhub, for the following images:
radixdlt/babylon-ng-database-migrations
radixdlt/babylon-ng-data-aggregator
radixdlt/babylon-ng-gateway-api
Please see RCnet v3.1 (Revision 1) for the full release / install notes.