1.1.4

Creating equitable access to the global financial system

DigitalBits Go Monorepo

This repo is the home for all of the public Go code produced by the XDB Foundation.

This repo contains various tools and services that you can use and deploy, as well as the SDK you can use to develop applications that integrate with the DigitalBits network.

Package Index

• Frontier Server: Full-featured API server for DigitalBits network
• Go Frontier SDK - frontierclient: Client for Frontier server (queries and transaction submission)
• Go Frontier SDK - txnbuild: Construct DigitalBits transactions and operations
• Ticker: An API server that provides statistics about assets and markets on the DigitalBits network
• Keystore: An API server that is used to store and manage encrypted keys for DigitalBits client applications
• Servers for Anchors & Financial Institutions
  • Federation Server: Allows organizations to provide addresses for users (jane*examplebank.com)

Dependencies

This repository is officially supported on the last two releases of Go.

It depends on a number of external dependencies, and uses Go Modules to manage them. Running any go command will automatically download dependencies required for that operation.

You can choose to checkout this repository into a GOPATH or into any directory.

Directory Layout

In addition to the other top-level packages, there are a few special directories that contain specific types of packages:

• clients contains packages that provide client packages to the various DigitalBits services.
• exp contains experimental packages. Use at your own risk.
• handlers contains packages that provide pluggable implementors of http.Handler that make it easier to incorporate portions of the DigitalBits protocol into your own http server.
• support contains packages that are not intended for consumption outside of DigitalBits's other packages. Packages that provide common infrastructure for use in our services and tools should go here, such as db or log.
• support/scripts contains single-file go programs and bash scripts used to support the development of this repo.
• services contains packages that compile to applications that are long-running processes (such as API servers).
• tools contains packages that compile to command line applications.

Each of these directories have their own README file that explain further the nature of their contents.

Other packages

In addition to the packages described above, this repository contains various packages related to working with the DigitalBits network from a go program. It's recommended that you use godoc to browse the documentation for each.

Package source layout

While much of the code in individual packages is organized based upon different developers' personal preferences, many of the packages follow a simple convention for organizing the declarations inside of a package that aim to aid in your ability to find code.

In each package, there may be one or more of a set of common files:

• errors.go: This file should contains declarations (both types and vars) for errors that are used by the package.
• example_test.go: This file should contains example tests, as described at https://blog.golang.org/examples.
• main.go/internal.go (deprecated): Older packages may have a main.go (public symbols) or internal.go (private symbols). These files contain, respectively, the exported and unexported vars, consts, types and funcs for the package. New packages do not follow this pattern, and instead follow the standard Go convention to co-locate structs and their methods in the same files.
• main.go (new convention): If present, this file contains a main function as part of an executable main package.

In addition to the above files, a package often has files that contains code that is specific to one declared type. This file uses the snake case form of the type name (for example loggly_hook.go would correspond to the type LogglyHook). This file should contain method declarations, interface implementation assertions and any other declarations that are tied solely to that type.

Each non-test file can have a test counterpart like normal, whose name ends with _test.go. The common files described above also have their own test counterparts... for example internal_test.go should contains tests that test unexported behavior and more commonly test helpers that are unexported.

Generally, file contents are sorted by exported/unexported, then declaration type (ordered as consts, vars, types, then funcs), then finally alphabetically.

Test helpers

Often, we provide test packages that aid in the creation of tests that interact with our other packages. For example, the support/db package has the support/db/dbtest package underneath it that contains elements that make it easier to test code that accesses a SQL database. We've found that this pattern of having a separate test package maximizes flexibility and simplifies package dependencies.

1.1.3

Creating equitable access to the global financial system

DigitalBits Go Monorepo

This repo is the home for all of the public Go code produced by the XDB Foundation.

This repo contains various tools and services that you can use and deploy, as well as the SDK you can use to develop applications that integrate with the DigitalBits network.

Package Index

• Frontier Server: Full-featured API server for DigitalBits network
• Go Frontier SDK - frontierclient: Client for Frontier server (queries and transaction submission)
• Go Frontier SDK - txnbuild: Construct DigitalBits transactions and operations
• Ticker: An API server that provides statistics about assets and markets on the DigitalBits network
• Keystore: An API server that is used to store and manage encrypted keys for DigitalBits client applications
• Servers for Anchors & Financial Institutions
  • Federation Server: Allows organizations to provide addresses for users (jane*examplebank.com)

Dependencies

This repository is officially supported on the last two releases of Go.

It depends on a number of external dependencies, and uses Go Modules to manage them. Running any go command will automatically download dependencies required for that operation.

You can choose to checkout this repository into a GOPATH or into any directory.

Directory Layout

In addition to the other top-level packages, there are a few special directories that contain specific types of packages:

