Wallet-Gated Data Vaults

A Data Vault is the fundamental storage unit of the Untrace protocol. Every piece of data stored on Untrace lives in a vault: an encrypted, sharded container whose storage nodes release shards only after verifying a wallet-signed retrieval request.

ZK is still part of the product, but it is not the shard-release gate. ZK proofs are used after a user has dashboard access to prove facts about files they can already access, such as selected claims from bank statement PDFs.

What Is a Vault?

A vault is not a file. It is not a folder. It is a cryptographic container with an on-chain identity, an access policy, and no physical home.

When you create a vault:

1. Your data is encrypted client-side with an ephemeral symmetric key
2. The symmetric key is split into threshold shares with Shamir's Secret Sharing
3. The encrypted payload is erasure-coded into recoverable shards
4. Shard bundles are distributed to independent storage nodes
5. An on-chain commitment anchors the vault identity, policy, and shard manifest
6. Reconstruction is possible only after shard nodes verify a wallet-signed retrieval request from an authorized wallet

At no point does the complete data exist anywhere outside your device - not on our servers, not on any single node, not on the blockchain.

Vault Structure

Vault {
  id:            bytes32          // Unique on-chain identifier
  owner:         address | DID     // Wallet or DID binding of the owner
  policy:        AccessPolicy     // Wallet-signature authorization policy
  shardManifest: ShardManifest    // Node assignments and shard commitments
  commitment:    bytes32          // Merkle root or vector commitment
  metadata:      VaultMetadata    // Schema hint, size, timestamps (encrypted)
  createdAt:     uint256          // Block timestamp of vault creation
}

The shardManifest is stored on-chain as commitments and node assignments, not as the shards themselves. Nodes know which shards they hold, but the manifest reveals nothing about the data content.

Vault Types

Untrace supports three vault types out of the box:

All three types share the same underlying sharding and encryption architecture. The difference is in the access policy layer.

Creating a Vault

Vault creation is a protocol flow. Until developer APIs and tooling are available, integrations should follow these protocol requirements:

1. Encrypt the payload locally with an ephemeral symmetric key
2. Split the key into threshold-protected shares
3. Erasure-code the encrypted payload into recoverable shards
4. Assign shard bundles to independent storage nodes
5. Anchor the vault ID, access policy, and manifest commitment on-chain
6. Keep raw data and reconstruction keys off-chain at all times

The result is a vaultId, the on-chain identifier used to reference the vault in future access, sharing, audit, and deletion operations.

Accessing Vault Data

Vault access follows wallet-signature boundaries:

1. The requester opens the dashboard or client SDK with their wallet
2. The client creates a retrieval request for the vault ID, shard generation, nonce, expiry, and action
3. The requester signs the full request with their wallet
4. Each storage node verifies the signature, nonce, expiry, policy, and shard assignment
5. Authorized nodes return encrypted shard bundles
6. The client reconstructs the symmetric key from K-of-N shares and recovers the payload through erasure decoding
7. The payload is decrypted locally

The entire flow is end-to-end. Reconstructed data never transits through Untrace infrastructure.

Dashboard ZK Proofs

ZK proofs are used in a different context: after a user already has access to files in their dashboard.

For example, a user can upload or access bank statement PDFs, extract structured facts locally or through a controlled processing workflow, and generate a ZK proof that discloses only the selected claim:

• Account balance is above a threshold
• Monthly income is within an approved range
• Statement date falls inside a required period
• A required institution or document type is present

Noir is a practical candidate for these circuits because Noir inputs are private by default, compiles to ACIR, and works with Barretenberg for proof generation and Solidity verifier generation. These proofs should be benchmarked for browser proving time, proof size, verifier gas, and mobile feasibility before being treated as production-ready.

Signed Attestations and SBT Minting

After a dashboard proof is generated, a user can optionally sign an attestation that mints a soulbound token on the chain of their choice.

Ethereum path:

• Use an attestation registry or a non-transferable ERC-721-style token
• Consider ERC-5192-style locked NFTs for simple soulbound semantics
• Verify Noir/Barretenberg proofs on EVM when proof costs are acceptable

Solana path:

• Use Token-2022 extensions where appropriate, including non-transferable token behavior when available in the selected tooling
• Use program-owned attestations or compressed credentials for lower-cost proof-of-concept deployments
• Treat full ZK verifier execution on Solana as a benchmark item, not an assumption

The SBT should represent the attested claim or eligibility status. It should not contain the underlying bank statement, raw PDF data, or private vault shards.

Sharing and Access Control

Sharing is expressed as an on-chain policy update for the vault. A grant records the authorized wallet or DID, allowed actions, and optional expiration. A revoke transaction removes that authorization before nodes release shards for future requests.

Access grants are enforced by shard nodes at retrieval time. Revocation takes effect after the policy update is confirmed and observed by nodes - no password reset, no administrator override, and no plaintext cache to invalidate.

Vault Versioning

Vaults are designed for versioned writes. Each write creates a new shard generation anchored to the same vault ID. This keeps history tamper-evident while the current access policy controls future reconstruction.

Previous versions can be retained according to policy. Version history is anchored on-chain, creating an audit trail without exposing plaintext data.

Security Properties