Why your deposit is safe
The no-loss guarantee is structural. It is enforced by the Move type system at compile time, not promised in documentation — and the full threat model is published for review.
Six properties, each enforced by structure rather than policy
A protective measure that depends on an operator behaving correctly is a promise. These are not that.
Principal is unreachable from admin code
No function taking the admin capability can reach the liquid balance, the staked principal, the total, or any deposit receipt. This is not a permission check that could be misconfigured or forgotten — those types are not in scope for that code path, and the compiler is what enforces it.
Total principal has exactly two writers
It increases in deposit, by exactly the coin paid in, and decreases in withdraw, by exactly the receipt principal. No other function writes it, and the test suite asserts the invariant after every operation.
Withdrawals have no guard to abuse
Deposits can be paused. Withdrawals cannot: there is no pause flag, cooldown or rate limit on the withdrawal path, and its absence is asserted directly in the tests so it cannot be reintroduced quietly.
Positions cannot be moved by anyone
The deposit receipt has key without store. It cannot be transferred, sold, lent or wrapped by any external transaction, which removes an entire class of position-stealing exploit rather than defending against it.
The draw cannot be ground
Randomness is drawn from Sui’s native source inside a non-public entry function, so the value cannot be observed and acted upon in the same transaction. Ineligible slots are resampled rather than skipped, keeping the distribution exactly proportional to stake.
The settlement swap is floored on chain
The price is read and a minimum output pinned into a ticket object that Move cannot drop, copy or store — so the transaction cannot complete unless the settlement consumes it in the same block. An execution below the floor reverts the swap with it.
The perimeter of the guarantee
A guarantee is only as good as its stated boundary. Here is exactly where ours sits — published in full, and tracked openly on GitHub.
Independent review in progress
The contract suite passes 75 tests and the no-loss invariant is enforced by the compiler. A published third-party review is the next milestone, and the two areas flagged for it — the randomness analysis and the admin-isolation argument — are documented in full on GitHub for anyone who wants to read them first.
Oracle validation
Settlement bounds every conversion with a Switchboard aggregator, validated hard: a non-positive price, a zero mean, a sample older than the freshness window, responder dispersion or a value outside the permitted band each abort the settlement outright. Multi-feed redundancy is on the roadmap.
Third-party liveness
Settlement needs an oracle gateway and a DEX pool to be reachable. When they are not, the epoch does not settle and the pot rolls forward. That is the designed outcome and it costs liveness, not principal.
Legal compliance is not a protocol property
Jurisdiction restrictions, the official rules and the sponsor’s legal identity are matters for counsel, not for code. Geo-restriction is one layer and is defeated by a VPN; it is not a compliance programme.
Monitoring what silence hides
A protocol can fail by doing nothing, and a dashboard showing green is not evidence that anything happened. ProjectX counts consecutive zero-yield harvests and the Sui epochs elapsed since yield was last realised, and reports the state as anomalous once it crosses a threshold — surfaced in the interfaces, where it cannot be quietly ignored.
Reporting a vulnerability
If you find a defect that affects deployed funds, report it privately to the contact published in the official rules rather than opening a public issue. A report that arrives before an exploit is worth considerably more to us than one that arrives after, and we would rather hear it early and imperfectly than late.