What do you want to see in Anchor V2?

[jacobcreech]

Anchor V1 was built during a different time of Solana and contains a number of choices that are very difficult to change without making a very breaking change to Anchor.

With Anchor V2, we want to design the framework from the ground up with all the learnings we've had maintaining and building Anchor. What works, what doesn't, what we wish we had, and more.

For this discussion we want to pose the following question:

If we were to rebuild Anchor from the ground up in V2, what should we change?

Things already under consideration:

• Use Pinocchio as the entrypoint

[hwsimmons17]

I would love a unification of tools with Anchor, i.e. just use Kit/Codama etc. from a UI perspective

[jacobcreech]

I expect Anchor V2 to unify tools around using Litesvm, using the solana-verify standard, potentially surfpool, Gill, and more. Codama is still up for discussion at this time.

[hwsimmons17]

Love it! That is my biggest complaint rn about the current state of Solana tooling is that there are 2 different tools supported by 2 different things so you have to choose and it's a pain because an SDK or whatever uses one tool but Anchor uses the other...

[hwsimmons17]

I hate the testing framework built into Anchor. Would love to have you plug in your testing framework of choice (such as LiteSVM)

[levicook]

Me too. Google litesvm-testing if you’re looking for a near and hopefully long term solution

[hwsimmons17]

I want Anchor V2 to be near as performant as "solana native" programs.

[jacobcreech]

That's the goal

[ChewingGlass]

On perf optimization, the default serialization should probably behave more like zero-copy but with better UX (IE not having to try to have perfect byte alignment, etc). Not sure if that's possible. But borsh is kind of terrible

[hwsimmons17]

I like this a lot

[Henry-E]

Ban u128s from accounts and force 8 byte alignment throughout

[mikemaccana]

Remove anchor-js (there doesn't seem to be much point now we have Codama, and it gives Acheron one less thing to maintain).

[mikemaccana]

@Henry-E totally agreed Codama is quite unpopular, I think that's mostly because it has poor documentation - it's like if opening a Lego box told you how to make plastic rather than how to build using the Lego.

If someone (including everyone here) fixed the Codama docs / scripts to have something like:

## Anchor

Run `npx codama generate anchor` to find the IDL and create a TS client in your `dist` directory. 

I feel people would like it more.

[tiago18c]

@mikemaccana agree on codama docs! Tried recently for the first time and did enjoy it, but the documentation was lacking trying to find examples and how to use some nodes related to PDAs.
Also, from the same nodes, rust client generation doesn't have PDA resolution while the TS version does.

[Henry-E]

Lack of documentation but also unclear frontier of what is and is not supported. According to some friends that tried and gave up on using it

[0xDeeep]

Codma is that dusty town on your startup road trip—you leave with nothing but a gray hair and a heap of node.

And for the love of sanity, can we please just have one TypeScript client and one Rust client for the shake-off industry? I’m tired of juggling a dozen codegen libraries and dependency hell.

[mikemaccana]

Codama docs are now updated - see I'm a busy Anchor developer. How do I use Codama?

[mikemaccana]

Default to not requiring flaky/unnecessary third party test runners like ts-mocha or ts-jest (node has a test runner and it works fine).

[spellsaif]

I’m not against SVM-Lite. In fact, it looks like a solid step forward, and I genuinely plan to give it a try soon.

But here’s where I stand, removing TS testing entirely is not the answer.

The solution isn’t to abandon something that works (even if imperfectly); it’s to improve and evolve it.

[hwsimmons17]

Agreed... that's why I'm advocating for letting the developer picking their testing package

[spellsaif]

Count me in ✨

[levicook]

Rust testing and benchmarking need to be a higher priority. I appreciate the ui is all typescript, but program quality is undermined by trying to avoid rust

[jacobcreech]

Litesvm also comes in ts and python. It'd be up to the dev to decide what they build with.

[Henry-E]

Get rid of remaining accounts. Support variable length arrays of the same type of account or some arbitrary constraint

[0x0ece]

A common case is array of tuple of accounts (eg mint + price oracle)

[0x7EAB07]

Remaining accounts are still useful when performing CPI

[tiago18c]

Would be interesting to drop the 8byte discriminators in favor of 1-byte as a default.

Either some analysis to lift some checks or allow me to override some of the account checks (e.g. can make a lot of assumptions when calling other programs like token/token22)

[jacobcreech]

Discriminator update is being considered. We just need to design it correctly to handle 1-byte or a better default.

Custom discriminators already exist as an anchor feature, but from what I can tell almost have 0 usage today

[hwsimmons17]

I did not know that... interesting

[tiago18c]

I didn't until recently. Its why I'm asking to take advantage of the major and breaking changes to change this default ! (also, do the custom discriminators work with accounts too or just indstructions?)

[Henry-E]

I used custom discriminators in mock programs where I define a differently named account but still want the same seed as the original program account

[levicook]

Food for thought; pattern I’m loving:
#[repr(u8)]

#[repr(u8)]
pub enum Instruction {
    Hello = 0,
    World = 1,
}

impl TryFrom<u8> for Instruction {
    type Error = ();

    fn try_from(value: u8) -> Result<Self, Self::Error> {
        match value {
            0 => Ok(Self::Hello),
            1 => Ok(Self::World),
            _ => Err(()),
        }
    }
}

pub fn process_instruction(
        program_id: &Pubkey,
        _accounts: &[AccountInfo],
        instruction_data: &[u8],
    ) -> ProgramResult {
        if instruction_data.is_empty() {
            return Err(ProgramError::InvalidInstructionData);
        }

        let (discriminator, remaining_data) = instruction_data.split_first().unwrap();

        match Instruction::try_from(*discriminator) {
            Ok(Instruction::Hello) => log_hello(program_id, remaining_data),
…
            Err(_) => {
                log!("Unknown instruction discriminator: {}", *discriminator);
                Err(ProgramError::InvalidInstructionData)
            }
        }
    }

[mikemaccana]

Remove boilerplate byte conversion for seeds - if someone wants to specify bytes, they can, otherwise Anchor should just do the conversion for us in the most popular way.

This won't break anything because people that specify bytes can still specify bytes.

Good frontend tools (like Kite 😁) already do this.

[ChewingGlass]

The interface should be as declarative as possible. Would be awesome if, like active record in ruby, I could just pull accounts off of an existing account.

More concretely, currently we do:

#[derive(Accounts)]
pub struct Thing<'info> {
  pub mint: Account<'info, Mint>
  #[account(has_one = mint)]
  pub stake_account: Account<'info, StakeAccount>,
}

