The Devnet Architecture
Last updated
Was this helpful?
Last updated
Was this helpful?
The Verifiable Settlement Layer (VSL) devnet is a prototype implementation of VSL’s vision for fast, secure, and customizable claim settlement. While the long-term architecture is designed to be decentralized and extensible, the devnet offers a simplified environment for developers to understand the fundamentals and start building.
At its core, the VSL devnet introduces a workflow between three main roles: clients, verifiers, and a validator. These actors interact via the VSL API to submit claims, verify them, and finalize settlement through a lightweight, permissioned process.
Clients are the starting point of all activity in the devnet. They represent users, applications, or systems that want to submit claims or initiate transactions. A client prepares a request—such as a token transfer, a data attestation, or a computation result—and signs it using their private key.
Each client has an account in the system, which includes a balance of native tokens, optional user-defined assets, and a 32-byte application-defined state hash.
Clients use the VSL API to submit signed messages, specify verification parameters, and provide a verification fee to incentivize verifiers. Once a claim is submitted, clients can check for its settlement status through polling or streaming endpoints.
Verifiers are also clients, but with a specialized role. They monitor the network for submitted claims that list them as the intended verifier. Upon receiving such a claim, the verifier performs a validation process, which may involve checking a digital signature, rerunning a computation, or reviewing attached proof data.
If the claim passes verification, the verifier signs a VerifiedClaim message and sends it to the validator. Like the client, the verifier pays a small processing fee to submit their result. However, once the claim is settled, the verifier receives the verification fee provided by the original client. This creates a natural incentive loop: verifiers are rewarded for honest, timely participation in the settlement process.
The validator is the core infrastructure node in the VSL devnet. It acts as a trusted authority responsible for receiving messages, validating signatures, enforcing nonce correctness, and updating the system’s state. In the devnet, there is only one validator, but the architecture is designed to eventually support a decentralized validator set.
The validator maintains two critical internal data structures. The first is the account database, which stores each client’s balance, asset holdings, and state field. The second is the claim database, which tracks submitted and settled claims.
When a verifier submits a verified claim, the validator checks for a matching submitted claim, confirms that the verifier is listed among the originally requested verifiers, and ensures that all fees and nonces are valid. If all conditions are met, the validator records the claim as settled and executes any associated state changes, such as transferring the verification fee.
All communication between clients, verifiers, and the validator is routed through the VSL API. This interface exposes endpoints for submitting claims (vsl_submitClaim), responding with verification results (vsl_settleClaim), and initiating payments or transfers. It also provides query endpoints for retrieving account balances, claim history, and settlement outcomes.
The API supports both polling and streaming subscriptions. Verifiers typically rely on streaming to receive claims as they come in, while clients can often poll for updates since they already know which claims to expect. Subscription endpoints like vsl_subscribeToSubmittedClaimsForReceiver and vsl_subscribeToSettledClaimsForReceiver provide real-time access to claim activity.
The claim lifecycle in the devnet follows a structured flow. A client first signs a claim and submits it to the validator through the API. This claim includes the message content, the chosen verifier, and a verification fee. The validator records the claim, deducts a small processing fee from the client's account, and indexes it for retrieval.
A verifier monitoring the network detects the claim, validates it, and responds with a signed verification result. This result is submitted via the API, and the verifier also pays a processing fee. The validator checks that the verification is legitimate and meets quorum requirements. If everything checks out, the validator finalizes the settlement, transfers the verification fee from the client to the verifier, and marks the claim as settled. At this point, both parties can query or subscribe to retrieve the finalized status.
The architecture diagram illustrates this workflow in full detail, highlighting the interactions between Client A, Verifier B, and the VSL validator. Each numbered step corresponds to a real action in the system, from claim submission and verification to account updates and fee transfers.
Outside of the client-validator-verifier loop, the broader architecture also anticipates integration with other distributed systems. In future deployments, smart contracts on external blockchains will allow those chains to query the VSL for claim settlement status. This functionality ensures that claims settled on the VSL can be trusted across ecosystems. These smart contracts are not part of the devnet but are a planned feature of the production system.
Another planned feature in the architecture is the role of a proxy. Proxies are optional helpers that improve the liveness of the system. They can relay messages from clients to validators and help aggregate verifier signatures.
A proxy might be a client, a verifier, a validator, or any combination of these roles. While proxies are not currently active in the devnet, they play an important role in the future scalability of the VSL protocol.
The devnet architecture introduces the foundational actors and workflows of the VSL network. Clients submit claims and initiate transactions. Verifiers validate claims and respond with signed results. The validator receives and verifies messages, processes fees, and finalizes settlement.
While the devnet runs on a single trusted validator and supports only a limited set of operations, it reflects the design goals of the broader VSL protocol—secure, minimal, extensible, and fast.
To explore what gets submitted and settled, continue to Transactions and Claims. To learn how accounts are structured, see the Account Model.
