Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
46 changes: 46 additions & 0 deletions contracts/escrow/docs/fuzzing.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,46 @@
# Fuzzing & Property‑Based Testing for the Escrow Contract

This document explains how to run the **property‑based tests** (`proptest`) and the **fuzz tests** (`fuzz_test`) that exercise the escrow contract’s accounting invariants and edge‑case behaviour.

## Running the test suites

```sh
# Run the property‑based tests (default 256 cases per property)
cargo test -p escrow --test proptest

# Run the fuzz suite (default 256 cases per property)
cargo test -p escrow --test fuzz_test
```

You can increase the number of generated cases via the `PROPTEST_CASES` environment variable, e.g.:

```sh
PROPTEST_CASES=1024 cargo test -p escrow --test proptest
```

If a test fails, **proptest** will automatically write a reproducible seed to `proptest-regressions/` (or `proptest‑regressions/fuzz_test.txt` for the fuzz suite). Re‑run the failing case with the seed:

```sh
PROPTEST_SEED=<hex‑seed> cargo test -p escrow --test proptest
```

## Tested invariants

1. **Accounting invariant** – after every operation the total deposited amount must equal the sum of released, refunded, and available balances.
2. **Non‑negative available balance** – the contract never reports a negative available balance.
3. **Milestone ordering** – deposits, releases and refunds follow the order enforced by the contract logic.
4. **Boundary checks** – maximum number of milestones (`MAX_MILESTONES`) and total escrow limit (`MAX_TOTAL_ESCROW_STROOPS`).
5. **Authorization** – only authorised callers can create, deposit, release, refund or pause the contract.
6. **Error handling** – invalid inputs (negative amounts, empty milestone vectors, duplicate milestones, over‑funding, etc.) are rejected without breaking invariants.

## Typical findings & mitigations

- **Over‑funding rejections** – attempts to deposit more than the required total correctly return `EscrowError::FundingExceedsRequired`.
- **Double‑release protection** – releasing the same milestone twice triggers `EscrowError::MilestoneAlreadyReleased` and leaves the contract state untouched.
- **Paused state enforcement** – when the contract is paused, all mutating entry‑points return `EscrowError::ContractPaused`.
- **Invariant preservation on failures** – even when a call panics (e.g., due to unauthorized caller), the invariant checks run before the panic and guarantee the contract remains in a consistent state.

The suites run in CI on every PR, ensuring that regressions are caught early.

---
*Generated by Antigravity*
3 changes: 1 addition & 2 deletions contracts/escrow/src/lib.rs
Original file line number Diff line number Diff line change
Expand Up @@ -621,6 +621,5 @@ impl Escrow {
mod proptest;
#[cfg(test)]
mod simple_amount_test;

#[cfg(test)]
mod test;
mod fuzz_test;
Loading