Over the past nine months, the ACES team has delivered on many of the original project goals. Let’s take a look at what we wanted to accomplish, see where we’re at, and discuss where we can go next.

In the original blog post titled “Seven Ways We Will Improve ACES” we laid out seven objectives for ACES following our original Ethereum Contract Deployment service. What were those seven items and how have we addressed them?

You can read the original blog post here: https://medium.com/@arkaces/seven-ways-we-will-improve-aces-62dba146610f

Setting up a node was too difficult

To address this, we most recently released the ACES deployment suite which makes it very easy to deploy any of the tools in the ACES infrastructure. You can now simply clone the master deployment repository, find your Ansible playbook, modify the configuration to your needs, and run it. It is extremely easy and takes all the troubleshooting away from the user. We expect to maintain the ansible deployments going forward so that all future services are included in the deployment repository.

2) Finding providers was too difficult.

With the completion of the marketplace, service providers can now quickly register their services on any available marketplace application. Each marketplace application serves as a directory of independent and externally hosted services. This is a huge improvement over the prior model which had all services on independent servers with no way for consumers to find them.

3) Developers didn’t have a clear path to creating their own services.

We developed a number of example services, including bitcoin, ethereum, and ark listeners and channel services. We built ethereum contract deployment services as well. We also released a number of APIs for interacting with services, and wrote deployment guides for each. This allows developers to quickly get a feel for the infrastructure and how to approach the same problems for their own chains. The ARK to ARK services provide a very useful tool for developers launching their own chain with the ARK ecosystem. Using ARK’s ecosystem is the quickest and easiest way to integrate with ACES.

4) Input forms may not be the most convenient for users.

The original intention of this goal was to introduce formless functions that can be called through the ARK wallet. We instead replaced this with a new concept called channel services, which means you simply create a channel with a service and it stay open indefinitely. You can send ARK to the appropriate channel service address and it will act appropriately. This means users will no longer need to use forms after the creation of their contract. The experience is as seamless as possible.

5) There was significant demand for a Bitcoin encoded listener.

Simply put, we built it. This includes a Bitcoin listener and a Bitcoin two-way channel service available in the repo.

6) Transfer services did not function “two-way”

All our services now function with two-way capabilities. But more than that, the services act as channels that are continuously open. This is a huge improvement from what was original considered and the entire user experience is greatly enhanced.

7) Nodes were not trustless.

This feature is still in the works. We are still using a service-provider model like ShapeShift, MorphToken, Changelly, etc. This model is still the industry standard, but we are constantly considering ways to make services trustless through multisig and other features that will become available through ARK in the future.

In summary, we have achieved nearly all of our original goals for ACES, and we hope with the release of these great deployment tools that we will start seeing more users participating in the ecosystem.

If you are a developer or user form another coin community, it may be a good time to explore building services for your coin to integrate into ACES. Feel free to reach out on Slack or Reddit to learn more!