r35157/com_r35157_nenjim-hubd-impl_ref
0
0
Fork 0
Code Issues 18 Pull Requests Actions Packages Projects Releases Wiki Activity

89: Review

Browse Source
This commit is contained in:
minimons
2026-10-04 19:01:25 +02:00
parent f365b69e51
commit a464f80cc4
5 changed files with 35 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files
openspec/changes/89-add-evelyn-liquidity-service/specs/evelyn-liquidity-service/spec.md
+9 -1
View File
@@ -5,7 +5,7 @@ Realize Evelyn's manually funded EVE/SyrupUSDC concentrated liquidity into USDC
## ADDED Requirements
### Requirement: Owned positions qualify by their normalized upper boundary
The service SHALL discover positions owned by its wallet in its configured CLMM pool and withdraw positive liquidity only when the upper EVE/SyrupUSDC boundary U satisfies U <= P*(1-h/100). P SHALL come from current on-chain pool state, both orientations SHALL be normalized, and decisions SHALL use pool precision. Unusable P SHALL skip withdrawals while allowing later steps.
The service SHALL discover positions owned by its wallet in its configured CLMM pool and withdraw positive liquidity only when the upper EVE/SyrupUSDC boundary U satisfies U <= P*(1-h/100). P SHALL come from a fresh on-chain pool read for each owned positive-liquidity position after NFT discovery and previous withdrawals have completed. The same state SHALL be used for that position's eligibility decision and withdrawal quote; an earlier position's price SHALL NOT be reused. Both orientations SHALL be normalized, and decisions SHALL use pool precision. Unusable P SHALL skip the remaining withdrawals in that iteration while allowing later steps.
#### Scenario: Inclusive threshold and upper boundary
- **WHEN** P is 15, h is 10 and positions span 13–13.5 and 13.5–14
@@ -19,6 +19,14 @@ The service SHALL discover positions owned by its wallet in its configured CLMM
- **WHEN** a position belongs to another wallet or pool, has zero liquidity, or its upper boundary exceeds the threshold after a price decline
- **THEN** it retains its state and the service neither withdraws it nor creates or refills positions
#### Scenario: Price declines during discovery or an earlier withdrawal
- **WHEN** a position qualifies before discovery or an earlier withdrawal, but its upper boundary exceeds the threshold at the new pool price
- **THEN** the service reads that new price before deciding and preserves the position's liquidity in either token orientation
#### Scenario: Pool read fails between positions
- **WHEN** an earlier position was withdrawn but the next current pool price is unavailable or unusable
- **THEN** no remaining position is withdrawn in that iteration and swap and payout still run on their independent balances
### Requirement: Swap and payout use independent current balances
The service SHALL read SyrupUSDC at step 2 and USDC at step 3 and operate on the entire respective balance above its nonnegative reserve. Absent or at/below-reserve balances SHALL be skipped. Exact-input swap SHALL use explicit maximum slippage. SPL payout SHALL target the configured wallet owner with existing account-creation support. Amounts SHALL never round upward. EVE and reward tokens SHALL remain untouched by this pipeline.
openspec/changes/89-add-evelyn-liquidity-service/specs/raydium-clmm-liquidity-withdrawal/spec.md
+9 -1
View File
@@ -5,7 +5,7 @@ Provide a narrowly scoped protected Raydium CLMM full liquidity decrease using t
## ADDED Requirements
### Requirement: Full withdrawal preserves the reusable position
The operation SHALL validate the NFT owner, pool and positive current liquidity, decrease that complete liquidity into the same wallet, collect pool-token fees and preserve the position account, NFT and NFT token account. Transaction/account details SHALL remain behind Raydium. It SHALL submit once and use existing confirmation behavior without close, burn or service-level retry.
The operation SHALL validate the NFT owner, pool and positive current liquidity, decrease that complete liquidity into the same wallet, collect pool-token fees and preserve the position account, NFT and NFT token account. For each pool or reward mint it SHALL reuse an existing owner token holding, including a non-associated account, after validating its mint, owner, program and initialized state. It SHALL use or create an ATA only when no owner holding exists and SHALL NOT fall back to account creation when holdings discovery fails. Transaction/account details SHALL remain behind Raydium. It SHALL submit once and use existing confirmation behavior without close, burn or service-level retry.
#### Scenario: Full protected withdrawal
- **WHEN** a wallet withdraws its position's complete liquidity
@@ -15,6 +15,14 @@ The operation SHALL validate the NFT owner, pool and positive current liquidity,
- **WHEN** ownership, pool or current position state is inconsistent with the requested withdrawal
- **THEN** the operation fails before signing
#### Scenario: Existing non-associated token accounts
- **WHEN** the wallet already has a pool-token or reward holding outside its ATA under either supported token program
- **THEN** the withdrawal targets that validated account and creates no additional account for that mint, preserving subsequent wallet balance reads
#### Scenario: Existing holding cannot be trusted
- **WHEN** holdings discovery fails or the selected account has a wrong mint, owner, token program or initialized state
- **THEN** withdrawal fails before signing without creating a replacement token account
### Requirement: Minimum output derives from precise state and explicit slippage
Withdrawal minimums SHALL derive from current Q64.64 pool state, exact CLMM tick/liquidity math and configured slippage with downward raw-token rounding. Both minimums SHALL NOT be unconditionally zero. Required legacy/Token-2022 accounts, tick arrays and bitmap extension SHALL follow the official decrease instruction. Unsupported token extensions SHALL fail safely before signing.