Mutable token program

[Henry-E]

fluid-solana-programs/programs/lending/src/state/context.rs

Lines 241 to 243 in 8304582

	#[account(mut)]
	/// CHECK: Safe, we check the address in the lending_admin PDA
	pub liquidity_program: UncheckedAccount<'info>,

What's up with setting the token program to mutable here and in a number of other places? Just fyi it's going to brick your program integrators if you set this to immutable later on.

[Henry-E]

Separate issue but related

fluid-solana-programs/programs/lending/src/state/context.rs

Lines 187 to 193 in 8304582

	#[account(
	mut,
	token::mint = mint,
	token::authority = signer,
	token::token_program = token_program
	)]
	pub depositor_token_account: Box<InterfaceAccount<'info, TokenAccount>>,

This is too strict a requirement for deposit account. This should simply be ownership and mint checks. Enforcing ATA isn't something a program should do. Check all the other borrow lends on solana, none of them enforce ATAs. Lots of integrating programs like to use their own seeds when managing token accounts for deposits.

EDIT: deleting this because the constraints in the code there don't enforce ATA, I don't know why my tests were failing for this instruction saying the account wasn't an ATA and only passing when it was. I have to get back to you on that

6 Program jup3YeL8QhtSx1e253b2FDvsMNC87fDrgQZivbrndc9 invoke [2]
7 Program log: Instruction: Deposit
8 Program log: AnchorError caused by account: depositor_token_account. Error Code: ConstraintAssociated. Error Number: 2009. Error Message: An associated constraint was violated.
9 Program log: Left:
10 Program log: Dt4kkn87KZF1UAx8zzFQzgjWCy54qkNgoBPbfs1DAYCp
11 Program log: Right:
12 Program log: 9sR491sVaUB7Z5NrbkNk1Ao2tk7Vh9i5T34dWSxYdWyN

Right, it looks like the version on mainnet is different from what's here.

[Henry-E]

Just to keep this all in one place

fluid-solana-programs/programs/lending/src/state/context.rs

Lines 183 to 185 in 8304582

	// depositor
	#[account(mut)]
	pub signer: Signer<'info>,

you also have signer as mutable here, which is unusual and not actually required by the program. It's the same in withdraw as well.

[Henry-E]

fluid-solana-programs/programs/lending/src/state/context.rs

Lines 350 to 352 in 8304582

	#[account(mut)]
	/// CHECK: Safe as this will be verified in liquidity program CPI call
	pub claim_account: Option<UncheckedAccount<'info>>,

Maybe it's just planning ahead here but this account is never used within withdraw.

It might be a problem on my end but when trying to pass None in for this account it raised a mut constraint violated which is a strange error to get when passing a None account (the program id). Could be an issue on my end though, just flagging it in case anyone else has run into something similar. The solution for now is just passing any dummy mutable account.

Edit: My guess is that this is the same issue the deposit token account constraints, the version on chain does not support optional accounts.

[adpthegreat]

It might be a problem on my end but when trying to pass None in for this account it raised a mut constraint violated

Yep @Henry-E got that same error too, i put the program address there as a placeholder, also check any jup lend transaction and you'll see thats how it is on chain

[pradyuman-verma]

fluid-solana-programs/programs/lending/src/state/context.rs

Lines 241 to 243 in 8304582

 #[account(mut)] 
 /// CHECK: Safe, we check the address in the lending_admin PDA 
 pub liquidity_program: UncheckedAccount<'info>, 

What's up with setting the token program to mutable here and in a number of other places? Just fyi it's going to brick your program integrators if you set this to immutable later on.

This has been fixed in the lending program Contexts.

[pradyuman-verma]

Separate issue but related

fluid-solana-programs/programs/lending/src/state/context.rs

Lines 187 to 193 in 8304582

 #[account( 
     mut, 
     token::mint = mint, 
     token::authority = signer, 
     token::token_program = token_program 
 )] 
 pub depositor_token_account: Box<InterfaceAccount<'info, TokenAccount>>, 

This is too strict a requirement for deposit account. This should simply be ownership and mint checks. Enforcing ATA isn't something a program should do. Check all the other borrow lends on solana, none of them enforce ATAs. Lots of integrating programs like to use their own seeds when managing token accounts for deposits.
EDIT: deleting this because the constraints in the code there don't enforce ATA, I don't know why my tests were failing for this instruction saying the account wasn't an ATA and only passing when it was. I have to get back to you on that

6 Program jup3YeL8QhtSx1e253b2FDvsMNC87fDrgQZivbrndc9 invoke [2]
7 Program log: Instruction: Deposit
8 Program log: AnchorError caused by account: depositor_token_account. Error Code: ConstraintAssociated. Error Number: 2009. Error Message: An associated constraint was violated.
9 Program log: Left:
10 Program log: Dt4kkn87KZF1UAx8zzFQzgjWCy54qkNgoBPbfs1DAYCp
11 Program log: Right:
12 Program log: 9sR491sVaUB7Z5NrbkNk1Ao2tk7Vh9i5T34dWSxYdWyN

Right, it looks like the version on mainnet is different from what's here.

Yes the deployed program was a previous version, the once on this repo had the latest code. We've done few improvements and deployed new version. Now it matches the code. You can verify using solana-verify. (LLRM contract is still using older code, so it might be possible it doesn't match)

[pradyuman-verma]

fluid-solana-programs/programs/lending/src/state/context.rs

Lines 350 to 352 in 8304582

 #[account(mut)] 
 /// CHECK: Safe as this will be verified in liquidity program CPI call 
 pub claim_account: Option<UncheckedAccount<'info>>, 

Maybe it's just planning ahead here but this account is never used within withdraw.
It might be a problem on my end but when trying to pass None in for this account it raised a mut constraint violated which is a strange error to get when passing a None account (the program id). Could be an issue on my end though, just flagging it in case anyone else has run into something similar. The solution for now is just passing any dummy mutable account.

Edit: My guess is that this is the same issue the deposit token account constraints, the version on chain does not support optional accounts.

We will remove this optional account in future deployment with proper communication with integrators. Jupiter lend Earn program has been integrated at more than 10+ places and removing an account is a breaking change.