Web3 Access Control Layer

Untrace's access control system is built on wallet signatures, node-side verification, on-chain policy state, and blockchain-native identity. Access decisions are made cryptographically by the nodes that hold shards, not administratively by a centralized server.

The Problem With Traditional Access Control

In centralized systems, access control relies on:

• An administrator who can intentionally leak data
• A database of credentials that can be stolen
• An audit log that can be tampered with
• A single authority that can grant itself access

Untrace eliminates each of these failure modes at the architectural level.

Core Primitives

1. Wallet Identity and DID Binding

Every identity on Untrace starts with a wallet. A wallet can be used directly or bound to a DID for portability across applications.

did:untrace:0x4f3e...a8b1

Wallets and DIDs serve as anchors for vault ownership records, access grants, signed retrieval requests, and dashboard attestations.

2. Wallet Signature Verification

Access to vault shards is gated by a wallet-signed retrieval request. The request asserts:

"This wallet is requesting this vault shard generation, for this action, before this expiry, using this nonce."

Each sharding node verifies the request before returning any encrypted shard. A valid request must satisfy:

Nodes also hold their own private keys. Node keys are used to authenticate node identities, sign shard responses, and produce delivery receipts that can be audited later.

3. On-Chain Access Policy Registry

Each vault is associated with an Access Policy stored on-chain. The policy defines:

interface AccessPolicy {
  owner: string
  grants: AccessGrant[]
  threshold: number
  expiry?: number
  revokedGrants: string[]
}

interface AccessGrant {
  grantee: string
  permissions: ("read" | "write" | "delegate")[]
  conditions?: PolicyCondition[]
  expiresAt?: number
}

Policy changes are signed by the vault owner and committed as on-chain transactions, creating an immutable access log.

Access Flow

Owner Access

[ Owner opens dashboard or SDK ]
          ↓
[ Client creates retrieval request: vault ID, generation, nonce, expiry, action ]
          ↓
[ Owner signs request with wallet ]
          ↓
[ K nodes verify signature, freshness, assignment, and policy ]
          ↓
[ Nodes return encrypted shard bundles and signed delivery receipts ]
          ↓
[ Client reconstructs and decrypts data locally ]

Delegated Access

[ Grantee opens shared vault ]
          ↓
[ Client creates retrieval request ]
          ↓
[ Grantee signs request with wallet ]
          ↓
[ Nodes verify grant, expiry, revocation status, and requested permission ]
          ↓
[ Authorized nodes return encrypted shard bundles ]

Conditional Access

Advanced policies can attach conditions to grants. In the MVP, these conditions should be deterministic checks that nodes can evaluate from policy state or signed attestations:

• Grant read access only until an expiration timestamp
• Grant access only to wallets with an active signed attestation
• Grant access only after a required payment or escrow event is finalized
• Grant access only while a compliance status remains valid

ZK proofs can support selected dashboard attestations, but shard retrieval itself should remain a wallet-signature and policy-verification flow.

Dashboard ZK Proofs

ZK belongs in the user-facing proof workflow after the user already has access to their files.

Example: a user has bank statement PDFs in the dashboard. They can generate a proof that a statement satisfies a claim without disclosing the PDF or unrelated fields. Noir is a candidate circuit language because it is designed for SNARK programs, keeps inputs private by default, compiles to ACIR, and works with Barretenberg for proof generation and Solidity verifier contracts.

Supported proof candidates:

• Balance above threshold
• Income range over a period
• Statement date inside a required window
• Document issuer or account type matches an allowed set

These proofs can feed attestations or soulbound token minting, but they should not be required for nodes to release ordinary vault shards.

Revocation

Access grants are revocable at any time by the vault owner. Revocation is an on-chain policy update that removes the grantee from future authorization checks.

Because nodes check policy state at every shard release request, revocation takes effect as soon as the policy update is confirmed and observed by the nodes. There is no password rotation or centralized cache invalidation step.

Audit Log

Every access event can produce signed records:

The log is append-only, tamper-evident, and auditable without revealing the contents of the data accessed.

Comparison With Traditional Access Control