Virtual Vaults are custom credit vaults, secured by cryptographic proofs.

Each vault is structured to the deal between a lender and a borrower, including the collateral mix, haircuts, margin thresholds, and liquidation logic. Space and Time generates continuous, cryptographic proof of vault state, so the lender verifies collateral the instant it moves, the borrower keeps custody, and neither side waits on a third party to tell them what's true.

This documentation covers the mechanisms underneath the platform. For the product overview, audiences, and use cases, see the Virtual Vaults landing page.

 Primitives this is built on

Virtual Vaults compose three primitives:

• zkTLS notaries for attesting that offchain balance data came from the named source (an exchange API, a custodian endpoint) over an authentic TLS session.
• SXT Chain as the decentralized tamperproof SQL data warehouse storing vault state and its proofs.
• Proof of SQL for zero-knowledge proofs that queries over vault state are executed correctly.

Architecture

A Virtual Vault is a three-layer system: collateral sources, verifiable data capture, and onchain commitment with reporting on top. Each layer addresses a specific trust assumption, so that the end-to-end flow has no single point of manipulation.

The three layers

 Layer 1: Collateral sources

Collateral can sit in two places, and the architecture handles both:

Centralized exchanges and custodians. Balance data is fetched from the venue's REST API. Credentials are used exclusively to sign pre-defined balance requests, so they can stay within the borrower's infrastructure.

Onchain wallets, smart contracts, and tokenized assets. Balances are read directly from chain through standard RPC calls, with no credentials needed because the data is public. For tokenized treasuries, money market funds, or other RWAs, the same mechanism extends to the underlying token contract and any associated registry, so both the borrower's holdings and the composition backing those holdings are captured.

A single vault can pull from multiple source types at once. A vault structured around stablecoin collateral spread across three exchanges plus an onchain wallet has four sources, all aggregated into one vault state.

Layer 2: Verifiable data capture

The capture layer for retrieving the balance information from the collateral sources and into the chain in a verifiable manner. For API-based sources, Virtual Vaults brings over a zkTLS notary run over TEE to participate in the TLS session and attest to its authenticity and contents.

The zkTLS session notary does not see the signed API request, nor the plaintext response. At the end of the session, the notary signs a cryptographic commitment of the session content, including the endpoint identity, the request, and the response, which a third party can later verify independently.

Layer 3: Onchain commitment and indexing

To preserve borrower privacy, Virtual Vaults encrypts the request, the response, and the zkTLS commitment, and inserts the result into a tamperproof table on SXT Chain. Anyone holding the decryption key can read the result and its verifiable commitment.

For onchain sources, this layer is bypassed because the source is already cryptographically verifiable through the chain itself.

The same SXT Chain table powers a hosted dashboard that lenders, borrowers, and any authorized third parties use to monitor the vault in real time. The dashboard reads records from the table, decrypts them at the edge using the keys held by the authorized party, and renders the current vault composition, balance, and proof history.

Continuous proof, not snapshot proof

The most common adjacent product is a snapshot proof of reserves: a single attestation produced at a single point in time and published. A snapshot proves the borrower had the reserves on the day the snapshot was taken. The instant the snapshot is published, it stops being true: the borrower could move funds the next minute, and the lender has no way to know until the next snapshot.

Virtual Vaults run the same notary primitive on a continuous polling cycle. Every attestation is committed onchain and indexed into a queryable state, so the lender's view is never stale by more than the polling interval. At sub-minute frequencies, the gap between "proven state" and "current state" collapses to the point where lender risk engines can read vault state as operational input rather than periodic report.

The practical consequence: snapshot proofs are reporting infrastructure (you can publish them, link to them, audit them after the fact), while Virtual Vaults are operational infrastructure (the lender's risk engine reads them as they happen, and automated logic triggers on them). This is what allows margin and liquidation to execute on proven state rather than reconciled reports, and what makes the difference between "I can prove I had the collateral last Tuesday" and "I am proving I have the collateral right now."

Audit trail

Every state change in a Virtual Vault is recorded onchain, so the history of the vault is preserved as part of the same infrastructure that produces the proofs. Lender, borrower, and any authorized third party reference the same onchain record rather than reconstructing state from separate reports.

Vault history persists for the life of the chain, so the full lifecycle of a vault remains accessible long after it has been wound down. The specific interfaces and tooling for working with that history will be documented as they stabilize.