The Publisher role on Syntropy Data Layer economy

Syntropy is reshaping how the world uses blockchain data. As the first On-Chain Streaming Oracle for Web3, Syntropy is bringing real-time, multi-chain data access to life.

TECHNOLOGY
Syntropy's On-Chain Streaming Oracle, powered by our proprietary tech stack, offers seamless access to real-time and historical on-chain data. We're transforming the landscape by eliminating dependence on centralized data services, delivering multi-chain data with lightning-fast speed.

ECOSYSTEM
Syntropy's ecosystem is a vibrant mix of data publishers, developers, applications, and end-users. All collaboratively employing the Data Layer to ensure swift and seamless access to real-time, historical on-chain data. It's an ecosystem committed to democratizing blockchain data access for everyone.

TEAM
What began as NOIA, an ambitious effort from a small group of eager individuals, eventually evolved into something much larger: Syntropy. Our efforts no longer represent a single project or application. This is a global movement to change how on-chain data is accessed for the better.
‍
The Syntropy ecosystem is developed and managed by open-source developers from around the world, supported by an executive team which includes Daniel Haudenschild (CEO), Dom Povilauskas (Vision & Strategy), Jonas Simanavicius (CTO), Domantas Jaskunas (COO), and Kipras Kazlauskas (CFO). The Syntropy board of directors consists of veteran developers, blockchain experts, and leaders at Fortune 500 companies

Publishing the subjects

​
The role of Publishers is to publish streams of data to the Broker network. A stream of messages has to have a subject, which is basically its name. The goal is to create an open and competing market for Publishers, therefore, there is no limit to the subjects that Publishers can publish.

An example of a subject is syntropy.ethereum.*, where syntropy is the name of the entity, i.e. Publisher’s owner, and ethereum is the name of the Publisher’s App. A single subject might have multiple tokens after these two initial prefixes, such as syntropy.ethereum.txs and syntropy.ethereum.logs.

Broker network is based on the messaging technology called NATS. In NATS terminology, tokens are words between the dots. Two wildcards, * and >, can be used to denote complex multi-token subjects. For instance, subject entityname.appname.swap.> would automatically enable a stream with multiple subtopics in the form of entityname.appname.swap.weth.usdt and entityname.appname.swap.usdt.weth that provide sorted transaction-based token swap pairs.
Read more about subject construction in NATS documentation and our official guide on how to run a Publisher.

Registering the services

​
Publisher subjects are registered on a chain and each subject is backed up by credit. This happens on the developer portal registration process. A service is an on-chain agreement between the Publisher and its Subscribers, which contains the price of data sent under the subject as well as other crypto-economic variables that ensure that the decentralized agreement is being fulfilled.

After the service is expired by the Publisher, and all the accounting rounds related to it are completed, the credit is returned to the Publisher.

Subjects are priced according to the service agreement. The service is accounted for in bytes and priced per some fixed number of bytes of data, e.g. 1 gigabyte. In theory the pricing could be designed to be per message, however, there are three main reasons why pricing and accounting per bytes were chosen:

1. Broker network costs are inherently attached to the number of bytes relayed.
2. Bytes are a common denominator of all data, the pricing between various Publishers is then easier to compare.
3. Subscribers prefer more sustainable Publishers, who can put the same information in a leaner format because it is cheaper to consume and saves Brokers’ bandwidth as well.

Trust assumptions

​
In the tokenomics v1, the trust of the Publisher has to be taken into account by each Subscriber when subscribing to its subjects. This is exactly the same as the currently existing setup in the RPC node market: clients are purchasing blockchain data from RPC node providers they trust.

Publisher exit

​
When a Publisher wants to exit the Data Layer economy, it would naturally seek to retrieve the tokens it has credited on the chain. However, this requires that all its services are expired and removable. Since the Publisher’s ability to expire the service depends on the demand for the service, the whole exit process can take some time. However, free-of-charge data streams can be closed much faster.

Future work​

CAUTION

All future work is the research and development that is planned, however, this cannot be seen as a commitment to deliver certain features.

Trustless Publishers

​
In the future version of the Syntropy Data Layer protocol, the access to published data should be trustless. This would require that multiple Publishers provide exactly the same data. Within such a setup, the Publisher’s credit has a future use, as it can be slashed if the Publisher fails to send data or sends corrupted data. Additionally, this feature would also improve the exit flow for any individual Publisher who is just one of many sources for the same data.

Credit-based publishing rate

​
The Publisher’s credit can be used as a limiting factor for the publishing rate: the more bytes per second a Publisher wants to push through the Broker network, the more tokens it has to credit. This puts some constraints on Publishers in how they construct their data streams: more data is not always desirable when the same information can fit in a smaller message. Pushing useless data through the network should be avoided when possible, and this would help to mitigate spam.

Credit delegation to the Publishers

​
A possible improvement of the Data Layer protocol would be enabling token delegation to the Publishers. In such a way, Publishers would be able to share some of the profits with their investors. Publishers themselves would profit from more credit bonded to them, as it would allow them to publish more subjects and/or publish at a higher rate (more bytes per second) in general.