VSL Backend Architecture (previous)
Overview
The Verifiable Settlement Layer (VSL) is the backbone of Pi Squared's vision for a trustless, provable Web3. At the heart of its design is the idea that every action should be verifiable, every interaction grounded in cryptographic truth, and every system modular, pluggable, and application-agnostic.
In the past, VSL’s backend relied on pod — a transaction-log-based infrastructure that mimicked blockchain behavior. But as our system matured, we moved beyond pod to build a purpose-built VSL backend. This backend now powers claim validation across any application, and it’s already live, replacing pod in real deployments like Wormhole.
This architecture guide explains how the new backend works, how claims flow through the system, and how each component interacts, all while maintaining the core design principle of “Verify once, use everywhere.”
Core design principles
The updated VSL backend is built around a few foundational ideas:
1. Everything is a claim
In VSL, every interaction is expressed as a claim. Whether it’s requesting a service, verifying a computation, transferring assets, or registering intent, it all begins with a claim. This makes the system uniform and extensible. Instead of building special-purpose flows for different use cases, VSL treats everything as claim-driven logic, which simplifies validation, auditing, and interoperability.
2. VSL only validates and stores claims
VSL’s job is to validate claims and record them immutably. It does not perform complex logic or heavy computation. That responsibility lies with external clients and verifiers. This design keeps the VSL layer minimal, fast, and secure.
Once a claim is validated, it becomes part of the universal claim set — an append-only, cryptographically-verifiable ledger of all settled claims. Any application or contract can query the VSL to check whether a claim was validated and retrieve its associated proof.
3. Verifiers do the work, while VSL manages storage
When a claim requires computation (like verifying a proof), it’s picked up by a designated verifier. The verifier performs the task off-chain and submits the result back to VSL as a second claim. This creates a two-step claim lifecycle:
Initial claim: “Please verify this.”
Result claim: “Here’s the verified result.”
VSL doesn’t need to understand the semantics of the computation, it just ensures the interaction is valid and properly signed.
4. Simple accounts, token-based incentives
Each VSL participant has an account that holds a balance of VSL tokens. These tokens are used to pay for claim validation and reward verifiers. For now, account handling is implemented using Linera (a temporary system), but we plan to transition to a native VSL ledger in the future.
When a claim is validated:
The submitter’s account is debited (flat fee).
The verifier’s account is credited (fee payout).
This ensures alignment between usage and contribution, and makes the entire economy modular and fair.
Component breakdown
The VSL backend consists of four major components:
1. VSL Client
The interface for users and applications to interact with VSL. It handles:
Submitting new claims
Checking claim status
Querying past claim history
2. Verifier
An off-chain actor (usually a service provider or agent) that watches the VSL for claims it can fulfill. Upon picking up a claim, it:
Performs the requested verification
Generates a result
Submits a result claim back to VSL
3. VSL Backend
The core logic for:
Validating claim signatures and formats
Deducting fees and updating balances
Storing verified claims in a tamper-proof store
It exposes all functionality through a VSL API and maintains the state of accounts and claims.
4. VSL API
A REST/gRPC interface that allows clients and verifiers to:
Submit claims
Submit verification results
Retrieve the claim log
Monitor settlement status
Claim validation workflow
The following is a breakdown of how a full claim verification cycle works:
Client submits a claim
A user (Client A) wants a message M verified. They submit a claim to the VSL that includes:
The message M
Any required parameters P
The designated verifier B
The proposed fee f
Claim is stored and fee deducted
The VSL validates the structure of the claim and deducts a flat fee from Client A’s account. The claim is now visible in the VSL Claim UI and accessible to verifiers.
Verifier observes the claim
Verifier B monitors the VSL claim log and sees the new task. If it matches their capability, they process the verification off-chain.
Verifier submits a result claim
Verifier B creates a second claim containing the result of the verification — e.g., M was valid, along with signature S_B.
VSL validates the result
The VSL checks the authenticity of Verifier B’s result claim. If valid, it stores the result and updates both accounts:
Deducts from Client A
Credits Verifier B
Results can be queried by anyone
Other systems can now query VSL for proof of that claim and receive a VSL membership proof showing that the claim has been verified and settled.
Last updated
Was this helpful?