Smart contracts
Map each Move module to its assets, objects, authorities, and events.
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.
Module map
| Module | Asset model | Persistent state | Primary authority |
|---|---|---|---|
foundation | None | Version marker only | None |
token_factory | Fungible Asset | Controller 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 over 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 immutable terms and lifecycle state for the dApp to re-verify.
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 modules require a fresh testnet publication or compatible upgrade record before their 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.