Custody and authority — Trust Stack Docs

“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	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 revision-6 testnet core uses immutable package policy 2. It was published, initialized, and frozen by a single-key testnet deployer wallet, so neither that wallet nor an operator can upgrade the package. Its fee governor, treasury administrator, collector, and asset-policy council are single-key testnet wallets held by one operator: role separation for testing, not multisig or independent custody. The retained revision-5 core was initialized through a 3-of-5 publisher multisig before its freeze. 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.