Proofs, transactions & ownership

Every proof belongs to a specific job

A job binds network, collection, wallet, epoch, revision, random seed, target and job ID. Workers receive a nonce range. These values prevent a result for one wallet, job or earlier target from being accepted as a result for another.

The proof uses a defined binary encoding: text fields carry lengths and epoch, seed, target and nonce have explicit encodings. The algorithm is qtards-sha256-v1 and the repeated hash search uses SHA-256.

digest = SHA256(canonical_job_bytes || nonce_bytes)
valid  = uint256_big_endian(digest) <= target

// Canonical bytes also bind wallet, epoch and revision.
// Expiry, nonce range and remaining capacity are checked separately.

What acceptance checks

• Worker access is valid and unexpired.
• The current job belongs to this worker, is unconsumed and has not expired.
• The nonce is in its assigned range and the recomputed hash meets the target.
• The active epoch has capacity after existing reservations and finalized mints.

The same consumed job cannot mint repeatedly. Allocation and counters are updated together, preventing simultaneous submissions from claiming more than the epoch supply.

A proof creates an opportunity

An accepted proof creates an unpaid reservation for its wallet at the current epoch price, lasting five minutes. It does not yet make you an owner.

When the mint review is prepared, an available token is assigned. Allocation order is shuffled at collection initialization. Operators can inspect that order; it is not trustless randomness. Browsing a token does not select it as your reward.

Payment and inscription together

The reviewed mint uses one atomic Quantus batch containing the price transfer and inscription remark. The remark carries the exact signed permit body. A failed atomic batch does not complete payment and inscription as a successful pair, although it may still incur a network fee.

utility.batchAll([
  balances.transferKeepAlive(treasury, epochPrice),
  system.remarkWithEvent(signedInscriptionPermit)
])

Finality decides ownership

Submission means signed bytes were sent to an RPC endpoint. Inclusion means a transaction appears in a block. Finality means the block has been finalized. QTARDS also checks execution success; appearing in a block alone is insufficient.

Only finalized success completes a mint or purchase. If a response is uncertain or the execution result cannot be read, ownership is not invented and the allocation stays pending.

The protocol boundary

QTARDS proof-of-work is separate from Quantus consensus mining and does not issue Quantus mining rewards. Quantus verifies QTC transactions and records remarks; QTARDS interprets permits and maintains its inscription registry.

The chain does not natively enforce QTARDS ownership, allocation, one-time permit use or registry updates. The collection authority and ownership records are part of the trust model.