• clients contains packages that provide client packages to the various DigitalBits services.
• exp contains experimental packages. Use at your own risk.
• handlers contains packages that provide pluggable implementors of http.Handler that make it easier to incorporate portions of the DigitalBits protocol into your own http server.
• support contains packages that are not intended for consumption outside of DigitalBits's other packages. Packages that provide common infrastructure for use in our services and tools should go here, such as db or log.
• support/scripts contains single-file go programs and bash scripts used to support the development of this repo.
• services contains packages that compile to applications that are long-running processes (such as API servers).
• tools contains packages that compile to command line applications.

Each of these directories have their own README file that explain further the nature of their contents.

Other packages

In addition to the packages described above, this repository contains various packages related to working with the DigitalBits network from a go program. It's recommended that you use godoc to browse the documentation for each.

Package source layout

While much of the code in individual packages is organized based upon different developers' personal preferences, many of the packages follow a simple convention for organizing the declarations inside of a package that aim to aid in your ability to find code.

In each package, there may be one or more of a set of common files:

• errors.go: This file should contains declarations (both types and vars) for errors that are used by the package.
• example_test.go: This file should contains example tests, as described at https://blog.golang.org/examples.
• main.go/internal.go (deprecated): Older packages may have a main.go (public symbols) or internal.go (private symbols). These files contain, respectively, the exported and unexported vars, consts, types and funcs for the package. New packages do not follow this pattern, and instead follow the standard Go convention to co-locate structs and their methods in the same files.
• main.go (new convention): If present, this file contains a main function as part of an executable main package.

In addition to the above files, a package often has files that contains code that is specific to one declared type. This file uses the snake case form of the type name (for example loggly_hook.go would correspond to the type LogglyHook). This file should contain method declarations, interface implementation assertions and any other declarations that are tied solely to that type.

Each non-test file can have a test counterpart like normal, whose name ends with _test.go. The common files described above also have their own test counterparts... for example internal_test.go should contains tests that test unexported behavior and more commonly test helpers that are unexported.

Generally, file contents are sorted by exported/unexported, then declaration type (ordered as consts, vars, types, then funcs), then finally alphabetically.

Test helpers

Often, we provide test packages that aid in the creation of tests that interact with our other packages. For example, the support/db package has the support/db/dbtest package underneath it that contains elements that make it easier to test code that accesses a SQL database. We've found that this pattern of having a separate test package maximizes flexibility and simplifies package dependencies.

Contributing

Contributions are welcome! See CONTRIBUTING.md for more details.

Developing

See DEVELOPING.md for helpful instructions for getting started developing code in this repository.

1.1.2

Creating equitable access to the global financial system

DigitalBits Go Monorepo

This repo is the home for all of the public Go code produced by the XDB Foundation.

This repo contains various tools and services that you can use and deploy, as well as the SDK you can use to develop applications that integrate with the DigitalBits network.

Package Index

• Frontier Server: Full-featured API server for DigitalBits network
• Go Frontier SDK - frontierclient: Client for Frontier server (queries and transaction submission)
• Go Frontier SDK - txnbuild: Construct DigitalBits transactions and operations
• Ticker: An API server that provides statistics about assets and markets on the DigitalBits network
• Keystore: An API server that is used to store and manage encrypted keys for DigitalBits client applications
• Servers for Anchors & Financial Institutions
  • Compliance Server: Allows financial institutions to exchange KYC information
  • Federation Server: Allows organizations to provide addresses for users (jane*examplebank.com)

Dependencies

This repository is officially supported on the last two releases of Go.

It depends on a number of external dependencies, and uses Go Modules to manage them. Running any go command will automatically download dependencies required for that operation.

You can choose to checkout this repository into a GOPATH or into any directory.

Directory Layout

In addition to the other top-level packages, there are a few special directories that contain specific types of packages:

• clients contains packages that provide client packages to the various DigitalBits services.
• exp contains experimental packages. Use at your own risk.
• handlers contains packages that provide pluggable implementors of http.Handler that make it easier to incorporate portions of the DigitalBits protocol into your own http server.
• support contains packages that are not intended for consumption outside of DigitalBits's other packages. Packages that provide common infrastructure for use in our services and tools should go here, such as db or log.
• support/scripts contains single-file go programs and bash scripts used to support the development of this repo.
• services contains packages that compile to applications that are long-running processes (such as API servers).
• tools contains packages that compile to command line applications.

Each of these directories have their own README file that explain further the nature of their contents.

Other packages

In addition to the packages described above, this repository contains various packages related to working with the DigitalBits network from a go program. It's recommended that you use godoc to browse the documentation for each.

Package source layout

