Umbra Privacy LogoUmbra Privacy
Key & Address Architecture

Individual Transaction Key (ITK) Creation

Protocol for deriving unique transaction keys from MVKs and timestamps for deposits and claims

Protocol Description

For each transaction, a unique Individual Transaction Key (ITK) is derived from the relevant MVK and a high-resolution timestamp (Y,M,D,h,m,s)(Y, M, D, h, m, s).

Deposit ITK

kITK,DPoseidon(kMVK,SOL,Y,M,D,h,m,s)k_{\text{ITK}, D} \triangleq \text{Poseidon}( k_{\text{MVK}, \text{SOL}}, Y, M, D, h, m, s )

Claim ITK

kITK,CPoseidon(kMVK,Ui,Y,M,D,h,m,s)k_{\text{ITK}, C} \triangleq \text{Poseidon}( k_{\text{MVK}, U_i}, Y, M, D, h, m, s )

Key Derivation Process

For Deposits

  1. Input: Solana MVK kMVK,SOLk_{\text{MVK}, \text{SOL}} (field element)
  2. Timestamp Components: Year, Month, Day, Hour, Minute, Second
  3. Hash Function: Poseidon hash function
  4. Output: Deposit ITK kITK,Dk_{\text{ITK}, D}

For Claims

  1. Input: Umbra address MVK kMVK,Uik_{\text{MVK}, U_i} (field element)
  2. Timestamp Components: Year, Month, Day, Hour, Minute, Second
  3. Hash Function: Poseidon hash function
  4. Output: Claim ITK kITK,Ck_{\text{ITK}, C}

Timestamp Resolution

The high-resolution timestamp ensures:

  • Uniqueness: Each transaction gets a unique ITK
  • Time-Bound: ITKs are tied to specific moments in time
  • Public Input: Timestamp is publicly observable on-chain
  • Granularity: Second-level precision prevents collisions

Transaction Types

Deposit Transactions

  • Use the Solana MVK kMVK,SOLk_{\text{MVK}, \text{SOL}}
  • Generate deposit ITK kITK,Dk_{\text{ITK}, D}
  • Enable linking deposits to the user's primary Solana address

Claim Transactions

  • Use the Umbra address MVK kMVK,Uik_{\text{MVK}, U_i}
  • Generate claim ITK kITK,Ck_{\text{ITK}, C}
  • Enable linking claims to the specific Umbra address

Security Analysis

Security Proof: Security of ITKs

Goal: An ITK must only be derivable by the holder of the corresponding MVK.

Assumption: Poseidon-as-a-PRF.

Argument: The MVK serves as the secret key for the PRF, and the public timestamp is the input. An on-chain observer cannot compute the ITK without the MVK.

Properties

  • MVK-Dependent: Only derivable by holders of the corresponding MVK
  • Time-Bound: Tied to specific transaction timestamps
  • Unique: Each transaction produces a unique ITK
  • Unlinkable: Without the MVK, ITKs appear random
  • Transaction-Specific: Different for deposits vs claims