Audit status
Current verification evidence, open risks, and release blockers.
As of September 22, 2026, Trust Stack core revision 5 is an immutable, chain-verified testnet publication. Its independent human security audit is pending, so it is not approved for mainnet or meaningful-value assets.
The authoritative deployed Move baseline is source commit
251320132139e73cda960909efc111203ad21d7a, published at package
0xc4dcb9a8a6dcabac0ae695fe95df5a7cb793f3f5766746ced70c1159705ec74b, and frozen under immutable
policy 2. Revision 4 at 0x993701927cc7da8c48a556af86a46128b42ee23044fc736d5eb9302cf58f5617,
revision 3 at 0x3218c2357c3dfad0edbfb620e7cb8c3e81f6ef0a3bd06c4f8cd129e87417a43f, and revision 2 at
0xa254b92f4a87c4cb48f84e42fd585a04f4f1cf2426496f0d66659e17d0e09005 remain available for their
existing positions. Web, API, and indexer releases are independently identified, must pass protected
CI, and are deployed by digest. Application-only releases cannot change the immutable on-chain
bytecode.
Verification baseline
- The revision-5 manifest records fresh compile evidence, 312 passing Move tests, and 95.48% aggregate instruction coverage.
- Its verification record reports all 12 deployed module bytecode hashes matching the reproduced
build, plus immutable policy
2. - The separate Dexlyn revision-2 manifest records 11 passing tests, fresh production compilation,
and a matching deployed adapter bytecode hash. Its compatible policy
1remains governed by 3-of-5 owners; mutable external Dexlyn dependencies prevent an immutable freeze. - Its public receipts record publication, fee configuration initialization, asset-policy initialization, and freeze. Fresh chain reads record the active roles and all five configured governance delays at 60 seconds.
- Separate revision-5 lifecycle evidence verifies 34 named actions and three early-claim rejections, including external-asset custody, beneficiary claims, revocation, streaming, staking, airdrops, and Digital Asset return. Partial schedules retain their expected remaining principal; the full factory token supply reconciles across the wallet and vaults.
- Shared TypeScript, dApp, marketing, and browser suites run as separate CI gates with coverage and desktop/mobile assertions. Their records do not substitute for live wallet or lifecycle receipts.
- Go controls include race-enabled tests, strict parsing, bounded HTTP behavior, vulnerability scanning, a 73% aggregate coverage floor, and a 60% floor for every selected core package in CI.
- Public receipt and direct-view verification use the configured Supra testnet RPC. No independent second public testnet RPC was available for this run.
Coverage and a matching hash are evidence of exercised and identified code, not a security score. The revision-5 manifest deliberately records a publication-time partial action snapshot; it does not claim a completed end-to-end product acceptance run. Later lifecycle receipts are separate evidence and do not retroactively turn that snapshot into a release-wide conclusion.
Resolved findings in the current candidate
| Severity | Finding | Resolution |
|---|---|---|
| High | Governance delays were compiled as zero in an immutable package | Revision 5 initialized all five delay settings to 60 seconds on testnet and records fresh readbacks in the deployment manifest. |
| Medium | Fee changes could be described as immediate despite delayed-governance code | Revision 5 disables direct set_schedule; a governor queues propose_schedule and any account applies it after the effective time. |
| Medium | Factory and external token provenance could be conflated | The dApp distinguishes verified factory control, external issuer control, and unavailable provenance before new positions are signed. |
| Medium | Staking reward rounding depended on interaction frequency | Added pool-level scaled remainder and regression coverage. |
| Medium | Merkle proof replay across networks/packages | Added chain ID, package, module, campaign, asset, index, recipient, and amount domain binding. |
| Medium | Block reconstruction treated proof-shaped RPC fields as inclusion evidence | Cursor recovery accepts only RPC-reconciled event responses whose emission fields pass strict validation. |
| Low | Runtime consumers could omit deployment-critical configuration inconsistently | Optional services resolve one validated, chain-keyed deployment registry and fail closed on drift. |
| Low | Aggregate Move coverage hid weak individual modules | CI requires every expected core module, rejects extras, and applies per-module and fee-sensitive thresholds. |
Open risks
- High release boundary: no independent human Move/DeFi audit covers the exact final candidate.
- Medium acceptance boundary: publication, configuration, and bytecode matching are not a completed end-to-end acceptance record. Revision-5 beneficiary claims, revocation, and a real Dexlyn LP lifecycle have separate positive evidence. Genuine-wallet extension acceptance remains incomplete, and testnet receipts do not establish economic safety.
- Medium asset boundary: revision 5 accepts compatible external Fungible Assets without council admission. Advisory policy records do not remove issuer mint, freeze, burn, transfer, or metadata authority and cannot make an external asset safe.
- Medium dependency boundary: Dexlyn upstream governance remains a third-party risk even though the revision-5 adapter has separate real registered-pool LP lifecycle evidence.
- Medium evidence boundary: public event evidence is single-provider RPC reconciliation, not an independent light client or provider quorum.
- Medium assurance boundary: a reproducible formal-prover environment is absent; the final human auditor must approve the executable-invariant alternative or require specifications.
- Operational custody boundary: the active release uses three distinct 3-of-5 multisig wallets with 15 unique owners, but one operator currently holds all encrypted testnet signer profiles. Independent owner custody and an off-host recovery ceremony are incomplete.
- Browser acceptance boundary: a genuine injected StarKey extension session remains unverified.
- Operational release boundaries: independent RPC ownership, protected GitHub tag/environment/branch settings, and exact mainnet tag/manifest identity remain incomplete. The immutable testnet wallet acceptance is not mainnet approval.
This page is checked against the active runtime registry and revision-5 immutable manifest so deployment identity cannot silently become stale. Tests, local/on-chain bytecode comparison, and live testnet lifecycles are useful engineering evidence; they are not an independent audit.