Trust & Safety
KEK is designed to reduce operational and execution risk through structure, validation, and separation of concerns.
This section explains how KEK approaches custody, execution, and risk—and where responsibility remains with the user. KEK prioritizes transparency over abstraction so system behavior is observable, reviewable, and auditable.
What this page covers
- KEK's custody and execution model
- How risk is controlled through validation
- System boundaries and limitations
- What KEK does — and does not — protect against
Core trust principles
1) Non-custodial by design
KEK never has custody of user funds.
In non-custodial systems, users retain control of their assets because they control their private keys, rather than relying on a third party to hold them.
KEK cannot access private keys or move funds independently. Execution occurs only through explicitly authorized actions.
2) Validation before execution
KEK enforces validation as a prerequisite to execution.
Every strategy must pass through:
- Backtesting
- Paper trading
- Monitoring and refinement
Backtesting simulates a strategy using historical data to evaluate risk and performance before risking capital.
Execution is optional. Validation is mandatory.
3) Separation of responsibilities
KEK separates the strategy lifecycle into independent concerns:
- Intelligence (strategy generation and research)
- Validation (testing, paper trading, monitoring)
- Execution (user-authorized trade placement)
No single component has unilateral authority. This prevents "execution-first" behavior and improves safety through deliberate gating.
4) Transparency over automation
KEK is built for explainability and auditability rather than blind automation.
System behavior is designed to be:
- observable
- reviewable
- reproducible
- attributable to a strategy version and lifecycle stage
Custody & execution model
What KEK can do
- Generate strategy hypotheses (structured)
- Store validation artifacts (backtests, paper trading outcomes)
- Monitor drift and recommend refinement cycles
- Provide user interfaces to review and deploy (optional)
What KEK cannot do
- Withdraw funds
- Access private keys
- Execute trades autonomously
- Override user authorization
Execution infrastructure and boundary
KEK's execution layer (KEK DEX) is Omnichain and built on Orderly Network's decentralized orderbook infrastructure, which is designed to provide a high-performance perpetual trading layer for builders without requiring them to build matching engines or bootstrap liquidity.
Execution remains downstream of validation and requires explicit user authorization.
Risk controls
KEK reduces structural risk through:
- Mandatory validation pipelines (historical + live simulation)
- Paper trading before eligibility (live conditions without capital exposure)
- Performance monitoring and drift detection (continuous evaluation over time)
- Explicit execution authorization (user-gated trading)
- Clear custody boundaries (non-custodial by default)
- Least-authority system design (components only have permissions required for their role)
These controls reduce operational and execution risk. They do not eliminate market risk.
What KEK does not protect against
KEK does not protect against:
- Market volatility and adverse price movement
- Strategy design errors and invalid assumptions
- Overfitting or misinterpretation of validation results
- Smart contract vulnerabilities or infrastructure failures in third-party systems
- User misconfiguration, misuse, or poor risk decisions
- Extreme or unforeseen market events
Trading involves risk. KEK reduces structural risk—not market uncertainty.
Security practices
KEK emphasizes:
- Non-custodial boundaries (user-controlled keys and funds)
- Principle of least privilege across system roles and permissions
- Auditable and versioned outputs (strategy and validation lineage)
- Dependencies are explicit
Where third-party infrastructure is used (e.g., execution rails), the security model is shared.
Known limitations
KEK explicitly does not guarantee outcomes:
- No strategy performance guarantees
- Validation cannot predict future behavior
- Execution infrastructure is external to KEK
- Users remain responsible for execution choices and risk limits
- Strategy drift is expected and must be monitored continuously
These limitations are explicit by design to prevent false certainty.
How this fits into the system
Trust & Safety applies across all layers of KEK:
Strategy Generation → Validation & Paper Trading → Monitoring & Meta-Learning → Optional Execution
At each stage, authority and responsibility are clearly defined so that intelligence never becomes custody, and validation never becomes autonomous execution.