Back to overviewResources

Feasibility Memo: ZK-Private, Ethereum-Based Creativity & Morality Testing

Version: August 2026 · Status: Feasible, with accepted trade-offs

How a candidate can hold a verifiable score credential in their own custody and reveal chosen subscores to a verifier, without a public on-chain record linking wallet to score.

Companion documents on this site: the morality and creativity bibliographies. The litepaper describes where this layer sits in the roadmap (v2).

Bottom line: feasible: but "exact raw score + subscores revealed" + "on-chain" + "anonymous" is the hardest corner of the design space. It is achievable, with explicit trade-offs that must be accepted.

1. The core tension to resolve

The request combines three things that partially collide:

WantImplication
Anonymous on-chain reputationNobody can link a score S to a wallet W from chain data alone
Exact raw score + subscoresThe verifier must learn the precise value → data exits ZK
Proof-of-humanity + walletOne identity anchor, one human, one result

The reconciliation: the score is not a public on-chain value; it is an encrypted, ZK-selectively-revealable credential that the wallet holder can present to a verifier on demand. "On-chain reputation" does not mean "score printed on-chain": it means the credential's authenticity and uniqueness are anchorable on-chain while the payload stays private. If the score is literally made visible in a public registry, that permanently leaks privacy and lets anyone correlate wallet to score. This memo therefore scopes "on-chain" to anchors / attestations-of-existence, not plaintext scores.

2. Recommended architecture

                    ┌──────────────────────────────────────────────┐
 TEST-TAKER (browser)                                              │
   wallet connect   │  SIWE session → unique nonce per attempt    │
   PoH gate         │  World ID / Gitcoin Passport (must pass)     │
   take instruments │  AUT · CNI · cheating · SIMI · MFQ · CAQ      │
                    └───────────────┬──────────────────────────────┘
                                    │ responses (never stored plaintext
                                    │  long-term; scored ephemerally)
                                    ▼
              ┌──────────────────────────────────────────┐
              │  SCORING ORCHESTRATOR (server, trusted)  │
              │  runs AUT/CNI/cheating/MFQ/SIMI/CAQ keys │
              │  → exact raw subscores                    │
              └───────────────┬──────────────────────────┘
                              │ score object
                              ▼
              ┌──────────────────────────────────────────┐
              │  EAS SCHEMA (register once, on-chain)     │
              │  schema: composite {u8 fluency, u8 flex,  │
              │   u8 orig, u8 elabor, u8 CNI_C, u8 CNI_N, │
              │   u8 CNI_I, u8 cheat, u8 SIMI_int,        │
              │   u8 SIMI_sym, u8 MFQ_*, u8 CAQ_total}    │
              │  OFF-CHAIN + SIGNED + ENCRYPTED           │
              └───────────────┬──────────────────────────┘
                              │ attestationUID + nullifier (on-chain)
                              ▼
                    ┌──────────────────────────────────┐
                    │  ZK PROOF SERVICE (Noir/Semaphore)│
                    │  - I am unique human (Semaphore)  │
                    │  - attestationUID is mine         │
                    │  - reveal selected fields         │
                    └──────────────────────────────────┘

Layer-by-layer tools (as of August 2026)

A. Wallet + auth, SIWE (EIP-4361), Standard, mature

  • @loginxyz/siwe (server-side verify) + wagmi / viem / RainbowKit / WalletConnect to connect MetaMask, Coinbase Wallet, etc.
  • Each attempt gets a fresh session-bound nonce so a test cannot be replayed or re-submitted.

B. Proof of humanity (mandatory): the anti-gaming backbone

  • World ID (recommended primary): Semaphore-based ZK "unique human" proof, zero data leaked, reusable, deployed (World Chain + EVM). Mature: 400+ participant trusted setup, audited.
  • Gitcoin Passport: web2-stamp trust score: good complement, catches more accounts, needs no biometric Orb.
  • BrightID / Humanity Protocol: alternatives.
  • Security note: require PoH before letting someone sit the test; otherwise sybils open many wallets and farm the battery.

