Web3 Access Control Layer

Untrace's access control system is built on Zero-Knowledge Proofs, on-chain policy enforcement, and blockchain-native identity — replacing traditional role-based access control (RBAC) with a verifiable, trustless alternative where access decisions are made cryptographically, not administratively.

The Problem With Traditional Access Control

In centralized systems, access control relies on:

An administrator who can be bribed, coerced, or subpoenaed
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. Decentralized Identifiers (DIDs)

Every identity on Untrace is a DID — a W3C-standard identifier anchored to the blockchain. DIDs are:

Self-sovereign: you generate and control them
Non-custodial: no registry can revoke them
Portable: usable across any protocol that supports the DID standard

did:untrace:0x4f3e...a8b1

DIDs serve as the anchor for all vault ownership records, access grants, and ZK identity claims.

2. Zero-Knowledge Proof Verification

Access to any vault is gated by a ZK proof. The proof asserts:

"I know the private key corresponding to the DID that is authorized to access this vault" — without revealing the private key.

Untrace uses Groth16 and PLONK proving systems depending on the access policy complexity. Proofs are verified by an on-chain verifier contract before any shard release is authorized.

Properties of ZK-gated access:

| Property | Description | | ----------------------- | ---------------------------------------------------------------------- | | Zero knowledge | Proof reveals nothing beyond the boolean "authorized / not authorized" | | Soundness | No adversary can forge a valid proof for a vault they don't own | | Non-interactive | Proof is submitted in a single transaction; no challenge-response | | On-chain verifiable | Any node can verify independently — no trusted verifier |

3. On-Chain Access Policy Registry

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

interface AccessPolicy {
  owner: DID                        // Primary identity; full access + admin
  grants: AccessGrant[]             // Delegated access to other identities
  threshold: number                 // Min shards required for reconstruction
  expiry?: number                   // Optional policy expiry timestamp
  revokedGrants: DID[]              // Revoked identities (checked at proof time)
}

interface AccessGrant {
  grantee: DID
  permissions: ("read" | "write" | "delegate")[]
  conditions?: ZKCondition[]        // Optional conditional access
  expiresAt?: number
}

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

Access Flow

Owner Access

[ Owner generates ZK proof of DID ownership ]
          ↓
[ Proof submitted to on-chain verifier ]
          ↓
[ Verifier checks: proof valid AND DID matches vault owner ]
          ↓
[ Approval event emitted ]
          ↓
[ K nodes independently verify the on-chain event ]
          ↓
[ Nodes release encrypted shards ]
          ↓
[ Client reconstructs data locally ]

Delegated Access (Grantee)

[ Grantee generates ZK proof of their DID ]
          ↓
[ Proof submitted to verifier with vault ID ]
          ↓
[ Verifier checks: proof valid AND DID is in active grants AND not expired AND not revoked ]
          ↓
[ Nodes release shards (read-only segments if permission = "read") ]

Conditional Access

Advanced policies can attach ZK conditions to grants — for example:

"Grant read access only if prover is over 18" (age credential, not revealed)
"Grant access only if prover holds a valid KYC attestation"
"Grant access only between 09:00–17:00 UTC"

Conditions are encoded as ZK circuits and evaluated as part of the proof.

Revocation

Access grants are revocable at any time by the vault owner. Revocation is instant and on-chain:

await client.vault.revokeAccess(vaultId, grantee: DID)

Because nodes check the on-chain policy state at every shard release request, revocation takes effect as soon as the transaction is confirmed — no TTL, no cache invalidation, no stale tokens.

Audit Log

Every access event produces an on-chain record:

| Field | Value | | -------------- | ---------------------------------- | | vault_id | Vault identifier | | accessor_did | The DID that accessed | | proof_hash | Hash of the submitted ZK proof | | timestamp | Block timestamp | | action | read, write, grant, revoke |

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

Comparison With Traditional Access Control

| Capability | RBAC / IAM | Untrace Web3 ACL | | -------------------------------- | ---------------- | ------------------------------------- | | Admin override possible | Yes | No | | Credential theft attack surface | High | None (ZK; no credentials transmitted) | | Audit log tamper-proof | No | Yes (on-chain) | | Revocation latency | Minutes to hours | One block (~2–10 seconds) | | Works without trusted authority | No | Yes | | Privacy-preserving access proofs | No | Yes |