Haskell
Haskell security review
Haskell is the language Cardano validators and minting policies are written in. Hackerbane audits those scripts and the off-chain code that builds the transaction.
scope
What we review
We audit the on-chain validators and minting policies, and the off-chain builder that assembles the transaction. Most tests only hit the builder. A second script input, a swapped redeemer, or an open time window can still make the on-chain script accept the spend.
Double satisfaction: one output counted by two validators, or by a validator and a minting policy, in the same transaction.
A redeemer (the argument a spend passes to a script) that skips checks because another redeemer or another script was assumed to have already run.
Minting policies that constrain one token name and leave the rest of that currency symbol (the policy's token family) free.
Off-chain builders that only assemble well-formed transactions, so the validator never sees hostile locked-output data, a redeemer, or an extra input.
Validity ranges left open, or time checks that treat the upper bound of the slot window as now.
Advanced Threat Detection
We built our own advanced threat detection stack that is more performant and cheaper than our competitors. We use a state-of-the-art AI harness coupled with world-class senior security engineers with proven experience finding vulnerabilities in well-tested software.
How we review this language
A Haskell review follows the same five-stage engagement as every Hackerbane audit. Cardano uses eUTXO: funds sit in unspent outputs (UTxOs), and one transaction spends them together. Each validator runs once per spent input and sees the whole transaction. A validator does not run when someone first locks a UTxO at its address.
Two senior engineers read the on-chain scripts and the off-chain builder in parallel. We write our own transaction builders so we can send a spend the project's endpoints would never construct, then see whether the validator still returns True.
Scope and threat model
We lock the validators, the commit, the on chain scripts, and what each locked output and redeemer authorizes, before the review starts.
Architecture and design review
We read the on-chain and off-chain split against the eUTXO model. We look for bugs that only show up in a whole transaction, not in one function.
Hybrid code and infrastructure review
Two senior engineers read the Haskell in parallel, backed by property tests that drive validators and minting policies through real spends.
Exploitability and root-cause analysis
High and Critical findings ship with a reproducer that spends or mints against the script and the root cause, so the class of bug gets fixed, not only the instance.
Reporting and remediation
A prioritized report, a live walkthrough, and verification of every in-scope fix within the remediation window.
Tools and practices
We work in the Cabal or Nix packages you already build. We compile the validators, drive them with property tests at the transaction level, and hand those tests back with the report.
What you get
Prioritized findings your engineers can ship against, each with root cause and a recommended fix.
Reproducers for High and Critical issues: a transaction that spends or mints against the script.
A report you can share with partners and integrators on Cardano.
Remediation verification and a final report that reflects the fixed scripts.
The property tests and transaction traces used during the review.
How to prepare
| # | Before review starts |
|---|---|
| 01 | The packages build cleanly from a fresh checkout with a pinned toolchain. |
| 02 | Locked-output and redeemer types are documented, including what each field authorizes. |
| 03 | Each minting policy is written down: intended token names, and whether it may fire more than once. |
| 04 | The off-chain builder and the script hashes it targets are described. |
| 05 | Scope is defined: which validators, which commit, and which on-chain scripts. |
Other pages
Questions
- Do you review the off-chain code as well as the validator?
- Yes. Most tests go through the builder, which already sanitizes the transaction. We read both, then we build transactions the builder would refuse, because that is what the validator sees.
- How do you handle minting policies?
- We check the whole currency symbol, not one token name. We also check whether the policy can be satisfied twice in one transaction, or whether a mint can stand in for a payment another validator expected.
- Do slot windows matter to the audit?
- They do. The validator never sees the current slot. It sees the validity range the builder set. An open upper bound, or a check that treats that bound as now, can let a spend happen outside the window you designed.
Next step
Request an audit
Share the Haskell packages, the scripts on chain, and your timeline. We will propose an audit plan and estimate.