Verifiable outcomes
Receipts, activity records, and finalized on-chain outcomes are designed to be checked against each other.
Trust boundary
Current Trust Boundary
This page explains the boundary that already exists today: what users can verify, who controls what, how active balances are protected, and which parts are still evolving.
At a glance
Current boundary, at a glance
Read these three points first, then decide whether you want the fuller boundary.
Clear control boundaries
User actions, system-managed flows, and current admin controls should be stated directly instead of left implicit.
Readable exits
When conditions change, the system should surface safer modes and clearer exit paths instead of hiding risk behind a success-looking state.
Verification
What users can verify today
SSS is designed so that a trade does not end at a front-end status. A user action should remain readable through receipts, activity, and finalized outcomes.
Readable receipts
A user action should not stop at a front-end status. Receipts are meant to make each outcome easier to inspect and explain.
Traceable activity
Activity records are meant to preserve a readable path from action to result.
Finalized on-chain outcomes
What matters most is the finalized outcome. That result is meant to be anchored on-chain rather than left as a platform-only status message.
Checkable system state
System correctness should not rely only on platform claims. The current product boundary is meant to stay inspectable.
Control boundary
Who controls what
Trust becomes clearer when control is described directly. The current structure is a controlled product flow, not the final trust-minimized end state.
User controls
These choices remain with the user.
- Whether to fund
- Whether to trade
- Whether to provide liquidity
- Whether to withdraw
- Whether to continue using SSS
System-managed flow today
These states are managed inside the active product flow today.
- Internal balance states inside active product flows
- Reservation and execution states
- Receipt and settlement states
- Consistency guards inside managed flows
Owner / admin controls today
These controls remain part of the current operating boundary today.
- Pausing higher-risk paths
- Switching risk modes
- Reconciliation and recovery operations
- Operational safety controls when needed
Active balance protection
How active balances are protected today
The current boundary is not only about where assets sit. It is also about how the system reacts when something no longer looks right.
Reconciliation
Differences should be surfaced and resolved rather than ignored.
Invariant checks
Core accounting relationships should be checked rather than merely assumed.
Withdrawal guards
Higher-risk states should be handled carefully before assets leave the active flow.
Risk modes
When conditions worsen, the system should reduce new risk before it expands activity further.
Failure & exits
If something goes wrong
Trust is tested when conditions stop being normal. A clearer interruption is better than a misleading success state.
- Abnormal conditions should be surfaced instead of being hidden behind a generic success flow
- Safer operating modes may be applied before normal operation resumes
- Exit paths and restrictions should be stated clearly
- Delayed, paused, or limited states should be shown as they are
Not promised yet
What is not promised yet
A clear trust page should also state what has not yet been claimed as complete.
- Not the final DAO / SNS governance state
- Not the final privacy-preserving execution state
- Not every future asset rail live today
- Not the final trust-minimized end state
Read the boundary, then decide how far to go
Trust becomes clearer when the current product boundary is stated explicitly. Start with the product, then return here when the boundary matters.