While much of the code in individual packages is organized based upon different developers' personal preferences, many of the packages follow a simple convention for organizing the declarations inside of a package that aim to aid in your ability to find code.

In each package, there may be one or more of a set of common files:

• errors.go: This file should contains declarations (both types and vars) for errors that are used by the package.
• example_test.go: This file should contains example tests, as described at https://blog.golang.org/examples.
• main.go/internal.go (deprecated): Older packages may have a main.go (public symbols) or internal.go (private symbols). These files contain, respectively, the exported and unexported vars, consts, types and funcs for the package. New packages do not follow this pattern, and instead follow the standard Go convention to co-locate structs and their methods in the same files.
• main.go (new convention): If present, this file contains a main function as part of an executable main package.

In addition to the above files, a package often has files that contains code that is specific to one declared type. This file uses the snake case form of the type name (for example loggly_hook.go would correspond to the type LogglyHook). This file should contain method declarations, interface implementation assertions and any other declarations that are tied solely to that type.

Each non-test file can have a test counterpart like normal, whose name ends with _test.go. The common files described above also have their own test counterparts... for example internal_test.go should contains tests that test unexported behavior and more commonly test helpers that are unexported.

Generally, file contents are sorted by exported/unexported, then declaration type (ordered as consts, vars, types, then funcs), then finally alphabetically.

Test helpers

Often, we provide test packages that aid in the creation of tests that interact with our other packages. For example, the support/db package has the support/db/dbtest package underneath it that contains elements that make it easier to test code that accesses a SQL database. We've found that this pattern of having a separate test package maximizes flexibility and simplifies package dependencies.

Contributing

Contributions are welcome! See CONTRIBUTING.md for more details.

Developing

See DEVELOPING.md for helpful instructions for getting started developing code in this repository.

1.1.1

Creating equitable access to the global financial system

DigitalBits Go Monorepo

This repo is the home for all of the public Go code produced by the XDB Foundation.

This repo contains various tools and services that you can use and deploy, as well as the SDK you can use to develop applications that integrate with the DigitalBits network.

Package Index

• Frontier Server: Full-featured API server for DigitalBits network
• Go Frontier SDK - frontierclient: Client for Frontier server (queries and transaction submission)
• Go Frontier SDK - txnbuild: Construct DigitalBits transactions and operations
• Ticker: An API server that provides statistics about assets and markets on the DigitalBits network
• Keystore: An API server that is used to store and manage encrypted keys for DigitalBits client applications
• Servers for Anchors & Financial Institutions
  • Compliance Server: Allows financial institutions to exchange KYC information
  • Federation Server: Allows organizations to provide addresses for users (jane*examplebank.com)

Dependencies

This repository is officially supported on the last two releases of Go.

It depends on a number of external dependencies, and uses Go Modules to manage them. Running any go command will automatically download dependencies required for that operation.

You can choose to checkout this repository into a GOPATH or into any directory.

Directory Layout

In addition to the other top-level packages, there are a few special directories that contain specific types of packages:

• clients contains packages that provide client packages to the various DigitalBits services.
• exp contains experimental packages. Use at your own risk.
• handlers contains packages that provide pluggable implementors of http.Handler that make it easier to incorporate portions of the DigitalBits protocol into your own http server.
• support contains packages that are not intended for consumption outside of DigitalBits's other packages. Packages that provide common infrastructure for use in our services and tools should go here, such as db or log.
• support/scripts contains single-file go programs and bash scripts used to support the development of this repo.
• services contains packages that compile to applications that are long-running processes (such as API servers).
• tools contains packages that compile to command line applications.

Each of these directories have their own README file that explain further the nature of their contents.

Other packages

In addition to the packages described above, this repository contains various packages related to working with the DigitalBits network from a go program. It's recommended that you use godoc to browse the documentation for each.

Package source layout

While much of the code in individual packages is organized based upon different developers' personal preferences, many of the packages follow a simple convention for organizing the declarations inside of a package that aim to aid in your ability to find code.

In each package, there may be one or more of a set of common files:

• errors.go: This file should contains declarations (both types and vars) for errors that are used by the package.
• example_test.go: This file should contains example tests, as described at https://blog.golang.org/examples.
• main.go/internal.go (deprecated): Older packages may have a main.go (public symbols) or internal.go (private symbols). These files contain, respectively, the exported and unexported vars, consts, types and funcs for the package. New packages do not follow this pattern, and instead follow the standard Go convention to co-locate structs and their methods in the same files.
• main.go (new convention): If present, this file contains a main function as part of an executable main package.

In addition to the above files, a package often has files that contains code that is specific to one declared type. This file uses the snake case form of the type name (for example loggly_hook.go would correspond to the type LogglyHook). This file should contain method declarations, interface implementation assertions and any other declarations that are tied solely to that type.

