ResolvedInstructionAccountMeta

type ResolvedInstructionAccountMeta<TInput, TAddress, TSignerMeta> = [TInput] extends [{
  role: infer TRole;
}] ? [TInput] extends [{
  signer: TransactionSigner<TAddress>;
}] ? AccountSignerMeta<TAddress> : AccountMeta<TAddress> & object : [TInput] extends [TransactionSigner<TAddress>] ? TSignerMeta : TAddress;

Computes the account meta type produced by an instruction account, based on the input provided by the caller.

This type helper mirrors the runtime logic of getAccountMetaFactory so that generated program clients can accurately type the accounts of the instructions they return. Namely:

• When the input carries an explicit role — i.e. it is an AccountNonSignerMeta or an AccountSignerMeta — the meta type preserves the input's role type: an inline role: AccountRole.READONLY override resolves to ReadonlyAccount, while a role only known at runtime widens to AccountMeta. If the input also carries a signer, AccountSignerMeta is used so the attached signer is reflected in the type.
• When the input is a TransactionSigner, the meta type is TSignerMeta — e.g. ReadonlySignerAccount<TAddress> & AccountSignerMeta<TAddress> for accounts the IDL declares as signers. For non-signer accounts, TSignerMeta should be left to its default of TAddress so that signers merely act as address carriers.
• Otherwise, the helper resolves to TAddress — the branded address string that generated instruction types map to the account meta declared by the program's IDL.

Note that the checks are wrapped in tuples ([TInput] extends [...]) to prevent unions from distributing. If TInput is not narrowed to the caller's specific input type — e.g. when a declared input union is provided instead — the helper deterministically falls back to TAddress, matching the account meta declared by the program's IDL.

Type Parameters

Example

The instruction builder below — the shape emitted by the Codama JS renderer — declares one type parameter per account holding the input value provided for that account, and recovers the account's address type parameter from it using InstructionAccountInputAddress. Since its input parameter remains a concrete object type once inferred, TypeScript keeps performing excess property checks on it, so a misspelled optional account is a compile error rather than silently falling back to its default value.

type TransferInput<
    TAccountAuthority extends InstructionAccountInput | InstructionSignerInput =
        | InstructionAccountInput
        | InstructionSignerInput,
> = { authority: TAccountAuthority; amount: bigint };
 
declare function getTransferInstruction<
    TAccountAuthority extends InstructionAccountInput | InstructionSignerInput,
>(
    input: TransferInput<TAccountAuthority>,
): TransferInstruction<
    ResolvedInstructionAccountMeta<
        TAccountAuthority,
        InstructionAccountInputAddress<TAccountAuthority>,
        ReadonlySignerAccount<InstructionAccountInputAddress<TAccountAuthority>> &
            AccountSignerMeta<InstructionAccountInputAddress<TAccountAuthority>>
    >
>;

Alternatively, instruction builders may capture the caller's whole input in a single TInput type parameter and index into it — at the cost of excess property checks, since the input is then inferred as TInput itself.

declare function getTransferInstruction<TInput extends TransferInput>(
    input: TInput,
): TransferInstruction<
    ResolvedInstructionAccountMeta<
        TInput['authority'],
        InstructionAccountInputAddress<TInput['authority']>,
        ReadonlySignerAccount<InstructionAccountInputAddress<TInput['authority']>> &
            AccountSignerMeta<InstructionAccountInputAddress<TInput['authority']>>
    >
>;

See

• getAccountMetaFactory
• InstructionAccountInputAddress