# Risks and trust assumptions



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 [#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 [#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](https://dev.spectra.finance/docs/stellar/operations-and-security).