Hub Update: Easily Integrate IOTA With Your Exchange, Custody Solution, Or Product

Update: IOTA Hub is deprecated with the Chrysalis network upgrade and will no longer work with the protocol changes. If you still use Hub, we ask you to have a look at our migration guide to upgrade your integration of IOTA. For a new exchange integration of IOTA read the exchange guide

Even though we are building IOTA for a world where machines can communicate seamlessly with one another, it is incredibly important that we take a step back to make sure that the usability of our technology suits the needs of the humans who are building with us. Known as User Experience, or UX, this philosophy is a critical component of adoption for most systems.

That’s why we’ve been revisiting some of our core components to see how we can make integration and development for integration partners easier. One area is with exchange partners and partners who wish to integrate an IOTA wallet into their product or service.

Unlike Nakamoto consensus blockchains or ERC20 clones, the Tangle has its own technical architecture that makes it well suited for real-world use-cases. A consequence of our uniqueness, however, is that technical teams must learn ‘yet another’ technology during the integration process. We understand that this can be difficult, so we want to make sure that our documentation, our support, and our process for set up is as easy as possible.

Today we have IOTA Hub, and it’s been an incredibly helpful tool. Hub allows integration teams to manage multiple IOTA wallets and corresponding seeds simultaneously. Hub also takes care of creating deposit addresses and makes sure that when an address is used, the transaction gets promoted or re-attached if required.

After some re-evaluation, we realized there are some areas where we could improve the Hub experience, and took the time to build four new features to make it even easier to integrate IOTA into your exchange, custody solution, or product.

With these four features, our development team was able to integrate into a test exchange in less than 3 hours!  

Feature 1: A REST/JSON API next to our existing gRPC API

In our previous version, services could communicate with HUB version using gRPC, a modern and high-performance way to call functions regardless of the programming language used. While technically sound, the technology is relatively new and unknown to many developers, adding a hurdle to working with Hub by requiring integration teams to learn a new technology. Compared to the relatively unknown gRPC, everyone is familiar with REST/JSON based API’s, so we’ve decided to include this as an option for integration teams more familiar with the REST/JSON technology. The gRPC API will continue to be available as an option, so your team can decide between convenience and maximum performance.

Feature 2: An endpoint for checking withdrawal addresses

The original version of Hub checked if the withdrawal address provided is valid and if it has not been spent from the moment you issue a withdrawal request. While the current iteration is fine, it is difficult to check the validity of an address before issuing the withdrawal command. This could only be done using a client library.

In this new version of Hub, there is a call for this command, taking away the need for a client library altogether. The new “WasAddressSpentFrom” call is now available and can be used to check the checksum of the provided address and whether it hasn’t been spent from.  

Feature 3: An endpoint for recovering funds

As some of you already know, Hub manages addresses for you. Once funds are received on an address, they are automatically moved (using a method known as a “sweep”) to another internal address in Hub. As soon as the funds are moved, the address is considered “used” and shouldn’t receive funds in the future. If this happens by chance (Trinity has some built-in protection to prevent this but not everyone uses Trinity yet) the funds are stuck in that address.

In our previous version, we provided a script to recover funds from these addresses managed by Hub, however, it was quite difficult to use.

As of this release, we are adding a new “RecoverFunds”function, making it a lot easier for your team to recover funds should they be sent to an already used address.  

Feature 4: Hub Docker Image

To save some time compiling Hub and setting up a server we now have a Docker alternative for Hub available as well. This makes it even faster to deploy a Hub setup without having to set up a whole new server with all dependencies. The Hub docker image is called `iotacafe/hub` and the latest builds can be found here (https://hub.docker.com/r/iotacafe/hub/tags?page=1&ordering=last_updated).

For the entire feature list for HUB, you can visit the HUB documentation page .

To demonstrate how fast and easy it is to integrate IOTA using Hub, we’ve made a video tutorial demonstrating how Hub can be integrated into a dummy exchange. The video can be found here:

Once you’ve gone through the HUB documentation, we recommend reaching out to us if any questions arise, or if you feel like you need our support. The IOTA Foundation is happy to work with your team to resolve any issues that appear during the integration process. We also have a dedicated Discord channel called #hub-discussion on discord.iota.org, which anyone is welcome to join.

This may seem like a small update, but it is part of a larger effort to optimize our approach with a more user-centric development methodology. We know that some integration partners thought our Hub technology was too complicated, and with this update, we hope we’ve made the process even easier.

We hope you enjoy using out the new version of Hub!