The Account Model

Overview

Every interaction in the VSL devnet, whether submitting a claim, settling a payment, or verifying computation, starts with an account.

An account in the VSL is a simple, self-sovereign construct defined by a public/private key pair. The account model is intentionally minimal but expressive, allowing users, apps, and services to manage identity, assets, and state with full cryptographic control.

Account Basics

• Address (Public Key Hash): Accounts are identified by public keys, just like in Ethereum. The public key is hashed to create the address, while the private key is used to sign claim messages and transactions.

• Private Keys: Private keys are never shared with the VSL network. They are used locally to sign messages that authorize balance transfers, claim submissions, and state updates.

Account Contents

Each account on the VSL network contains the following core components:

1. Native token balance

Every account holds a balance of the VSL’s native token, used to pay processing fees for submitting or settling claims and fund other accounts or services.

2. Custom asset balances

Accounts can hold balances of user-created assets, such as ERC-like fungible tokens, non-fungible tokens (NFTs), or real-world asset representations.

These assets are treated as structured claims, and transfers must be settled through the VSL like any other state transition.

3. Custom state

Each account maintains a state—a 32-byte value, typically the hash of an arbitrary application-defined state.

Examples:

• A hash of KYC metadata

• A Merkle root of an on-chain or off-chain record

• A pointer to a decentralized identifiers (DID) document

The state can be updated using a special claim type (e.g., state := <new_value>), which is signed by the account and verified during settlement.

State Transitions via Claims

All changes to an account, whether through sending tokens, transferring assets, or updating state, must occur through signed claims.

Each such signed operation becomes:

• A verifiable claim message submitted to VSL

• A part of the global settlement history

• A trigger for validator state updates if valid

Because of this, VSL acts like a universal audit trail for all account-related activity.

Example Use Cases

• Alice creates a new account, funds it with native tokens, and sets a KYC hash as its state.

• Bob sends Alice an NFT. This is done via a structured asset transfer claim and requires settlement.

• An oracle updates its own account state with the latest data root hash every 10 minutes using a signed state := <hash> claim.

Advanced Concepts

• Multisigs and Verifiers: Accounts can define external verifiers (other clients) and quorum thresholds for verifying claims. This allows you to build multisig or delegated authorization setups.

• Stateless Verifiability: Since every meaningful action is a settled claim, validators don’t need to understand the full internal semantics of an account’s application. They only enforce the validity of claim structure, signatures, and nonce ordering.

Summary

VSL accounts are minimal yet powerful. Backed by cryptographic keys, they store balances, custom assets, and user-defined state. All changes happen through signed claims, ensuring that every operation is verifiable and consistent across the network. While permissionlessness is a core goal of VSL, the current devnet uses a single trusted validator with special privileges.