C. ZK layer: Noir recommended over raw Circom

  • Noir (nargo + Barretenberg) for the proof: multi-typed composite scores and threshold/subfield disclosure are far more pleasant in Noir than hand-written Circom, and it is backend-agnostic.
  • Semaphore for the "unique human + nullifier anti-double-signing" part: it already solves "one person, one voucher" so a person cannot mint 50 reputations.

D. Attestation & selective disclosure: EAS

  • EAS free, open source, deployed on Ethereum + L2s + World Chain. Use off-chain signed attestations (signOffchainAttestation), the schema is signed by the scoring authority, shared to the test-taker, and the attestationUID is timestamped on-chain as the existence anchor. For selective disclosure EAS ships a PrivateData class (Merkle-tree multiproofs) to reveal chosen fields while hiding the rest. Note: EAS's own selective-disclosure tooling is Merkle-multiproof based, not a zk-SNARK, the actual zero-knowledge proof is generated separately in Noir and combined with the EAS attestation as the authenticity layer.

E. Exact raw payoff

  1. Taker holds an EAS attestation (encrypted, in their custody).
  2. To a verifier, the taker generates a Noir proof: "attestationUID U belongs to me AND reveals subscore CNI_C = 0.72 (exact)" plus a Semaphore proof "I am a unique, real human."
  3. Verifier checks: EAS attestation exists + not revoked + ZK proof valid → accepts CNI_C = 0.72 as truthful.
  4. No central database ever links wallet ↔ score; the link exists only momentarily in that verifier session.

2b. Service-by-service notes (from official docs, August 2026)

Each tool below was checked against its current official documentation to confirm it works for this project. Two claims in the original plan needed correcting (marked update).

A. Sign-In with Ethereum (EIP-4361) ✅ Confirmed

  • Official docs (login.xyz) + maintained TS/Rust/Python/Ruby libraries; @loginxyz/siwe for server verification.
  • Works exactly as planned: bind a session to a wallet address, replay-resistant nonce per attempt. Mature and actively maintained.

B. World ID (World) ✅ Confirmed, with integration update

  • Current integration is World ID 4.0 via IDKit (@worldcoin/idkit-core / React / Swift / Kotlin), not raw Semaphore calls.
  • Flow: your backend signs an RP signature (RP = relying party); IDKit requests a proof from the user's World App; your backend verifies via the Developer Portal POST /v4/verify/{rp_id} or on-chain Solidity (verifyProof).
  • Update to plan: proof verification is a server-side (Developer Portal) or on-chain call, and the anti-reuse mechanism is an RP-scoped nullifier your backend stores (UNIQUE on nullifier + action).
  • Plus: the signal field lets you bind the proof to a wallet address / test context: exactly what you need to semantically tie "this human" → "this wallet → this score."
  • Under the hood it is still Semaphore/zero-knowledge (WorldIDRegistry + Merkle inclusion + nullifier), so the security model in §1–§3 is unchanged. World Chain also offers free gas for verified users.

C. Human Passport (formerly Gitcoin Passport) ✅ Confirmed, renamed

  • Update to plan: Gitcoin Passport is now Human Passport (passport.xyz / passport.gitcoin docs).
  • Product line: Stamps (KYC, biometrics, web3 activity, web-of-trust, web2 → aggregate score), Stamps API v2, Passport Embed (React), Passport Models (address sybil classifier), and Individual Verifications (privacy-preserving ZK: Government-ID KYC, Phone, Biometrics, Clean-Hands) with on-chain attestations on Optimism/Base.
  • Fits as the complementary PoH layer: Passport Models can classify a wallet as human/sybil with no user friction (as an alternative to a Stamps account), or Stamps-based score as a stronger pre-test gate.

D. Noir + Barretenberg (bb.js) ✅ Confirmed, incl. browser

  • Noir (v1.0.0-beta.25) + nargo for the circuit; @aztec/bb.js runs the prover/verifier in the browser and Node (UltraHonk), and can emit a Solidity verifier (Keccak variant) for EVM verification.
  • Official "building a web app with Noir + Barretenberg" guide; browser multithreading works with COOP/COEP headers. Confirms client-side ZK proving is feasible.

E. Semaphore V4 ✅ Confirmed

  • ZK group-membership + nullifier to prevent double-signaling. Audited (PSE, Veridise) with a completed trusted-setup ceremony (400+ participants). Validates "one real human → one reputation."

