[FEAT] Zero-Knowledge Anonymous Provider Staking & Shielded Reputation Proofs

[jotel-dev]

telegram link : t.me/nullifiersystem

---

1. Summary & Core Promise

Currently, providers staking collateral in contracts/reputation/src/lib.rs must link their public Stellar wallet address to their registered provider identity in apps/api/src/lib/store.ts. This allows external observers to track provider net worth and physical cash transaction volume on-chain.

This feature implements a Zero-Knowledge Anonymous Provider Staking & Shielded Reputation Proof Engine. Providers stake collateral into a shielded Soroban pool (contracts/reputation/src/lib.rs), receive a cryptographic commitment H(secret + stake), and generate local zk-SNARK Merkle membership proofs (contracts/zk-credential/src/lib.rs) to prove minimum stake compliance without revealing their public Stellar address.

---

2. Background & Architectural Risks

• Financial Surveillance: Public address linkage allows competitors to track exact provider collateral balances and physical locations.
• Double-Spending Shielded Stakes: Without nullifier tracking, a provider could use a single shielded stake commitment to verify multiple fake provider profiles.

---

3. Database Layer Specifications

Migration SQL (032_add_shielded_provider_staking.sql)

CREATE TABLE shielded_stake_commitments (
    commitment_hash VARCHAR(64) PRIMARY KEY,
    merkle_leaf_index INT NOT NULL,
    staked_amount_stroops BIGINT NOT NULL,
    is_active BOOLEAN NOT NULL DEFAULT TRUE,
    created_at TIMESTAMP WITH TIME ZONE DEFAULT CURRENT_TIMESTAMP
);

CREATE TABLE shielded_provider_nullifiers (
    nullifier_hash VARCHAR(64) PRIMARY KEY,
    provider_id VARCHAR(64) NOT NULL,
    created_at TIMESTAMP WITH TIME ZONE DEFAULT CURRENT_TIMESTAMP
);

Data Locking (SELECT FOR UPDATE)

BEGIN;
SELECT nullifier_hash FROM shielded_provider_nullifiers WHERE nullifier_hash = $1 FOR UPDATE;
-- Verify nullifier has not been spent/used by another provider profile...
COMMIT;

---

4. Backend Route & Service Layer Specifications

Route: POST /api/v1/provider/shielded-stake/verify

1. Validation: Zod validates ZK proof payload, merkleRoot, and nullifierHash.
2. Locking: DB transaction acquires SELECT FOR UPDATE on shielded_provider_nullifiers.
3. Proof Verification: Verifies ZK proof against on-chain Merkle root.
4. Response: Returns HTTP 200 OK with anonymous provider verification status.

---

5. Background Processors / Workers

(Client WASM Proof Generation + Soroban On-Chain Verifier)

---

6. Frontend / UI Component Specifications

Component: mobile/frontend/src/components/ShieldedStakingModal.tsx

• Modal allowing providers to deposit shielded collateral, generate local WebAssembly ZK stake proofs, and attach anonymous verification badges to their profile.

---

7. Rigor & Test Plan

1. Rust Smart Contract Test (contracts/reputation/src/lib.rs): Verify shielded stake commitment deposit and Merkle root update.
2. Double-Verification Nullifier Test (shielded_stake_test.ts): Assert reusing the same nullifier hash fails with 409 Conflict.

---

8. Relevant Files Inventory

New Files to Create

• apps/api/src/db/migrations/032_add_shielded_provider_staking.sql
• apps/api/src/routes/shielded-staking.ts
• apps/api/src/routes/__tests__/shielded-staking.test.ts
• mobile/frontend/src/components/ShieldedStakingModal.tsx

Existing Files to Modify

• contracts/reputation/src/lib.rs
• contracts/zk-credential/src/lib.rs
• apps/api/src/lib/crypto.ts
• apps/api/src/lib/stellar.ts
• apps/api/src/app.ts
• mobile/frontend/src/pages/Dashboard.tsx

---

9. Acceptance Criteria

• Providers stake collateral into a shielded pool without revealing public wallet addresses.
• ZK proofs verify minimum stake compliance on-chain.
• Nullifier tracking prevents double-binding a single stake to multiple profiles.

---

10. Contributor Notes

• ⚠️ Nullifier Safety: ALWAYS check shielded_provider_nullifiers in a SELECT FOR UPDATE block to prevent identity cloning.

[devJaja]

Cna I take this issue please

[grantfox-oss]

🦊 GrantFox — @devJaja has been assigned to this issue as part of the Third Campaign campaign!

Next steps:

1. Open a Pull Request referencing this issue (e.g., Closes #427)
2. Your PR will be reviewed by the Nullifier-Systems maintainers

Good luck! Track your progress on GrantFox.