# business-verified-v1

businessVerified == 1 (business_registered 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 | `0x827ba9c0f6ab9737e9170ce49c745a3482588fd8e9ab1d6d5c568f37c352b2c4` = keccak256("business-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 | `businessVerified`: 1 when the holder's `business_registered` badge is at evidence L2 or above, else 0 |
| Public signals | `commitment`, `expected`, `nonce` |
| Request (`<sw-verify request>`) | `business-verified` -> predicate `{ "circuit": "business-verified-v1", "params": {} }` |
| Registry | **Not registered as of 2026-09-27**: until `register-circuit business-verified-v1 0xE918663b7e9218EA85Bb09F2F2Bb0Db6DBA776f3 0xab173add5a694de0caa645ae6365a5001923253c4f72d178936dfb2855c3e41d 1 https://trendy.storydot.kr/sdk/zk/business-verified-v1/` is sent, verifiers refuse this predicate |

## Why a separate name is safe

A proof for `business-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("business-verified-v1"))` on the
registry, and the issuer puts only the businessVerified commitment there. A proof about
identityVerified, relabelled as business-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("business-verified-v1") to a verifier whose vkHash is the one above; the proof passes
   `verifyProof` there.
2. `publicSignals[0]` equals `commitment(credentialId, keccak256("business-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.