Skip to content

calculate_credits ignores boost allocation for Position-based staking #170

Description

@ritaifeoluwa

Description

The FarmingPool contract's get_credits function calculates credits based on the current multiplier, but the user's stake may have been recorded with a different multiplier. This means get_credits can return different values depending on when it's called.

Current behavior

pub fn get_credits(env: Env, user: Address) -> Result<i128, PoolError> {
    // ...
    let multiplier = stake.multiplier;  // Uses multiplier from last checkpoint
    // ...
}

Wait, actually it uses stake.multiplier which is stored at checkpoint time. Let me re-read...

Actually looking at the code again:

pub fn get_credits(env: Env, user: Address) -> Result<i128, PoolError> {
    // ...
    let allocation_pct = get_user_boost(&env, &user).unwrap_or(0);
    let multiplier = stake.multiplier;
    let elapsed = env.ledger().sequence().saturating_sub(stake.start_ledger);
    Ok(stake.credits_banked
        + compute_credits(
            stake.amount,
            allocation_pct,
            multiplier,
            stake.credit_rate,
            elapsed,
        ))
}

It uses stake.multiplier which is from the last checkpoint. This is correct behavior. Let me change this issue.

Revised description

The calculate_credits function for Position-based staking does not account for boost allocation, while get_credits for UserStake-based staking does. This inconsistency means Position-based users never get boost benefits.

Current behavior

pub fn calculate_credits(env: Env, user: Address) -> Result<i128, PoolError> {
    // Position-based: no boost consideration
    Ok(position.total_credits + position.amount * position.credit_rate * elapsed as i128)
}

Expected behavior

Apply boost allocation to Position-based staking as well, or document why it's excluded.

Labels

correctness, farming-pool, hard

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

Stellar WaveIssues in the Stellar wave programcorrectnessLogic correctness and invariant enforcementfarming-poolFarmingPool contracthardRequires deep domain knowledge and careful design — not a quick fix

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions