|
| 1 | +# Smart-contract invariant testing |
| 2 | + |
| 3 | +The Soroban contracts are maintained in the dedicated |
| 4 | +[`Stellar-Insightss/contracts`](https://github.com/Stellar-Insightss/contracts) repository. |
| 5 | +They were intentionally split out of this dashboard repository in commit `05fd5054` so that |
| 6 | +contract deployment, audit, and release controls are isolated from application changes. |
| 7 | + |
| 8 | +## Contract ownership and required safety properties |
| 9 | + |
| 10 | +The contracts repository is the source of truth for both the executable contract code and its |
| 11 | +property/fuzz suites. Every contract change must document and test the following invariants before |
| 12 | +it is merged: |
| 13 | + |
| 14 | +| Contract | Core invariants | |
| 15 | +| --- | --- | |
| 16 | +| `access-control` | Only an authorised administrator can change roles or pause state; role membership is idempotent. | |
| 17 | +| `analytics` | Snapshot epochs are strictly monotonic; an accepted snapshot cannot be replaced by an older epoch. | |
| 18 | +| `stellar_insights` | Snapshot submissions are authorised, monotonically ordered, and cannot mutate state while paused. | |
| 19 | +| `governance` | A proposal executes only after its voting period and only when quorum and the passing rule are met; a voter votes at most once. | |
| 20 | +| `governance-voting` | Vote weights are counted exactly once, and finalisation is immutable after the deadline. | |
| 21 | +| `escrow` | An escrow reaches exactly one terminal state; deposited funds cannot be released to both parties. | |
| 22 | +| `multi-sig-wallet` | A transaction executes at most once and never below its configured owner threshold. | |
| 23 | +| `time-locked-transactions` | A transfer cannot be released before its unlock time and has one terminal state. | |
| 24 | +| `token-swap` | An offer is filled or cancelled at most once; token movement is atomic and respects the quoted amounts. | |
| 25 | +| `upgrade` | Only approved upgrades can change the active code/version, and each proposal has one final outcome. | |
| 26 | + |
| 27 | +## Required verification in the contracts repository |
| 28 | + |
| 29 | +Each deployable crate must have a `tests/properties.rs` suite using generated values to exercise |
| 30 | +its documented invariant, including numeric boundaries and call-order permutations. Parsing or |
| 31 | +deserialising attacker-controlled input must additionally have a `cargo-fuzz` target. The contract |
| 32 | +repository's CI runs property tests and time-boxed fuzz targets, then publishes an LCOV report so |
| 33 | +uncovered contract paths are visible in review. |
| 34 | + |
| 35 | +This repository deliberately does **not** vendor a second copy of the contracts: doing so would |
| 36 | +make the dashboard CI test a potentially stale artifact rather than the code that is deployed. |
| 37 | +The workflow in `.github/workflows/contract-fuzzing.yml` therefore verifies that contract testing |
| 38 | +is owned by the contract repository and fails fast if a contracts directory is accidentally |
| 39 | +reintroduced here. |
0 commit comments