Klineo's liquidity contracts implement issuer-owned vaults and bounded venue actions. The application and SDKs prepare, explain, and observe those actions; ownership, policy, and execution checks remain onchain.
Canonical deployment status as of September 30, 2026: both checked-in release manifests have activation disabled. V2 is a BOT 968 testnet draft with Level 0 authority, paused emergency state, disabled adapters, and no canonical component addresses or runtime hashes. No production deployment address or completed independent audit is supplied by this page.
Two contract generations#
V1 binds one issuer-owned vault to a bounded BDEX V3 venue profile. V2 introduces a typed adapter registry and a scheduled controller with explicit autonomy levels. These are separate immutable contract architectures; a v2 feature does not silently upgrade a v1 vault.
| Generation | Main authority model | Custody and venue boundary |
|---|---|---|
| V1 | Issuer Safe, versioned policy manager, execution controller, configured executor and guardian. | Private vault and BDEX V3 module with fixed venue and asset constraints. |
| V2 | Issuer Safe, adapter registry, policy-configured guardian, executor and reconciler, scheduled controller. | Private vault admits approved assets and registered typed adapters with runtime-bound generations. |
The contracts do not issue public vault shares. The architecture does not expose a generic arbitrary-target or arbitrary-calldata execution primitive, and the canonical release forbids proxy upgrades. A new version requires a new deployment and explicit issuer migration approval.
V1 components#
| Contract | Responsibility |
|---|---|
KlineOVaultFactory |
Deterministic deployment with expected child/runtime code-hash enforcement. |
KlineOPrivateVault |
Asset and position custody, protected quote reserve, issuer ownership, pause and independent recovery paths. |
BDEXV3Module |
Typed position-manager and exact-input swap operations against the bounded venue profile. |
PolicyManager |
Versioned policy hashes, strategy constraints, action and daily budgets, and risk-expansion delay. |
OracleGuard |
Freshness and deviation checks for independent price sources and configured pool evidence. |
ExecutionController |
Action digest and policy validation, nonce and deadline checks, custody-changing execution and result events. |
ExecutionRiskEngine |
Immutable stateless risk validation, authenticated NAV and policy-accounting calculations. |
VaultLens |
Read and reconciliation views. |
KlineOLiquidityResults |
Execution-result evidence and reconciliation surfaces. |
A prepared action binds the intended vault, policy and typed economic operation. Execution validates the active policy, caller authority, replay and deadline conditions, and relevant risk constraints before calling the venue path. Policies constrain the venue, recipient and oracle authority; v1 risk expansion includes a 24-hour delay. Relevant oracle and pool evidence is validated around execution.
The v1 issuer can pause and withdraw idle balances, reduce or recover a position, and recover a position NFT through owner-only paths. Those paths do not depend on the backend issuing a new proposal or an executor continuing to operate. Some recovery operations require the vault to be paused first. Underlying token and venue behavior, minimum amounts, deadlines, and gas still matter.
V2 components#
| Contract | Responsibility |
|---|---|
VenueAdapterRegistryV2 |
Issuer-owned registry of venue, adapter, runtime code hash, audit commitment, and manifest commitment for each generation. |
KlineOPrivateVaultV2 |
Issuer-owned custody, approved assets, typed adapter execution, exact allowances, observed balance accounting, position custody checks, pause and issuer exit. |
ScheduledLiquidityControllerV2 |
Policy configuration, autonomy limits, replay protection, budgets, epochs, emergency controls, and ordered Merkle plans with reconciliation barriers. |
BDEXV3AdapterV2 |
Typed BDEX V3 action implementation with constructor-bound assets and venue dependencies. |
Adapter registration checks the deployed adapter's runtime code hash and venue identity and requires audit and manifest commitments. Execution checks the current, unrevoked generation again. Revocation immediately disables that generation. A revoked generation is retained in history; any later registration is a new generation with its own evidence.
An audit hash is an evidence commitment, not a certification. Integrators must obtain the referenced review and confirm its scope, exact source and bytecode, exclusions, findings, and remediation. The canonical v2 audit gate currently remains false.
Typed actions and accounting#
The v2 action enum supports:
- Opening, increasing, decreasing, and closing a liquidity position.
- Collecting fees.
- Exact-input swaps and reserve-protection swaps.
Each action has explicit fields for its intended assets, position, amounts, limits, deadline, and relevant quote identity. Contracts do not accept user-supplied opaque calldata as a substitute for the typed action.
The vault checks that the adapter belongs to that vault and asset pair. It grants only the allowance required by the action and clears it in the same call. It compares actual before/after token balance deltas with the adapter's report, enforces minimum outputs and spend limits, and checks position NFT custody and approvals. Risk-increasing position operations validate price and pool evidence before and after the external venue call; a failed check reverts the whole action.
Residual recovery in the BDEX v2 adapter is limited to its constructor-bound assets and initialized issuer vault. It is not a permissionless sweep to a caller-chosen asset or destination.
V2 authority levels#
| Level | Contract name | Intended authority |
|---|---|---|
| 0 | OBSERVE |
Observe evidence; no execution authority. |
| 1 | RECOMMEND |
Produce recommendations within the application workflow. |
| 2 | PREPARE_SAFE |
Permit the issuer Safe's bounded typed-action execution path under an active policy. |
| 3 | SCHEDULED_PLAN |
Permit a Safe-approved, ordered plan with committed legs and caps. |
| 4 | BOUNDED_AUTOPILOT |
Permit the configured executor's typed actions under explicit policy limits. |
The effective level is bounded by policy, controller state, and release authorization. Contract capability alone does not establish that a deployment is allowed to use it. The current canonical v2 release limits authority to Level 0.
Authority expansion has a 24-hour delay. Scheduled plans have a minimum one-hour delay and bind the policy and control epoch, validity window, ordered leg commitments, and per-asset and per-venue caps. The next leg cannot execute while the previous leg awaits required reconciliation.
Immediate demotion, policy revocation, and emergency pause advance control authority so stale plans or actions cannot inherit prior permissions. The issuer Safe can demote or revoke. The configured guardian may trigger emergency pause. Acknowledging an emergency does not automatically restore execution authority; a separately authorized policy activation is required.
Issuer exit#
V2 issuerExit is owner-only, pauses the vault, marks it exited, and transfers the specified ERC-20 balances and position NFTs to the issuer-selected nonzero recipient. It does not require the active policy, controller, executor, oracle, or external provider to approve the transfer.
The caller must supply the correct asset and NFT inventory. A transfer can revert because of underlying asset behavior or NFT recipient restrictions. Moving a position NFT preserves ownership of the position; it does not necessarily unwind its liquidity. Review the exact exit transaction and test the procedure for the deployed assets and recipient before an incident.
An application pause workflow and a confirmed onchain pause are different evidence states. Independently verify transaction finality and resulting contract state. Preserve the issuer's direct Safe access and a tested recovery procedure so an unavailable UI or backend does not prevent exercising owner authority.
Deployment verification#
Before connecting to a real contract:
- Obtain the release identity and verify its environment, chain, validity, approvals, feature state, emergency state, and named vault limits.
- Match deployed component and dependency addresses to the release evidence.
- Compare onchain runtime hashes with the release's compiled and reviewed artifacts.
- Verify issuer Safe ownership and threshold, current policy, controller, asset and adapter permissions, active registry generations, and configured role addresses.
- Confirm required oracle, pool, provider, finality, and reconciliation evidence is current.
- Verify direct issuer pause and exit procedures using the applicable reviewed runbook.
Never copy addresses from a template, mock, example, disposable sandbox, or documentation illustration as deployment facts. Synthetic addresses in Ignition parameter examples are not canonical deployment addresses. SDK ABIs and successful local compilation do not establish that a matching contract is deployed or released.
Verification and audit status#
The contract workspace provides compilation, compiler/build-info provenance checks, runtime and initcode size checks, contract tests, seeded invariants, TypeScript consumer checks, and release-manifest validation. The v2 gate also requires an independent audit tied to the precise source, compiler settings, deployed bytecode and validated fixes; pinned-venue behavior and operational exit evidence remain required acceptance work.
Local validation is useful engineering evidence. It does not replace independent review, attest to an external chain, or authorize capital. Current manifests intentionally remain disabled until the release requirements are satisfied. See Security and trust for the current status and remaining acceptance boundary.
Implementation references#
Contract source lives under contracts/liquidity-studio/contracts. Canonical manifests live under contracts/liquidity-studio/manifest; release acceptance requirements are maintained in docs/liquidity-studio/RELEASE_GATES.md. Generated contract interfaces are intended for decoding and typed integration against a verified deployment, not for asserting deployment authority.