Repository navigation
Conversation
anxolin
marked this pull request as draft
October 31, 2026 20:34
`SOL` and `WSOL` resolved to Token-2022's native mint, which carries no liquidity, so the orders they produced could not be filled. Both now resolve to the legacy wrapped SOL mint. Wrapping was gated on the user typing "sol", so naming the token by mint address skipped it and created an order over an empty account that silently never filled. The gate is now what the token names: `SOL` or the native SOL marker wraps the shortfall, creating the account if needed, while `WSOL` or a mint address spends the balance already held and fails when it is short. The summary reports the sell mint and any wrapping.
anxolin
force-pushed
the
fix/native-sol-wrap
branch
from
October 31, 2026 22:58
a4a4ba2 to
22b43aa
Compare
anxolin
marked this pull request as ready for review
November 3, 2026 05:29
kaze-cow
requested changes
Nov 3, 2026
kaze-cow
left a comment
Contributor
There was a problem hiding this comment.
overall the changes seem a lot more verbose than actually necessary.
as the most simple solution, couldn't we just update the address of WSOL? example PR
Also, the native sol marker is not universally or low level recognized as 11111111111111111111111111111111, so it seems wierd to explicitly code for it in the test CLI. if we do want to do such a thing
Comment on lines
+243
to
+246
| /// Whether `token_str` names native SOL: the `SOL` symbol, or the marker the | ||
| /// wire uses for a native side ([`ENCODED_NATIVE_SOL_TRANSFER`], the system | ||
| /// program). `WSOL` and the wrapped mint's address are the wrapped token, not | ||
| /// this. |
Contributor
There was a problem hiding this comment.
too verbose
also I think this function should be named is_native_sol for clarity that this is effectively a yes/no check. Also, I believe we have an applicable function
Contributor
Author
|
Closing in favour of #216 |
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 join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
What
SOLandWSOLresolved to Token-2022's native mint (9pan9bMn…) rather thanSo111…112. Nothing quotes that mint, so every order selling SOL was unfillable. Both symbols now resolve to the legacy wrapped SOL mint.Wrapping was also gated on the user typing the literal string
sol, so naming the sell token by mint address — the only workaround for the above — skipped the wrap, and the CLI never creates the sell-side account either. That produced a successful transaction and an order over an empty account, which just never filled.The gate is now what the token names:
SOL, or11111111111111111111111111111111WSOL, or a mint addressThe native SOL marker is accepted as a sell token because lamports have no mint on the wire — the sell side can only carry them wrapped, so the CLI does the conversion and reports it. The summary now prints
sellMint, pluswrappedLamportswhen it wrapped.Test plan
I run the following: