Skip to content

Conversation

@pkxro
Copy link
Collaborator

@pkxro pkxro commented Oct 18, 2025

  • gill compatible version of solana pay
  • new package as to not break the existing web3js implementation
  • 1:1 compatible with web3js solana pay
  • includes same tests

Copy link

@ellipsis-dev ellipsis-dev bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Important

Looks good to me! 👍

Reviewed everything up to ecbc920 in 42 seconds. Click for details.
  • Reviewed 1593 lines of code in 19 files
  • Skipped 2 files when reviewing.
  • Skipped posting 4 draft comments. View those below.
  • Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.
1. corev2/create-sol-transfer.ts:11
  • Draft comment:
    Unused import: 'getTransferSolInstruction' is imported but not used. Remove it if unnecessary.
  • Reason this comment was not posted:
    Comment was not on a location in the diff, so it can't be submitted as a review comment.
2. corev2/create-spl-transfer.ts:66
  • Draft comment:
    Remove commented-out code blocks to keep the file clean and maintainable.
  • Reason this comment was not posted:
    Comment was not on a location in the diff, so it can't be submitted as a review comment.
3. corev2/parse-url.ts:64
  • Draft comment:
    Consider using the SOL_DECIMALS constant instead of hardcoding '9' for decimals validation.
  • Reason this comment was not posted:
    Comment was not on a location in the diff, so it can't be submitted as a review comment.
4. corev2/fetch-transaction.ts:19
  • Draft comment:
    Double casting with 'as unknown as Transaction' indicates a type mismatch. Consider refining the types or handling the conversion more explicitly.
  • Reason this comment was not posted:
    Comment was not on a location in the diff, so it can't be submitted as a review comment.

Workflow ID: wflow_yM4WL3Ty1F8Teu4X

You can customize Ellipsis by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.

@pkxro pkxro requested a review from gitteri October 21, 2025 08:42
Copy link
Collaborator

@gitteri gitteri left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you add something to the readme about this addition? there are no docs for this right now.

Comment on lines +8 to +10
export const MEMO_PROGRAM_ID = address('MemoSq4gqABAXKb96qnH8TysNcWxMyWCqXgDLGmfcHr');

export const TOKEN_PROGRAM_ID = address('TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA');
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These don't seem to be used (memo / token program ids)

const recipientAddress = address(recipient);

return [
getTransferInstruction({
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

doesn't look like this works with memos even though they're allowed to be passed in. can you add the memo instruction

Comment on lines +83 to +98
// const recipientATAInfo = await rpc.getAccountInfo(recipientATA).send();
// if (!recipientATAInfo.value) {
// instructions.push(
// getCreateAssociatedTokenInstruction({
// mint: splTokenAddress,
// tokenProgram,
// owner: recipientAddress,
// ata: recipientATA,
// payer:
// })
// );
// } else {
// const recipientAccount = await fetchTokenAccount(rpc, recipientATA, { programAddress: tokenProgram });
// if (!recipientAccount.data.isInitialized) throw new CreateTransferError('recipient not initialized');
// if (recipientAccount.data.isFrozen) throw new CreateTransferError('recipient frozen');
// }
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should this be uncommented?

@mcintyre94
Copy link
Collaborator

As a general suggestion, I think it would make sense to use @solana/kit as your dependency instead of gill here. This would be less opinionated and reduce dependencies for apps that import @solana/pay and are not using gill but are using kit, either directly or through another higher-level library.

Looking at your imports, everything you import from gill is available from @solana/kit, ie you're not making use of any of the value add of gill AFAICT. Which I think makes sense for a library like this.

Where you import from @gill/programs you would import the same things from eg @solana-program/system and @solana-program/memo. Again you're just importing things that gill re-exports, and nothing it adds, so you should be able to just swap the dependencies.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants