Wallet cluster: devnet · keeper defaults to simulation-only
Sentient
← Engines

PHOENIX

Built for the second life.

While activity is high, PHOENIX retains a configured share of eligible resources (claimed fees, treasury) as reserve instead of deploying it. After a severe drawdown followed by renewed volume, it enters REVIVE and deploys that reserve into a bid-ask range around the new price — under exactly the same risk limits as any other action.

v2.0Meteora DLMMExecutable · gatedby protocol
Install on a token →
Illustration

Reserve held for revival

—

Undeployed lamports PHOENIX is required to keep. Summed across installations with a connected treasury.

Installations

0

Confirmed transactions: 0 · LP fees earned 0.00 SOL

Execution status

Plans, simulates and (when the execution gate allows) submits through the Meteora DLMM SDK. Simulation-only by default.

Modes

  1. OBSERVEReading the market. No liquidity action proposed.
  2. RETAINHolding a larger share of resources in reserve while activity is high.
  3. IDLEMarket dormant. Preserving resources.
  4. REVIVEDeploying reserve after a drawdown and renewed activity.

Observes · proposes

Market inputs
PriceDrawdown from highVolume vs 24h averageVolatilityLiquidity depth
Actions it may propose (everything else is rejected by the risk engine)
CREATE_POSITIONADD_LIQUIDITYREMOVE_LIQUIDITYREBALANCE_LIQUIDITYCLAIM_FEESLOCK_LIQUIDITYHOLD

What is enforced

  • ✓Positions are owned by the installation's engine treasury and are withdrawable; nothing is locked.
  • ✓Every action passes the risk engine and an RPC simulation before it can be submitted.
  • ✓REVIVE only triggers when both the drawdown and the renewed-volume thresholds are observed.

What it does not do

  • ✕PHOENIX is not price protection. It cannot stop a decline, and REVIVE does not cause or guarantee a recovery.
  • ✕REVIVE may release reserve only down to a protocol-limited fraction of the configured floor.

Default config

PHOENIX v2.0 · BID_ASK
● editable at install
● Range width40
Concentration45%
● Reserve floor60%
● Deployment per epoch15%
Rebalance trigger12
Volatility response50%
Max positions2
● Rebalance cooldown1.0h
● Max slippage60bp
Evaluation interval5m
Fee claim threshold0.025 SOL
Fee redeployment0%
● Retention during activity50%

Bars show each value within its protocol bound. Every config is validated against these bounds before it can operate.

Running PHOENIX

No installations yet.