agentsclimarketplace

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

Install
npx -y skills add mysteryon88/skills --skill mina-privacy-credentials-security

Assembled 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/

Keep looking

Skills are one crate of 326,834. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.