feat(buy-sol) PR 3: let native SOL buys into the auction - #4989
Merged
squadgazzz merged 22 commits intoSep 30, 2026
Merged
squadgazzz merged 22 commits into
squadgazzz merged 22 commits into
Conversation
…issing-buy-token-accounts-for-solvers
…issing-buy-token-accounts-for-solvers
squadgazzz
marked this pull request as ready for review
September 29, 2026 11:06
Contributor
|
Claude finished @squadgazzz's task in 3m 18s —— View job Review
I reviewed the diff against What I verified:
Minor observations (non-blocking, no change required):
|
Every order the branch would keep costs the winning solver's keypair the rent for an account its owner can close right after the fill, and no engine prices that rent in yet. The expression stays next to the TODO so turning it on is one edit.
"Only the owner's ATA can be created" is a domain rule, but it sat in the blockchain adapter, which had to pull in `domain::Order` to apply it. The adapter is back to handing out classified account states only.
Reinstates the filter 47b4494 removed. The autopilot's cut drops these orders too, but it fails open when its own lookup fails, and then one such order takes down the whole settlement it lands in.
The flag is a per-solve annotation, so carrying it on the domain order forced every constructor and test fixture to set it. The resolution now returns the uids and the DTO builder looks them up.
Every solver engine this driver hosts receives the same auction, so each of them paid for its own getMultipleAccounts round trip in front of the engine call. One shared slot now serves them all, and the engines that arrive while the lookup is in flight wait for its result.
The paragraph on ResolvedSettlement was the only place describing the whole instruction order; it comes back with the buy ATAs among the setup accounts. The DTO TODOs now point at setupCostLamports, which keeps the rent math out of the engines, and the openapi says what happens to an order whose destination cannot be created.
This is the one place the solver keypair pays rent for someone else, and the owner can close the account for the lamports right after the fill, so the cost needs to be countable.
…token-accounts-for-solvers' into solana-autopilot/be-331-let-native-sol-buys-into-the-auction # Conflicts: # crates/autopilot-svm/src/infra/provider.rs
tilacog
approved these changes
Sep 29, 2026
Comment on lines
+297
to
+304
| fn payable_orders(orders: Vec<Order>) -> Vec<Order> { | ||
| // TODO: use the cluster's rent, refreshed periodically. The SDK default is | ||
| // above it since SIMD-0437, so this floor also drops small payouts that | ||
| // would settle. | ||
| let min_payout = Rent::default().minimum_balance(0); | ||
| orders | ||
| .into_iter() | ||
| .filter(|order| { |
Contributor
There was a problem hiding this comment.
nit: since this fn owns the vec, I sussegt using Vec::retain instead of filter + collect(), which creates a second vector.
Base automatically changed from
tiago/be-305-detect-missing-buy-token-accounts-for-solvers
to
main
September 30, 2026 15:50
…31-let-native-sol-buys-into-the-auction
squadgazzz
enabled auto-merge
September 30, 2026 17:51
squadgazzz
deleted the
solana-autopilot/be-331-let-native-sol-buys-into-the-auction
branch
September 30, 2026 18:11
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.
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.
Description
A native SOL buy puts the System Program ID where the buy mint goes, and its buy account is a plain wallet. The autopilot looks for a token account of the buy mint there, so it drops every native buy. It also has no price for them. #4986 lets the driver settle these orders, so this PR lets on-chain ones into the auction. Sponsored native buys still need the orderbook side in BE-332.
A few have to stay out, since a failed payout reverts the whole batch. The rent-exempt minimum for an account with no data is 890,880 lamports, and a smaller payout into an empty wallet fails. A small partial fill can hit the same limit, so partially fillable native buys stay out for now. A wSOL sell for native SOL would reach solvers as wSOL for wSOL, and EVM rejects the WETH to ETH case the same way.
Winner selection doesn't let two winners settle the same token pair, and on EVM it counts ETH as WETH for this check. Solana had no such mapping. Staging runs with 20 winners, so a native buy and a wSOL buy could both win and settle the same pair at different prices.
Merges after #4986. Stacked on #4982.
Changes
unpayable_native_buyscounter tracks themcanonical_tokenmaps native SOL to wSOL for the winner pair checkHow to test
New unit tests.
Related issues
BE-331