Horizon-as-a-Service as a project is the beginning, we are looking to build a development platform for Stellar like we see with Alchemy and Infura. Our initial focus is on providing production ready infrastructure API endpoints for Horizon API servers and Soroban RPC nodes, as well as managed instances.

We want to make sure we provide a platform that is reliable and developer friendly.

One problem that we are looking to solve is that teams may not want to run their own infrastructure. So we are available to run and manage that for them. Another problem is that other solutions may be cost prohibitive, so we want to provide an affordable option that is more accessible.

Progress

Since our first submission, the majority of our progress has been around research and testing in the following areas:

• Different deployment configurations of the various Stellar software components
• Methods\Solutions for integrating system to track Usage Based Pricing
• Initial Infrastructure as Code templates, Golden images and rough Proof of Concept architecture design
• How to align this project with the competition and overall objectives
• Rough API design and what it means to be API First

Modifications

1. The first modification since we last submitted is around our pricing strategy. We are going with usage-based pricing and were unsure of the strategy the first time around. This should allow customers to start a lower cost, minimizing any barriers to adoption. We want to make sure we make it as accessible as possible. Our primary KPI metric is also Monthly Recurring Revenue, so we believe this also better ties the price paid with the value received.
2. Addition of Soroban RPC nodes to initial launch. Soroban is an important stage in the future of Stellar and it would make sense to have that available at launch. Another factor is that with the current infrastructure templates, it makes it no problem to build and deploy RPC nodes along with Horizon.
3. Focus on API-First design. The thinking behind this is that these first APIs are just the first building blocks of a larger puzzle. It makes sense to think about how they will be consumed in the future as we are getting started.

What's next

1. More community engagement. Some of the feedback that was received focused around the need for more updates and I agree.
2. Looking forward to the release of the API prototype. This will also be a chance for more community engagement to discuss ways to make the process and data received even better heading towards product launch.

What are we trying to deliver for SCF#12? v0

The goal is to have everything in place for users to be able to sign up and receive services from the site. A developer should be able to put in their information and get access to a Horizon instance on all networks or a Soroban RPC node on futurenet. Each deliverable is setting the foundation for the next one after that.

Revenue Model and Funding

Revenue model is based around Usage Based Pricing, this allows users to pay for only what they consume. Continued funding will be based on revenue generated from services. The instances and nodes available will be based on their type: Shared or Dedicated. While examining a lot of the other competition's pricing structure you fall into a couple different camps around Usage Based Pricing: per API call or time used. For Shared instances, we will base the usage on the number of API calls. For Dedicated instances, we will base pricing on hours in use.

Sample Pricing

Shared - Price per API call - $0.0007

Dedicated - Developer level - Price per hour $0.093

This information will need to be captured with the Data and Billing infrastructure that will handle the metering and event storage

Growth

There are fewer developer platforms aimed at Stellar vs other blockchains, this presents an opportunity to build beyond just API access and Nodes. Services like Automated Notifications, Custom Event Streaming or even an Access Marketplace are just a few services that would benefit developers. These other services will also provide additional revenue streams.

KPIs

Our primary metric is Monthly Recurring Revenue, which also allows us to calculate our Burn Rate, Runway and Growth Rate. Our secondary metrics are Retention and Revenue Churn.

Keeping this project going means a heavy focus needs to be made around community engagement and a product in hand to onboard paying customers.

Market & Industry Research

Competition

• Blockdaemon
• Quicknode
• NOWNodes
• Alchemy
• Infura
• Tenderly

Why are we better?

• Our primary focus is on Stellar and Soroban. This will allow us to adopt to changes in the network quickly. We will also be able to go deeper with unique services that would only be available on Stellar.
• Ingestion Filtering by default. Running Horizon with full network history is expensive and the costs will continue to grow. Running Horizon with recent history is preferred and Ingestion Filtering for a list of relevant accounts and assets will also bring down costs.
• Usage Based Pricing. Other providers may only offer core nodes or a standard Horizon interface for a monthly fee. The high prices for nodes create a higher barrier of entry.

SWOT Analysis

Strengths

• Technical experience and knowledge
• Small team will be able to move quickly with changes in the ecosystem

Weaknesses

• Limited financial resources means deployment of funds has to be highly efficient
• Competitors are well funded

Opportunities

• The ecosystem for Soroban is being developed as we speak, this creates opportunities for new projects to start off with Stellar.

Threats

• Market downturns will turn away some developers and that lowers the total available market of potential customers

Marketing and Sales

First customers are developers focused on Stellar, so that means focusing on where they are and creating content they can use. These are the channels we want to focus on right now:

• Participation in Stellar-related Discord servers
• Publishing code to Github (Build product/dev tooling)
• Sharing knowledge through tutorials, blogs and newsletters
• Highlight other community members and projects
• Paid community produced content (Similar to DigitalOcean Write for DOnations)

Immediate Challenges Ahead

• Right sized architecture. In addition to the prerequisites for running Horizon which have various data and hardware requirements. We also have to look at the underlying data infrastructure of the solution. Pulling together and transforming data from various sources to ensure we have visibility into all the metrics. Those are the same metrics we will use for our usage based pricing. So for both the core infrastructure we need to make sure we build the architecture in a way that can scale but also doesn't break the bank before we can get off the ground

The API Prototype is the first deliverable and the foundation

Steps for completion:

• Create hosted resources
• Update API specifications
• Update mock servers
• Deploy PoC nodes
• Update dashboard prototype to display API prototype information

The first deliverable will be made available online, as well as the accompanying documentation.

Platform API documentation

Horizon API documentation

Postman Repo

Postman Workspace

OpenAPI Repo

Mock Server (Best used with Postman or API docs)

Hosted Resource Repo

Dashboard PoC (Mockup)

Futurenet instance

I've included the relevant repos and documentation. The Platform API documentation is currently pointed at a mock server running a version of the OpenAPI spec. There is also a Postman workspace. The Horizon API is taken from the OpenAPI spec used in the Stellar Docs this points to a Quickstart version of futurenet. The Dashboard PoC has not been released as of yet.

As I was going through the process and going through some of the questions on Discord I realized this process could be even simpler. For a shared instance we want to reduce the friction even more. Ask for the minimal amount of information and provide the endpoint needed. This current version of the api doesn't showcase that.

The resources are hosted in Digitalocean on a Hashicorp Nomad cluster. The PoC versions running futurenet use the quickstart versions of our Nomad pack.