Core Futures

ZK ONE core functionality is implemented through a hybrid on-chain/off-chain pipeline that provides identity verification, data integrity assurance, and permissioned access while preserving user priv

E-Identity Module

Provides decentralized identity lifecycle: creation, validation, storage, and revocation.

Core Mechanics

  • Hash-based immutability: identityHash = SHA-256(normalizedDocument).

  • ZK verification: User proves document validity without revealing raw data.

  • Canonical normalization: prevents hash divergence across devices.

  • IdentityRecord structure:

struct IdentityRecord {
  bytes32 identityHash;
  uint64 timestamp;
  bool isVerified;
  address owner;
}

Flow

flowchart LR
    A[User Document] --> B[Normalize & Hash]
    B --> C[Generate zk-Proof]
    C --> D[Submit to Lisk L2]
    D --> E[IdentityRegistry Contract]
    E --> F[Record Created / Updated]

Identity Verification

A deterministic smart-contract pipeline validates ZK-proofs and ensures stored identities match local cryptographic transformations.

Verification Steps

  1. Validate zk-proof using Verifier.sol.

  2. Validate proof inputs (document hash).

  3. Mark identity as verified.

  4. Emit attestation events for external verifiers.

Flow

sequenceDiagram
    participant U as User
    participant C as Client Crypto Layer
    participant SC as VerificationContract
    participant L as Lisk L2

    U->>C: Uploads document
    C->>C: Normalize + Hash + zk-Proof
    C->>SC: Submit proof + hash
    SC->>L: On-chain verification
    L->>SC: Proof valid
    SC->>U: Identity Verified

Access Control (Permission Framework)

Omega uses a high-performance bitmask permission model for granular resource control.

Permission Mask

VIEW      = 0x01
VERIFY    = 0x02
SHARE     = 0x04
ADMIN     = 0x08

Revocation

Implemented using:

  • revocation index per resource

  • time-based expiry

  • O(1) lookups

Flow

flowchart LR
    A[Access Request] --> B[Permission Bitmask Check]
    B --> C{Revoked?}
    C -- Yes --> D[Access Denied]
    C -- No --> E[Access Granted]

Data Verification

Ensures data integrity without storing raw data on-chain.

What Goes On-Chain

Only 32-byte hash + metadata, never documents.

struct DataHashRecord {
  bytes32 dataHash;
  uint64 timestamp;
  address owner;
  bool exists;
}

Verification Flow

flowchart LR
    A[Raw Data] --> B[Normalization]
    B --> C[Hash Locally]
    C --> D[Compare with On-Chain Hash]
    D --> E{Match?}
    E -- Yes --> F[Valid Data]
    E -- No --> G[Integrity Breach]

Secure Sharing

Data sharing uses ephemeral tokens derived from key material and access scope.

shareToken = H(resourceId | recipient | expiry | nonce)

Sharing Flow

flowchart LR
    A[User Grants Share] --> B[Smart Contract Registers Token]
    B --> C[Recipient Requests Access]
    C --> D{Token Valid?}
    D -- Yes --> E[Access Granted]
    D -- No --> F[Access Denied]

Last updated