github-starred/better-auth
2
0
Fork 0
mirror of https://github.com/better-auth/better-auth.git synced 2026-05-22 22:32:01 -05:00
Code Issues 2.5k Packages Projects Releases 112 Wiki Activity

[GH-ISSUE #6738] SIWX #27931

New Issue
Open
opened 2026-04-17 19:13:14 -05:00 by GiteaMirror · 6 comments
GiteaMirror commented 2026-04-17 19:13:14 -05:00
Owner
Copy Link

Originally created by @coopbri on GitHub (Dec 13, 2025).
Original GitHub issue: https://github.com/better-auth/better-auth/issues/6738

Is this suited for github?

  • Yes, this is suited for github

Is your feature request related to a problem? Please describe.

As @reslear mentioned here, the BA official SIWE plugin should evolve into SIWX to be more chain-agnostic.

I would be happy to work on this. Do we want to evolve SIWE -> SIWX, or support both? I think the former is better, but breaking for the community. Personally I'm a "break it anyway" kind of person but the point of this is issue is RFC.

Describe the solution you'd like

Better Auth currently has a SIWE plugin. This works well for EVM chains, but there is a more agnostic standard that can be used instead: SIWX, which implements CAIP-122. That would allow cross-chain authentication with a unified API, e.g. for EVM chains and Solana.

Additional context

There is ongoing SIWS plugin work at https://github.com/better-auth/better-auth/issues/3495#issuecomment-3412201618, but it hasn't been updated in 2 months and I think a better solution is to strictly support SIWX (unless anyone knows limitations I don't: reasons for BA to support more than just an official SIWX plugin).

Originally created by @coopbri on GitHub (Dec 13, 2025). Original GitHub issue: https://github.com/better-auth/better-auth/issues/6738 ### Is this suited for github? - [x] Yes, this is suited for github ### Is your feature request related to a problem? Please describe. As @reslear mentioned [here](https://github.com/better-auth/better-auth/issues/3495#issuecomment-3412201618), the BA official SIWE plugin should evolve into SIWX to be more chain-agnostic. I would be happy to work on this. Do we want to evolve SIWE -> SIWX, or support both? I think the former is better, but breaking for the community. Personally I'm a "break it anyway" kind of person but the point of this is issue is RFC. ### Describe the solution you'd like Better Auth currently has a SIWE plugin. This works well for EVM chains, but there is a more agnostic standard that can be used instead: [SIWX](https://docs.reown.com/appkit/vue/core/siwx), which implements [CAIP-122](https://github.com/ChainAgnostic/CAIPs/blob/main/CAIPs/caip-122.md). That would allow cross-chain authentication with a unified API, e.g. for EVM chains and Solana. ### Additional context There is ongoing SIWS plugin work at https://github.com/better-auth/better-auth/issues/3495#issuecomment-3412201618, but it hasn't been updated in 2 months and I think a better solution is to strictly support SIWX (unless anyone knows limitations I don't: reasons for BA to support more than just an official SIWX plugin).
GiteaMirror added the credentials label 2026-04-17 19:13:14 -05:00
GiteaMirror commented 2026-04-17 19:13:16 -05:00
Author
Owner
Copy Link

@Re4GD commented on GitHub (Dec 14, 2025):

Siwx is definitely needed as an official plugin to support all crypto sign ins. I derived a siwx plugin from the siws plugin few months ago and I have been using it since in production. I have ironed out most issues and even finished the customizable native mobile deeplink callback API that I have talked about in siws (did not update siws). I did not adhere to caip122 though, I was not aware of it, it is nice that you mention it and I will definitely take a look and modify existing code.

I mostly use eth and sol, and it is working very well currently. Other chains I did not try as I don't use them but they should work in theory. It would be nice to talk about edge cases and other chains behavior's in this thread.

In my opinion we should not evolve siwe to siwx, as I mentioned in the siws thread, I am really not happy with siwe plugin modifying User table with the address column. The provider specific fields should live in the Accounts table. As a side note, before I did siwx, I needed siwe so I copied all the siwe source code and stripped it from this behavior (I really did not like this design choice). And also, siwx plugin is mostly exposing functions that the user will fill and the plugin will execute in order. So I don't see a way we can change siwe to siwx without breaking everything, they are not similar.

Current siwx plugin includes my business logic, I can post the code snippets here when I strip from that

<!-- gh-comment-id:3650507639 --> @Re4GD commented on GitHub (Dec 14, 2025): Siwx is definitely needed as an official plugin to support all crypto sign ins. I derived a siwx plugin from the siws plugin few months ago and I have been using it since in production. I have ironed out most issues and even finished the customizable native mobile deeplink callback API that I have talked about in siws (did not update siws). I did not adhere to caip122 though, I was not aware of it, it is nice that you mention it and I will definitely take a look and modify existing code. I mostly use eth and sol, and it is working very well currently. Other chains I did not try as I don't use them but they should work in theory. It would be nice to talk about edge cases and other chains behavior's in this thread. In my opinion we should not evolve siwe to siwx, as I mentioned in the siws thread, I am really not happy with siwe plugin modifying User table with the address column. The provider specific fields should live in the Accounts table. As a side note, before I did siwx, I needed siwe so I copied all the siwe source code and stripped it from this behavior (I really did not like this design choice). And also, siwx plugin is mostly exposing functions that the user will fill and the plugin will execute in order. So I don't see a way we can change siwe to siwx without breaking everything, they are not similar. Current siwx plugin includes my business logic, I can post the code snippets here when I strip from that
GiteaMirror commented 2026-04-17 19:13:16 -05:00
Author
Owner
Copy Link

@coopbri commented on GitHub (Dec 14, 2025):

Thanks @Re4GD for your thoughts and for your breakdown, I was unaware of the full scope of your work!

I agree, I was wondering what the purpose of the database DDL was in SIWE plugin. I like your architecture in SIWS better, however there is one case I'm unsure of which is 1 BA account, multiple wallets. It seems the SIWE plugin having a dedicated wallet_address table solves this case, and the alternative does not. There may be account linking possibility that I'm unaware of. What are your thoughts on this?

With evolving SIWE to SIWX plugin, I was including any deeper changes thereof (such as removing the schema changes). In other words, I was imagining the SIWE plugin wouldn't just turn into SIWX, we could rewrite it entirely to be more aligned with your more stateless vision in SIWS. Hence "break it anyway". If you still think they should both be maintained and separate, let me know. Ultimately up to the BA core team anyways. I'm someone that doesn't worry about breaking things between versions, which a lot of devs aren't like, I respect.

Personally, I don't use non-EVM chains myself, only EVM+Solana. Perhaps others can weigh in on these.

With all of this said, since you have a working SIWX plugin, I would love to help on it if any help is needed if you could submit a PR! I am using SIWE + SIWS plugins in production and would prefer to bridge them under one roof.

<!-- gh-comment-id:3651990570 --> @coopbri commented on GitHub (Dec 14, 2025): Thanks @Re4GD for your thoughts and for your breakdown, I was unaware of the full scope of your work! I agree, I was wondering what the purpose of the database DDL was in SIWE plugin. I like your architecture in SIWS better, however there is one case I'm unsure of which is 1 BA account, multiple wallets. It seems the SIWE plugin having a dedicated `wallet_address` table solves this case, and the alternative does not. There may be account linking possibility that I'm unaware of. What are your thoughts on this? With evolving SIWE to SIWX plugin, I was including any deeper changes thereof (such as removing the schema changes). In other words, I was imagining the SIWE plugin wouldn't just turn into SIWX, we could rewrite it entirely to be more aligned with your more stateless vision in SIWS. Hence "break it anyway". If you still think they should both be maintained and separate, let me know. Ultimately up to the BA core team anyways. I'm someone that doesn't worry about breaking things between versions, which a lot of devs aren't like, I respect. Personally, I don't use non-EVM chains myself, only EVM+Solana. Perhaps others can weigh in on these. With all of this said, since you have a working SIWX plugin, I would love to help on it if any help is needed if you could submit a PR! I am using SIWE + SIWS plugins in production and would prefer to bridge them under one roof.
GiteaMirror commented 2026-04-17 19:13:17 -05:00
Author
Owner
Copy Link

@Re4GD commented on GitHub (Dec 14, 2025):

As far as I know there is no explicit link endpoint in siwe, but it is easy to implement. Just copy the source code of the plugin and add a link endpoint yourself. Session middleware + link account call does the trick. The linking works like that in general, you call the link endpoint when already signed in (some plugins don't implement linking out of the box. I was working on the telegram plugin and someone pointed that out to me also).

By adding wallet_address to User table it does not solve the issue of multiple wallets, and imo there is no issue about 1 account multiple wallets. In my current setup when a user signs up with a sol wallet for example, an email with siws-{random id}@myapp.com is generated. This also creates an Account row which the providerId = siws:SoLAd...dress with referenced userId. Then when I am already logged in, I link with my eth wallet, creating a new Account row, providerId = siwe:1:0xabc...def. Now I have 1 user with 2 accounts. It is essentially same as having one User + credentials account + google account, nothing new. When I try to log in with either sol or eth wallet, as I would know the providerId in advance (as it is deterministic), I check against db and if that account exists, fetch the user, then log in (the difference from credentials or social is, I go from account -> user, not email search and find user). Eventually all providerIds will become siwx:{chain}:{chainId}:{publicKey}, but you get the idea.

If you were talking about a primary wallet use case, then it is a different story, but I am sure it would be possible without adding a new field to core tables (and maybe the primary wallet feature is not needed at all, it is a weird feature imo) (modifying the providerId from siws:address to siws:address:primary). But of course, adding an isPrimary field to Account table would also be an obvious solution without cluttering the User table.

I mean it is up to them of course, and BA team officially supporting these plugins would be ideal, but does not really make a difference at this point. Plugin system is very nice to work with and copying 2-3 files to every project takes no time.

I will tag you for sure when I strip business logic and post the code snippets here

<!-- gh-comment-id:3652126762 --> @Re4GD commented on GitHub (Dec 14, 2025): As far as I know there is no explicit `link` endpoint in siwe, but it is easy to implement. Just copy the source code of the plugin and add a link endpoint yourself. Session middleware + link account call does the trick. The linking works like that in general, you call the link endpoint when already signed in (some plugins don't implement linking out of the box. I was working on the telegram plugin and someone pointed that out to me also). By adding `wallet_address` to User table it does not solve the issue of multiple wallets, and imo there is no issue about 1 account multiple wallets. In my current setup when a user signs up with a sol wallet for example, an email with `siws-{random id}@myapp.com` is generated. This also creates an Account row which the `providerId = siws:SoLAd...dress` with referenced `userId`. Then when I am already logged in, I link with my eth wallet, creating a new Account row, `providerId = siwe:1:0xabc...def`. Now I have 1 user with 2 accounts. It is essentially same as having one User + credentials account + google account, nothing new. When I try to log in with either sol or eth wallet, as I would know the `providerId` in advance (as it is deterministic), I check against db and if that account exists, fetch the user, then log in (the difference from credentials or social is, I go from account -> user, not email search and find user). Eventually all providerIds will become `siwx:{chain}:{chainId}:{publicKey}`, but you get the idea. If you were talking about a primary wallet use case, then it is a different story, but I am sure it would be possible without adding a new field to core tables (and maybe the primary wallet feature is not needed at all, it is a weird feature imo) (modifying the `providerId` from `siws:address` to `siws:address:primary`). But of course, adding an `isPrimary` field to Account table would also be an obvious solution without cluttering the User table. I mean it is up to them of course, and BA team officially supporting these plugins would be ideal, but does not really make a difference at this point. Plugin system is very nice to work with and copying 2-3 files to every project takes no time. I will tag you for sure when I strip business logic and post the code snippets here
GiteaMirror commented 2026-04-17 19:13:17 -05:00
Author
Owner
Copy Link

@coopbri commented on GitHub (Dec 15, 2025):

Good point re schema, makes sense. I definitely prefer your architecture anyways, I think it's more scalable. The less core DB migrations, the better(-auth) :)

<!-- gh-comment-id:3652573028 --> @coopbri commented on GitHub (Dec 15, 2025): Good point re schema, makes sense. I definitely prefer your architecture anyways, I think it's more scalable. The less core DB migrations, the better(-auth) :)
GiteaMirror commented 2026-04-17 19:13:17 -05:00
Author
Owner
Copy Link

@dosubot[bot] commented on GitHub (Mar 16, 2026):

Hi, @coopbri. I'm Dosu, and I'm helping the better-auth team manage their backlog and am marking this issue as stale.

Issue Summary:

  • You proposed evolving the Better Auth SIWE plugin into a chain-agnostic SIWX plugin supporting cross-chain authentication via CAIP-122.
  • @Re4GD shared an alternative SIWX plugin design that avoids modifying the User table and supports multiple wallets per account.
  • There are differing opinions on whether to evolve SIWE into SIWX or maintain separate approaches due to architectural differences.
  • You expressed openness to rewriting SIWE into a more stateless SIWX and invited collaboration and PRs.
  • The discussion remains unresolved, highlighting the need for official support and community input on cross-chain auth plugin development.

Next Steps:

  • Please let me know if this issue is still relevant to the latest version of the better-auth repository by commenting here to keep the discussion open.
  • Otherwise, this issue will be automatically closed in 7 days.

Thanks for your understanding and contribution!

<!-- gh-comment-id:4068841145 --> @dosubot[bot] commented on GitHub (Mar 16, 2026): Hi, @coopbri. I'm [Dosu](https://dosu.dev), and I'm helping the better-auth team manage their backlog and am marking this issue as stale. **Issue Summary:** - You proposed evolving the Better Auth SIWE plugin into a chain-agnostic SIWX plugin supporting cross-chain authentication via CAIP-122. - @Re4GD shared an alternative SIWX plugin design that avoids modifying the User table and supports multiple wallets per account. - There are differing opinions on whether to evolve SIWE into SIWX or maintain separate approaches due to architectural differences. - You expressed openness to rewriting SIWE into a more stateless SIWX and invited collaboration and PRs. - The discussion remains unresolved, highlighting the need for official support and community input on cross-chain auth plugin development. **Next Steps:** - Please let me know if this issue is still relevant to the latest version of the better-auth repository by commenting here to keep the discussion open. - Otherwise, this issue will be automatically closed in 7 days. Thanks for your understanding and contribution!
GiteaMirror commented 2026-04-17 19:13:18 -05:00
Author
Owner
Copy Link

@reslear commented on GitHub (Mar 16, 2026):

@dosubot not stale

<!-- gh-comment-id:4069200596 --> @reslear commented on GitHub (Mar 16, 2026): @dosubot not stale
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
adapter
astro
awaiting external contributor
blocked
breaking
breaking change
bug
c-devops
core
credentials
database
dependencies
devops
devtools
docs
documentation
duplicate
elysia
enhancement
enterprise
expo
express
fastify
good first issue
help wanted
hono
identity
infra
integration
invalid
javascript
locked
maintenance
need-more-information
needs: info
needs: repro
nextjs
nuxt
oauth
organization
P0
payments
perf
platform
plugin
pull-request
Mirrored from GitHub Pull Request
 question
ready
regression
remix
security
social-provider
solid
stale
svelte
tanstack-start
tracking
version-bump
vue
wontfix
No Label credentials
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/better-auth#27931
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?