Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

addSignersToTransactionMessage should upgrade feePayer to a signer #82

Closed
steveluscher opened this issue Jan 29, 2025 · 2 comments · Fixed by #151
Closed

addSignersToTransactionMessage should upgrade feePayer to a signer #82

steveluscher opened this issue Jan 29, 2025 · 2 comments · Fixed by #151
Assignees
Labels
enhancement New feature or request

Comments

@steveluscher
Copy link
Collaborator

Motivation

Imagine a transaction message with a non-signer fee payer, having address 'abc'. Imagine a signer also having address 'abc'.

If you call addSignersToTransactionMessage() on that message, it should notice that the fee payer address matches the signer address, and should ‘upgrade’ the feePayer to a signer.

Example use case

const message = pipe(
      createTransactionMessage({ version: 0 }),
      m => setTransactionMessageFeePayer(signer.address, m), // non-signer version of this function
      m => addSignersToTransactionMessage([signer], m),
);
message.feePayer satisfies TransactionSigner<'abc'>;
@lorisleiva
Copy link
Member

Thanks! I'll tackle this as soon as I can.

lorisleiva added a commit that referenced this issue Feb 27, 2025

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature.
…sage` (#151)

This PR upgrades the `feePayer` attribute of a transaction message if and only if:
- The current `feePayer` attribute is set.
- The current `feePayer` attribute is not already a signer (i.e. address only).
- The current `feePayer` address matches one of the provided signers.

Note that the `addSignersToTransactionMessage` does not narrow the returned transaction message with a `ITransactionMessageWithFeePayerSigner` because this may or may not happen based on the provided signers. If desired, we could iterate over the explicit `TransactionSigner<TAddress>` array to figure out at compile time if we need to return a `ITransactionMessageWithFeePayerSigner` type. This felt like an overkill and over-complication of the types to me but happy to disagree and commit.

Fixes #82
Copy link
Contributor

github-actions bot commented Mar 7, 2025

Because there has been no activity on this issue for 7 days since it was closed, it has been automatically locked. Please open a new issue if it requires a follow up.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Mar 7, 2025
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants