QuantovaQstampby Quantova
EN
EnglishEN日本語JAFilipinoFIL한국어KO简体中文ZHFrançaisFREspañolESУкраїнськаUK
GitHub Start building →
Qstamp / Data flows
Data flows

What moves where, and what never leaves your systems.

Every product in the Qstamp family follows the same three flows. A record is sealed inside the systems of its owner, a salted commitment is anchored on the Quantova network, and any party can later verify the record against its receipt. This page traces each flow step by step and states exactly which data crosses which boundary.

Live flow

The three flows in motion.

Each step lights in turn as a record moves through it. Steps inside your systems never send content out. Only the anchor reaches the Quantova network, and only chain facts are public on QVMScan.

Live flowQstamp, from your application to the explorer
  1. Your systemsYour applicationCreates a record, a decision, a model or a document
  2. Your systemsQstamp SDKSHA3 256 fingerprint bound to a fresh random salt
  3. Your systemsBatch treeUp to 1,048,576 records in one RFC 9162 tree
  4. Quantova networkQstamp contractCommitment anchored in a transaction signed with ML DSA 65
  5. Quantova networkFinalityValidator committee finalises the block in about 0.2 seconds
  6. PublicQVMScanAnchor public, record content private
  7. PublicAny verifierProves the record existed unchanged at that time
Inside your systemsQuantova networkPublic and verifiable
Boundaries

Three zones, and the data allowed in each.

The design rule of the family is that record content never leaves the zone of its owner. Only fixed length commitments cross to the network, and only chain facts are public.

Zone 1

Inside your systems

  • The record and its documents
  • Signing keys and salts
  • Personal and commercial data
  • Signed envelopes and receipts
Zone 2

Sent to the network

  • One salted 32 byte commitment per batch
  • The record kind, such as QTax
  • A transaction signed with ML DSA 65
  • Nothing that can be reversed into content
Zone 3

Public on QVMScan

  • The commitment and the signer address
  • The block, its time and its finality
  • The record kind and the batch size
  • No record, document or identity
Flow 1

Sealing a record, inside your systems.

Sealing happens where the record is created, with no network access required.

  1. 01Capture

    The application creates the record at the moment the event occurs, such as an agent action, a filing or a payment.

  2. 02Canonical encoding

    The record is encoded in a fixed binary form, so the same record always produces the same bytes and no field can be reinterpreted.

  3. 03Signature

    The record is signed with ML DSA under a context string unique to the product, using a key held only by its owner.

  4. 04Fingerprint

    A SHA3 256 fingerprint is computed over the encoded record and its signature, with a domain label unique to the product.

  5. 05Salted leaf

    The fingerprint is combined with a fresh random salt, so nothing published can be used to confirm a guess about the record.

  6. 06Batch tree

    Leaves are collected into a Merkle tree following RFC 9162, so one commitment can cover thousands of records.

Flow 2

Anchoring a commitment on the Quantova network.

Anchoring fixes the commitment in time. It can run on a schedule, through a controlled gateway, from a single funded account.

  1. 01Commitment

    The root of the batch tree is bound to the network, the contract, the signer, the record kind and the batch size.

  2. 02Transaction

    The commitment is sent to the official Qstamp contract in a transaction signed with ML DSA 65.

  3. 03Finality

    A committee of validators signing with ML DSA 65 finalises the block, typically within about 0.2 seconds.

  4. 04Event

    The contract emits an event carrying the signer, the commitment and the record kind, visible on QVMScan.

  5. 05Receipt

    Each record receives its own receipt with its inclusion path, its salt and the transaction, stored with the record.

  6. 06Recovery

    If the connection fails after sending, a pending stamp is kept and the anchor is completed later, so no record is anchored twice.

Flow 3

Verifying a record, by anyone, at any time.

Verification needs the record, its envelope, its receipt and the public key of the signer. It does not need Quantova software or the producer's systems.

  1. 01Signature

    The verifier checks the ML DSA signature against the public key named in the record and against the trusted keys it expects.

  2. 02Links

    Where the record relies on earlier records, each linked record is checked to be exactly the one named and validly signed.

  3. 03Rules

    Product rules are applied, such as separation of duties, running totals, ordering in time and limits on anchoring delay.

  4. 04Inclusion

    The leaf is recomputed and its path checked to the committed root.

  5. 05Chain

    The verifier confirms on the network that the transaction is final and that the contract emitted the commitment.

  6. 06Result

    The result is valid, invalid or indeterminate, with every check listed. Missing evidence never produces a valid result.

By use case

The same flows, applied to real records.

Use caseRecord sealedLinked toWhat a verifier can prove
AI agentsEach tool call, model change and decisionThe previous log entry and the agent mandateThe agent acted within its mandate and no action was removed
Agent paymentsEach payment intent and receiptThe mandate and its spending limitsPayments stayed within the authorised limits
TaxFilings, invoices, assessments and refundsThe filing, the assessment and earlier refundsNo refund exceeds the refund due and no record was backdated
ProcurementBid commitments, scores and awardsThe tender notice and the signed scoresNo bid was added or replaced after the deadline
ElectionsStation returns and tabulation actionsRegistered officials and softwareThe declared result equals the certified returns
AI contentContent, models and data setsIngredients and the model ownerThe origin and history of content are as claimed
Keys

Key custody in every flow.

Generated locally

Keys are generated from the secure random source of the operator's own system and are never transmitted to Quantova.

Held by role

Separate keys are held for separate roles, so that one person or system cannot create and approve the same record.

Wiped after use

The SDKs clear key material from memory after each operation, and command line key files must be readable only by their owner.