Symbiotic’s flexibility enhances nearly any use case through increased security and decentralization while maintaining sovereignty. In this article, we’ll explore how Symbiotic can be integrated into appchain networks. We’ll start by describing an abstract protocol and identify specific areas where Symbiotic infrastructure may provide value.

What’s an Appchain?

Appchains are the same familiar blockchains but are designed with a much narrower scope. Major blockchains, known as generalized blockchains, are typically constructed to allow other protocols to operate on them. However, this can affect factors such as finalization time, transaction costs, stake size for operators, and other issues. For this reason, widely used blockchains may be suitable for a specific project, but they might not be the best choice. The most optimal solution often involves creating a custom application-specific blockchain tailored to address the particular issue. This is a tradeoff, as this blockchain may not be suitable for broader use cases.

A general appchain can be absolutely anything, and the question of its construction is similar to the question of building any arbitrary blockchain. Therefore, we will only consider the main points and features that must be considered when developing your own appchain, such as how and in which situations it can be integrated with Symbiotic, and highlight several interesting areas where an appchain can be beneficial.

Thus, an appchain primarily consists of:

1. Nodes that perform specific tasks.

2. A consensus algorithm among the nodes

3. The state of the appchain.

In addition to the aforementioned points, the following questions arise:

1. What requirements must a node meet to be permitted to operate?

2. What mechanism verifies these requirements, and how does it function?

3. During its operation, a node may generate data. How is this data disseminated across the network, and how is it stored?

Let’s dive in!

Node Requirements

Generally, the requirements for a node affect two essential aspects: liveness and safety. Of course, the network's consensus also influences this, but we will discuss that later. How can the issue of safety be addressed? It is necessary to introduce limiting factors for an operator's entry into the network. For example, this could be a whitelist or a staking requirement. The issue of safety is typically addressed by implementing a system of penalties for offending operators. In general, such penalties can be implemented in various ways, but the most common method is through slashing.

Transmitting Data

Transmitting data is crucial to appchain functionality, especially when integrating with systems like Symbiotic. Appchains need robust mechanisms for both sending and receiving data across networks.

Here, we will explore how communication between an appchain and another network can occur. We have schematically depicted the InputPort as a smart contract/mechanism for receiving data in the network and the OutputPort as a mechanism for transmitting data.

We can categorize data entry into another network into two types: when a specific node records its own data, and when there is a recording of shared data obtained by nodes (this data can be acquired through consensus algorithms, external sources, TEE, etc.). It is necessary to distinguish between these two types on the side of the other network, as the mechanisms for processing them may differ.

On the other hand, it is also necessary to implement a mechanism for receiving data from another network. For example, this could include information about user deposits, operator stakes, or price oracle data. There are numerous ways to implement this. One option is to incorporate such data processing into a light client so that most nodes will arrive at the same value simply through the consensus mechanism. Additionally, a bridge or a trusted party could disseminate information between nodes.

Storing Data

The last aspect we will examine is how an appchain can store data. There can be many different approaches to this. An appchain can implement its own system of blocks and establish consensus on them independently, or it can leverage the security of other networks and transmit information to them in a specific manner. Some solutions also use a Data Availability (DA) solution for data storage. In any case, it is crucial to clearly define the trust assumptions regarding how information is stored and transmitted between nodes. If this process occurs natively, it is also necessary to establish rules for verifying this information.

Below is a schematic representation of an appchain interacting with different networks and receiving and transmitting information between them.

Symbiotic's Vault System

Symbiotic, on its part, offers a flexible vault system with which the network can interact to determine operators' stakes. In the illustration, the section related to Symbiotic is depicted in green.

Let's examine this issue from the perspective of the Ethereum network. Operators opt into vaults and the network via OptInService contracts. In some cases, the network must additionally register operators within its middleware, which also provides information about the current operators' stakes. 

In essence, Ethereum and the Middleware within it serve as another network with which an appchain can interact. The middleware functions both as an OutputPort and can also serve as an InputPort. It acts as an OutputPort for determining the so-called Validator Set—those nodes that can and should operate. It may also provide other information, although this is not specified. It can serve as an InputPort in situations where slashing is necessary. It is essential to properly implement the transmission of information to Ethereum so that slashing can be verifiable. Specifically, in the case of a fraud proof system, the information must be verifiable onchain; if the decision regarding slashing is made at the consensus level, it should also be verifiable on-chain, and so on.

Key Points for Implementation

In this post, we covered a high-level appchain implementation using Symbiotic that follows several key points:

1. Appchains can be beneficial in situations where a protocol requires a separate optimized consensus algorithm to address a specific issue. Optimizing consensus can be helpful in highly specialized appchains, like orderbook-based appchains (such as Hyperliquid’s HyperBFT). Constructing such a system can be as complex as designing a standalone blockchain.

2. Symbiotic, for its part, offers a convenient system of Vaults that can address critical system issues such as maintaining liveness and safety.

3. To utilize Symbiotic in such a project, middleware must be created. This middleware should contain a module responsible for transmitting information about the validator set, including their stakes, order of operation, and so forth.

Conclusion

Appchains offer a powerful solution for protocols requiring specialized blockchain infrastructure tailored to their specific needs. By focusing on narrow use cases, appchains can optimize performance, cost-efficiency, and functionality beyond what generalized blockchains typically offer. Integrating Symbiotic's flexible vault system into appchain networks presents a robust framework for managing operator stakes, ensuring network security, and maintaining both liveness and safety. 

As we continue exploring and expanding Symbiotic's capabilities, we invite the community to get involved. Whether you're a network builder, an operator, or simply an enthusiast interested in the future of shared security, there's a place for you. If you are interested in learning more or collaborating with Symbiotic, reach out to us here.