Audit status — Trust Stack Docs

As of October 19, 2026, Trust Stack core revision 6 is the active immutable, chain-verified testnet publication. Its independent human security audit is pending (SEC-1), so it is not approved for mainnet or meaningful-value assets.

The authoritative deployed Move baseline is source commit 608ab9a80d32812b084c4fbac442b230d43babb0, published at package 0x0afbe7d92996d30632c228665bac163478ae2a04922fdfc8cb3c69a51fba9230 in transaction 0x78e118451269ca05f5fa19e34a2fa4bf61dd937c44a41c08c445df07478d8dc2 at block 148375016, and frozen under immutable policy 2. The following immutable cores are retained claim-only for their existing positions: revision 5 at 0xc4dcb9a8a6dcabac0ae695fe95df5a7cb793f3f5766746ced70c1159705ec74b (source commit 251320132139e73cda960909efc111203ad21d7a), revision 4 at 0x993701927cc7da8c48a556af86a46128b42ee23044fc736d5eb9302cf58f5617, revision 3 at 0x3218c2357c3dfad0edbfb620e7cb8c3e81f6ef0a3bd06c4f8cd129e87417a43f, and revision 2 at 0xa254b92f4a87c4cb48f84e42fd585a04f4f1cf2426496f0d66659e17d0e09005. 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-6 manifest records 439 passing Move tests and 96.73% aggregate instruction coverage from the frozen source commit.
Its verification record reports 12/12 deployed module bytecode hashes matching the reproduced build, the on-chain source digest matching the build, immutable policy 2, and a post-freeze upgrade attempt rejected on chain.
Its public receipts record publication, fee configuration initialization, asset-policy initialization, and freeze. All five governance delays are 300 seconds, shortened for testing; mainnet payloads use 604,800 seconds.
The revision-6 acceptance record covers 113 transactions: 50 successful and 63 expected failures that aborted on chain with the exact expected error, across token creation with the lifetime mint cap, fixed locks, revocable vesting, collector principal safety, payment streams, Merkle airdrops, staking, batch distribution, Digital Asset locks, a real Dexlyn LP lock, and governance timelocks including the governor handoff that cancels a pending schedule. Every transaction is independently re-fetchable by the recorded verifier script.
The 14-day acceptance window and the 48-hour production delay floor are covered by Move unit tests; they cannot be observed on testnet chain 6, which is allow-listed.
Revision 6 reuses the Dexlyn revision-2 adapter, whose manifest records 11 passing tests, fresh production compilation, and a matching deployed adapter bytecode hash. Its compatible policy 1 remains governed by 3-of-5 owners; mutable external Dexlyn dependencies prevent an immutable freeze.
The retained revision-5 manifest records 312 passing Move tests, 95.48% coverage, and 12 of 12 matching bytecode hashes. Separate revision-5 lifecycle evidence verifies 34 named actions and three early-claim rejections.
Two real StarKey 4.12.0 extension runs signed token creation, a fixed lock, vesting, a payment stream, and a beneficiary claim against revision 6, and verified connection denial, wrong-network recovery, and transaction denial. The second run verified the denial fixes.
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 these runs.

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. The revision-6 acceptance record is testnet engineering evidence with shortened durations; it does not establish economic safety and is not an independent audit.

Findings register#

The audit findings register holds 31 rows: 16 resolved, 13 accepted, 1 false positive, and 1 open. There are no Critical findings. The single open row is SEC-1 (High): the independent human smart-contract audit, which blocks the mainnet release gate. Revision 6 (source 608ab9a) resolved these contract findings:

ID	Severity	Finding	Revision 6 resolution
GOV-1 / SEC-2	Medium	No contract floor on governance delays	`initialize` rejects any delay below 172,800 seconds (48 hours) unless the chain ID is 6 or 4; chain 8 and unknown chains fail closed.
GOV-2	Low	A pending fee schedule survived a governor handoff	`accept_fee_governor` cancels the outgoing governor's pending schedule; verified on testnet.
GOV-3	Low	Governance proposals never expired	Every timelocked proposal must execute within 14 days (1,209,600 seconds) of its effective time; an expired proposal can be canceled or replaced.
FEE-1	Low	A collector that cannot receive fees blocked fee-bearing operations	The collector must hold a registered SUPRA coin store at initialize, proposal, and acceptance.
TF-1	Low	Maximum supply capped circulating, not lifetime, supply	`maximum_supply` caps lifetime `total_minted`, which burning never reduces; verified on testnet.
AP-1	Low	Admissions survived a council rotation	Rotation increments `council_epoch`; earlier-epoch admissions abort.
TF-2	Info	The token metadata object was transferable	Factory metadata objects are untransferable; holder stores stay transferable.
VLT-2	Info	Staking principal withdrawal depended on reward solvency	`withdraw` always returns principal; an unbacked settled reward is forfeited instead of aborting.
VLT-5	Info	Deposits made after the first airdrop reclaim could be stranded	Later reclaims sweep new deposits to the creator and abort only when the vault is empty.

SEC-3 to SEC-8 (on-chain negative tests, partial revoke and mid-stream cancel, real StarKey signing, legacy deprecation, reproducible source archive, and evidence hygiene) are resolved with recorded evidence. Accepted rows carry a documented rationale, for example advisory asset admission (AP-2), issuer-retained capabilities of external assets (VLT-7), and permanent renunciation (GOV-4); the auditor is asked to re-confirm each.

Earlier revisions also resolved zero governance delays in an immutable package, cross-network Merkle proof replay, staking reward rounding that depended on interaction frequency, factory versus external provenance labelling, and proof-shaped RPC fields being treated as inclusion evidence.

Open risks#

High release boundary (SEC-1): no independent human Move/DeFi audit covers the exact frozen source. The mainnet release gate fails while this finding is open.
Medium acceptance boundary: the revision-6 acceptance run used shortened durations and signed through the SDK. Two real StarKey 4.12.0 extension runs signed five transactions each and verified denial and wrong-network handling, but later UI-only releases were not re-run with the extension, and testnet receipts do not establish economic safety.
Medium asset boundary: revisions 5 and 6 accept 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 reused revision-2 adapter has real Dexlyn LP lifecycle evidence on revisions 5 and 6. The adapter is excluded from mainnet scope.
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.
Medium on-chain observation boundary: the 48-hour delay floor and the 14-day proposal expiry are proven by Move unit tests only; they must be observed on chain during a mainnet ceremony.
Operational custody boundary: the active revision-6 testnet roles are single-key wallets held by one operator, not multisigs. The retained revision-5 package uses three distinct 3-of-5 multisig wallets with 15 unique owners, but one operator holds all encrypted testnet signer profiles. Mainnet requires five non-overlapping 3-of-5 multisigs and an off-host recovery ceremony, which are not provisioned.
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 the revision-6 and revision-5 immutable manifests 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.