Contract verification matrix
What each Move module does, which behaviors are exercised, and where test evidence stops.
Trust Stack tests contracts at three different boundaries. Move tests execute the contract bytecode and prove expected state transitions or aborts. TypeScript tests exercise the exact builders, readers, event decoders, and reconciliation rules used by the dApp. Browser tests then verify that a person can reach each workflow, review a draft, connect a deterministic wallet, and receive actionable feedback on both desktop and mobile.
Those layers complement one another. A browser mock cannot prove Move conservation, and a Move test cannot prove that a labelled field remains usable on a phone.
Core package
The core package currently has 291 passing Move tests and 95.37% instruction coverage. Every value-bearing module has a successful lifecycle plus authorization, amount, time, replay, and custody tests appropriate to its state machine.
| Module | Public operation | Positive evidence | Adversarial and boundary evidence | Coverage |
|---|---|---|---|---|
foundation | Version and schedule bounds | Returns package policy constants | Maximum-horizon equality and overflow-safe boundary behavior | 100.00% |
fee_config | Initialize, govern, renounce, and collect fees | Queued bounded changes with a 60-second testnet activation delay and separate governor, treasury, and collector roles | Missing configuration, unauthorized/premature/duplicate actions, pending-change conflicts, role rotation, terminal-schedule binding, and irreversible renunciation | 95.71% |
asset_policy | Record advisory asset assessments | Compatible external-asset custody without admission and optional issuer-capability risk disclosure | Wrong council, premature/expired assessment, council-rotation acceptance, invalid risk flags, and maximum schedule horizon | 91.42% |
token_factory | create, mint, burn, rotate or renounce authority | Fixed and capped creation, creator minting, holder self-burn, and creation-fee collection | Wrong controller, disabled capabilities, zero values, zero recipient, cap enforcement, and authority rotation | 92.22% |
fixed_lock | create, claim, sweep_surplus | Exact deposit, fixed creation fee, and one-time beneficiary release | Early, wrong-beneficiary, duplicate, zero-value, dispatchable-asset, surplus, and issuer-capability cases | 96.29% |
vesting | create, claim, revoke, sweep_fees, sweep_surplus | Cliff, linear, and stepped settlement with optional revocation, snapshotted in-kind claim fees, and exact final remainder | Invalid schedules, vested/unvested split, fee rounding, wide arithmetic, early/duplicate/wrong-beneficiary claims, and hostile asset authority | 97.25% |
batch_distribution | send | Atomic distribution to the requested recipients | Empty, mismatched, oversized, duplicate, zero, overflowing, and dispatchable batches | 98.94% |
merkle_airdrop | create, claim, reclaim | Valid claims and post-deadline remainder recovery | Replay, recipient mismatch, invalid root/node/depth/window/allocation, equal-node ordering, duplicate reclaim, and vault isolation | 94.53% |
digital_asset_factory | create | One standard Digital Asset minted to its first owner | Empty identity/URI and zero-recipient rejection | 97.86% |
digital_asset_lock | create, claim | Exact owner-gated object custody and beneficiary release | Wrong owner/beneficiary, early/duplicate claim, retained transfer authority, and non-owner-gated assets | 96.55% |
payment_stream | create, claim, cancel, sweep_surplus | Accrual claims, creator refund of only unearned value, and post-cancellation beneficiary claims | Wrong role, premature or repeated actions, frozen beneficiary, invalid schedule/value, non-cancelable streams, surplus, and vault isolation | 96.24% |
staking_pool | Create, stake, claim, withdraw, and recover bounded surplus | Join-time reward accounting, repeated claims, withdrawal, and creator recovery | Wrong owner, early/duplicate/empty actions, live-stake recovery, denominator changes, surplus isolation, and update-frequency neutrality | 94.63% |
Isolated packages
The Dexlyn V1 adapter is deliberately outside the core package. Its 11 tests exercise the isolated coin vault, exact release, pool-provenance guard, beneficiary authorization, timing, one-time claim, and zero-value boundaries. It has 89.17% instruction coverage. The thin public wrapper that calls Dexlyn's native router can only be completed against a registered testnet pool; the repository does not replace that external integration with a fake claim of coverage.
The fixed-supply test token has 5 passing tests and 94.90% coverage. They exercise one-time deployer initialization, exact supply, normal primary-store transfers, zero-recipient rejection, non-deployer rejection, and duplicate initialization.
What the browser suite proves
The browser suite covers every non-dynamic dApp route in Chromium and Pixel 7 emulation. It checks page status, headings, horizontal overflow, shared Shadcn controls, incomplete-draft feedback, grouped mobile navigation, deterministic StarKey connection, network recovery, and representative workflow transitions. Component integration tests cover successful immutable-version fee-proof, prepare, sign, finalize, event-match, and state-reread paths for every dApp operation. Separate live acceptance records cover token, lock, batch, vesting, airdrop, stream, staking, Digital Asset, and browser-signed create/revoke lifecycles; browser mocks are not presented as a substitute for those receipts.
Honest limits
Passing tests do not establish mainnet safety. The remaining external gates are a real registered Dexlyn LP lifecycle, independent review, a production asset-attestation policy, accepted formal or executable invariant evidence, production governance/operations approval, and stronger proof-provider independence. These limits are release decisions, not lines that can be made green by weakening a test or inventing local chain evidence.