Each non-test file can have a test counterpart like normal, whose name ends with _test.go. The common files described above also have their own test counterparts... for example internal_test.go should contains tests that test unexported behavior and more commonly test helpers that are unexported.

Generally, file contents are sorted by exported/unexported, then declaration type (ordered as consts, vars, types, then funcs), then finally alphabetically.

Test helpers

Often, we provide test packages that aid in the creation of tests that interact with our other packages. For example, the support/db package has the support/db/dbtest package underneath it that contains elements that make it easier to test code that accesses a SQL database. We've found that this pattern of having a separate test package maximizes flexibility and simplifies package dependencies.

Contributing

Contributions are welcome! See CONTRIBUTING.md for more details.

Developing

See DEVELOPING.md for helpful instructions for getting started developing code in this repository.

1.1.1-beta.1

Creating equitable access to the global financial system

DigitalBits Go Monorepo

This repo is the home for all of the public Go code produced by the XDB Foundation.

This repo contains various tools and services that you can use and deploy, as well as the SDK you can use to develop applications that integrate with the DigitalBits network.

Package Index

• Frontier Server: Full-featured API server for DigitalBits network
• Go Frontier SDK - frontierclient: Client for Frontier server (queries and transaction submission)
• Go Frontier SDK - txnbuild: Construct DigitalBits transactions and operations
• Ticker: An API server that provides statistics about assets and markets on the DigitalBits network
• Keystore: An API server that is used to store and manage encrypted keys for DigitalBits client applications
• Servers for Anchors & Financial Institutions
  • Compliance Server: Allows financial institutions to exchange KYC information
  • Federation Server: Allows organizations to provide addresses for users (jane*examplebank.com)

Dependencies

This repository is officially supported on the last two releases of Go.

It depends on a number of external dependencies, and uses Go Modules to manage them. Running any go command will automatically download dependencies required for that operation.

You can choose to checkout this repository into a GOPATH or into any directory.

Directory Layout

In addition to the other top-level packages, there are a few special directories that contain specific types of packages:

• clients contains packages that provide client packages to the various DigitalBits services.
• exp contains experimental packages. Use at your own risk.
• handlers contains packages that provide pluggable implementors of http.Handler that make it easier to incorporate portions of the DigitalBits protocol into your own http server.
• support contains packages that are not intended for consumption outside of DigitalBits's other packages. Packages that provide common infrastructure for use in our services and tools should go here, such as db or log.
• support/scripts contains single-file go programs and bash scripts used to support the development of this repo.
• services contains packages that compile to applications that are long-running processes (such as API servers).
• tools contains packages that compile to command line applications.

Each of these directories have their own README file that explain further the nature of their contents.

Other packages

In addition to the packages described above, this repository contains various packages related to working with the DigitalBits network from a go program. It's recommended that you use godoc to browse the documentation for each.

Package source layout

While much of the code in individual packages is organized based upon different developers' personal preferences, many of the packages follow a simple convention for organizing the declarations inside of a package that aim to aid in your ability to find code.

In each package, there may be one or more of a set of common files:

• errors.go: This file should contains declarations (both types and vars) for errors that are used by the package.
• example_test.go: This file should contains example tests, as described at https://blog.golang.org/examples.
• main.go/internal.go (deprecated): Older packages may have a main.go (public symbols) or internal.go (private symbols). These files contain, respectively, the exported and unexported vars, consts, types and funcs for the package. New packages do not follow this pattern, and instead follow the standard Go convention to co-locate structs and their methods in the same files.
• main.go (new convention): If present, this file contains a main function as part of an executable main package.

In addition to the above files, a package often has files that contains code that is specific to one declared type. This file uses the snake case form of the type name (for example loggly_hook.go would correspond to the type LogglyHook). This file should contain method declarations, interface implementation assertions and any other declarations that are tied solely to that type.

Each non-test file can have a test counterpart like normal, whose name ends with _test.go. The common files described above also have their own test counterparts... for example internal_test.go should contains tests that test unexported behavior and more commonly test helpers that are unexported.

Generally, file contents are sorted by exported/unexported, then declaration type (ordered as consts, vars, types, then funcs), then finally alphabetically.

Test helpers

Often, we provide test packages that aid in the creation of tests that interact with our other packages. For example, the support/db package has the support/db/dbtest package underneath it that contains elements that make it easier to test code that accesses a SQL database. We've found that this pattern of having a separate test package maximizes flexibility and simplifies package dependencies.

Contributing

Contributions are welcome! See CONTRIBUTING.md for more details.

Developing

See DEVELOPING.md for helpful instructions for getting started developing code in this repository.

1.1.1-beta.0

Creating equitable access to the global financial system

