Stellar
Risks and trust assumptions
The main technical and operational assumptions across the Stellar stack.
The Stellar stack combines Core v2 contracts with external vaults, messaging networks, and administrative roles. Each layer introduces a separate trust boundary.
| Layer | Main assumptions |
|---|---|
| IBT | The backing protocol remains solvent and the wrapper's rate and liquidity views remain serviceable. |
| Bridge | Messengers remain live and authentic; trusted remotes, gas, fees, recipients, and rate limits are configured correctly. |
| Oracle | The configured implied APY and future PT value are appropriate, and owner/upgrader keys are secure. |
Operational assumptions
- Soroban storage can expire. Long-lived contracts and per-user state need a TTL maintenance strategy (permissionless).
- Transferring the top-level admin does not automatically move every operational role.
- The Registry's PT list is permissionless and should not be treated as a curated asset allowlist.
- Router and engine balances are shared contract balances, not per-user accounts. Transactions must sweep their intended outputs and avoid leaving residual assets.
Audit scope
Security reports apply to specific commits and cannot establish the status of a different branch or deployment. Integrators should verify the deployed WASM or bytecode, release manifest, audit commit, unresolved findings, and administrator configuration together.
For implementation-level safeguards, see Stellar operations and security.