Stellar

Operations and security

Roles, invariants, TTL maintenance, and audit scope for the Stellar stack.

Operate each component as a separate security domain. Core, wrappers, bridge, messengers, and oracle instances have distinct privileged roles and release histories.

Core invariants

  • Before maturity, PT and YT supply are minted and burned as a pair.
  • Wrapper backing remains at least equal to outstanding wrapper shares.
  • Deposit-and-redeem round trips cannot create value through rounding.
  • Claimed yield, claimable yield, and fees do not exceed realized backing gains.
  • Maturity rate freezing is final and cannot pay the same yield twice.
  • Router and LOE integrations must avoid consuming balances that predate the transaction; balance-based amounts can include shared contract balances.
  • Every nested token pull has the required Soroban authorization declaration.

Privileged capabilities

CapabilityImpact
Upgrade rolesCan replace contract logic immediately unless controlled by an external governance delay.
Registry/configuration rolesCan change deployable hashes, fees, collectors, and peripheral addresses.
PausersCan stop PT, YT, Router, LOE, wrapper, or bridge operations according to component scope.
Router managerChooses the Registry, engine, broker, and bridge used by Router commands.
Rewards rolesConfigure and invoke reward proxies with the PT or wrapper as the direct caller.
Bridge operatorControls messengers, trusted remotes, wrappers, fees, limits, and fee withdrawal.
Oracle owner/upgraderControls future PT value and oracle code.

Use separate keys, multisig policies, monitoring, and incident procedures for these capabilities. A two-step top-level admin transfer does not automatically revoke roles held by the outgoing administrator.

Soroban operations

  • Monitor instance, persistent, and temporary storage TTLs.
  • Bump long-maturity oracle instances and inactive user state before archival.
  • Maintain trustlines for payout recipients using Stellar classic assets.
  • Build production WASM with the release's required stack and optimization settings.
  • Simulate high-resource LOE and Blend routes before submission.
  • Verify deployed WASM hashes and contract specs against the selected source commit.

Audits

Audit reports cover specific source revisions. Match a report's scope and commit to the deployed WASM or bytecode and check any unresolved findings. The deployed contract addresses identify infrastructure contracts; they do not establish audit coverage for a particular implementation or configuration.

On this page