Custody and authority
Separate Trust Stack vault guarantees from external issuer and upgrade powers.
“Non-custodial” means the Trust Stack service does not possess a wallet key and its operators do not hold a general capability to withdraw user positions. It does not mean every external authority in an asset or dependency disappears.
Role boundaries
| Role | Can do | Cannot do through Trust Stack |
|---|---|---|
| Wallet signer | Authorize actions for its address | Act for another beneficiary |
| Position creator | Fund and use an explicitly selected creator action | Seize strict locks or vested beneficiary value |
| Beneficiary or recipient | Claim according to the position policy | Claim early or beyond eligibility |
| Indexer operator | Serve derived records and proofs | Sign or move position assets |
| Frontend operator | Build and explain a transaction | Bypass Move checks or silently redefine a funded policy |
| Package publisher multisig | Initialize the recorded governance roles before freeze | Upgrade or replace the active immutable core package |
| Asset issuer | Exercise capabilities retained in the asset standard/package | Use Trust Stack's vault module as proof those capabilities were destroyed |
| Dexlyn authority | Control upstream packages according to Dexlyn policy | Become part of the core standard-asset custody guarantee |
Isolated custody
Locks, schedules, campaigns, streams, staking pools/positions, and Digital Asset locks use distinct objects or vaults. They do not share an omnibus user balance. Ordinary object ownership is removed where the module must retain only a narrow withdrawal mechanism.
External asset authority
A Fungible Asset issuer may retain mint, freeze, burn, dispatch, transfer, metadata, or package upgrade capabilities. A Digital Asset issuer may retain transfer authority. Trust Stack rejects dispatchable Fungible Assets for flows whose conservation model assumes standard transfer behavior, but cannot universally prove every external capability was destroyed.
Upgrade authority
The active testnet core uses immutable package policy 2. It was initialized through a 3-of-5
publisher multisig and then frozen, so neither that multisig nor an operator can upgrade the package.
New contract behavior requires a side-by-side package and explicit runtime-registry change. The
separate Dexlyn adapter and upstream packages remain compatible-upgrade dependencies, and Supra
framework addresses remain a chain-governance boundary.
Evaluate both layers
A correctly enforced lock can still contain an asset with issuer risk. Review the position policy and the underlying asset/package authority separately.