Skip to content

feat: LP token for Stableswap pool #314

Open
sivo4kin wants to merge 40 commits into
EkuboProtocol:mainfrom
sivo4kin:main
Open

feat: LP token for Stableswap pool #314
sivo4kin wants to merge 40 commits into
EkuboProtocol:mainfrom
sivo4kin:main

Conversation

@sivo4kin

@sivo4kin sivo4kin commented Jan 23, 2026

Copy link
Copy Markdown

Fee Distribution System

On every deposit/withdraw, fees are auto-compounded:

  1. Collect - Accrued swap fees collected from Core position
  2. Protocol Cut - SWAP_PROTOCOL_FEE_X64 % deducted and sent to protocol's savedBalances
  3. Compound - Remaining fees converted to liquidity and added to the position
  4. Leftovers - Any fees that can't be paired (due to price imbalance) are stored as pendingFees and included in the next compound attempt

Result: LP token value grows over time as fees compound into liquidity. Protocol takes a fixed percentage; LPs keep the rest (including any temporarily unpairable amounts).

StableswapLPPositions Gas Report

Deployment: 3,548,031 gas / 16,605 bytes

Core Functions

Function Min Avg Median Max Calls
deposit 24,840 186,765 148,989 281,540 3,477
withdraw 24,750 127,792 121,355 160,506 2,026
withdrawProtocolFees 25,090 56,786 51,191 99,674 4

View Functions

Function Min Avg Median Max Calls
getProtocolFees 6,153 6,153 6,153 6,153 6
getPendingFees 6,224 6,224 6,224 6,224 3
totalSupply 807 2,800 2,807 2,807 291
totalLiquidity 763 2,761 2,763 2,763 1,830
SWAP_PROTOCOL_FEE_X64 506 506 506 506 3

ERC6909 Metadata

Function Min Avg Median Max Calls
name 446 446 446 446 2
symbol 644 644 644 644 2
decimals 302 302 302 302 2

ERC6909 Token Operations

Function Min Avg Median Max Calls
balanceOf 2,428 2,428 2,428 2,428 3,104
allowance 2,780 2,780 2,780 2,780 2
isOperator 2,910 2,910 2,910 2,910 4
approve 46,882 46,966 46,930 47,230 7
setOperator 24,114 40,548 46,026 46,026 4
transfer 23,770 23,898 23,950 23,950 7
transferFrom 24,690 24,810 24,840 24,870 10

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 201d9014a8

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

Comment thread src/StableswapLPPositions.sol Outdated
Comment on lines +158 to +160
// Then claim fees for the user from the LP token
if (claimed0 > 0 || claimed1 > 0) {
StableswapLPToken(payable(lpToken)).claimFeesFor(msg.sender);

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Always claim user fees even when no new Core fees

Because claimFees only calls claimFeesFor when claimed0 or claimed1 from Core collection is non‑zero, a user who has pending fees already accumulated in the LP token will get no payout if no new Core fees were collected in that call. This means claimFees silently does nothing in the common case where fees were accumulated earlier and the pool has since stopped accruing, despite the interface promising “claims accumulated fees for the caller.” Consider invoking claimFeesFor unconditionally (or based on pending fees) so users can claim existing balances even when Core returns zero.

Useful? React with 👍 / 👎.

@moodysalem moodysalem changed the title feay: LP token for Stableswap pool feat: LP token for Stableswap pool Jan 26, 2026
- Optimize PoolMetadata struct
- Extract LPTokenMathLib for reusable LP token calculations
  * calculateMint() with MINIMUM_LIQUIDITY burn logic
  * calculateBurn() for proportional liquidity removal
  * Safe add/remove liquidity operations with overflow protection

- Optimize _autoCompoundFees() to accept pre-computed parameters
  * Pass sqrtRatio, tickLower, tickUpper as parameters
  * Eliminate redundant CORE.poolState() and tick range queries

- Add poolMetadata() getter for interface compatibility
  * Private _poolMetadata mapping with public getter
  * Dynamically compute initialized flag
- Remove redundant overflow checks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant