Currently the default expiration for a Soroban signature (i.e. signature used to authorize SorobanAuthorizationEntry) is set to a maximum possible value (https://github.com/stellar/js-stellar-sdk/blob/e5e49dcde5b4333d4b0082abffb5d4cb1ff5cc1d/src/contract/assembled_transaction.ts#L651). That's both unnecessarily expensive and unnecessarily unsafe - currently the max entry expiration is ~6 months and it's not really a good practice to have such long-lived signatures by default. Instead, the default value should be set to a small, conservative, about 5-10 minutes in ledgers from the current ledger (e.g. current_ledger_seq + 100).
The users can customize the expiration if longer value is necessary. However, it would also be nicer to make the setting relative instead of being absolute, i.e. encapsulate the logic of getting current_ledger_seq inside the SDK instead of asking the users to do the math.
Currently the default expiration for a Soroban signature (i.e. signature used to authorize
SorobanAuthorizationEntry) is set to a maximum possible value (https://github.com/stellar/js-stellar-sdk/blob/e5e49dcde5b4333d4b0082abffb5d4cb1ff5cc1d/src/contract/assembled_transaction.ts#L651). That's both unnecessarily expensive and unnecessarily unsafe - currently the max entry expiration is ~6 months and it's not really a good practice to have such long-lived signatures by default. Instead, the default value should be set to a small, conservative, about 5-10 minutes in ledgers from the current ledger (e.g.current_ledger_seq + 100).The users can customize the expiration if longer value is necessary. However, it would also be nicer to make the setting relative instead of being absolute, i.e. encapsulate the logic of getting
current_ledger_seqinside the SDK instead of asking the users to do the math.