Allow Optional Accounts in Anchor Programs

[anoushk1234]

Let's say I have a mint instruction in my program and I allow paying for the mint using native tokens and custom tokens I have two options:

• to pass in the ATAs for the custom tokens even if I dont want to pay using sol which makes the transaction more expensive
• Make two instructions one for minting native and one for custom tokens making the code longer

A more elegant and efficient solution would be to allow Optional accounts in the accounts struct using Option<>

❌Current Scenario

#[derive(Accounts)]
pub struct MintNFT<'info> {
 #[account(mut)]
    pub mint_authority: Signer<'info>,
     #[account(
        init_if_needed,
        payer = mint_authority,
        associated_token::mint = custom_spl_token,
        associated_token::authority = mint_authority,
    )]
    pub custom_ata: Box<Account<'info, TokenAccount>>,
 #[account(mut)]
    pub custom_spl_token: AccountInfo<'info>,
    }

✅ Improved scenario

#[derive(Accounts)]
pub struct MintNFT<'info> {
#[account(mut)]
  pub mint_authority: Signer<'info>,
   #[account(
      init_if_needed,
      payer = mint_authority,
      associated_token::mint = custom_spl_token,
      associated_token::authority = mint_authority,
  )]
  pub custom_ata: Option<Box<Account<'info, TokenAccount>>>,
#[account(mut)]
  pub custom_spl_token: AccountInfo<'info>,
  }

Currently if you wrap accounts with Option this error pops up

proc-macro derive panicked

help: message: Invariant violation: composite constraints can only be raw or literals

[mmdhrumil]

Much needed. The current way to circumvent this limitation AFAIK is to use remaining_accounts along with manual security checks.

[stegaBOB]

I'm currently working on this!

[stegaBOB]

#2094 here's the draft PR

[0xC0A1]

Has there been a followup on this?

[anoushk1234]

merged! can be closed now

[stegaBOB]

🎉

[Henry-E]

first time visiting the discussion section

[0xC0A1]

🔥 @anoushk1234 can you link the PR?