| name | review-contract |
| description | Security review for Cardano smart contracts written in Aiken, Plutus, or OpShin. Trigger: "review contract", "audit validator", "check security", "find vulnerabilities", "security review", "smart contract audit", "check for exploits". |
| allowed-tools | Read Grep Glob |
| disallowed-tools | Bash Edit Write WebFetch WebSearch |
Review Cardano Smart Contract
Perform a structured security review of a Cardano smart contract (validator, minting policy, or staking script). Produces findings with severity ratings and actionable remediation.
When to use
- User asks to review, audit, or check a Cardano smart contract
- User wants to find vulnerabilities in a validator
- User asks "is this contract safe?" or "what are the risks?"
- Before deploying a validator to mainnet
- When reviewing a pull request that modifies on-chain code
When NOT to use
- For off-chain transaction building code (use general code review)
- For Cardano node configuration or infrastructure
- For non-Cardano smart contracts (Solidity, Move, etc.)
- When the user only wants a feature explanation, not a security assessment
Key principles
- eUTxO model awareness: Cardano uses eUTxO, not accounts. Vulnerabilities differ fundamentally from EVM chains. Focus on datum/redeemer validation, value preservation, and transaction-level attacks.
- Completeness over speed: Check every pattern in the vulnerability checklist. Missing one critical issue negates the value of the entire review.
- Context matters: A pattern that is safe in one validator design may be dangerous in another. Understand the protocol design before judging.
- Severity accuracy: Do not inflate severity. A missing check that cannot be exploited in practice is informational, not critical.
- Actionable output: Every finding must include what is wrong, why it matters, and how to fix it.
Workflow
Step 1: Understand the contract
Read the validator source files and any associated documentation.
- Identify the contract type: spending validator, minting policy, staking validator, or multi-validator
- Identify the datum type and its fields
- Identify the redeemer type and its variants
- Identify what the validator is trying to accomplish (escrow, DEX, lending, etc.)
- Note any linked validators (e.g., minting policy that works with a spending validator)
Search the project for related files:
- Look for test files, specification documents, and off-chain code
- Look for configuration or parameter files
Step 2: Search Bundled Documentation
Search the bundled documentation for relevant content:
${CLAUDE_SKILL_DIR}/../../docs/sources/aiken/ - Aiken language docs${CLAUDE_SKILL_DIR}/../../docs/sources/aiken-design-patterns/ - Aiken design patterns${CLAUDE_SKILL_DIR}/../../docs/sources/smart-contract-vulnerabilities/ - Smart contract vulnerability reference${CLAUDE_SKILL_DIR}/../../docs/sources/plinth/ - Plinth (PlutusTx) docs
Step 3: Check against the vulnerability checklist
Go through every item in the vulnerability checklist (see References below). For each pattern:
- Determine if the pattern is applicable to this contract type
- If applicable, search for the specific code patterns that indicate vulnerability
- If a vulnerability is found, document it with the exact code location
Key checks by contract type:
Spending validators:
- Double satisfaction: Is each input bound to its own output (tagging, or one script input per tx)?
- Datum hijacking: Is the continuing output's full address pinned, not just its datum?
- UTxO authentication: Are protocol UTxOs identified by token, not by address?
- Value preservation: Are output values checked, and is only the expected asset set allowed?
- Signer checks: Are required signers validated on every branch, including the fallback?
- Datum transitions: Are immutable fields asserted equal across the transition?
- Output ordering: Are outputs found by predicate, or by unverified index?
Minting policies:
- Infinite minting: Is the quantity constrained across the whole policy, not one asset name?
- One-shot uniqueness: Is the policy parameterized by a consumed
OutputReference?
- Burn path: Are negative quantities an explicit decision?
Stake scripts (withdraw / publish handlers):
- Withdrawal validation bypass: does the spender pin the specific stake script hash?
- Insufficient staking control: does
withdraw constrain where rewards go, and publish restrict certificates?
Step 3b: Decide whether the design/operational pass applies
references/design-and-operational-risks.md covers five concerns that are not
vulnerabilities: hardcoded addresses, collateral assumptions, script hash mismatch,
Plutus version confusion, and redeemer size. They never belong in the findings table.
Read the user's request to decide what they actually want:
- Security review only ("is this safe?", "find vulnerabilities", "audit this") --
work the vulnerability checklist. When you finish, tell the user the design and
operational pass exists and ask whether they want it. Do not run it uninvited and do
not pad the report with it.
- Deployment or readiness framing ("are we ready for mainnet?", "review before we
deploy", "check the deployment") -- both apply. Run the vulnerability checklist and
the design/operational pass, and say up front that you are doing both.
- Explicitly operational ("check our parameterization", "is our Plutus version
right?") -- run the design/operational pass. Offer the security review as well, since
a request framed operationally often wants exploitability checked too.
When both are in scope, keep them visually separate in the output (see Step 6). If a
design/operational concern turns out to be concretely exploitable, it stops being an
observation: report it as a finding under whichever vulnerability class it actually
falls into, and cite the exploit.
Several entries correlate across the two documents and carry Related links --
follow them rather than treating the split as a hard wall.
Step 4: Language-specific checks
Aiken:
- Use of
expect vs when/is -- expect causes script failure on mismatch; sometimes this is desired, sometimes it hides logic errors
- Function signatures and type safety
- CIP-57 blueprint compliance
- Proper use of
builtin functions vs stdlib
- Trace messages that leak information
Plutus (Haskell):
- Unsafe use of
error vs returning False
- Integer overflow considerations
- Lazy evaluation causing unexpected memory use
- Proper use of
PlutusTx.IsData derivations
OpShin (Python):
- Type annotation completeness
- Python-specific pitfalls (mutable defaults, etc.)
- Correct use of OpShin-specific decorators
Step 5: Search for cross-cutting concerns
- Search for hardcoded addresses or currency symbols
- Search for time-dependent logic and check range handling
- Search for any TODO, FIXME, HACK comments
- Check if tests exist and what they cover
- Check if there is an off-chain component and whether it matches on-chain logic
Step 6: Compile and report findings
Organize findings by severity:
- Critical: Direct loss of funds or complete protocol bypass. Must fix before deployment.
- High: Likely exploitable under realistic conditions. Should fix before deployment.
- Medium: Exploitable under specific conditions or causes protocol degradation. Should fix.
- Low: Minor issues, defense-in-depth concerns, or unlikely attack vectors. Consider fixing.
- Info: Best practice suggestions, code quality, documentation gaps.
For each finding, provide:
### [Severity] Finding title
**Location**: file:line
**Pattern**: Which vulnerability pattern from the checklist
**Description**: What the issue is
**Impact**: What an attacker could do
**Recommendation**: How to fix it
End with a summary table and overall risk assessment.
If you also ran the design/operational pass, put it after the findings under its own
heading -- "Design and operational observations" -- with no severity labels and no
entries in the findings summary table. Say plainly that these are not vulnerabilities.
Mixing them into the severity-ranked list is what makes a reviewer look like they are
padding, and it buries the findings that matter.
If you did not run that pass, close with one line telling the user it is available and
what it covers, so they can ask for it.
References
references/vulnerability-checklist.md -- 32 eUTxO exploit classes with detection and mitigation guidance; this is the source of findingsreferences/design-and-operational-risks.md -- 5 design, deployment, and compatibility concerns that are not vulnerabilities; report as observations only- Search
${CLAUDE_SKILL_DIR}/../../docs/sources/ for protocol specifications, design documents, and architecture notes
- Aiken standard library documentation at https://aiken-lang.github.io/stdlib/
- Cardano CIPs for relevant standards (CIP-57 for Plutus blueprints, CIP-68 for token metadata)