fn handler(ctx: Context<Thing>) -> Result<()> {
  do_something(ctx.accounts.mint)
  do_something(ctx.accounts.stake_account)
}

This has the potential footgun of forgetting to add that has_one. What if instead I was able to write code like:

#[derive(Accounts)]
pub struct CloseEntityClaimCronV0<'info> {
  pub stake_account: Account<'info, StakeAccount>
}

fn handler(ctx: Context<Thing>) -> Result<()> {
  do_something(ctx.accounts.stake_account.mint)
  do_something(ctx.accounts.stake_account)
}

Likewise, any client should be able to infer these types of relationships when forming instructions. When I want to execute a contract endpoint, typically I only care about a single account. Then lots of other things get pulled in around the side that I (the programmer that didn't write the contract) don't care about. I want to be able to do deleteStakeAccount(stakeAccount) not deleteStakeAccount(the entire kitchen and the kitchen sink). To get around this, developers end up writing heaps of annoying SDKs that are not at all standardized. So that devs interacting with their programs don't cut themselves on all the PDA/has_one glass.

[Henry-E]

This is also how they do it in Sui. I had planned to try and add something like this accounts on accounts back when I was maintaining but never found the time to try. It should be pretty manageable when using zero copy.

Although I will say removing explicit account loading and making it implicit will make integrations for others very difficult since there's no longer an easily available canonical list of what accounts you need and why and where they come from.

So I think you should be able to more easily access accounts on other accounts e.g. user_account.mint and if mint is a pubkey then you would be able to just get the mint account automatically. But stil specify that you need the mint in the account context. Then it's the accounts on accounts loader that handles the has_one check implicitly by only giving you a mint account if it finds the pubkey stored in that variable in the provided account infos. They should still use has_one but at least if they forget it's sort of double checking and might save them by accident.

[ChewingGlass]

I think you can make this more manageable by having rules similar to the way react does hooks. You can't use a react-hook after a conditional. They all need to be at the top. So if you want accounts, you need to get all your accounts into variables before you do any conditional logic. Then the set of accounts is always fixed and predictable.

[tiago18c]

Pinocchio-like CPI api! This felt like such a breath of fresh air when I tried pinocchio!

[jacobcreech]

With using Pinocchio as the entrypoint, this should come for free in v2

[Henry-E]

Needs a well thought solution to multiple versions of account or different possible account structs being loaded based on a version number

[jacobcreech]

Additionally a better way to migrate between these versioned accounts?

[tiago18c]

I think this is somewhat solved by decoupling the discriminator from the account name

[Henry-E]

Yes. Setting the canonical version of an account and having predefined ways of upgrading. It's really hard to know what a good ergonomic solution for this looks like without battle testing but could start with a few approaches and whittle it down over time with feedback and usage. It's a very core issue though for long running large protocols and only a bunch of hacky solutions like padding exist or are used at the moment.

[hwsimmons17]

I have been thinking about this a lot lately, and I think what databases do is the best, i.e. defining migrations. I would love to define a migration, i.e. the PDA was 60 bytes (or whatever) I added a Pubkey on it (adding 32 bytes), so the new PDA is now 92 bytes. If you get passed in an old PDA, here is the behavior I want you to do to upgrade it... something like that

[mikemaccana]

This is a big one, but: I'd move the seeds for each struct as a macro for the struct.

PDAs are a key/value store. The struct is the value, the seeds are the key. Put them in the same place.

[hwsimmons17]

Totally agreed here

[ChewingGlass]

My only caveat here is sometimes the same struct can have multiple possible PDA derivations. So needs to be a many to one type relationship.

[Henry-E]

Yeh I don't see how the struct and PDA have anything to do with each other. Maybe if there's a particular part of the PDA seed that is a constant. But many other parts of the seed tend to be linked to variables on other accounts or args. Plus keeping account validation in the account context makes the most sense. If there was some way to more easily specify the same set of seeds for the same struct across contexts that would be useful but not clear what that would even look like or if it'd be worth it.

[ChewingGlass]

Imo would be nice if I could even just do something like:

struct MyAccount {
...
}

impl MyAccount {
   pub fn seeds(mint: Pubkey) {
     ["my_seeds", mint.as_ref()]
   }
}

#[derive(Accounts)]
struct Thing {
  #[account(seeds = MyAccount::seeds(mint))]
  pub my_account: Account<'info, MyAccount>
}

Right now iirc the macros really don't like that. And not sure rust would even like returning an array like that. But you get the point.

[ChewingGlass]

Please God version IDLs. A breaking change to IDL formats that breaks clients should be uploaded to a different place so that old clients can peacefully coexist with new ones. The Anchor 29 to Anchor 30 upgrade gave me my first gray hairs.

[gnattishness]

Is this not now handled with the metadata.spec field? Or am I misunderstanding?

[Henry-E]

Try to optimise the structure of the new anchor for use with AI. Make sure that the best AI can intuitively figure out the structure and reconsider redesigning any obvious sticking points where it makes repeated mistakes

[mikemaccana]

Oh another one: Codama (and probably anchor-js but I can't remember) doesn't have any tsdoc for the functions it exports.

Whatever generates the TS for frontend should show up nicely in editors (this means tsdoc, whether we like it or not). Possible add a macro in Rust to add comments into the IDL?

[ChewingGlass]

The IDL already exports the docstrings you have on accounts. This one seems pretty low-hanging.

[ChewingGlass]

Read layer integration. We're defining all these well-structured accounts that are easy to parse. Why am I not able to query the RPC with GraphQL?

Solana is basically a database. I should be able to define my models (accounts) and how they relate. Those relations should be used when I'm coding my contract endpoints to prevent footguns. The RPC should also be aware of those relations and give me a nice structured way to query, join, and aggregate data. This would be a massive UX unlock over getMultipleAccounts, getProgramAccounts, etc.

[ChewingGlass]

If I define:

#[account]
struct Proposal {
   pub name: String,
   pub choices: ...
}

#[account(has_one = Proposal)]
pub Vote {
  pub voter: Pubkey,
  pub proposal: Pubkey,
  pub weight: u64
}

I should be able to go to the RPC and query:

{
  proposal(name: "foo") {
    votes {
      voter,
      weight
    }
  }
}

or

{
  vote(voter: "my pubkey") {
    weight,
    proposal {
      name,
    }
  }
}

[CanardMandarin]

Less macros!!! Debugging errors in macro is a pain, macros are not flexible at all and AI-based editors also struggle to provide accurate hints. New developers often don't understand what's happening behind the scenes.

I would love some kind of rework on the serialization and deserialization. Copying accounts makes anchor stack hungry. This will be an issue with the upcoming increase in transaction size, as developers will be able to include more accounts.

[spellsaif]

I do agree on some of it. I mean, when I was learning to build solana program using anchor was bit confusing, difficult due to uses of so many macros. I mean some abstractions are good but it does bring some learning curve. You will get used to it and macros helps alot in managing things which you don't have to do but framework can easily handle it.

Yeah, there is always room to improve it.

[adrena-orex]

CPI utility function that auto-reloads accounts that need to be

.reload()?

[levicook]

Ooh, good one

[Henry-E]

Accessor is useful for this. For example for token balances

[adrena-orex]

Helper to expose the current instruction’s index in the transaction

i.e

     let ix_index = ctx.instruction_index()?; // auto-injects sysvar internally

[Henry-E]

You need the instructions sysvar passed in the accounts list for this to work

[BretasArthur1]

LiteSVM for testing and also using surfpool as the native local validator

[WillShirley13]

Allow for <8byte account/instruction discriminators?

[mikemaccana]

That's already done, current Anchor has custom discriminators.

[mikemaccana]

Less boilerplate .to_account_info():

    let transfer_accounts = TransferChecked {
        from: from.to_account_info(),
        mint: mint.to_account_info(),
        to: to.to_account_info(),
        authority: authority.to_account_info(),
    };

Allow devs to just:

    let transfer_accounts = TransferChecked { from, mint, to, authority };

[hasip-timurtas]

Hi everyone,

I would like to suggest adding an anchor audit parameter that scans vulnerabilities in a project and suggests fixes.

The Solana ecosystem is already very large, but there’s still a lack of native tools focused on automated security analysis. I believe this is something the ecosystem truly needs. Developers should be able to catch common security issues early, without leaving their existing workflow.

I’ve been working on a tool called Solsec: https://github.com/hasip-timurtas/solsec
It’s a Rust-based CLI that performs static analysis, IDL-based fuzzing, and supports a plugin system along with multi-format reporting. The project is new, but it became quite popular in a short amount of time. It’s also published on crates.io: https://crates.io/crates/solsec

Solsec is designed to be lightweight and developer-friendly. I believe it would be a great fit for powering an anchor audit command inside the Anchor CLI.

I’d be happy to work on a PR to explore and implement this integration. Let me know what you think or if there are any specific requirements you’d like to see.

Thanks,
Hasip Timurtas

[ERoydev]

I wonder will this allow us to be able to compile Anchor code as executable binary if we want to, so we can use for debugging in LLDB. Because currently i don't have much choice on compiling it compiles to SBF Bytecode that is not usable for debugging.

[Chester-King]

Hey everyone
Would like to add time control inbuilt in the Anchor's testing framework so devs can write tests where they can fast_forward(1 day) or similar to check out correct working of solana programs while in active development

Thanks,
https://x.com/0xChesterKing

[mikemaccana]

@Chester-King LiteSVM does this, there's a lot of discussion to making it default for Anchor V2 earlier in the thread (cc @jacobcreech )

[Henry-E]

And litesvm supposedly has ts support as well, which is key

[adimasduvitra]

I just wish I can code from arm device plz 🙏😭

[0x0ece]

What is the issue? I code on mac m3, ie arm

[adimasduvitra]

I'm on Windows/WSL, didn't successfully build it myself after installing some build tools. Would be nice if it works out of the box still 🙏 any guide/help would be appreciated

[MrCatnip]

Interface for fetching sliced accounts
Make stuff work on windows without hacks
Not having to turn off account resolution because of breaking constraints inside seeds
Better type interface for folks willing to extend anchor functionalities

[baiwfg2]

1. Please make anchor (rust) public API more developer-friendly. I'm learning the 2024 bootcamp project 9 token lottery. The interfaces are so confusing and error-prone, even the official developer are hard to figure out where those symbols should be imported from.

2. Furthermore, when I hover cursor onto API functions, it shows no comments, even for those that are difficult to understand. Adding more comments is quite appreciated.

3. Actually I don't understand why you said V1 was built. But people only see latest version is 0.x, right ?

[mikemaccana]

Remove declare_id - our projects already have a program ID in Anchor.toml, and deployment details don't belong in source code.