Mina privacy credentials security
Skill mysteryon88/skills/mina-protocol/skills/mina-privacy-credentials-security
Use when designing, implementing, testing, or reviewing Mina privacy flows, credentials, zkKYC, selective disclosure, nullifiers, unlinkability, issuer signatures, or private-data leakage.From its SKILL.md
npx -y skills add mysteryon88/skills --skill mina-privacy-credentials-securityAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
4.4 KB, 907 tokens by cl100k_base, as published. Nobody here has run it
Mina Privacy and Credentials Security Skill
Use when
Use this skill when building or auditing private credentials, zkKYC, attestations, proof of membership, proof of age, private voting, private reputation, selective disclosure or nullifier-based applications on Mina.
Shared references
If installed from the full package, shared resources live in ../mina-protocol-agent/references/. Load ../mina-protocol-agent/references/INDEX.md only when task cards, examples, templates, source links or deeper checklists are needed.
Core principle
A proof can hide a witness, but the full application can still leak identity through public inputs, events, actions, logs, backend APIs, frontend analytics, timing, IP metadata, wallet behavior or reused nullifiers.
First output
Produce a data map before design or findings:
Value | Public on-chain | Public proof input | Private witness | Frontend | Backend | Wallet | Logs/analytics | Retention
Privacy claim matrix
For every user-facing claim, verify actual leakage:
Claim:
What chain sees:
What backend sees:
What frontend sees:
What issuer sees:
What relayer sees:
Linkability risk:
Remaining caveat:
Credential model checklist
Issuer
- issuer public key is constrained;
- issuer signature binds all credential fields;
- issuer key rotation is defined;
- malicious issuer risk is documented;
- issuer does not learn unnecessary verifier/app usage if privacy claim requires that.
Credential
- credential schema is fixed and versioned;
- expiry is constrained;
- revocation model exists;
- credential commitment has domain separation;
- selective disclosure fields are constrained correctly;
- undisclosed fields cannot be swapped.
Nullifier
A good nullifier usually binds:
domain/app id
action id or circuit id
user secret or credential secret
contract address or network if needed
round/epoch/poll id if needed
Check:
- nullifier cannot be reused for the same action;
- nullifier is not linkable across unrelated apps unless intended;
- nullifier is not derived from low-entropy PII;
- nullifier is stored/checked on-chain or in a verifiable commitment structure.
Replay and freshness
- proof includes current app domain;
- proof binds recipient/action/amount when relevant;
- proof has expiry or epoch if needed;
- old public input cannot be replayed with new transaction details;
- relayer cannot alter outputs.
Data leakage
Check that private data is not in:
- public inputs;
- state fields;
- events;
- actions;
- transaction memo;
- frontend console logs;
- backend request body;
- analytics;
- crash reports;
- browser localStorage if not encrypted/justified;
- screenshots or debug UI.
Common bad patterns
Nullifier too broad
Bad:
const nullifier = Poseidon.hash([secret]);
This links the user everywhere.
Better:
const nullifier = Poseidon.hash([
DOMAIN_NULLIFIER,
appId,
actionId,
epoch,
secret,
]);
Signature does not bind app/action
Bad:
issuerSig.verify(issuer, [age]).assertTrue();
Better:
issuerSig.verify(issuer, [
DOMAIN_CREDENTIAL,
schemaVersion,
subjectCommitment,
ageLowerBound,
expiry,
]).assertTrue();
Then the app-specific proof should bind its own public inputs and nullifier.
Privacy claim ignores backend
Bad claim:
No one sees your passport data.
But backend receives raw passport data to generate proof.
Better design:
Proof is generated locally or with a clearly disclosed trusted prover.
Backend receives only proof and public inputs.
Required tests
- invalid issuer signature fails;
- wrong credential field fails;
- expired credential fails;
- revoked credential fails if revocation is in scope;
- reused nullifier fails;
- same user can create unlinkable proofs for different domains if intended;
- relayer cannot change recipient/action after proof generation;
- logs/events/actions contain no raw PII;
- frontend does not send witness to backend unless explicitly trusted.
Output format
Data leakage map
Privacy claim matrix
Credential trust model
Nullifier/domain model
Circuit findings
Frontend/backend findings
Regression tests
User-facing caveats
What ships with it: 1 file
242 B alongside SKILL.md
agents/
- openai.yaml242 B