Understand the system before you trust it.
A plain-language view of Keele Labs' intended execution path, security boundaries, and risk controls. Product behavior should eventually be documented here before it is enabled.
Scope & principles
Keele Labs is planning a non-custodial, EVM-first system that moves from market analysis to signals, user-directed execution, yield research, and carefully reviewed multi-chain support. This is a product roadmap, not a production API reference or financial advice.
Paper before money
Nothing should touch real money until it has survived forward paper trading. Backtests are useful, but they can overfit.
Evidence gates
Each phase has a measurable exit condition. A failed gate means iterate, narrow the scope, or stop — not proceed on confidence alone.
Bounded AI
AI output is one input to a deterministic policy layer. It never becomes a direct instruction to sign a transaction.
Non-custodial design
The system is intended to avoid holding user keys or pooled funds. If a bug can drain a user, the architecture needs to change.
Planning estimate: real-money execution is a gated outcome, not a date commitment. Product scope, timing, and integrations may change.
Decisions & foundations
Stage 0 is complete. The product plan records the choices that are costly to reverse: custody, initial chain scope, token universe, strategy horizon, reliability threshold, and legal posture.
Custody model
Version one is intended to be user-signed. Any later session-key automation should be scoped, revocable, and enforced by the account contract rather than a server-held key.
EVM-first scope
The initial focus is a small number of EVM networks and an allowlisted token universe, rather than broad support for every asset or chain.
Reliability definition
The roadmap uses a forward paper-trading threshold, with net-of-cost comparison against documented baselines, before execution is considered.
Legal posture
The product must remain clear about jurisdictional limits, risk, and the difference between an advisory interface and discretionary management.
Market analysis engine
Stage 1 is in progress. The market-analysis engine is being built to produce a validated, structured read of market state for allowlisted EVM pairs. It does not produce trading signals by itself.
Data ingestion
Planned inputs include pool state, normalized OHLCV, reference prices, swap and liquidity flows, token-risk checks, and feature-flagged headline sentiment. Raw provider payloads should be retained for replay.
Features
Planned feature engineering covers price and volatility, trend and momentum, depth and slippage curves, liquidity health, on-chain flow, cross-venue basis, and market-regime labels.
AI analysis
The planned quantitative layer will produce features and risk flags. A reasoning layer will receive a compact evidence-backed payload and return validated structured output; raw candles are not sent to a language model.
Data quality
The design requires provider rate limits, retry behavior, failover, circuit breakers, and visible degradation status. Features are intended to be pure, unit-tested functions with lookahead-bias guards.
Target gate: a versioned analysis schema, sustained data quality, green feature tests, and a clean snapshot history before downstream signal work relies on it.
Simulation & evaluation
Simulation is planned as the bridge between research and any execution workflow. It will replay the same inputs and feature pipeline, model costs, and track a virtual portfolio continuously.
Deterministic replay
Replaying stored snapshots through the production pipeline should reproduce the same feature output. If replay and live analysis disagree, performance evaluation is not reliable.
Realistic cost model
The planned model will include chain fees, DEX fees, depth-based slippage, public-mempool MEV exposure, and router overhead at the intended trade size.
Paper engine
Candidate signals will be simulated against market depth and recorded in a virtual portfolio. The intended design keeps this engine active as a continuous comparison layer after launch.
Evaluation metrics
Planned reporting includes net PnL after costs, baseline comparisons, hit rate, drawdown, turnover, exposure time, and cost drag rather than headline performance alone.
Signal engine
The signal engine is intended to create buy and sell candidates only after the analysis and simulation layers are in place. Yield and staking are handled separately.
Signal path
Analysis results will pass through regime-gated rules and hard filters, quantitative scoring, bounded AI confirmation or veto, and a typed signal with evidence, expiry, conviction, and an abstain path.
Baselines first
Simple documented strategies such as moving-average crossover, RSI mean reversion, and buy-and-hold will be used as comparisons. Added AI complexity must demonstrate measurable value after modeled costs.
Evidence, not prediction
AI is intended to provide contextual review and connect every narrative claim to evidence. It is not a price oracle and does not authorize execution.
Continuous evaluation
Signal versions should run as champion and challenger candidates through the paper engine using walk-forward validation rather than a single train/test split.
Target gate: a sufficiently long out-of-sample paper-trading period, net-of-cost comparison against baselines, and drawdown evidence before moving toward execution.
Risk & policy layer
The planned risk layer will be deterministic code, separate from AI. Its role is to bound exposure and fail closed when data, policy, or infrastructure conditions are not acceptable.
Trade boundaries
Planned controls include per-trade sizing, daily loss and drawdown responses, token and venue allowlists, liquidity floors, slippage limits, and trade-rate limits.
Pre-flight checks
Every supported transaction should be simulated before submission where possible. Stale data, provider failures, and anomalous volatility are reasons to pause rather than trade.
Adversarial testing
The test suite is intended to cover malformed model output, signal storms, price manipulation, reorgs, stale RPC responses, disappearing depth, and approval races.
Kill switch
A kill switch and explicit pause behavior must be exercised end to end. Limits should be enforced on the server and on-chain where the account and transaction model allow it.
Execution & custody
Execution is planned as a user-directed, non-custodial workflow. Established protocols and routers are preferred over proprietary vaults or strategy contracts in version one.
User-signed first
The initial execution path is signal, review, and user signature. The preview should disclose expected and worst-case output, slippage bounds, gas, and checks that passed.
Established integrations
The roadmap evaluates battle-tested routing, expiring signature-based approvals, private or protected transaction delivery, and fork or transaction simulation instead of building a proprietary router.
Bounded automation
If introduced later, session-key automation must limit assets, spend, duration, and permitted actions, and remain revocable by the user.
Staged rollout
Any live testing is intended to proceed from testnet to tightly capped internal use before a constrained external beta. It is contingent on the preceding evidence gates.
Yield & staking
Yield and staking are a separate workflow from directional trading, with different inputs, risks, models, and user experience. They should not be ranked by headline APY alone.
Risk-adjusted research
Planned analysis covers fee yield versus emissions, reward-token sell pressure, impermanent loss, lockups and unbonding, audit and exploit history, TVL, and oracle or depeg risk.
Constrained scope
The intended first scope is established protocols and assets under review, not new farms or unusually high promotional yields.
Evaluation
A yield ranking must account for reward-token depreciation and impermanent loss, then be compared with a simple highest-APY selection before it is relied upon.
Multi-chain expansion
New chains are not a checkbox. Each one needs data QA, policy coverage, cost modeling, execution testing, and an appropriate wallet and transaction adapter.
EVM fan-out
Additional EVM networks can share interfaces but still require chain-specific RPC, routing, permit, gas, block-time, and L2 operational checks.
Solana adapter
Solana uses a different account model, routing stack, fee model, transaction construction, and wallet flow. It is planned as a dedicated adapter rather than a small EVM increment.
Cross-chain transfers
Bridging introduces distinct security, latency, and failure risks. It is deferred unless there is a clear, validated reason to support it.
Target gate: per-chain parity tests for data, policy, and execution before a network is enabled.
FAQ
Short answers to the architecture questions that matter most.
Does Keele Labs hold funds?
The target architecture does not pool user funds or hold user keys. Final wording will be updated to match the implemented signer and account model.
Can Keele Labs prevent MEV?
No. Simulation and private or protected routing may reduce selected MEV risks where supported; they cannot eliminate them.
Are signals financial advice?
No. Signals are product outputs built from configured inputs and can be wrong. They are not a recommendation or a promise of any result.
Do controls prevent losses?
No. Controls constrain selected actions and exposures, but markets, code, infrastructure, models, and controls can fail. Users can lose some or all assets traded.
Nothing here is a guarantee.
Crypto trading involves substantial risk. Model outputs, execution routes, permissions, risk controls, smart contracts, and infrastructure may fail. Nothing in these docs is financial advice.
Follow product updates