Overview & Background
Smart contracts escrowing user assets must satisfy strict mathematical invariants regardless of sequence ordering, arbitrary timestamps, rate modifications, or extreme token amounts. While standard unit tests cover nominal paths, edge-case rounding errors or balance accounting bugs can lead to protocol insolvency (where the contract's actual token balance is less than the cumulative claimable debt owed to stream recipients).
Detailed Problem Statement
- Complex Interleaved State Machine:
- Complex lifecycle permutations (e.g.
create -> pause -> top_up -> cliff_pass -> partial_withdraw -> resume -> cancel) may introduce rounding drift or state inconsistencies.
- Integer Truncation & Stroop Precision:
- Integer division in
rate_per_second accrual calculations can accumulate 1-stroop discrepancies over millions of seconds.
Technical Specification & Architecture
1. Invariants to Mathematically Prove
Implement in contracts/stream_contract/src/property_tests.rs:
-
Contract Solvency Invariant:
$$\text{Contract Balance} \ge \sum_{i \in \text{ActiveStreams}} (\text{Deposited}_i - \text{Withdrawn}_i)$$
-
Zero-Sum Completion Invariant:
When a stream completes, $\text{Deposited} == \text{Withdrawn}$, with zero stranded dust remaining.
-
Monotonic Claimability Invariant:
For any stream without top-up, $\text{Claimable}(t_2) \ge \text{Claimable}(t_1)$ for all $t_2 \ge t_1$.
-
Cliff Protection Invariant:
For all ledger timestamps $t < \text{cliff_time}$, $\text{Claimable}(t) \equiv 0$.
2. Stateful Fuzzing Runner (proptest)
- Executes 20,000 generated sequences with randomized action selections, amounts up to $10^{18}$, rates, and ledger timestamp increments.
- Asserts all four invariants after every single state mutation.
Target Files
contracts/stream_contract/src/property_tests.rs
contracts/stream_contract/Cargo.toml
Acceptance Criteria
Overview & Background
Smart contracts escrowing user assets must satisfy strict mathematical invariants regardless of sequence ordering, arbitrary timestamps, rate modifications, or extreme token amounts. While standard unit tests cover nominal paths, edge-case rounding errors or balance accounting bugs can lead to protocol insolvency (where the contract's actual token balance is less than the cumulative claimable debt owed to stream recipients).
Detailed Problem Statement
create->pause->top_up->cliff_pass->partial_withdraw->resume->cancel) may introduce rounding drift or state inconsistencies.rate_per_secondaccrual calculations can accumulate 1-stroop discrepancies over millions of seconds.Technical Specification & Architecture
1. Invariants to Mathematically Prove
Implement in
contracts/stream_contract/src/property_tests.rs:When a stream completes,
For any stream without top-up,
For all ledger timestamps
2. Stateful Fuzzing Runner (
proptest)Target Files
contracts/stream_contract/src/property_tests.rscontracts/stream_contract/Cargo.tomlAcceptance Criteria
cargo test).