Security Assurance
The escrow contract is backed by a comprehensive automated test suite that verifies correctness, security, and edge case handling. The suite contains 50+ individual tests covering every fund flow, access control rule, and failure scenario.
What Is Tested
Fund Locking (Deposits) — 6 tests
Verifies that deposits are recorded correctly and that invalid deposits are rejected.
| Scenario | What Is Verified |
|---|---|
| Standard deposit | Funds are locked and recorded with the correct amount, currency, and depositor |
| Stablecoin deposit | Token transfer completes and deposit is recorded accurately |
| Zero amount rejected | The contract refuses to accept a deposit of zero value |
| Invalid token rejected | The contract refuses deposits with invalid currency identifiers |
| Unapproved transfer rejected | The contract refuses token deposits that haven't been pre-approved |
Budget Allocation — 12 tests
Verifies that allocations are created correctly, that access controls are enforced, and that over-allocation is prevented.
| Scenario | What Is Verified |
|---|---|
| Single-slot allocation | Allocation is created with correct terms |
| Multi-slot equal payouts | Budget is split equally across slots |
| Variable payouts | Different per-slot amounts are committed correctly |
| Multiple streamers | Several streamers can be allocated from the same deposit |
| Non-depositor blocked | Only the original depositor can create allocations |
| Over-allocation blocked | The contract prevents allocating more than the available balance |
| Past deadline blocked | Allocations cannot be created with already-expired deadlines |
| Duplicate streamer blocked | The same streamer cannot receive two allocations from one deposit |
Payout Claims — 15 tests
Verifies that valid claims result in payment, invalid claims are rejected, and double-claiming is prevented.
| Scenario | What Is Verified |
|---|---|
| Valid single claim | Streamer receives correct amount for a completed slot |
| Valid claim (native currency) | Payout works for both stablecoins and native currency |
| Out-of-order claims | Slots can be claimed in any order |
| All slots claimed | Allocation is marked complete when every slot is paid |
| Invalid proof rejected | Wrong proof of fulfillment is rejected — no payout |
| Wrong amount rejected | Claiming a different amount than committed is rejected |
| Double claim blocked | The same slot cannot be claimed twice |
| Completed allocation blocked | No further claims accepted after all slots are paid |
Batch Claims — 8 tests
Verifies that multi-slot claims in a single transaction work correctly.
| Scenario | What Is Verified |
|---|---|
| Batch all equal slots | All slots claimed at once with equal amounts |
| Batch variable slots | All slots claimed at once with different amounts |
| Partial batch | Subset of slots claimed in one batch |
| Mixed batch and single | Combining single claims with batch claims |
| Empty batch rejected | The contract refuses empty claim submissions |
| Duplicate in batch rejected | The same slot cannot appear twice in one batch |
Allocation Refunds — 8 tests
Verifies that operators can recover unclaimed funds correctly and that early refunds are blocked.
| Scenario | What Is Verified |
|---|---|
| Full refund | All unclaimed funds returned when no slots were claimed |
| Partial refund (equal) | Correct amount returned when some equal slots were claimed |
| Partial refund (variable) | Correct amount returned when some variable slots were claimed |
| Early refund blocked | Refund is rejected before the agreed deadline |
| Non-depositor blocked | Only the original depositor can trigger a refund |
| Completed allocation blocked | Cannot refund an allocation where all slots were already paid |
| Re-allocation after refund | Refunded funds can be allocated to a new streamer |
Deposit Refunds — 6 tests
Verifies that operators can withdraw unallocated balances and that double refunds are prevented.
| Scenario | What Is Verified |
|---|---|
| Partial refund | Unallocated balance returned to operator |
| Full refund | Entire deposit returned when nothing was allocated |
| Native currency refund | Refund works for native currency deposits |
| No balance rejected | Refund is rejected when all funds are allocated |
| Non-depositor blocked | Only the original depositor can withdraw |
| Double refund blocked | Cannot refund the same unallocated balance twice |
End-to-End Lifecycle — 1 test
A comprehensive integration test that exercises the complete lifecycle:
Deposit → Allocate to 2 streamers → Partial payouts → Batch payout → Deadline passes → Allocation refund → Deposit refund
This test verifies that all stages interact correctly and that fund balances are accurate throughout the entire process.
Randomised Testing (Fuzz) — 3 tests
The contract is also subjected to fuzz testing, where hundreds of randomised inputs are used to verify correctness:
| Scenario | What Is Verified |
|---|---|
| Random amounts and secrets | Single-slot claims work with arbitrary values |
| Random slot counts (1–32) | Equal-payout allocations work for any number of slots |
| Random variable amounts (2–9 slots) | Variable-payout allocations handle arbitrary per-slot distributions |
Fuzz testing is designed to find edge cases that manual tests might miss — such as rounding errors, overflow conditions, or unexpected input combinations.