Smart Contract Audit for Medley Finance

Management Summary

Medley Finance contacted Sayfer to perform a security audit on their Solana programs in 03/2025. 

This report includes a review of the Medley Finance Solana smart contracts, developed using Rust and Anchor. The review covers architectural structure, authority models, CPI interactions, SPL token usage, and a list of implementation and security improvement recommendations. All findings and risk ratings are framed exclusively around Solana’s PDA authority model, CPI patterns, rent-exempt account requirements, and compute-unit limits.

Over the research period of 4 weeks, we discovered 24 vulnerabilities. 3 of them are marked as critical, as deploying the contract as-is may lead to direct loss of funds and functionality.

Several fixes should be implemented following the report, to ensure the system’s security posture is competent.

After a review by the Sayfer team, we certify that all the security issues mentioned in this report have been addressed by the Medley Finance team.

Risk Methodology

At Sayfer, we are committed to delivering high-quality smart contract audits tailored to the blockchain execution environment under review. For Solana programs, our risk model considers the architectural distinctions of Solana’s runtime.

Our risk assessment is based on two key factors: IMPACT and LIKELIHOOD. Impact refers to the potential harm resulting from an issue (e.g., lamport loss, account corruption, program failure). Likelihood considers factors such as the complexity of the program, frequency of user interaction, and surface exposure via cross-program invocations (CPIs).

Given Solana’s parallel transaction execution model, compute budget limits, and strict account ownership model, the following additional considerations influence risk:

• Rent-exemption and lamport management for persistent accounts.
• BPF compute budget exhaustion or CPI depth errors.
• Account deserialization failures and runtime constraints.
• Authority misuse or PDA derivation conflicts.

Risk is defined as follows:

Protocol Overview

Protocol Introduction

Medley is a decentralized finance (DeFi) protocol designed to provide users with advanced financial tools and services within the blockchain ecosystem. It offers features such as decentralized lending, borrowing, and yield optimization strategies, enabling users to maximize their crypto assets’ potential. By leveraging smart contracts, Medley ensures transparency, security, and efficiency in its operations, aiming to democratize access to financial services and foster a more inclusive financial system.

Security Assessment Findings

Inverted Token Validation

Description

The code implements an inverted comparison operator when validating token mints during swap operations. Instead of checking that the provided token matches the expected one in the index, it requires them to be different.

• lib.rs:412-415, 662-665

require!(
 index_info.index_tokens[token_index].mint ≠
expected_token_mint.key(),
 ErrorCode IncorrectTokenMint
);

Mitigation

Invert the comparison operator from != to == to correctly validate that the token being swapped matches the expected token.

Decimal Precision Risk in Swaps

Description

swap_to_sol(…) accepts an external token_amount_in_decimals parameter and uses it directly in token transfers without any validation or adjustment based on the token’s decimal precision.

This is problematic because Solana tokens have widely varying decimal precisions – SOL uses 9 decimals, USDC uses 6, and many bridged tokens use 18 decimals. When processing a token with 18 decimals as if it had 9, amounts would be off by a factor of 10^9 – a billion times too large or too small.

This mathematical miscalculation is deterministic and guaranteed to occur whenever tokens with non-standard decimals are processed.

Mitigation

Make sure that the protocol accounts for token decimal precision by modifying the IndexToken struct to store decimal information and implementing appropriate normalization when calculating transfer amounts. Retrieve this information when tokens are added to the index and incorporate decimal-aware calculations throughout all token transfer operations.

No Recovery Path for Failed Multi-Step Operations

Description

The protocol implements complex multi-step operations that span multiple transactions, but provides no recovery mechanism if these operations fail part way through. For example, in swap_to_tkn( ), funds are transferred to temporary accounts before swaps are executed, but if these swaps fail, there’s no way to recover the transferred funds.

• lib.rs:430-447

invoke_signed(
 &transfer(
  &ctx.accounts.program_authority_pda.key(),
  &ctx.accounts.wsol_token_account.key(),
  // swap_to_tkn_info.sol_to_swap,
  sol_to_swap,
 ),
 &[
ctx.accounts.program_authority_pda.to_account_info().clone(),
  ctx.accounts.wsol_token_account.to_account_info().clone(),
  ctx.accounts.system_program.to_account_info().clone(),
 ],
 &[&[
  PROGRAM_AUTHORITY_SEED,
  ctx.accounts.index_mint.key().as_ref(),
  &[bump],
 ]], // Sign with PDA's seeds
)?; 

