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 deployer | Upgrade a compatible testnet package while authority remains | Retroactively make that authority risk disappear |
| 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 current testnet package uses a compatible upgrade policy so audit findings can be remediated. That is an explicit high-severity governance boundary, not an immutability claim. A mainnet proposal must define whether packages are immutable or governed by a reviewed multisig and delay, then publish the exact policy and addresses.
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.