Deployment status
Know which source modules are actually published and which acceptance work remains.
Trust Stack targets Supra MoveVM Testnet, chain ID 6. The deployment manifest—not a feature page or source directory—is authoritative for live package identity.
Active revision-5 deployment
The active runtime registry selects the core package:
0xc4dcb9a8a6dcabac0ae695fe95df5a7cb793f3f5766746ced70c1159705ec74bIt was published at block 137913840 from source commit
251320132139e73cda960909efc111203ad21d7a, initialized, and frozen with immutable upgrade
policy 2. Its 12 modules include fee_config, asset_policy, and digital_asset_factory
alongside the custody, distribution, streaming, staking, vesting, and token modules.
The revision-5 manifest records the public publish receipt, fee and asset-policy initialization, freeze, source and toolchain pins, fresh role reads, all five 60-second governance-delay reads, 12 of 12 matching deployed bytecode hashes, and fresh compile/test/coverage evidence. Its acceptance section is a publication-time partial snapshot, not a release-wide acceptance conclusion; later lifecycle receipts are recorded separately. Neither form of testnet evidence replaces an independent audit.
Revision 4 remains registered as coreV4 for positions that it created:
0x993701927cc7da8c48a556af86a46128b42ee23044fc736d5eb9302cf58f5617The earlier immutable revision-3 and revision-2 cores also remain registered for existing positions:
0x3218c2357c3dfad0edbfb620e7cb8c3e81f6ef0a3bd06c4f8cd129e87417a43f0xa254b92f4a87c4cb48f84e42fd585a04f4f1cf2426496f0d66659e17d0e09005Public proof URLs retain the originating package so each position is read and managed with the package that created it. The current separately published Dexlyn adapter is:
0x7ce836f84a15d1ba576da4a18703f67aba3ba71c67b22fac27dddcc11c7735adIts fresh source and bytecode are recorded in the
Dexlyn revision-2 manifest.
It retains compatible upgrade policy under 3-of-5 owners: Supra rejects an immutable freeze while
the external Dexlyn router and LP dependencies remain upgradeable. The earlier adapter at
0x899b43319d957a345b65667db7166e2e843c80433f55e1c79e427d2dbea203ba remains registered as
dexlynAdapterV1 for existing locks. New locks use revision 2; management selects the originating
adapter, and the indexer retains both histories.
The machine-readable deployments/runtime-registry.json file is the authority consumed by the SDK,
dApp, API, and indexer. The dated immutable manifest is the deployment-evidence record for the
active core. A copied address in documentation must never override either file.
Exact immutable release boundary
The active core package bytecode matches the pinned build recorded in the manifest and cannot be upgraded. Later repository commits do not alter that on-chain code; a future contract change must use a new package address and a new evidence record.
Separately gated work
| Capability | Status boundary |
|---|---|
| Fee configuration | Initialized with 50 SUPRA token creation, 50 SUPRA fixed lock, and 100 bps vesting fees. Schedule changes must be proposed by the governor and applied after the configured 60-second delay; direct immediate scheduling is disabled. |
| Asset policy | Initialized and advisory. Compatible external Fungible Assets can enter custody without admission; issuer capabilities remain a disclosed trust boundary. |
| Vesting revocation | Optional per position and defaults to irrevocable. A revision-5 revocable vesting create and revoke were verified; timed beneficiary claims are still separate evidence. |
| Digital Asset factory/media | The revision-5 factory, lock creation, and matured beneficiary claim were verified. A fresh owner read confirmed the Digital Asset returned to the beneficiary; earlier revision-3 evidence remains historical. |
| Dexlyn V1 LP lock | A real registered-pool LP lock-and-claim lifecycle and an early-claim rejection were verified. The adapter and its Dexlyn dependencies remain a separately monitored third-party boundary. |
| Partner webhooks | Engine implemented; approved external destination and delivery evidence still required. |
| Browser signing | Initial acceptance used a synthetic bridge for four real revision-5 creation and revocation transactions. Later browser claim receipts are separate evidence. This is not a genuine injected StarKey session, which remains a release-evidence gate. |
| Independent audit | An independent human Move security audit is pending. |
Release evidence checklist
Before presenting a module as live:
- run the pinned Move compile, tests, and instruction coverage;
- perform focused manual security review;
- publish a fresh release from the exact reviewed commit when the contract version changes; require immutable core policy and explicitly record any adapter upgrade authority and external dependencies;
- read exact bytecode and ABI back from chain;
- compare local and on-chain hashes;
- complete one real positive and required negative lifecycle;
- archive transaction links, object/resource reads, events, and source commit;
- update the shared runtime registry and evidence manifest in one reviewed release; and
- confirm every consumer resolves the same chain ID, package, module set, and start height.
No mainnet approval
No Trust Stack module documented here is approved for mainnet. Testnet deployment evidence is not an independent audit or economic-safety guarantee.
The active multisig structure uses three distinct 3-of-5 wallets with 15 unique owners, but one operator currently controls the encrypted local testnet profiles for all owners. This is testnet operational separation, not independent signer custody.