Whitepaper

Draft - This document is a work in progress and subject to change.

Untrace: A Privacy-First Network for Sharded, Wallet-Gated Data and Verifiable Attestations

Version 0.1 - May 2026

Abstract

Untrace is a privacy protocol for storing, sharing, and proving facts about sensitive data without placing the full data object in one location. It combines client-side encryption, Shamir's Secret Sharing, erasure-coded payload shards, node-side wallet-signature verification, decentralized node distribution, and optional ZK proofs for dashboard attestations.

Our Roadmap is to build up to a Layer 1 gradually, reaching every privacy primitive in a practical path: private vault storage first, Rust-based sharding nodes, policy registries on existing chains, and Noir-based ZK proofs for selected file-derived claims such as bank statement PDF attestations.

1. Introduction

1.1 The Centralization Problem

Every data breach in history shared one architectural characteristic: the data existed in one place. Firewalls, encryption-at-rest, intrusion detection systems, and AI-powered SOC teams all operate under the assumption that data will be stored centrally and that security means defending that central location.

This model has failed systematically. The asymmetry is structural: attackers only need one path into the target, while defenders must secure every path forever.

1.2 The Untrace Thesis

The solution is a fundamentally different model for how data lives in the world:

• Sharded - split into encrypted, threshold-protected fragments
• Distributed - stored across independent nodes
• Wallet-gated - shards are returned only after nodes verify wallet-signed retrieval requests
• Provable - selected file-derived claims can be proven with ZK after dashboard access is granted

There is no master copy. No central database. No single point of failure. No administrator with unilateral plaintext access.

2. Protocol Architecture

2.1 Stack Overview

┌─────────────────────────────────────────────────────────────┐
│                 APPLICATION LAYER                           │
│  Privacy Vault │ Bank Statement Proofs │ SBT Attestations   │
├─────────────────────────────────────────────────────────────┤
│                 ATTESTATION LAYER                           │
│  Noir Circuits │ Barretenberg Proofs │ ETH/Solana SBTs      │
├─────────────────────────────────────────────────────────────┤
│                  ACCESS POLICY LAYER                        │
│  Wallet Signatures │ On-Chain Grants │ Revocations          │
├─────────────────────────────────────────────────────────────┤
│                  STORAGE PROTOCOL                           │
│  Encryption │ SSS Key Shares │ Erasure-Coded Payload Shards │
└─────────────────────────────────────────────────────────────┘

2.2 Data Lifecycle

[ Raw Data ]
     ↓
[ Client-side symmetric encryption ]
     ↓
[ Key split into N shares via Shamir's Secret Sharing ]
     ↓
[ Encrypted payload erasure-coded into N shards ]
     ↓
[ Shard bundles distributed to Rust storage nodes ]
     ↓
[ Vault policy and manifest commitment anchored on-chain ]
     ↓
[ Reconstruction requires wallet-signed request + K-of-N shard retrieval ]

No node ever holds sufficient information to reconstruct the data independently. No entity, including Untrace, can access data without a valid wallet-signed retrieval request and enough authorized shard responses.

2.3 Cryptographic Primitives

Noir is a strong candidate for the first ZK proof layer because Noir inputs are private by default, Noir compiles to ACIR, and Barretenberg supports proof generation, circuit analysis, recursive proof work, and Solidity verifier generation.

2.4 Node Network

The initial Untrace node network should be built as a Rust service before any full Layer 1 work. Nodes are responsible for:

1. Storing assigned encrypted shard bundles
2. Maintaining node identity keys
3. Verifying wallet-signed retrieval requests
4. Checking vault policy and revocation state
5. Returning encrypted shards with signed delivery receipts
6. Participating in availability checks

Recommended Rust components include tokio for async runtime, QUIC or gRPC for transport, and RocksDB, object storage, or a similar backend for shard persistence. A permissioned or semi-permissioned node set is the realistic MVP; permissionless staking, slashing, and full storage proofs should come later.

3. Access and Identity Layer

3.1 Wallet-Signed Retrieval

Vault access requires a signed request from an authorized wallet. The request includes vault ID, shard generation, nonce, expiry, action, and policy context. Each node verifies the request independently before releasing a shard.

This approach keeps shard release close to the storage boundary. It also avoids making ZK proof verification a dependency for ordinary file retrieval.

3.2 On-Chain Policy Registry

Vault policies record ownership, grants, revocations, thresholds, and expiration rules. Policies can live first on Ethereum-compatible testnets, then expand to Solana or other chains as integrations mature.

3.3 Dashboard ZK Proof System

ZK proofs are used when the user already has dashboard access and wants to prove a fact from a document without disclosing the document.

Example: a user can prove from a bank statement PDF that their balance is above a threshold or that their income falls inside a required range. The proof can be generated with a Noir circuit and verified on EVM through a Barretenberg-generated Solidity verifier when gas and proof size benchmarks are acceptable.

3.4 Soulbound Attestations

After a proof or document-derived claim is approved, the user may sign an attestation that mints a soulbound token on Ethereum or Solana.

Ethereum path:

• Use an attestation registry or non-transferable ERC-721 pattern
• Consider ERC-5192-style locked NFTs for simple SBT semantics
• Keep raw document data off-chain

Solana path:

• Use Token-2022 extensions or program-owned attestations
• Consider non-transferable token behavior where supported by the selected implementation
• Benchmark full ZK verifier execution separately; do not assume it is MVP-ready

4. Future dApp Ecosystem

The Untrace base layer can support a future ecosystem after the core vault network is validated.

5. Security Analysis

5.1 Threat Model

5.2 Comparison

6. Roadmap

7. Conclusion

Untrace represents a shift in how sensitive data can be stored and proven. The feasible near-term protocol is a wallet-gated private vault network with signed shard retrieval and optional ZK attestations. A full Layer 1, permissionless storage economy, generalized private transactions, and production storage proofs are possible future phases, but they should follow a validated vault and attestation MVP.

References

• Shamir, A. (1979). How to Share a Secret. Communications of the ACM.
• W3C. (2022). Decentralized Identifiers (DIDs) v1.0. W3C Recommendation.
• Noir documentation: private-by-default circuit inputs, ACIR compilation, Nargo testing, and Barretenberg Solidity verifier generation.
• Solana Token-2022 documentation: token extensions including metadata, default account state, and programmable transfer behavior.
• OpenZeppelin Contracts documentation: secure smart contract building blocks for Ethereum-compatible deployments.

This whitepaper is a draft. All specifications, figures, and timelines are subject to change as the protocol evolves.