# employment-verified-v1

employmentVerified == 1 (employment_verified badge at evidence L2 or above). Proven without revealing the attribute, against a commitment
`Poseidon(value, salt)` the issuer recorded in SuperWalletTrustRegistry under this circuit's id,
and bound to the verifier's nonce.

**This circuit has no files of its own.** It is [identity-verified-v1](../identity-verified-v1/) - the same equality
circuit, proving key, verification key and verifier contract - registered under another name. The
key ceremony, the transcript and every file are in [../identity-verified-v1/](../identity-verified-v1/).

| | |
|---|---|
| circuitId | `0x4776d0243523cd301e1ce8e220b04f5c91685c6cb608520940e125addd933384` = keccak256("employment-verified-v1") |
| Key and verifier of | `identity-verified-v1` (circuitId `0xbbaa81fbe949e6bb2d04a67ab3d30af5dc8558122e51ec926160662bde545a0d`) |
| vkHash | `0xab173add5a694de0caa645ae6365a5001923253c4f72d178936dfb2855c3e41d` (identical to identity-verified-v1's) |
| Verifier contract (Xphere 20250217) | `0xE918663b7e9218EA85Bb09F2F2Bb0Db6DBA776f3` (identity-verified-v1's; runtime keccak256 `0x8b5b21a8f328725191064aaa6cd4990e9157011b8d1b883df0c975db8ebffdf6`) |
| ceremonyContributions | 1 (identity-verified-v1's ceremony) |
| Committed attribute | `employmentVerified`: 1 when the holder's `employment_verified` badge is at evidence L2 or above, else 0. There is no occupation or industry code in the system, and none is claimed |
| Public signals | `commitment`, `expected`, `nonce` |
| Request (`<sw-verify request>`) | `employment-verified` -> predicate `{ "circuit": "employment-verified-v1", "params": {} }` |
| Registry | **Not registered as of 2026-09-27**: until `register-circuit employment-verified-v1 0xE918663b7e9218EA85Bb09F2F2Bb0Db6DBA776f3 0xab173add5a694de0caa645ae6365a5001923253c4f72d178936dfb2855c3e41d 1 https://trendy.storydot.kr/sdk/zk/employment-verified-v1/` is sent, verifiers refuse this predicate |

## Why a separate name is safe

A proof for `employment-verified-v1` and one for `identity-verified-v1` are checked by the same contract with the same
key, so the contract alone cannot tell them apart. What tells them apart is the commitment: a
verifier compares `publicSignals[0]` with `commitment(credentialId, keccak256("employment-verified-v1"))` on the
registry, and the issuer puts only the employmentVerified commitment there. A proof about
identityVerified, relabelled as employment-verified-v1, carries the identityVerified commitment and fails that
comparison - as long as the issuer uses a different salt for every attribute (the backend draws one
per attribute).

## What a verifier checks

1. The registry maps keccak256("employment-verified-v1") to a verifier whose vkHash is the one above; the proof passes
   `verifyProof` there.
2. `publicSignals[0]` equals `commitment(credentialId, keccak256("employment-verified-v1"))`, the credential is
   anchored and not revoked, and its issuer is active.
3. The last public signal equals the nonce the verifier issued.
4. `expected` = 1.