# Architecture

In this guide, we introduce the architecture of the Verifiable Settlement Layer (VSL) network.&#x20;

{% hint style="info" %}
The VSL is still in the design phase, so technical details and decisions will require future revisions. A prototype implementation of the VSL is accessible via our [Devnet](broken-reference).

Developers are welcome to join our whitelist and request early access to the Devnet to experiment with the VSL Devnet.&#x20;
{% endhint %}

The VSL network consists of many VSL validators, also known as VSL nodes. A VSL node consists of a consensus component and a state component. The consensus component is responsible for the consensus logic and message gossip, while the state component is responsible for processing messages, validating signatures, and updating the state. These two components constitute a single VSL node.&#x20;

A user of the VSL network called a client, interacts with the network by broadcasting messages to all the VSL nodes. These messages include claims that the client wants to settle on the VSL. As explained in [what-is-vsl](what-is-vsl "mention"), claims are a central concept of VSL and one of the fundamental building blocks. Claims can encode any payments, transactions, computations, assets, and data that the client wants to settle.&#x20;

Any other distributed networ&#x6B;**,** such as a layer-1 blockchai&#x6E;**, must also run a VSL smart contract** to observe the states of the VSL networ&#x6B;**.** The smart contract responds to on-chain queries and confirms the settlement of claims.

The diagram below shows the relationship among the VSL nodes, VSL clients, and other distributed networks.&#x20;

## VSL Node: Consensus Component

FastSet is the underlying consensus protocol that powers the VSL. It is a distributed protocol that enables a set of clients to settle verifiable claims consistently using a set of validators. Clients broadcast their claims to all validators, and validators replicate the network state based on the order in which they receive the claims.&#x20;

The diagram below shows the workflow of a complete settlement on the VSL.&#x20;

<figure><img src="https://1807447557-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FPLmwKHYt9IQXlVvNGdPk%2Fuploads%2F2EDB5ZL9TyuaEk7JrsUu%2FVSL%20Diagram-5-23-2025.png?alt=media&#x26;token=5bc81746-043e-4f3d-a97a-6dc6dd7cde72" alt=""><figcaption></figcaption></figure>

The Proxy is a helper that only affects the liveness of the FastSet protocol and not its safety. The Proxy can be a Client (the sender of the original message containing the claim sequence or a different client such as a beneficiary, a verifier, or a service provider), a Validator, or any combination of these for all or any of the two services it provides: broadcasting messages to Validators and signature aggregation.

{% stepper %}
{% step %}
**Steps 1 & 2**

A client signs a sequence of claims and signs the message. An appropriate set of verifiers verify the message and sign it individually. A proxy then aggregates the verifiers' signatures and broadcasts them to all the validators.
{% endstep %}

{% step %}
**Step 3**

Upon receiving the broadcast message that includes the original sequence of claims and aggregated signatures from a set of verifiers, the VSL validator checks if the signatures are valid and if a quorum of verifiers, as originally specified by the client, **has been** reached.
{% endstep %}

{% step %}
**Step 4**

The validator signs the message back to a proxy.&#x20;
{% endstep %}

{% step %}
**Step 5**

As more validators sign the message, a collection of **their** signatures continues to grow and eventually **forms** a quorum. **Thus, a** settlement certificate is created and broadcast to all validators for final settlement. Technically, at this stage, the claim settlement request is final in the sense that it cannot be canceled and will proceed eventually.
{% endstep %}

{% step %}
**Step 6**

Each VSL validator checks the signatures and the quorum of the settlement certificate.&#x20;
{% endstep %}

{% step %}
**Step 7**

Each VSL validator settles the claim and updates its internal state.&#x20;
{% endstep %}
{% endstepper %}

## VSL Node: State Component

A VSL node maintains a balance sheet and a claim database. The balance sheet maintains a mapping from VSL accounts to the various custom assets that they own. The claim database maintains a non-ordering set of claims that have been settled.&#x20;

VSL validators only validate signatures, check quorums, and update states. As a result, the VSL states are also simple structures. Complex business logic or resource-demanding computations are delegated to external service providers (as clients). This design aims at making the VSL network minimal, fast, and secure.&#x20;

## VSL API Endpoints

The VSL API endpoints form the interface between clients and the VSL validators, enabling the submission, validation, aggregation, and confirmation of claim settlement.&#x20;

## VSL Smart Contracts

A VSL smart contract is an on-chain component that allows other distributed systems, such as layer-1 blockchains, to query the most recent state of the VSL network and the settlement status of any given claim. It serves as the endpoint of communication from the VSL network to the target distributed system.

## VSL Explorer

The VSL Explorer is the frontend of the VSL that enables the visualization of claims and their settlement status and the retrieval of claim history.
