diff --git a/requirements/zerokit.md b/requirements/zerokit.md
index 89deb23..9ce7851 100644
--- a/requirements/zerokit.md
+++ b/requirements/zerokit.md
@@ -4,16 +4,15 @@
 
 Zerokit is the recommended library for cryptographic operations including Poseidon hashing, RLN identity generation, and proof verification. 
 Waku relies on Zerokit, primarily for two implementaions:
-- js-waku (rln-wasm): credentials  
-- nwaku: credentials + proof generation & verification 
+- js-waku (rln-wasm): credentials (now), proof generation and verification (2025H2)
+- nwaku: proof generation & verification (now), credentials (2025H2)
 
 Current JS integration faces two main challenges:
-- **WASM cold start/load latency:** The WASM blob load time improved from ~15 seconds (v0.1.0) to ~5 seconds (v0.2.0). Notably, the current `rln-wasm` build includes proof generation and verification, which js-waku does not require. This suggests a smaller, credential-only WASM library could further reduce load times for js-waku.
+- **WASM cold start/load latency:** The WASM blob load time improved from ~15 seconds (v0.1.0) to ~5 seconds (v0.2.0). Notably, the current `rln-wasm` build includes proof generation and verification, which not all web apps built with Waku require. And even if one web app requires both credentials and proof verification/generation, it is likely done in different areas from a UX and functional PoV. This suggests a smaller, credential-only and proof-handling-only WASM libraries could further reduce load times for js-waku.
 - **Endianness mismatch:** js-waku uses big-endian (BE) throughout, as required by contracts, while Zerokit expects little-endian (LE). This necessitates conversion when interfacing between the two, though this is less critical than load latency.
 
 Additional minor challenges:
-- Insufficient documentation and upgrade notes.
-- Unclear purpose and usage of `InitOutput` and root exports.
+- Lack of documentation regarding `InitOutput` and root exports.
 - Ambiguity around the sequence and role of initialization functions such as `init()`, `initPanicHook()`, etc.
 
 We aim to align expectations and optimize collaboration between the Waku and Vac ACZ teams by clearly expressing our functional and non-functional requirements.
@@ -31,18 +30,16 @@ We aim to align expectations and optimize collaboration between the Waku and Vac
 
 - **F1.1:** Generate deterministic identity commitment (`idCommitment`) from entropy/seed.
 - **F1.2:** Generate full identity object (`commitment`, `secret`, `nullifier`, `trapdoor`).
-- **F1.3:** Support Big-Endian (BE), instead of Little-Endian (LE)
 
 ### Usability
 
 - **U1.1:** WASM load time should be <5s in cold start on most browsers.
-- **U1.3:** _Optional:_ Provide a reduced WASM build or a dedicated `@zerokit/credentials` package that only supports credentials (no proof logic).
+- **U1.2:** API accepts and return Big-Endian (BE), so data can be passed to Web3 RPC API without manipulation.
+- **U1.3:** Documentation is provided to use APIs to generate and load credentials.
 
 ### Reliability
 
-- **R1.1:** Deterministic outputs — BE/LE encoding should not affect hash reproducibility (if possible).
-- **R1.2:** Cross-language consistency between js-waku and nwaku.
-- **R1.3:** Exposed APIs should be stable and well-documented.
+- **R1.1:** Inter-operability between Zerokit FFI (x86_64, ARM, binaries) and WASI (browser WASM) APIs.
 
 ### Performance
 
@@ -50,7 +47,7 @@ We aim to align expectations and optimize collaboration between the Waku and Vac
 
 ### Supportability
 
-- **S1.1:** Available for: JavaScript/TypeScript (browsers), nim
----
+- **S1.1:** Available for: JavaScript/TypeScript (browsers)
+- **S1.2:** Available for Nim
+
 
-## Use Case 2: Proof Generation and Verification