If any step fails after this initial transfer, the funds remain in intermediate accounts with no recovery path.

Mitigation

Implement emergency recovery functions that allow administrators to rescue funds from intermediate states in case of multi-step operation failures. Add timeouts to operations and automatic cleanup mechanics if certain operations aren’t completed within expected timeframes.

Zero Rent-Exempt Lamports for Account Creation

Description

The code explicitly sets rent_exempt_lamports to zero when creating program authority PDAs, ignoring the Solana requirement for rent exemption. This approach violates Solana’s account model where accounts must maintain a minimum balance to avoid deletion

• lib.rs:175-188

let space = 0; // No extra data, just a pure System Account
let rent_exempt_lamports = 0;

let binding = ctx.accounts.index_mint.key();
let seeds: &[&[u8]] = &[PROGRAM_AUTHORITY_SEED, binding.as_ref()];
let (pda_pubkey, bump) = Pubkey fnd_program_address(seeds,
ctx.program_id);

let create_account_ix = create_account(
 &payer.key(),
 &pda_pubkey,
 rent_exempt_lamports,
 space as u64,
 &system_program.key(), // Set owner as System Program
); 

Without proper rent exemption, these accounts will be purged by the runtime, causing critical protocol functions to fail unexpectedly.

Mitigation

Calculate the proper rent-exempt lamports amount based on the account size and provide this value when creating accounts. Replace the hardcoded zero with the calculated value.

Infrequent Index Valuation Updates

Description

The protocol tracks index value in the total_value field, but this value is only updated during user-initiated transactions and not based on current market prices of the underlying assets. When market prices change, the stored index value becomes outdated, creating price discrepancies.

• lib.rs:359-351

// Update state
index_info.total_value += deposited_sol_in_usd;
index_info.total_supply += tokens_to_mint;

Without regular updates based on current asset prices, the index value can significantly deviate from the true market value of its underlying assets

Mitigation

Implement a mechanism to update the index’s total value based on current market prices of underlying assets, either through a dedicated update function that can be called regularly or by calculating real-time values at the point of user operations using price oracles.

Token standard mismatch in swap operations

Description

The code inconsistently handles different token standards, hardcoding assumptions about which standard to use for different operations. The index token uses Token2022 but swap operations use the standard token program, creating potential incompatibilities.

• lib.rs:1157-1159; struct CreateIndex

pub price_update: Account<'info, PriceUpdateV2>, // Pyth price feed account
pub token_program: Program<'info, Token2022>, // SPL Token program
pub system_program: Program<'info, System>, // System program

• lib.rs:1311; struct SwapToTkn

pub token_program: Interface<'info, TokenInterface> 

This separation assumes external tokens always use the standard token program, which will fail when interacting with Token2022 tokens, an increasingly common standard on Solana.

Mitigation

Implement a flexible approach that can handle both token standards which standard a token uses at runtime. Use the TokenInterface approach to accept any token program that implements the standard interface, and adjust operations based on the detected token program.

Missing Slippage Protection in Jupiter Swaps

Description

The protocol integrates with Jupiter for token swaps but implements no slippage protection or minimum output validation. When calling the Jupiter swap function, there’s no validation of the output amount received against any minimum threshold.

Without slippage protection, users can receive significantly less value than expected if prices move before their transaction executes, or if their transaction is front-run. The same issue can be found in rebalance_index( … ).

Mitigation

Implement minimum output validation after swaps by comparing the expected output amount to the actual received amount. Either use Jupiter’s built-in slippage protection parameters in the swap instruction data or add a post-swap verification.

Excessive Staleness Window

Description

get_token_price(…) accepts price feed data up to 10 minutes old (600,000 milliseconds), which is substantially longer than standard practice in DeFi protocols

• lib.rs:73

 let price = price_update.get_price_no_older_than(&Clock get()?, 600000, &feed_id_bytes)?; 

This extended window increases vulnerability to price manipulation, especially in volatile markets. Even a moderate 5% price movement within this window could create significant arbitrage opportunities for attackers who can time their transactions accordingly.

Mitigation

• Reduce the maximum staleness period to 1-2 minutes (60,000-120,000 milliseconds) to ensure prices more accurately reflect current market conditions.
• Add additional checks for extreme price movements, especially for highly volatile assets.

No Admin Rotation

Description

