DOCS

SENTIENT is a programmable liquidity operating system for memecoins that already exist.

• Pump.fun = launch. The token is created there. SENTIENT never creates tokens, bonding curves or pools.
• Meteora = liquidity rails. DLMM bins and DAMM v2 pools hold the liquidity engines manage.
• SENTIENT = engine layer. Installable engines read the market, propose liquidity actions, and pass every one through a risk engine, a simulation and an execution gate.

Engine model

Four records describe everything an engine does. They are designed so third-party engines can be registered later without changing the pipeline.

• Engine: identity and author (V1: protocol only).
• EngineVersion: an immutable manifest that lists venue, modes, the action types it may propose, default params, editable params, guarantees and limits.
• EngineConfig: an immutable, validated parameter set for one version (defaults plus allowed overrides within protocol bounds).
• EngineInstallation: one config running on one token’s market, with its venue pool, engine treasury and status.

V1 runs no third-party code. Engines are deterministic TypeScript in packages/engines. The risk engine rejects any action type a manifest does not declare. Future engines will plug in as new manifests with the same contract.

Regimes

Every engine uses the same regime classifier. Below 50% data completeness, the regime is UNKNOWN and engines only observe.

• UNKNOWN · Not enough observations to classify the market yet.
• CALM · Normal activity and volatility.
• ACCELERATING · Volume rising faster than its recent average with normal volatility.
• STRESSED · Volatility elevated and liquidity or bids deteriorating.
• DORMANT · Very low trading activity.
• RECOVERING · Deep drawdown from the high followed by renewed volume.

Engines

Installing an engine

1. Paste a contract address. The scan reads the mint, Pump.fun state, PumpSwap, DEX markets, 5-minute candles, and Meteora DLMM and DAMM v2 pools. Everything comes from live mainnet data.
2. Engine compatibility is computed from the pools that exist now: READY (a token/SOL pool exists on the engine’s venue), PREVIEW (the pool exists, but the adapter is still preview), OBSERVE_ONLY (no pool), or UNAVAILABLE.
3. Choose an engine and adjust only the parameters it exposes. Your wallet signs a plain-text message containing the engine, version, token and exact config. Nothing else is signed.
4. If the token has a Pump creator on record, only that wallet can install. Otherwise the installation is marked unverified.
5. The installation starts in OBSERVE. It acts only after an engine treasury is connected and funded. In V1 the operator connects the treasury, because the keeper signs for it.

SENTIENT does not create pools in V1. A token with no Meteora pool is observed, not operated.

Decision pipeline

Engine proposes. Risk engine validates. Executor executes.

1. Observe: market state from DexScreener, GeckoTerminal, Pump and the Meteora SDK. Each field records its source; missing fields stay null.
2. Engine: deterministic regime detection (with hysteresis), then the engine’s mode logic proposes typed actions. No language model builds transactions.
3. Risk: validates, sizes or rejects every action (see below).
4. Plan: builds transactions with the official Meteora SDKs only (@meteora-ag/dlmm, @meteora-ag/cp-amm-sdk).
5. Simulate: RPC simulation against live state. The transaction’s program IDs are checked against the venue allowlist.
6. Execute: submits only if the execution gate allows it. Otherwise the result is recorded as SIMULATED.
7. Record: every step is written to the public engine log, including blocked and failed steps.

Risk engine risk-2.0.0

• emergency-pause: the protocol or installation pause blocks everything.
• config-bounds: the installed config must validate against protocol bounds.
• engine-match: the decision must come from the installed engine and version.
• min-confidence: decisions below the confidence floor are rejected.
• allowed-pool: actions only on the installation’s pool, on the engine’s venue, for the token/quote pair.
• oracle-deviation: deployments are blocked if the pool price deviates from an independent reference.
• reserve-floor: the reserve can only be raised by an engine. The one exception is PHOENIX REVIVE, which may release down to a protocol-limited fraction.
• epoch-cap: limits the share of deployable treasury committed per epoch.
• Per-action rules: undeclared action types are rejected. REMOVE and REBALANCE are rejected on locked positions and on lock engines. LOCK is accepted only on an owned DAMM v2 position that is not already fully locked.
• simulation-required: nothing is submitted without a passing simulation and an allowlisted program set.

Permanent locks (BLACK HOLE)

BLACK HOLE locks liquidity with Meteora DAMM v2’s permanent_lock_position instruction (program cpamdpZCGKUy5JxQXB4dcpGPiikHawvSWAd6mEn1sGG). It moves position liquidity into permanent_locked_liquidity. The DAMM v2 program has no instruction that withdraws it. Locked liquidity still earns trading fees, which the engine can claim.

• Liquidity is reported as consumed only after the lock transaction confirms and the position is re-read on-chain.
• Treasury balances and the reserve are not locked until they are deposited and locked.
• Meteora DLMM has no permanent lock. BLACK HOLE therefore runs only on DAMM v2 pools.
• A lock does not create a USD price floor. The locked position’s value moves with the market.
• Status: adapter preview. Transactions are built and simulated, but submission is disabled until the operator sets DAMM_V2_EXECUTION=true. Currently: disabled.

Creator fees

SENTIENT cannot redirect Pump creator fees. A Pump creator can configure Pump’s fee sharing to pay part of their creator fees to an engine treasury. That is the creator’s choice, made with Pump’s own instructions, and can only be done once per coin. Until then, engine resources come only from deposits and claimed LP fees, and every inflow is attributed to its source.

Market health

Market Health measures observable market-health characteristics. It is not a prediction of future token price.

It is a weighted average of observed components: liquidity depth versus market cap, volume, holder distribution, drawdown, volatility, and engine reserve runway. If less than 50% of the weight is observable, no score is shown.

Execution gate

Simulation-only is the default. Live submission requires a keeper signer, SIMULATION_ONLY=false, and on mainnet both ENABLE_MAINNET_EXECUTION=true and an exact acknowledgement phrase.

This deployment: execution simulation-only · cluster devnet.

V1 status

• HYDRA, PHOENIX, COMPOUND, FORTRESS: full DLMM pipeline (plan, simulate, gated submit). Simulation-only by default.
• BLACK HOLE: DAMM v2 adapter preview (read, plan, simulate). Submission is gated behind DAMM_V2_EXECUTION.
• Pool creation, swaps and third-party engines are not part of V1.
• Treasury connection is operator-configured in V1.