DigitalBits Go Monorepo

This repo is the home for all of the public Go code produced by the XDB Foundation.

This repo contains various tools and services that you can use and deploy, as well as the SDK you can use to develop applications that integrate with the DigitalBits network.

Package Index

• Frontier Server: Full-featured API server for DigitalBits network
• Go Frontier SDK - frontierclient: Client for Frontier server (queries and transaction submission)
• Go Frontier SDK - txnbuild: Construct DigitalBits transactions and operations
• Ticker: An API server that provides statistics about assets and markets on the DigitalBits network
• Keystore: An API server that is used to store and manage encrypted keys for DigitalBits client applications
• Servers for Anchors & Financial Institutions
  • Compliance Server: Allows financial institutions to exchange KYC information
  • Federation Server: Allows organizations to provide addresses for users (jane*examplebank.com)

Dependencies

This repository is officially supported on the last two releases of Go.

It depends on a number of external dependencies, and uses Go Modules to manage them. Running any go command will automatically download dependencies required for that operation.

You can choose to checkout this repository into a GOPATH or into any directory.

Directory Layout

In addition to the other top-level packages, there are a few special directories that contain specific types of packages:

• clients contains packages that provide client packages to the various DigitalBits services.
• exp contains experimental packages. Use at your own risk.
• handlers contains packages that provide pluggable implementors of http.Handler that make it easier to incorporate portions of the DigitalBits protocol into your own http server.
• support contains packages that are not intended for consumption outside of DigitalBits's other packages. Packages that provide common infrastructure for use in our services and tools should go here, such as db or log.
• support/scripts contains single-file go programs and bash scripts used to support the development of this repo.
• services contains packages that compile to applications that are long-running processes (such as API servers).
• tools contains packages that compile to command line applications.

Each of these directories have their own README file that explain further the nature of their contents.

Other packages

In addition to the packages described above, this repository contains various packages related to working with the DigitalBits network from a go program. It's recommended that you use godoc to browse the documentation for each.

Package source layout

While much of the code in individual packages is organized based upon different developers' personal preferences, many of the packages follow a simple convention for organizing the declarations inside of a package that aim to aid in your ability to find code.

In each package, there may be one or more of a set of common files:

• errors.go: This file should contains declarations (both types and vars) for errors that are used by the package.
• example_test.go: This file should contains example tests, as described at https://blog.golang.org/examples.
• main.go/internal.go (deprecated): Older packages may have a main.go (public symbols) or internal.go (private symbols). These files contain, respectively, the exported and unexported vars, consts, types and funcs for the package. New packages do not follow this pattern, and instead follow the standard Go convention to co-locate structs and their methods in the same files.
• main.go (new convention): If present, this file contains a main function as part of an executable main package.

In addition to the above files, a package often has files that contains code that is specific to one declared type. This file uses the snake case form of the type name (for example loggly_hook.go would correspond to the type LogglyHook). This file should contain method declarations, interface implementation assertions and any other declarations that are tied solely to that type.

Each non-test file can have a test counterpart like normal, whose name ends with _test.go. The common files described above also have their own test counterparts... for example internal_test.go should contains tests that test unexported behavior and more commonly test helpers that are unexported.

Generally, file contents are sorted by exported/unexported, then declaration type (ordered as consts, vars, types, then funcs), then finally alphabetically.

Test helpers

Often, we provide test packages that aid in the creation of tests that interact with our other packages. For example, the support/db package has the support/db/dbtest package underneath it that contains elements that make it easier to test code that accesses a SQL database. We've found that this pattern of having a separate test package maximizes flexibility and simplifies package dependencies.

Contributing

Contributions are welcome! See CONTRIBUTING.md for more details.

Developing

See DEVELOPING.md for helpful instructions for getting started developing code in this repository.

1.1.0

Frontier 1.1.0

Welcome to this major upgrade! We're excited to bring you a range of new features, improvements, and fixes. This release represents a significant step forward in our efforts to improve Frontier, providing support for Protocol 18 (CAP 38: Automated Market Makers), and introducing a number of important updates. We've worked hard to optimize the system's performance and make it easier to use, while also adding powerful new capabilities. Let's dive into the details.

Upgrades and Migrations

Upgrading to this version from <= v1.0.x will trigger a state rebuild. During this process (which will take at least 10 minutes), Frontier will not ingest new ledgers.

This release introduces multiple DB migrations:

1. Removal of offer_id field from history_trades table and addition of new tables related to Automated Market Makers (AMM). It should not take more than 15 minutes to complete this migration.
2. Addition of columns to the history_trades table to enable filtering trades by "rounding slippage". As this is a large table, migration may take a significant amount of time depending on your DB hardware.
3. The addition of columns to the history_trades table to enable filtering trades by "rounding slippage". Due to the large size of the table, this migration may take considerable time, depending on your DB hardware. It's advised to test the migrations execution time on a copy of your production DB first.
4. DB Schema Migration introduces new tables: account_filter_rules, asset_filter_rules and txsub_results. This migration should execute quickly.

