Deduct ATA creation cost from client fee when payment address ATA is missing

[dev-jodee]

When a Kora node operator's payment address does not have an ATA for an accepted fee token (e.g., USDC), the client currently cannot safely use createAssociatedTokenIdempotent because the ATA creation cost would be borne entirely by the client.

Proposal: If the payment address ATA does not exist at transaction time, Kora should:

Allow the client to include a createAssociatedTokenIdempotent instruction for the destination ATA

Deduct the ATA creation rent cost from the client's fee payment amount

This makes createAssociatedTokenIdempotent safe to use in the SDK's paymaster flow without unfairly charging the client for the operator's missing ATA. The operator is still responsible for maintaining ATAs via kora rpc initialize-atas, but this provides a graceful fallback.

• This should be a config the node operator can decide to enable or disable

Acceptance criteria:

Kora detects when the payment address ATA does not exist for the fee token

ATA creation rent cost is subtracted from the client's fee amount

Existing flow (ATA already exists) is unaffected

SDK can safely use createAssociatedTokenIdempotent without extra client cost

[raushan728]

Implementation Plan

Planning to implement this in a single PR with the following changes:

Files to modify:

config.rs — Add dynamic_ata_deduction: bool to ValidationConfig with #[serde(default)]

constant.rs — Add NEW_ACCOUNT_INDEX = 1 and update REQUIRED_NUMBER_OF_ACCOUNTS = 2
in system_create_account module

instruction_util.rs — Add new_account: Pubkey to SystemCreateAccount variant,
extract from account index 1 during parsing

fee/fee.rs — In calculate_fee_payer_outflow, skip adding lamports to outflow when
new_account == expected_payment_ata and flag is enabled

token/token.rs — In find_payment_in_transaction, parse system instructions and credit
ATA rent toward total_lamport_value when flag is enabled

One concern: find_payment_in_transaction does not currently have access to parsed
system instructions — will need to parse them inline or restructure. Open to suggestions
on preferred approach.

@dev-jodee happy to adjust based on feedback before starting.

[dev-jodee]

I think it makes sense, as for the concern, find_payment_in_transaction received VersionedTransactionResolved, which has access to the parsed instructions, so I think it would work for that?