Design Philosophy of the SubQuery Network

The guiding principle of the SubQuery Network is simplicity and flexibility for different use cases, payment methods, and networks. While other data services have many different major network participants, SubQuery focuses on three key ones. While other networks have complicated algorithmic signalling mechanisms, SubQuery relies on the most fundamental signal, consumer demand. While other networks provide only one type of payment model (generally PAYG), SubQuery provides several advanced subscription based options for Consumers and Node Operators, And finally, while other networks only support one layer-1 chain, SubQuery is designed to be multi-chain from the outset.

Different types of Infrastructure

Web3 middleware services like indexers, RPCs, oracles and storage services are pivotal in blockchain dApp development. In fact, the utilisation of these middleware services is what sets apart successful, large-scale, production dApps - they accelerate performance and can scale to thousands of users, while providing a superior developer experience to bring in more users, TVL, and value. Indexers and RPCs shoulder the heavy lifting, standing as mission-critical services that underpin the functionality and efficiency of web3 applications.

Knowing that the SubQuery Network could give our existing community of top node runners a solution to trustlessly receive rewards for running data indexing infrastructure, why couldn’t it work for those other services, for other parts of the dApp tech stack?

We realised the full potential of the SubQuery Network mainnet should not be limited to just data indexing; its fundamental contracts, tools, and reward flows enable it to be so much more. By harnessing the power of the existing participants and mechanisms, the SubQuery Network is ready to extend to various infrastructure verticals. It dawned on us that there is a massive opportunity ahead of us when we think holistically about the entire developer experience.

Our next step is to decentralise the biggest infrastructure component for dApps - Remote Procedure Call or RPC services.

Multi-Chain by Design

SubQuery believes in the idea that a community of blockchains, working together to encourage web3 adoption, is the future.

SubQuery is multi-chain. SubQuery knows that there are going to be many different blockchains working together to solve different problems. The plan is to take SubQuery and to adapt it to work for other blockchains that don't have sufficient indexing solutions - to support builders wherever they decide to build and launch their dApps.

The SubQuery Network is designed to support any SubQuery Project from any Layer 1 network within it. It will be designed and built to be multi-chain from the outset, where you will see projects from one network being indexed alongside projects from another.

SubQuery currently supports over 150 chains, with many more being added each week.

Simple and Accessible

The SubQuery Network is designed to be the data provider of the people.

The guiding principle of the SubQuery Network is simplicity. It is SubQuery’s opinion that other approaches to decentralised data query services are overly complex and make it difficult for participants to predict their return on investment. The aim is to make it easy for you to get involved in the network, and to clearly forecast your future potential return.

It is planned that the SubQuery Network won’t require high staking thresholds to participate or huge investment into hardware. The focus will be on making SubQuery easier to join and build with than other data providers - SubQuery’s success depends on the success of others creating the future on it.

This means that a design goal is to make it as easy as possible for anyone to participate. You don’t need to be a developer or have a deep knowledge of the token economic model, you can easily participate as a Delegator. As a Consumer, you also have plenty of payment options to best suit your needs. Finally, a key focus of the SubQuery Foundation is to ensure that there is enough support that anyone, from an expert blockchain team to a new hobbyist developer, can build their own SubQuery project.

Flexible

SubQuery is just a tool in the hands of our community, endless opportunities exist limited only by the creativity of the people.

The potential of SubQuery may lie in its flexibility - users will have the freedom to adapt and transform decentralised data to suit their needs. dApp developers need data in a specific format tailored for their dApp for ease of development and to set it apart from others.

Unlike other “unified” decentralised API service providers, SubQuery is open source, so Consumers will have the freedom to define their data set specifically for their needs. Rather than having to combine queries from different API endpoints - the creators and consumers of SubQuery projects can define the shape of their APIs data models themselves. It saves time, money, and provides a vastly better experience for end-users.

Natural Demand Signalling and Different Payment Options

With marketplaces like what SubQuery is proposing, where there are both buyers and sellers attempting to commoditise data, signalling demand for future supply tends to be a tricky issue. Other networks create an artificial role in an attempt to predict future demand, and they’re rewarded when that future demand materialises. The plan is to take a different approach, one that requires up-front natural demand signalling.

A Consumer can take advantage of either Open or Closed Service Agreements to concretely indicate and commit demand for a new SubQuery Project. This will facilitate and encourage supply at a fixed price and volume (essentially helping secure pre-allocated rewards for Data Indexers of a SubQuery Project) and provide price and service certainty to both parties. This can be used both to attract Data Indexers to new SubQuery Projects, or to attract additional Data Indexers to existing and uncompetitive SubQuery Projects.

It additionally provides several advanced subscription based options for Consumers and Indexers. Some parties may benefit from the certainty of rewards provided by Closed Agreements and the predictability of recurring costs. Some may instead prefer to hunt out the most affordable data by going for high volume recurring agreements or low spot prices on the Pay as you Go market.

Node Operator/Delegator Imbalance

Among some competitors, it is observed that there is a serious imbalance between Node Operators and Delegators in terms of the ability to change delegation rates without warning. SubQuery has tried to equalise this imbalance by requiring that the Node Operator advertise an increase to the Node Operator Commission Rate for an entire staking Era. Delegators are also free to withdraw their delegated tokens at any point during the staking Era, but they will lose any rewards that they could have been eligible for during that Era.

Incentives for Query Performance

To become a high-performing, mission-critical platform - the SubQuery Network must operate at the highest level. That is why the Node Operator discovery process will include performance data (latency and uptime) for all Node Operators, and we will take steps to ensure that Consumers report on query speed and performance as often as possible.

Tools may also be provided to limit the availability of Node Operators to a certain geographical region so that they can focus on providing the best service to that region, attract the most requests, and potentially maximise rewards for their contributions. This will allow larger and more mature Node Operators to run location specific infrastructure all around the world.