New Features

• Protocol 18 (CAP 38: Automated Market Makers) support.
• New frontier flag --max-assets-per-path-request (15 by default).
• New endpoint /liquidity_pools?account={account_id}.
• New command frontier db fill-gaps to fill any gaps in history in the frontier db.
• Muxed Accounts (SEP-23) are now enabled by default.
• Enable captive core based ingestion to use remote DB persistence rather than in-memory for ledger states. This feature essentially moves what would have been stored in RAM to the external DB instead. Use the new command line flag --captive-core-use-db=true to enable this feature.
• New experimental feature: Ingestion Filters. These filters provide the ability to select which ledger transactions are accepted at ingestion time to be stored on Horizon's historical database. Filter rules can be defined through the Admin API and include 'whitelist by account id' and 'whitelist by canonical asset id'.
• Added disable-path-finding Horizon flag to disable the path finding endpoints. This flag should be enabled on ingesting Horizon instances which do not serve HTTP traffic.

Breaking Changes

Multiple breaking changes are included that will activate on Protocol 18 upgrade. Check the Frontier Liquidity Pool API doc for more information. Ensure to upgrade to the latest SDKs that are backward compatible.

Improvements and Changes

• Numerous performance improvements made in various areas including /paths endpoint, state ingestion processors, and XDR encoding.
• Changes in API related to Automated Market Makers as outlined in Frontier Liquidity Pool API doc.
• Multiple new Prometheus metrics added including round_trip_time_seconds, state_verify_ledger_entries_count, ledger_fetch_duration_seconds, and ProcessorsRunDurationSummary.
• Updates and improvements made to error handling, logging, and commands.
• XDR encoding/decoding pipelines have been optimized for better performance.

Fixes

• Improved error parsing from Captive Core.
• Prevented duplicate errors related to liquidity pool tables during repeated reingestion of the same range.
• Exclude trades with high "rounding slippage" from /trade_aggregations endpoint.
• Released DB connection in /paths when no longer needed.
• Fixed false positive warning during orderbook verification in the Horizon log output whenever the in-memory orderbook is inconsistent with the postgres liquidity pool and offers table.
• Postgres connections for non ingesting Horizon instances are now configured to timeout on long running queries / transactions.

Please review the release notes thoroughly and test this upgrade on your testing environment before deploying in production. As always, we appreciate your valuable feedback. Enjoy the new features!

1.0.154-beta.3

Creating equitable access to the global financial system

DigitalBits Go Monorepo

This repo is the home for all of the public Go code produced by the XDB Foundation.

This repo contains various tools and services that you can use and deploy, as well as the SDK you can use to develop applications that integrate with the DigitalBits network.

Package Index

• Frontier Server: Full-featured API server for DigitalBits network
• Go Frontier SDK - frontierclient: Client for Frontier server (queries and transaction submission)
• Go Frontier SDK - txnbuild: Construct DigitalBits transactions and operations
• Ticker: An API server that provides statistics about assets and markets on the DigitalBits network
• Keystore: An API server that is used to store and manage encrypted keys for DigitalBits client applications
• Servers for Anchors & Financial Institutions
  • Compliance Server: Allows financial institutions to exchange KYC information
  • Federation Server: Allows organizations to provide addresses for users (jane*examplebank.com)

Dependencies

This repository is officially supported on the last two releases of Go.

It depends on a number of external dependencies, and uses Go Modules to manage them. Running any go command will automatically download dependencies required for that operation.

You can choose to checkout this repository into a GOPATH or into any directory.

Directory Layout

In addition to the other top-level packages, there are a few special directories that contain specific types of packages:

• clients contains packages that provide client packages to the various DigitalBits services.
• exp contains experimental packages. Use at your own risk.
• handlers contains packages that provide pluggable implementors of http.Handler that make it easier to incorporate portions of the DigitalBits protocol into your own http server.
• support contains packages that are not intended for consumption outside of DigitalBits's other packages. Packages that provide common infrastructure for use in our services and tools should go here, such as db or log.
• support/scripts contains single-file go programs and bash scripts used to support the development of this repo.
• services contains packages that compile to applications that are long-running processes (such as API servers).
• tools contains packages that compile to command line applications.

Each of these directories have their own README file that explain further the nature of their contents.

Other packages

In addition to the packages described above, this repository contains various packages related to working with the DigitalBits network from a go program. It's recommended that you use godoc to browse the documentation for each.