The protocol lacks the ability to change the admin address once it is set during initialization. The hardcoded admin key combined with its storage in state lead to an overly rigid structure, which prevents protocol governance evolution, as ownership cannot be transferred to multisig or DAO structures as the protocol matures.

• lib.rs:106-117

const ADMIN: Pubkey =
pubkey!("2LYa8F6T2iPd4uaxM7hu3ctKXXtHnBPgP5YzCETrFgiT");
const TOKEN_2022_PROGRAM_ID: Pubkey =
pubkey!("TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb");
pub fn initialize(ctx: Context, admin: Pubkey) Result<()> {
 require!(ADMIN *ctx.accounts.admin.key, ErrorCode Unauthorized);
 let program_state = &mut ctx.accounts.program_state;
 program_state.admin = admin;
 program_state.bump = ctx.bumps.program_state;
 Ok(())
} 

Mitigation

Implement an admin rotation functionality that allows the current admin to transfer their privileges to a new address.

No Emergency Pause

Description

While the protocol includes an index status field that is checked in multiple operations, it is impossible to change the default active state (0). This creates a structural weakness in the protocol’s emergency response capabilities.

Mitigation

• Implement a pause/unpause function accessible only to the admin or another governance mechanism that can change the index status value.
• Add an appropriate status enum with clear states (Active, Paused) rather than using numeric values.

Missing Index Token Verification

Description

sell_index( … ) does not verify that the index tokens being burned correspond to the provided index_info account. The function readily accepts the token burn and calculates redemption values without confirming this critical relationship.

Mitigation

• Add explicit verification that the burn matches the expected burn for the provided index_info account.
• Create a direct connection between these accounts through appropriate seed derivation and validation.

No Weight Validation during Rebalancing

Description

rebalance_index_start( … ) doesn’t verify that the new weights sum to 100%, unlike the initial validation performed during index creation. Without this, an admin could set weights that don’t properly sum to 100%, permanently damaging the index’s accounting.

Mitigation

Add the weight validation logic from create_index( … ) to rebalance_index_start( … ).

• lib.rs:144-148

let total_weight: u64 = index_tokens
 .iter()
 .map(|index_token| index_token.weight)
 .sum();
require!(total_weight 100_00, ErrorCode InvalidTokenWeight);

Unbounded Fee

Description

The platform fee parameter has no upper bound, allowing it to be set to arbitrary values. While the default is a reasonable 100 basis points (1%), an admin could set this to 10000 (100%) or even higher.

• lib.rs:230-232

index_info.platform_fee_bps = platform_fee_bps.unwrap_or(100);
ctx.accounts.initialize_token_metadata(name, symbol, uri)?; 

Mitigation

Decide a maximum cap on platform fees (e.g., 500 basis points or 5%) and add logic to enforce this maximum.

Incorrect Token-2022 Implementation

Description

The code incorrectly configures the metadata_pointer extension by setting the metadata address to the mint itself, which violates the Token-2022 standard that requires metadata to be stored in a separate account.

• lib.rs:1147

extensions metadata_pointer metadata_address = index_mint, 

Mitigation

• Create a separate account for token metadata and configure the metadata_pointer extension to point to this separate account, following the Token-2022 standard guidelines.
• Alternatively, consider using the built-in metadata capability of Token-2022 without the pointer extension.

Fixed Fee Can Underflow

Description

The new reversion introduces a fixed swap fee but doesn’t properly validate that the input amount is sufficient to cover both the fixed and percentage-based fees before calculation.

While the code checks that amount_after_fee 0, it doesn’t verify that amount_in_lamports > fee_in_lamports + FIXED_SWAP_FEE before performing the subtraction, which could lead to arithmetic underflow in the calculation if the sum of fees exceeds the deposit amount, reverting the transaction at the end.

Mitigation

We recommend adding an explicit check to ensure the input amount is greater than the combined fees before calculation.

Duplicate Event Emission

Description

buy_index( … ) emits DmacSwapToTokenStartEvent twice with identical parameters.

• lib.rs:371-375, 384-388

emit!(DmacSwapToTokenStartEvent {
 index_mint: ctx.accounts.index_mint.key(),
 sol_to_swap: swap_to_tkn_info.sol_to_swap,
 tokens: swap_to_tkn_info.swapped_tokens.len() as u64,
});
...
emit!(DmacSwapToTokenStartEvent {
 index_mint: ctx.accounts.index_mint.key(),
 sol_to_swap: swap_to_tkn_info.sol_to_swap,
 tokens: swap_to_tkn_info.swapped_tokens.len() as u64,
});

