A vault is an operating record for issuer-owned liquidity. The issuer Safe and active canonical policy provide authority. A saved public project, workspace membership or plan preview does not establish that authority.
The connected workflow requires configured services, supported deployments and verified evidence. Current release and funding permission must be checked against platform status and release gates. Demo onboarding completion marks and sample balances do not establish deployed custody or execution.
Qualify an issuer-controlled vault#
Open /app/onboarding. An organization owner or treasury admin can begin the issuer qualification path; operators perform their separately permitted preparation and eligibility work.
1. Verify the issuer Safe#
Enter the intended Safe, request a short-lived verification challenge and inspect its typed signing data. Sign through the external Safe process and submit the signature for verification. Server checks include the chain, Safe proxy/singleton, owners and threshold. Challenges are single-use and expire; changing the Safe requires matching verification.
2. Bind and qualify the configuration#
Specify the owner Safe, project token, quote token, supported BDEX V3 pool, quote profile, launch context and initial strategy family. The form collects deployable capital, protected reserve, policy dates, contacts, objectives, prohibited behavior, disclosure/governance evidence and data-room terms.
Eligibility requires current asset, venue, pool and oracle certifications from one compatible signed release generation. Reload certification after assessment changes. An assessment receipt alone does not establish that all selected facts remain eligible and compatible.
Initial strategy choices include bootstrap and diversification. Diversification additionally requires post-launch context and an issuer-Safe-only mandate with sale caps, organic-volume participation limits, minimum price, retained balance, protected reserve, expiry, disclosures and public-reporting scope.
Accepted qualification creates a qualified vault record. It does not deploy a contract or fund it.
3. Assemble readiness evidence#
The server verifies progression through:
QUALIFIED → DATA_ROOM → SIMULATED → POLICY_DRAFT → TESTNET → SHADOW → FUND_READY
Upload supported confidential evidence through the supplied short-lived path. Admission checks the exact SHA-256 and clean malware-scan result; the ledger retains the receipt/hash. Testnet readiness requires independent evidence for the required mechanics, including deployment, ownership, funding/withdrawal, positions, fees, unwind, failures, rotation, pause/exit, reorg/replacement and reporting.
The operator preparing test evidence and issuer approving it have separate responsibilities. Resume the existing qualification when returning to an in-progress setup. The next steps depend on the saved launch context.
For POST_LAUNCH, complete the TESTNET gate, then use Create runtime-only Safe packet in the capital-free runtime panel. Inspect and download the exact release-bound deployment transaction; its approved funding is zero. The issuer executes through the external Safe process. Submit the executed transaction hash using Verify runtime finality, then wait for a newer finalized, reconciled zero-custody checkpoint before advancing to SHADOW. Unexpected capital blocks this unfunded path until its recovery requirements are met.
POST_LAUNCH FUND_READY requires at least 14 continuous days of finalized scored shadow coverage and five distinct meaningful shadow decisions within that run, bound to the accepted simulation and independently approved policy. Policy-allowed decisions require successful exact controller simulation; denied decisions require explicit suppression evidence. Each meaningful decision needs an available scored outcome. Elapsed calendar time or five unscored proposals does not satisfy the gate.
For PRE_TGE, the supported exception is an undeployed Bootstrap vault. FUND_READY uses the approved canonical replay with explicit hypothetical opening inventory, applied price-gap, one-way-flow, delay, oracle-outage, reorg and gas-spike stress, and a policy-allowed meaningful shadow decision. Transaction simulation is explicitly not applicable before deployment. This synthetic-stress acceptance is separate from the 14-day POST_LAUNCH path.
4. Review deployment and funding#
After FUND_READY, review current release, capital-cap, Safe, commercial and source admission. Funding token and quote amounts must match the hypothetical opening amounts of the exact accepted canonical replay, including its bound policy and indexed dataset; changing amounts requires fresh evidence review.
For an undeployed PRE_TGE Bootstrap vault, inspect the deterministic preview: approved factory release, helper runtime and registry, child templates, signed dependencies and pool/oracle valuation at one block. Download the exact Safe deployment and funding packet. For POST_LAUNCH, the runtime is already deployed: the later packet funds that existing runtime and does not deploy a second vault. Existing-runtime funding also checks its newer finalized zero-custody checkpoint and complete capital-flow coverage.
The issuer executes externally. Register the transaction hash and wait for finality, runtime-identity, balance and risk-admission reconciliation. Klineo's preparation does not sign or broadcast that deployment/funding transaction. A prepared packet, issuer signature, submitted transaction and finalized reconciled result are distinct states.
Inspect and manage a vault#
Open /app/vaults, search or filter by lifecycle and market, then open the intended record. A listed vault may be draft, paused, unfunded or archived. Compare values only within compatible valuation scopes and quote units; the directory keeps differing per-vault values separate.
| Tab | What to review |
|---|---|
| Overview | Vault identity, owner, strategy, evidenced balances and current issues. |
| Positions & inventory | Idle balances, ranges, liquidity, fees and custody/position provenance. |
| Market quality | Quality evidence scoped to this vault and pool. |
| Strategy & policy | Boundaries, caps, reserves, dates and active authority. |
| Proposals & executions | Prepared changes, internal decisions, Safe submissions and reconciled outcomes. |
| Performance | Covered results, benchmarks, costs and exact report context. |
| Incidents | Affected evidence and permitted response history. |
| Settings & exit | Supported pause/exit controls and their prerequisites. |
Market, inventory, data, automation and policy health are separate dimensions. Missing evidence remains unassessed. Review data quality before acting on balances or proposed risk expansion.
Strategy drafts and studies inform review. Internal policy or proposal approval does not substitute for issuer Safe authorization, current source evidence, release gates or finality. Use the allowed pause, risk-reduction or exit path for the exact situation; a local form cannot enable autonomous execution.
Review service fees#
Open /app/billing?view=fees and select the vault. Inspect the exact terms version, quote profile, acceptance evidence, benchmark, caps and accrual history. Prepared terms are shown for review when no current accepted authority exists.
Schedules can cover setup/service fees, a performance fee and cap, finalized gas reimbursement, pass-through caps and a combined period cap. Performance fees use the signed benchmark with cumulative-alpha, high-water-mark and negative-carry rules. No universal rate is implied by sample prices.
Issuer-Safe acceptance records the exact terms generation separately from activation. Future accepted terms remain PENDING before validAfter; they are ACTIVE only from validAfter until, but excluding, validUntil, and new risk still requires the other current admission checks. They become EXPIRED at validUntil. Acceptance alone does not permit new risk before the validity window opens.
Accruals require finalized, covered reporting periods; contiguous ready accruals can be invoiced. Unavailable fee components are not zero fees. Payment reconciliation requires the exact finalized Safe token transfer, and viewing an invoice does not pay it.
Expired commercial authority prevents new service risk while preserving the documented pause, risk-reduction, exit, reporting and payment paths. Billing authority does not create custody or policy authority.