Add a function to extract the lifetime from a CompiledTransactionMessage#918
Merged
Conversation
🦋 Changeset detectedLatest commit: 7171940 The changes in this PR will be included in the next version bump. This PR includes changesets to release 41 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
Member
Author
BundleMonFiles updated (7)
Unchanged files (123)
Total files change +1.74KB +0.49% Final result: ✅ View report in BundleMon website ➡️ |
mcintyre94
force-pushed
the
transaction-lifetime-construct
branch
from
9e66c0e to
8052f35
Compare
Contributor
|
Documentation Preview: https://kit-docs-2uqvfagu1-anza-tech.vercel.app |
mcintyre94
force-pushed
the
transaction-lifetime-construct
branch
2 times, most recently
from
7f36bdf to
a44d7a9
Compare
Contributor
steveluscher
left a comment
steveluscher
left a comment
There was a problem hiding this comment.
I don't have answers, only questions. Should we take the same approach as with transaction confirmation and split these into one function for blockhash based transactions and one for nonce transactions, presuming that the applications knows which one it prepared, rather than to make one function that autodetects the type of lifetime? I presume the answer is no, because in the next PR it's presumed that the wallet-account-transaction-signer is a TransactionModifyingSigner, meaning that just because the transaction went in with a blockhash-based lifetime doesn't mean it's going to come out with one.
steveluscher
approved these changes
Sep 30, 2025
mcintyre94
force-pushed
the
transaction-lifetime-construct
branch
from
abc3ad2 to
525e9ae
Compare
Closed
This was referenced Oct 1, 2025
mcintyre94
force-pushed
the
transaction-lifetime-construct
branch
from
525e9ae to
11136da
Compare
lorisleiva
approved these changes
Oct 1, 2025
Member
lorisleiva
left a comment
lorisleiva
left a comment
There was a problem hiding this comment.
Thank you for your work on that stack! I'm gradually making my way through your PRs.
mcintyre94
force-pushed
the
transaction-lifetime-construct
branch
from
11136da to
7171940
Compare
Member
Author
Merge activity
|
mcintyre94
added a commit
that referenced
this pull request
Oct 3, 2025
…nt for the updated transaction (#919) #### Problem Currently this signer only returns what is required for the signer interface, a `Transaction`. However, per #891 this interface needs to be changed to return a `Transaction & TransactionWithLifetime`, ie augmented with a `lifetimeConstraint` field. #### Summary of Changes The signer now returns a lifetime, by decoding the returned `messageBytes` and comparing the returned `lifetimeToken` with the existing lifetime of the input transaction. - If the input transaction does not have a lifetime, then we create one for the signed transaction using #918. Otherwise: - If the input transaction and signed transaction have identical message bytes, then we return the existing lifetime. Ie if the wallet returns the transaction unchanged. - If the message bytes differ, but the `lifetimeToken` of the signed transaction matches the existing lifetime (either blockhash or nonce field), then we return the existing lifetime. Ie if the wallet modifies the transaction but not its lifetime. - If the lifetime token of the signed transaction differs from that of the input transaction, then we create a new lifetime for the signed transaction using #918. This pre-emptively makes `useWalletAccountTransactionSigner` comply with a stricter interface for `TransactionModifyingSigner` that will require returning `Transaction & TransactionWithLifetime`.
This was referenced Oct 3, 2025
Merged
Closed
Contributor
|
Because there has been no activity on this PR for 14 days since it was merged, it has been automatically locked. Please open a new issue if it requires a follow up. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
When writing a signer, it is possible that you receive a Transaction from for example an external wallet, and need to determine its lifetime constraint.
Summary of Changes
This PR adds a new function
getTransactionLifetimeConstraintFromCompiledTransactionMessagewhich enables a best-effort extraction of the lifetime constraint from aCompiledTransactionMessage, ie without full information about the transaction.The check is less robust than the equivalent for a
TransactionMessage, because the accounts passed to an advance nonce instruction may be in lookup tables - and therefore we can't verify their address or role. However, we are able to check the program address, program data and number of accounts passed in. A transaction that incorrectly passes this check is one that passes incorrect accounts to the advance nonce instruction. The impact of attempting to confirm it with an incorrect lifetime should be minimal (it will fail to land regardless).There is one error case I've added - if the first account passed to the instruction is not a static address, then we can't use its address in the returned
TransactionDurableNonceLifetimeand we throw. I think this is an edge case and not worth the cost of resolving lookup tables.This function will be used to enable
useWalletAccountTransactionSignerto return a lifetime in cases where the wallet modifies the lifetime token of the input transaction. I think it will also be useful to anybody else writing similar signers.