JupUSD Updates

delete_operator() only requires the caller’s operator to have OperatorRole::Adminand prevents self-deletion, but does not restrict which deleted_operator can be closed. As a result, any admin can close any other Operator account by passing it as deleted_operator, and can select any payer to receive the reclaimed rent via close = payer.

If intended, document this behavior in DeleteOperator/delete_operator() so it’s an explicit design choice. Otherwise, constrain deleted_operator to the caller’s operator_authority (or a designated governance authority) and/or hardcode the close destination to a treasury account instead of a caller-supplied payer.

Jupiter: Acknowledged.

when a vault has >= 2 oracles, parse_oracles always selects the MIN price and redeem uses that MIN for both the max_oracle_price_usd check and payout math, so a lagging/low feed ( spread allowed up to 200bps ) can make redeems pay 1:1 (minus fee only) even when another oracle shows > $1, meaning the higher oracle price would be more profitable to the protocol while redeeming

consider setting fees higher than 10 bps to cover the worst case divergence, If this is intended, we are sending this one as information

If you are planning to support a high volatility stable token as collateral, use the max oracle in redeem and keep using the min oracle in minting

Jupiter: Pending.

The slot_tresholdvariable in from_switchboard_on_demand() spells threshold incorrectly.

Fix the typo

- let slot_treshold = stalesness_threshold * 1000 / clock::DEFAULT_MS_PER_SLOT;
+ let slot_threshold = stalesness_threshold * 1000 / clock::DEFAULT_MS_PER_SLOT;

Jupiter: Resolved.

from_doves() enforces price.timestamp + s > clock.unix_timestamp, which rejects prices exactly at the staleness boundary. The from_pyth_v2() path uses get_price_no_older_than() (>=), and the Switchboard path checks last_update_timestamp + staleness_threshold >= clock.unix_timestamp. This creates inconsistent staleness semantics across oracles.

Align the boundary check by using >= in from_doves() or document the stricter Doves behavior for operators.

Jupiter: Resolved.

Each benefactor stores an array of 4 fee overrides that can be modified or deleted by an operator with the BenefactorManager role. To do that, the operator has to provide the index of the fee override they wish to modify.

This creates the possibility of race conditions where the data at that index changed before that and the end state ends up being different than what's expected.

For example, if slot 0 is empty and two different operators decide to fill it - one for USDC and the other for USDT. After their transactions execute, only one of the overrides will remain, depending on which transaction executed first.

Be aware of this behavior and monitor the fee overrides to ensure the state is being updated as intended.

Jupiter: Acknowledged.

The redeem_amount is compared against min_amount_out to ensure the user is protected against unexpected redeem results.

require!(
    redeem_amount >= min_amount_out,
    JupStableError::SlippageToleranceExceeded
);

Then the code enforces that the amount that leaves vault_token_account is the exact redeem_amount

let amount_before = ctx.accounts.vault_token_account.amount;
transfer_checked(
    ctx.accounts
        .withdraw_collateral()
        .with_signer(&[authority_seeds!(config.authority_bump)]),
    redeem_amount,
    ctx.accounts.vault_mint.decimals,
)?;
ctx.accounts.vault_token_account.reload()?;
let amount_after = ctx.accounts.vault_token_account.amount;
require!(
    amount_after == amount_before - redeem_amount,
    JupStableError::InsufficientAmount
);

However, this doesn't guarantee the user received the same amount. For example, if the underlying token has a fee feature that has been turned on after the mint path was used, the user may receive an amount under their specified slippage parameter.

Consider using the delta in the slippage check as well.

Jupiter: Acknowledged.

The last_update_slot() check only requires that one submission happened after last_restart_slot. However, get_value() still computes the median over all submissions within slot_treshold slots, which can include pre‑restart submissions if the restart slot falls inside the staleness window. This means the post‑restart gate does not fully prevent using pre‑restart data.

Document this if it's an accepted behavior.

Jupiter: Acknowledged.

from_doves() converts the price using Decimal::from_i128_with_scale(price.price, price.expo.abs()). This implicitly assumes expo is non‑positive. If expo is ever positive, using abs() would divide by 10^expo instead of multiplying, producing an incorrect price.

Pyth usually uses negative expos, so keep this in mind if somehow one of the configured oracles may return positive one.

Jupiter: Resolved.

parse_oracles() forwards the same stalesness_threshold to from_pyth_v2(), from_switchboard_on_demand(), and from_doves(). If any of the oracles update times differs, stale price may be used.

Ensure the staleness used will be suitable for all of the configured oracles.

Jupiter: Acknowledged.

from_pyth_v2() compares Pyth price.conf (an explicit confidence interval half-width) against MAX_CONFIDENCE_BPS, while from_switchboard_on_demand() compares std_dev() (standard deviation of submissions) against the same threshold. and because of that the end result is not exactly the same. The std must be in MAX_CONFIDENCE_BPS of the actual price.

If the current behavior is intended, document the assumption in the oracle handling. Otherwise implement different check for the std.

Jupiter: Resolved.

The final decision for pricing redeems is to use the minimum price returned by all the configured oracles in order to minimize spread. This increases the potential impact of oracle manipulation, as now only one of the oracles has to return a lower price in order to affect redeems.

For example, if the real price is 1.01, a manipulated oracle may return 0.999 and trigger redeem with the 1 branch. It's expected that the fee charged will compensate for this, but it still depends on the exact configuration.

Be aware of this and keep monitoring the oracles after deployment.

Jupiter: Pending.