You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There is no page a depositor (or a prospective one) can visit to see the vault's current contract addresses, parameters, and pause history without reading source or querying RPC directly.
Motivation
Trust in a non-custodial vault depends on being able to verify what's actually deployed, not take the frontend's word for it. Once mainnet contracts exist, users evaluating whether to deposit real money need a place to confirm the vault address matches what's audited, see its current adapter and parameters, and check whether it has ever been paused.
Proposed Solution
A public /status page (or a static section of the docs site) showing, per network:
Vault, adapter, and mUSDC contract addresses, linked to a Stellar explorer
Current parameters (migration cooldown, slippage tolerances, TTL thresholds)
Linking directly to a block explorer was considered as a lower-effort alternative, but explorers don't surface application-level context (which address is "the vault" versus an old superseded one, per the migration-history precedent in testnet-deployment.md).
Acceptance Criteria
Page renders current contract addresses and parameters per network, reading from CONTRACT_ADDRESSES/KNOWN_POOLS
Shows pause history (can start empty/placeholder if the monitoring/event-indexing issue isn't filed yet)
Audit report link field exists even if empty until an audit exists
Summary
There is no page a depositor (or a prospective one) can visit to see the vault's current contract addresses, parameters, and pause history without reading source or querying RPC directly.
Motivation
Trust in a non-custodial vault depends on being able to verify what's actually deployed, not take the frontend's word for it. Once mainnet contracts exist, users evaluating whether to deposit real money need a place to confirm the vault address matches what's audited, see its current adapter and parameters, and check whether it has ever been paused.
Proposed Solution
A public
/statuspage (or a static section of the docs site) showing, per network:pausedevents feat(vault): contract-side admin events + RPC admin-history reader #698 already emits (pairs naturally with the event-monitoring service, once filed)Scope
Alternatives Considered
Linking directly to a block explorer was considered as a lower-effort alternative, but explorers don't surface application-level context (which address is "the vault" versus an old superseded one, per the migration-history precedent in
testnet-deployment.md).Acceptance Criteria
CONTRACT_ADDRESSES/KNOWN_POOLSAdditional Context
None.