Missing accounts marked as signers in JS Client #58

Activity

1. lorisleiva commented on Oct 13, 2025

   

   lorisleiva

   on Oct 13, 2025

   Member

   More actions

   Hi there,

   I'm confused, it does mark them as signers. You have to pass a TransactionSigner as per the input type on both instructions.

   system/clients/js/src/generated/instructions/transferSol.ts

   Line 99 in 7e5f04e

   source: TransactionSigner<TAccountSource>;

   system/clients/js/src/generated/instructions/createAccount.ts

   Lines 116 to 117 in 7e5f04e

   	payer: TransactionSigner<TAccountPayer>;
   	newAccount: TransactionSigner<TAccountNewAccount>;
2. EnriqueL8 commented on Oct 14, 2025

   

   EnriqueL8

   on Oct 14, 2025

   Author

   More actions

   You need to know before creating the instruction which fields are the signers instead of the create instruction telling you these are the signers you need for this
3. lorisleiva commented on Oct 14, 2025

   

   lorisleiva

   on Oct 14, 2025

   Member

   More actions

   Again, I'm a bit confused about why you think this is the case. TypeScript will throw a type error if you try and pass anything other than a signer as input. You don't need to know anything. It's all explicitly typed.
4. EnriqueL8 commented on Oct 16, 2025

   

   EnriqueL8

   on Oct 16, 2025

   Last edited by EnriqueL8

   Author

   More actions

   Sorry let me explain with a bit more detail, let's say I want to front the system program client by an API to build system programs. The input to that API is purely JSON based, so the signer would be a base58 encoded string in a field such as source or payer or authority or whatever. Instead of me being able to pass that to the SDK and it figuring out who is the signer, I need to do translation of:

   • the authority is passed in so that is the signer , this doesn't add signer to the accounts so need to add manually
   • the multiSigners is passed in so they are the signers, and authority is actually just an address to the multiSign account.

   Maybe this is not the intended consumer of this, and writing a wrapper around this is the correct approach
5. lorisleiva commented on Feb 26, 2026

   

   lorisleiva

   on Feb 26, 2026

   Member

   More actions

   Damn sorry for the late reply this must have been buried in my GitHub notifications.

   If I understand correctly, the issue is that the developer has to understand that:

   • Passing authority as a signer means not using multi-signers.
   • Passing authority as an address means using multi-signers which must be passed in the appropriate multiSigners array.

   And you are suggesting that these helpers should be specific to these two use-cases so users don't have to understand this wiring.

   If so, then you're not wrong. Having separate helpers could help the developer experience slightly. However these helpers are generated which means they are designed how the program designed them. In a way, there's also value in having helpers that don't deviate too much from the program's design decision to avoid having multiple mental models over the same thing. That being said, additional helpers on top of lower-level helpers could be beneficial to some people.

   We're adding a new DX improvement layer on top of these generated helpers called Kit Plugins. Perhaps this could be the place to have two functions for these two use-cases.

   I could be completely off though so do let me know if I got that right haha.