agentsclimarketplace

Mina o1js security review

Skill mysteryon88/skills/mina-protocol/skills/mina-o1js-security-review

My Web3 skills & experiments

Install
npx -y skills add mysteryon88/skills --skill mina-o1js-security-review

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.

What its author says it does

Copied from the file, not written here

Use when auditing, threat modeling, hardening, or reviewing Mina o1js zkApps, circuits, AccountUpdates, permissions, custom tokens, frontend prover flows, privacy, or deployment security.

SKILL.md

7.0 KB, as published. Nobody here has run it

Mina o1js Security Review Skill

Use when

Use this skill when the user asks for an audit, security review, vulnerability assessment, threat model, hardening plan or code review for a Mina/o1js zkApp.

This skill is defensive. Review only user-owned or authorized code.

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.

Safety boundary

  • Do not provide destructive exploitation against third-party systems.
  • Do not exfiltrate secrets.
  • If secrets appear in files, report minimal evidence and recommend immediate rotation.
  • Do not ask the user to paste private keys, seed phrases or production secrets.

Review principle

Mina/o1js security bugs often happen when a developer believes a normal TypeScript check is part of the proof, or when an AccountUpdate/permission path allows something the proof logic did not intend.

Always separate:

Ordinary TS runtime check
Provable assertion
State precondition
Signature authorization
Permission authorization
Transaction/AccountUpdate structure
Frontend/backend trust assumption

Audit workflow

1. Scope capture

Collect or infer:

  • repository and commit hash;
  • o1js version and zkApp CLI version;
  • deployed addresses if any;
  • target network;
  • in-scope files;
  • roles: deployer, admin, user, prover, frontend, backend, relayer, oracle, issuer, auditor;
  • assets at risk: MINA, custom tokens, credentials, votes, reputation, private data, verification keys;
  • high-risk features: tokens, reducers/actions, custom AccountUpdates, recursion, Merkle state, credentials, external data.

2. Architecture map

Produce this before findings:

Contracts:
ZkPrograms:
State fields:
Methods and call graph:
Events/actions:
AccountUpdate tree per user flow:
Permissions and upgrade policy:
Frontend/prover/backend flow:
External dependencies:

3. Invariant list

Write project-specific invariants. Examples:

  • only authorized users can update state;
  • state transitions bind to the current on-chain state;
  • every private witness is constrained to public input or on-chain commitment;
  • nullifier can be used only once;
  • token supply equals documented mint minus burn plus/minus pending operations;
  • all token movements are approved by the intended token owner logic;
  • every accepted action can be reduced without permanently bricking the contract;
  • admin cannot silently replace verification key unless explicitly documented;
  • private data does not appear in public inputs, events, actions, logs or analytics;
  • frontend/backend cannot forge a proof or swap public inputs without detection.

4. Code review checklist

Provable constraints

  • Security checks use assertEquals, assertTrue, assertFalse, range assertions or equivalent provable constraints.
  • No witness is accepted without being tied to a public root, hash, signature, commitment or state value.
  • Conditional logic uses Provable.if() correctly and avoids side effects inside branches.
  • Fixed-size provable arrays are used where required.
  • Field modular arithmetic is not used where bounded integer behavior is required.
  • Hashes include domain separation.
  • Signatures bind all required fields: app id, chain/network id if needed, contract address, action id, nonce/nullifier, amount, recipient, expiry.

State and preconditions

  • Security-critical state reads use getAndRequireEquals() or requireEquals().
  • Account and network preconditions are explicit for balances, nonce, timestamp, slot, delegate or token state where relevant.
  • Stale state and concurrent user flows are handled.

AccountUpdates

  • Every AccountUpdate has the intended account, tokenId, authorization and balance change.
  • Child AccountUpdates cannot inherit unintended token powers.
  • mayUseToken and token ownership are understood and tested.
  • fundNewAccount, AccountUpdate.create, createSigned, approve, custom send/mint/burn flows are reviewed.
  • Transaction shape is stable enough for security assumptions.

Permissions and upgrades

  • Permission matrix is documented.
  • setVerificationKey and setPermissions are not left too loose.
  • Least authority is applied.
  • Upgrade path is either locked, proof-governed, multisig/timelock-governed or clearly documented as admin-trusted.

Actions/reducers

  • Actions are public and not used for secret data.
  • Reducer can process malformed or adversarial actions safely.
  • Action type has canonical representation if needed.
  • Queue growth, batching and griefing are considered.
  • Reduction state cannot be permanently stuck by one bad action.

Privacy

  • Public inputs, events, actions and state do not reveal private values accidentally.
  • Backend and frontend do not log private witnesses.
  • Nullifiers are domain-separated.
  • Timing/IP/wallet metadata risks are documented when privacy claims are made.

Dependencies and devops

  • o1js version is pinned.
  • Deprecated APIs are flagged.
  • Deployment scripts do not expose keys.
  • CI does not print secrets or proofs containing sensitive auxiliary data.
  • Frontend integrity and supply chain risks are considered.

Finding format

### [Severity] Title

Affected files:
Confidence: High / Medium / Low
Category:
Description:
Impact:
Why this happens in Mina/o1js:
Proof-of-concept or exploit sketch:
Recommended fix:
Regression test:
References:

Severity guide

  • Critical: direct theft, arbitrary mint/burn, arbitrary state update, verification key replacement, permanent fund lock for high-value assets.
  • High: unauthorized privileged action, replay of important operation, broken nullifier, severe privacy leak, reducer bricking.
  • Medium: missing precondition with realistic race risk, incomplete supply invariant, centralization risk not documented, unsafe upgrade process.
  • Low: weak docs, test gaps, non-critical leakage, maintainability issues.
  • Informational: hardening suggestion or architectural note.

Required output

For every review, return:

  1. Scope and assumptions.
  2. Architecture map.
  3. Role model.
  4. Permission matrix.
  5. AccountUpdate map.
  6. Invariants.
  7. Findings.
  8. Test gaps.
  9. Deployment risks.
  10. Recommended next steps.

Red flags

  • get() without requireEquals() on state used in security logic.
  • Provable.witness() without assertions tying it to public data.
  • Field used as token amount without range/UInt wrapper.
  • JS if depending on provable values.
  • Admin can set verification key by signature without disclosure.
  • Token manager approves arbitrary child updates.
  • Reducer assumes all actions are honest.
  • Events/actions contain PII or secrets.
  • Tests only cover happy path.
  • README claims privacy but frontend sends raw credential to backend.

Keep looking

Skills are one crate of 328,083. 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.