F. EAS ✅ Confirmed, one nuance

  • SDK supports off-chain signed attestations, delegated on-chain, and timestamping off-chain UIDs on-chain. PrivateData (Merkle multiproof) provides selective disclosure of fields.
  • Nuance: EAS's built-in selective disclosure is Merkle-based, not SNARK-based; the zero-knowledge component is supplied by Noir. Treat EAS as the authenticity/attestation ledger, Noir as the privacy layer.

G. Sign Protocol ➕ New: worth considering

  • Human Passport's own privacy-preserving verifications post attestations via Sign Protocol on Optimism/Base (an EAS alternative). If you prefer an EIP-7122-style attestation standard, Sign Protocol is a viable swap for EAS, but EAS's off-chain + timestamp flow is the closer fit to this design.

Net: All six planned services are real, current, and fit this project. The material changes to the plan are: (1) World ID via IDKit 4.0 + Developer Portal/on-chain verification with RP-scoped nullifiers and an optional wallet-binding signal; (2) Passport is now Human Passport with added Models/Individual-Verifications options; (3) EAS selective disclosure is Merkle-based, so Noir supplies the ZK.

3. Threat model (blockchain security perspective)

ThreatMitigation
Wallet farming / sybilMandatory PoH (World ID / Gitcoin Passport) pre-test; Semaphore nullifier blocks multi-mint
Test-taker fakes scoreScoring done by trusted orchestrator; response data not self-reported for performance items
Proctor/operator sees identityResponses transient; score encrypted to the taker
Score ↔ wallet correlation on-chainScores never in public plaintext; only hashes / UIDs / nullifiers
Attestation replay / forgeryEAS schema signed by the scoring authority; on-chain UID
One real human → many reputationsSemaphore nullifier = exactly one reputation per human
AI/LLM takes the testPoH blocks bots at the account layer; behavioral timing/entropy analytics on performance items

Residual risk (must be accepted): a central scoring oracle is trusted. It knows exact scores and could, if compromised, fake or link them. Mitigate with threshold / multisig signing, key rotation, and not retaining response plaintext. This is inherent to any "instrument scored by proprietary keys" design. Full decentralization of scoring would require the scoring logic to run in verifiable computation (e.g., a zkVM / stealth EVM of the scoring rules): a heavier, future extension.

Biggest privacy leak to avoid shipping: putting the score in public on-chain clear; that permanently links wallet ↔ score. Stay with encrypted + selective-disclosure.

4. Trade-offs summary

  • ✅ Best privacy: encrypted EAS + Noir selective disclosure + Semaphore uniqueness
  • ⚠️ Cost / complexity: Noir proving + Semaphore integration is real engineering; budget for a circuit audit
  • ⚠️ UX: requires MetaMask / Coinbase Wallet plus World ID or Passport; some candidates will churn
  • ⚠️ Trust: central scoring oracle remains a single point of trust
  • ✅ Composability: EAS yields a portable "creativity/morality score" reputation that others can consume

5. Recommendation & build path

Adopt the architecture above. Pragmatic staging:

  1. Phase 0 (prove concept): SIWE connect → one instrument (AUT) → EAS off-chain encrypted attestation → Noir proof revealing one subscore on a testnet (Sepolia / Base / World Chain testnet). Validate UX with 1 wallet + World ID.
  2. Phase 1: Add Semaphore uniqueness; wire all remaining instruments; exact-subscore disclosure; build the verifier dApp.
  3. Phase 2: Rotate in heavier privacy (scoring in a verifiable zkVM) only if the central-oracle trust model becomes unacceptable.

Do NOT skip: a security / circuit audit (Semaphore is already audited; custom Noir circuits are not), and a privacy / legal review: collecting moral-dilemma and cheating-task data triggers GDPR / employment-law considerations regardless of on-chain anchors.

6. Open follow-ups

  • Draft the EAS composite schema JSON and a sample Noir circuit for subscore disclosure.
  • Comparison doc of PoH providers (World ID vs Gitcoin Passport vs BrightID) with integration cost estimates.
More resources