Transactions and Claims

As stated earlier, at the heart of the VSL lies the concept of claims—self-contained, verifiable units of information or computation. A transaction in the VSL context is the process through which these claims are submitted, verified, and eventually settled across a decentralized set of validators.

The VSL acts as a neutral, infrastructure-level layer that provides fast, permissionless, and secure verifiable settlement, which is the process of accepting claims, verifying them against their proofs, and finalizing them publicly and immutably.

What is a Claim?

A claim is a statement made by a client and intended to be verified by one or more verifiers. Claims may carry data, represent computation results, attest to facts, or encode payments.

Examples include:

• “I, Alice, pay Bob 10 tokens.”

• “This AI model’s output for input X is Y.”

• “The result of code execution is Z.”

• “This user passed KYC verification.”

Each claim must be independently verifiable either by direct computation, signature checks, or more complex proof systems like ZKPs or TEE attestations.

Claim Lifecycle

A general claim goes through the following stages:

1. Submission

A client creates and signs a claim, specifying the verifiers it wants to verify the claim, a verification fee, and the claim data itself. The client submits this claim using the vsl_submitClaim endpoint.

Upon receipt:

• The validator deducts a small processing fee.

• The claim is stored and indexed by sender and verifier addresses.

2. Verification

Verifiers monitor submitted claims using vsl_subscribeToSubmittedClaimsForReceiver for real-time updates. If selected as a verifier, a client can verify the claim against its chosen proof system and submit a signed VerifiedClaim to the validators using the vsl_settleClaim endpoint.

At this point:

• Another processing fee is charged by the validators

• The validator checks:

  • Whether the submitted claim exists and is not expired

  • Whether the sender is an authorized verifier

• If valid, a SettledVerifiedClaim is created, stored, and signed by the validator

Note that not all submitted claims are accepted by the VSL. A transaction can be rejected by a validator if:

• It does not match any submitted claim currently tracked by the system

• The sender is not one of the requested verifiers

• The claim has expired or was submitted with a conflicting nonce

A claim is only considered settled when a quorum of verifiers have approved it and the VSL validator has signed and recorded the settlement.

Settlement is the strongest form of acceptance. It makes the claim part of the VSL’s verifiable history and allows clients to trust its result.

3. Settlement

Once enough verifiers have signed off (based on the required quorum), the claim is considered settled. In production, an aggregate signature is used to optimize storage and verification.

Clients can check for settled claims using vsl_listSettledClaimsForRecevier. There is also a subscription-based version available–vsl_subscribeToSettledClaimsForRecevier, though polling is often sufficient here since clients typically know how many claims to expect and their expiration timelines.

Clients may validate the validator’s signature and ensure the signed claim matches the expected original.

Simple Transactions

For simple transactions like making a payment, the client's signature is enough and there is no need to involve verifiers. In these cases, the validators will immediately settle a claim recording the transaction (and also update the account state, if only to increment the expected nonce).

FastSet: A Parallel Settlement Engine

VSL is designed with the FastSet protocol in mind—a model for scalable, concurrent settlement of verifiable claims. While the devnet currently supports only partially this design (e.g., payments and account state updates), future versions aim to expand toward the complete FastSet architecture.

FastSet requires claims issued by different accounts to be in a so-called weak independence relation. This means that for any two such individually valid claims:

• It must be valid to apply both claims together

• The final state must be the same regardless of the order in which they are applied

A classic example is: account A sends tokens to B, and B sends tokens to C. These two operations affect B’s balance, but they’re still weakly independent which means they can be processed in any order and result in the same final balances.

Given this property, FastSet guarantees strong eventual consistency: validators who settle the same set of claims, regardless of order, reach the same final state.

The protocol also ensures determinism, monotonicity (claims stay valid once accepted), and liveness (validators eventually make progress).

Key roles

• Clients: Users, apps, L1/L2 chains, or services that issue claims.

• Verifiers: Any client designated to validate claims. They can check execution, signatures, or any form of proof.

• Validators: Infrastructure nodes that maintain the global settlement state and enforce consistency.

• Proxies (Optional): Entities that relay messages and aggregate signatures.

Claim Rejection and Settlement

Before any signed request, whether it's a claim submission, payment, or verification, is processed by the VSL, it must meet two basic conditions:

• The sender must have enough tokens to pay the validator’s processing fee.

• The request must include the correct nonce: it must match the next expected nonce for that account.

If either of these checks fails, the request is immediately rejected.

Types of Claims

VSL supports many claim types. Common examples include:

• Payments: transfer(receiver, amount)

• Facts: “User X has at least 20 tokens”

• Proofs: Results of computations, signatures, attestations

• Computations: compute(code, input, pre_state, post_state)

Each type can be verified in different ways, depending on the application needs.

Summary

VSL is designed to enable trustless, cross-platform proof of actions, states, and intents. It decouples the act of proving from the act of accepting, allowing applications to choose their own proof methods and verifiers.

While the devnet currently operates with a single trusted validator, the architecture aims for a decentralized, low-latency, and high-throughput settlement layer inspired by the FastSet protocol.