Leftover Function

Remove one of the duplicate event emissions to ensure each event is emitted exactly once per operation.

Missing Index Token Verification

Description

While the Token-2022 transfer hook extensions have been removed, the supporting check_is_transferring( ) still remains in the code.

Mitigation

• Remove check_is_transferring( ) and any related code that supported the transfer hook implementation.
• Remove the TransferHook account structure.

Misleading Comment

Description

The codebase contains comments regarding token program types, referring to Token2022 program declarations as “SPL Token program”.

• lib.rs:1219

pub token_program: Program<'info, Token2022>, SPL Token program

Mitigation

Correct the comment.

Unexplained ‘Magic’ Number

Description

get_rebalance_info( … ) uses the number 10001 as a default return value without any explanation of its significance or meaning.

• lib.rs:1982-1983

// If neither negative nor positive diffs exist, return (usize MAX, 10001)
(usize MAX, 10001) 

Mitigation

• Replace magic numbers with named constants that clearly express their meaning and purpose.
• Alternatively, clearly explain the significance of the number in a comment.

Unused Program State

Description

buy_index( … ) and sell_index( … ) load the program_state account but don’t use it for any logical operations.

Mitigation

• Remove program_state from the Context structure if not necessary for the function’s logic
• Alternatively, implement consistent validation against program_state values if the intent is to perform administrative checks.

Unused Parameter in swap_on_jupiter<‘_>( … )

Description

swap_on_jupiter<‘_>( … ) accepts a program_id parameter but never uses it for validation or any other purpose.

Mitigation

Either remove the unused parameter or properly validate that the program ID matches the expected Jupiter program ID before proceeding with the swap.

Deprecated Findings

The following findings do not appear to be relevant to the most recent reversion of the code sent to us, either because they were fixed, or the code had significantly changed, but were included in the report for completeness. These findings were not included in the vulnerability breakdown or cout given above.

Premature Token Minting

Description

The protocol mints index tokens to users immediately during the buy_index( ), before the corresponding assets are purchased through swap operations. If the swap operations fail after minting, users would hold tokens not backed by assets.

• lib.rs:334-358

// Mint tokens to the user
let tokens_to_mint: f64 = if index_info.total_value 0.0 {
 deposited_sol_in_usd
} else {
 (deposited_sol_in_usd * index_info.total_supply) /
index_info.total_value
};
if tokens_to_mint > 0.0 {
 token_2022 mint_to(
  CpiContext new(
   ctx.accounts.token_program.to_account_info(),
   token_2022 MintTo {
    mint: ctx.accounts.index_mint.to_account_info().clone(),
    to: ctx.accounts.user_token_account.to_account_info(),
    authority:
ctx.accounts.authority.to_account_info().clone(),
  },
  ),
  (tokens_to_mint * LAMPORTS_PER_SOL as f64) as u64,
 )?;
 msg!(
  "Minted {} tokens to user: {}",
  tokens_to_mint,
  ctx.accounts.user.key()
 ); 
} 

Mitigation

Delay token minting until after successful asset acquisition. Implement a two-phase process where user deposits are first used to acquire underlying assets, and only after successful acquisition, mint the corresponding index tokens to the user.

Risk of Race Conditions in Swap Operations

Description

The code uses shared PDAs without user-specific context for tracking swap progress, creating potential race conditions in concurrent operations. The swap tracking PDA is created with seeds that don’t include the user’s pubkey, making it shared across all users.

• lib.rs:1219-1228

#[account(
 init,
 payer = admin,
 space = 8 + size_of () + size_of () + index_info.index_tokens.len(),
 seeds = [ 
  b"swap_to_tkn",
  index_mint.key().as_ref() ],
 bump, 
)] 

Mitigation

Include the user’s pubkey in the seed for swap-related PDAs to isolate operations between users.

Improper Error Handling in transfer hook

Description

The transfer hook implementation uses a panic to prevent unauthorized transfers instead of returning a proper error. This approach is problematic as it leaves transactions in an indeterminate state and doesn’t provide meaningful debugging information.

• lib.rs:988-994

#[interface(spl_transfer_hook_interface execute)]
pub fn execute(ctx: Context, _amount: u64) Result<()> {
// Fail this instruction if it is not called from within a transfer hook
 check_is_transferring(&ctx)?;
 panic!("Transfer not allowed");
} 

Mitigation

Replace the panic with a proper error return to provide clear feedback and ensure consistent transaction handling.