Package source layout

While much of the code in individual packages is organized based upon different developers' personal preferences, many of the packages follow a simple convention for organizing the declarations inside of a package that aim to aid in your ability to find code.

In each package, there may be one or more of a set of common files:

• errors.go: This file should contains declarations (both types and vars) for errors that are used by the package.
• example_test.go: This file should contains example tests, as described at https://blog.golang.org/examples.
• main.go/internal.go (deprecated): Older packages may have a main.go (public symbols) or internal.go (private symbols). These files contain, respectively, the exported and unexported vars, consts, types and funcs for the package. New packages do not follow this pattern, and instead follow the standard Go convention to co-locate structs and their methods in the same files.
• main.go (new convention): If present, this file contains a main function as part of an executable main package.

In addition to the above files, a package often has files that contains code that is specific to one declared type. This file uses the snake case form of the type name (for example loggly_hook.go would correspond to the type LogglyHook). This file should contain method declarations, interface implementation assertions and any other declarations that are tied solely to that type.

Each non-test file can have a test counterpart like normal, whose name ends with _test.go. The common files described above also have their own test counterparts... for example internal_test.go should contains tests that test unexported behavior and more commonly test helpers that are unexported.

Generally, file contents are sorted by exported/unexported, then declaration type (ordered as consts, vars, types, then funcs), then finally alphabetically.

Test helpers

Often, we provide test packages that aid in the creation of tests that interact with our other packages. For example, the support/db package has the support/db/dbtest package underneath it that contains elements that make it easier to test code that accesses a SQL database. We've found that this pattern of having a separate test package maximizes flexibility and simplifies package dependencies.

Contributing

Contributions are welcome! See CONTRIBUTING.md for more details.

Developing

See DEVELOPING.md for helpful instructions for getting started developing code in this repository.

1.0.154

Creating equitable access to the global financial system

DigitalBits Go Monorepo

This repo is the home for all of the public Go code produced by the XDB Foundation.

This repo contains various tools and services that you can use and deploy, as well as the SDK you can use to develop applications that integrate with the DigitalBits network.

Package Index

• Frontier Server: Full-featured API server for DigitalBits network
• Go Frontier SDK - frontierclient: Client for Frontier server (queries and transaction submission)
• Go Frontier SDK - txnbuild: Construct DigitalBits transactions and operations
• Ticker: An API server that provides statistics about assets and markets on the DigitalBits network
• Keystore: An API server that is used to store and manage encrypted keys for DigitalBits client applications
• Servers for Anchors & Financial Institutions
  • Compliance Server: Allows financial institutions to exchange KYC information
  • Federation Server: Allows organizations to provide addresses for users (jane*examplebank.com)

Dependencies

This repository is officially supported on the last two releases of Go.

It depends on a number of external dependencies, and uses Go Modules to manage them. Running any go command will automatically download dependencies required for that operation.

You can choose to checkout this repository into a GOPATH or into any directory.

Directory Layout

In addition to the other top-level packages, there are a few special directories that contain specific types of packages:

• clients contains packages that provide client packages to the various DigitalBits services.
• exp contains experimental packages. Use at your own risk.
• handlers contains packages that provide pluggable implementors of http.Handler that make it easier to incorporate portions of the DigitalBits protocol into your own http server.
• support contains packages that are not intended for consumption outside of DigitalBits's other packages. Packages that provide common infrastructure for use in our services and tools should go here, such as db or log.
• support/scripts contains single-file go programs and bash scripts used to support the development of this repo.
• services contains packages that compile to applications that are long-running processes (such as API servers).
• tools contains packages that compile to command line applications.

Each of these directories have their own README file that explain further the nature of their contents.

Other packages

In addition to the packages described above, this repository contains various packages related to working with the DigitalBits network from a go program. It's recommended that you use godoc to browse the documentation for each.

Package source layout

While much of the code in individual packages is organized based upon different developers' personal preferences, many of the packages follow a simple convention for organizing the declarations inside of a package that aim to aid in your ability to find code.

In each package, there may be one or more of a set of common files:

• errors.go: This file should contains declarations (both types and vars) for errors that are used by the package.
• example_test.go: This file should contains example tests, as described at https://blog.golang.org/examples.
• main.go/internal.go (deprecated): Older packages may have a main.go (public symbols) or internal.go (private symbols). These files contain, respectively, the exported and unexported vars, consts, types and funcs for the package. New packages do not follow this pattern, and instead follow the standard Go convention to co-locate structs and their methods in the same files.
• main.go (new convention): If present, this file contains a main function as part of an executable main package.

In addition to the above files, a package often has files that contains code that is specific to one declared type. This file uses the snake case form of the type name (for example loggly_hook.go would correspond to the type LogglyHook). This file should contain method declarations, interface implementation assertions and any other declarations that are tied solely to that type.

