Smart contracts — Trust Stack Docs

The core package is supra_trust_stack. Its framework dependency is pinned to commit 3fecf50d0701f38064faa83c980aabe5c63309fe; local tests use the reviewed Supra CLI container digest recorded in move/trust-stack/README.md.

Revision-6 replacement#

The October 19 immutable publication at 0x0afbe7d92996d30632c228665bac163478ae2a04922fdfc8cb3c69a51fba9230 is the active revision-6 core. It keeps the module-version-3 entry-function ABI and adds the read-only views token_factory::total_minted and asset_policy::council_epoch; the runtime registry marks it module version 4 because its on-chain rules changed. Timelocked governance proposals expire if not executed within a 14-day acceptance window, delays below 48 hours are rejected outside allow-listed test chains, the fee collector must hold a registered SUPRA coin store, maximum supply caps lifetime minted supply, a council rotation invalidates pending admissions, accepting a new fee governor cancels the outgoing governor's pending schedule, token metadata objects are untransferable, a staking withdraw always returns principal (an unbacked settled reward is forfeited instead of aborting), and a later Merkle airdrop reclaim sweeps late deposits to the creator and aborts only when the vault is empty. Testnet governance delays are 300 seconds, shortened for testing. The revision-6 manifest records publication, initialization, freeze, and 12 of 12 matching bytecode hashes; the separate acceptance record covers 113 testnet transactions.

The September 22 revision-5 core (0xc4dcb9a8a6dcabac0ae695fe95df5a7cb793f3f5766746ced70c1159705ec74b) introduced compatible external Fungible Asset custody without admission, bounded fee increases as well as decreases, 60-second queued testnet governance (shortened for testing), and opt-in revocable vesting. It is now retained claim-only, alongside revisions 4, 3, and 2, for historical positions. asset_policy attestations are advisory for core Fungible Asset custody, and vesting supports creator-only refunds of unvested principal for schedules created with that option.

Module map#

Module	Asset model	Persistent state	Primary authority
`foundation`	None	None; version, schedule-horizon, 48-hour delay-floor, 14-day acceptance-window, and test-chain constants	None
`fee_config`	Native SUPRA and in-kind vesting fees	Global schedule, roles, and renunciation state	Governor; separate treasury administrator and collector
`asset_policy`	None	Advisory external-asset attestations and council epoch	Rotatable policy council
`token_factory`	Fungible Asset	Controller and lifetime minted total at metadata object	Creator mint; holder self-burn when enabled
`fixed_lock`	Fungible Asset	One position and store object	Beneficiary after unlock
`vesting`	Fungible Asset	One schedule and store object	Beneficiary claims; original creator may revoke an explicitly revocable schedule
`batch_distribution`	Fungible Asset	Events only	Sender in one atomic transaction
`merkle_airdrop`	Fungible Asset	Campaign, claim set, store object	Leaf recipient; creator-only remainder destination
`digital_asset_factory`	`0x4` Digital Asset	Standard collection and token objects	First owner after mint
`digital_asset_lock`	`0x4` Digital Asset	Lock object owning one token	Beneficiary after unlock
`payment_stream`	Fungible Asset	Stream and store object	Recipient claims; creator cancel only if selected
`staking_pool`	Fungible Asset	Pool vaults and position objects	Staker; bounded creator reward recovery

The Dexlyn V1 dexlyn_lp_lock module is a separate package because it stores a legacy generic Coin<LP<X,Y,Curve>> and depends on an external protocol's type identity.

Design conventions#

Creation and funding happen atomically.
Every custody position owns an untransferable object or vault.
Assets are bound by metadata or object identity, never by display symbol.
Chain time enforces schedules.
State is updated in a transfer-safe order and replay is rejected.
Terminal actions verify exact vault conservation.
Events are emitted only after successful state transitions.
Public views expose enough recorded terms and lifecycle state for the dApp to reconcile current state.

Package policy#

Source presence does not imply deployment. The checked-in deployment manifest is authoritative for package address, chain ID, source commit, bytecode hashes, transaction evidence, and acceptance lifecycles. New contract behavior requires a fresh immutable testnet publication and evidence record before its UI action can be described as live.

For value-bearing releases, prefer immutable packages deployed side by side. Existing positions continue under their original package and policy; migration should be a beneficiary-authorized withdrawal and new deposit, not an invisible global logic change.