Protocol Flow

One order is decomposed into shards, autonomously routed by the protocol, and converges into a single deterministic validation condition.
Order Initialization

The buyer submits an order for a defined quantity of asset (e.g. gold). Funds are immediately locked in protocol-controlled escrow, ensuring that execution can only proceed under validated conditions.
↓
Order Sharding

The order is decomposed into multiple execution shards. Each shard represents a portion of the total order, with quantity and distribution generated according to protocol rules.

Sharding occurs prior to any execution path selection.
↓
Buyer and Seller Shards

Both buy orders and sell orders are decomposed into shards. The seller does not execute a full order as a single block. Seller shards are randomly and anonymously matched with buyer shards through protocol-level allocation.

Each participant can track only their own execution flow: buyers can follow their buyer shards, and sellers can follow their seller shards.

The protocol preserves a historical record of buy and sell shards, with cryptographic proofs and unique identification codes.
↓
Protocol Allocation Engine

Each shard is independently routed by the protocol. Allocation is not decided by any participant, but emerges from protocol-level optimization logic.

Shards are distributed across two execution channels:

• Bootstrap Channel → expands the VRS layer
• Internal Channel → operates on existing verified reserves

Allocation criteria include:
• reinforcement of existing vault capacity
• integration of new vaults from approved candidates
• optimization of reserve distribution and system liquidity

Execution is determined per shard, not per order.
↓

Bootstrap Path

VRS Layer Construction
External Issuer (Physical Seller) The issuer in this phase is not a monetary authority, but the physical provider of the asset entering the system.
Case 1 — External Acquisition The issuer acquires gold outside the protocol using its own capital. This creates capital exposure until validation is completed.
Case 2 — Pre-Owned Asset The issuer already holds physical gold not yet registered in VRS and uses the protocol to onboard it into the system.
Protocol-Controlled Transport Transport is assigned by the protocol. Direct coordination between participants is minimized.
Vault Entry and Audit The asset enters vault custody. Auditors verify its physical existence, quantity and consistency.
Validation Layer Validators confirm certificates, ownership references and protocol state.
VRS Expansion The verified asset is added to the Verified Reserve State, expanding the system’s physical layer.

Internal Transfer Path

VRS-Native Exchange
Internal Issuer (Protocol Function) Inside the protocol, issuer is no longer an entity. It is an automatic function governing execution.
Verified Ownership The seller already holds VRS-backed ownership, eliminating the need for physical asset movement.
Shard Matching Buyer shards are matched with seller shards. Matching is non-linear, distributed and protocol-driven.
Case 3 — Ownership Acquisition A participant may first act as a buyer, acquire VRS ownership, and later become a seller.
Audit Consistency Check Auditors verify that the VRS remains consistent and valid.
Validation Layer Validators confirm shard integrity, ownership state and invariants.
Ownership Reallocation Ownership is reassigned through state transition. No physical transfer occurs.
Common Final Condition
I(sᵢ) = 1 ⇔ Valid(sᵢ)
Issuance depends exclusively on validity conditions, not on execution path.
The protocol emits the final ownership token.
The issuer does not emit currency.

External issuer = physical asset provider
Internal issuer = protocol execution function
← Back to main site