KlineO separates implementation, deployment evidence, and permission to operate. An API route, SDK method, or application screen can exist before a capability is enabled in your environment.
This page describes the source baseline and intended direction. It does not establish a production launch date. The status returned by your API deployment is the authority for that deployment's current release state.
Current source baseline#
The API v2 contract remains at version 2.0.0. The TypeScript and Python SDKs are at version 2.1.0, generated from its current 238 operations and 332 schemas. The contract covers planning, deterministic studies, strategies, review workspaces, market intelligence, evidence, and developer integrations. The application also includes saved public projects, Health investigations, Research comparisons, Decision Packs, and treasury scenario review.
SDK 2.1.0 adds partner preparation receipt recovery and its two response types to the client surface. Recovery can report a verified committed receipt or UNRESOLVED; an unresolved response does not establish that another preparation is safe. This contract refresh does not enable execution or change API version 2.0.0. See the changelog for upgrade details.
The committed release templates target BOT testnet, chain ID 968. They leave activation disabled, live rollout disabled, executable adapters disabled, and autonomy at level 0. V2 feature entries are marked SHADOW. Those template values describe the committed baseline; an operated deployment must supply its own verified release evidence.
| Capability | What exists in source | What determines availability |
|---|---|---|
| API v2 and SDKs | API contract 2.0.0 and generated TypeScript/Python SDKs 2.1.0 | Deployment access, credentials, scopes, membership, and resource prerequisites |
| Planning and simulations | Intent, capital, launch, strategy, and deterministic study resources | Enabled data sources, source lineage, engine capacity, and authorization |
| Public project analysis | Read-only supported public identifier analysis | Trusted provider configuration and supported chain/pool coverage |
| Saved projects and review | Versioned private records, investigations, Research studies, Decision Packs | Current workspace membership, valid referenced evidence, and completed jobs |
| Treasury evidence and scenarios | Signed custody admission, reconciliation, assumptions, and historical projections | Configured providers, verified authority, enabled verification, and complete source bindings |
| Execution and new-vault funding | Typed contracts, policy checks, simulation, release and operational gates | Exact signed releases, deployed runtime bindings, accepted evidence, and explicit environment enablement |
| External EVM V3 venues | Read-only visibility boundary | Supported observations; write adapters remain disabled in the committed v2 release |
Check an environment#
Read GET /api/liquidity-studio/v2/status for liveAuthority, release.authorityEnabled, release.featureStates, the release reason, chain binding, and rollout fields. AVAILABLE means the API's required storage is ready; it does not mean live execution is authorized.
Read GET /api/liquidity-studio/v1/status for the underlying Studio environment, chain ID, release gates, productionRuntimeActivationAllowed, automatedExecutionAllowed, and newVaultFundingAllowed. A release must be both verified and valid for the running environment and artifacts. An SDK cannot change these results.
Intended milestones#
The internal product plan describes an approximately 24-month progression after the baseline is accepted. Its quarter labels and customer targets are planning assumptions. They are not calendar commitments or evidence that any phase has been completed.
- Establish testnet and review evidence. Reconcile dependency facts, demonstrate Safe and venue compatibility, validate finality and reconciliation, complete scoped independent reviews, and prepare operational and incident evidence.
- Validate controlled pilots. Gather customer demand and shadow evidence for exact versions. Any named capped live pilot depends on complete release, legal, commercial, data, and operating approvals.
- Make onboarding and outcomes repeatable. Improve review workflows, evidence reporting, support, and integrations using observed issuer needs. Expansion of capital limits follows accepted operating evidence.
- Extend the platform selectively. Evaluate venue specifications, migration previews, asset profiles, and partner integrations. A new executable adapter requires its own threat analysis, tests, release evidence, and exit design.
- Choose a demand-backed expansion. Consider a second venue or chain, a reference-aware asset profile, or a protected execution lane when customer need and operating capacity justify it. These directions remain uncommitted until separately accepted and released.
Some API schemas already describe resources associated with later milestones. Schema coverage does not move a milestone into a live state. In particular, a protected-execution plan, partner record, policy draft, or strategy package is not itself an authorization to execute.
How a capability becomes live#
Runtime checks require exact source and artifact bindings, deployed addresses and runtime code hashes, accepted provider evidence, release signatures, and applicable safety and operational gates. V2 additionally binds enabled typed adapters, autonomy limits, feature states, and rollout limits. Missing, expired, mismatched, or rejected evidence keeps authority disabled.
These requirements describe release checks implemented in the product. They do not claim that an independent audit, service-level agreement, or production authorization has been completed. Public release notes should identify the accepted version and environment when those facts become available.
For the current contract baseline, see the changelog. For common access and availability questions, see the FAQ.