Each non-test file can have a test counterpart like normal, whose name ends with _test.go. The common files described above also have their own test counterparts... for example internal_test.go should contains tests that test unexported behavior and more commonly test helpers that are unexported.

Generally, file contents are sorted by exported/unexported, then declaration type (ordered as consts, vars, types, then funcs), then finally alphabetically.

Test helpers

Often, we provide test packages that aid in the creation of tests that interact with our other packages. For example, the support/db package has the support/db/dbtest package underneath it that contains elements that make it easier to test code that accesses a SQL database. We've found that this pattern of having a separate test package maximizes flexibility and simplifies package dependencies.

Contributing

Contributions are welcome! See CONTRIBUTING.md for more details.

Developing

See DEVELOPING.md for helpful instructions for getting started developing code in this repository.

1.0.154-beta.2

Creating equitable access to the global financial system

DigitalBits Go Monorepo

This repo is the home for all of the public Go code produced by the XDB Foundation.

This repo contains various tools and services that you can use and deploy, as well as the SDK you can use to develop applications that integrate with the DigitalBits network.

Package Index

• Frontier Server: Full-featured API server for DigitalBits network
• Go Frontier SDK - frontierclient: Client for Frontier server (queries and transaction submission)
• Go Frontier SDK - txnbuild: Construct DigitalBits transactions and operations
• Ticker: An API server that provides statistics about assets and markets on the DigitalBits network
• Keystore: An API server that is used to store and manage encrypted keys for DigitalBits client applications
• Servers for Anchors & Financial Institutions
  • Compliance Server: Allows financial institutions to exchange KYC information
  • Federation Server: Allows organizations to provide addresses for users (jane*examplebank.com)

Dependencies

This repository is officially supported on the last two releases of Go.

It depends on a number of external dependencies, and uses Go Modules to manage them. Running any go command will automatically download dependencies required for that operation.

You can choose to checkout this repository into a GOPATH or into any directory.

Directory Layout

In addition to the other top-level packages, there are a few special directories that contain specific types of packages:

• clients contains packages that provide client packages to the various DigitalBits services.
• exp contains experimental packages. Use at your own risk.
• handlers contains packages that provide pluggable implementors of http.Handler that make it easier to incorporate portions of the DigitalBits protocol into your own http server.
• support contains packages that are not intended for consumption outside of DigitalBits's other packages. Packages that provide common infrastructure for use in our services and tools should go here, such as db or log.
• support/scripts contains single-file go programs and bash scripts used to support the development of this repo.
• services contains packages that compile to applications that are long-running processes (such as API servers).
• tools contains packages that compile to command line applications.

Each of these directories have their own README file that explain further the nature of their contents.

Other packages

In addition to the packages described above, this repository contains various packages related to working with the DigitalBits network from a go program. It's recommended that you use godoc to browse the documentation for each.

Package source layout

While much of the code in individual packages is organized based upon different developers' personal preferences, many of the packages follow a simple convention for organizing the declarations inside of a package that aim to aid in your ability to find code.

In each package, there may be one or more of a set of common files:

• errors.go: This file should contains declarations (both types and vars) for errors that are used by the package.
• example_test.go: This file should contains example tests, as described at https://blog.golang.org/examples.
• main.go/internal.go (deprecated): Older packages may have a main.go (public symbols) or internal.go (private symbols). These files contain, respectively, the exported and unexported vars, consts, types and funcs for the package. New packages do not follow this pattern, and instead follow the standard Go convention to co-locate structs and their methods in the same files.
• main.go (new convention): If present, this file contains a main function as part of an executable main package.

In addition to the above files, a package often has files that contains code that is specific to one declared type. This file uses the snake case form of the type name (for example loggly_hook.go would correspond to the type LogglyHook). This file should contain method declarations, interface implementation assertions and any other declarations that are tied solely to that type.

Each non-test file can have a test counterpart like normal, whose name ends with _test.go. The common files described above also have their own test counterparts... for example internal_test.go should contains tests that test unexported behavior and more commonly test helpers that are unexported.

Generally, file contents are sorted by exported/unexported, then declaration type (ordered as consts, vars, types, then funcs), then finally alphabetically.

Test helpers

Often, we provide test packages that aid in the creation of tests that interact with our other packages. For example, the support/db package has the support/db/dbtest package underneath it that contains elements that make it easier to test code that accesses a SQL database. We've found that this pattern of having a separate test package maximizes flexibility and simplifies package dependencies.

Contributing

Contributions are welcome! See CONTRIBUTING.md for more details.

Developing

See DEVELOPING.md for helpful instructions for getting started developing code in this repository.