Non-custodial Solana swaps via Jupiter. Smart Guard checks every swap before you sign and blocks drain vectors before any network fee.
0.50% transparent fee.
Trade passport.
Your wallet signs, always.
https://t.co/3NI8AJyFDH
#Solana#DeFi#Jupiter
Under the hood: blocks SetAuthority/Approve pre-sign
fixes the writable set so inner calls (CPI) can't reach your other accounts
blocks Token-2022 permanent delegate + transfer hook
simulates signed bytes: delegate/owner/close unchanged.
#Solana#DeFi#Jupiter#NVDA
You're right, and we changed the design accordingly - the decode is no longer the load-bearing control. The writable account set (static keys + the ALT writable band, read via message.isAccountWritable) is fixed at signing, and a CPI can neither add accounts nor promote a readonly account to writable, so it is a hard upper bound on everything inner calls can reach, including attacks with no pattern yet. We now fail-closed block (DRAIN_WRITABLE_ACCOUNT, before signing, no network fee) any SPL Token / Token-2022 account owned by the taker that is writable but outside the swap's {input, output, WSOL} ATAs, and the panel leads with the writable set, expanded, above the decoded min-out. Honest limit: this bounds reach, not intent - the input ATA must stay writable, so a malicious in-swap program could still approve against it within the bound; we shrink the blast radius to the trade's minimum, layered with the top-level drain blocklist, post-sign message equality, and min-out. Risk reduction, not a safety guarantee. Validated on 4 live Jupiter routes (metis/dflow/okx, up to 33 writable accounts): zero false positives.
Meet SpaceSwap.🫰
A Solana swap aggregator built on Jupiter. We find the route, and you sign the transaction in your own wallet—your funds never touch our servers.
Why we exist: to make swaps transparent, rather than a matter of "blind signing."
https://t.co/mq19GnoSvz
#solana #SolanaMemecoins #spaceswap
SpaceSwap — an exchange on Solana that verifies transactions both before and after signing.
It blocks instructions designed to drain tokens, displays the actual minimum amount you will receive, and detects unauthorized third-party access. Non-custodial. A single, transparent fee.
Not "100% security" - but risk mitigation backed by proof.
https://t.co/mq19GnoSvz
#solana #SolanaMemecoins #spaceswap
You're right on both counts, and the distinction matters enough to state plainly.
1/ "Refusing to send is not undoing." Correct. Once the wallet returns a signed message, those bytes are submittable by anyone holding them until the blockhash ages out — a minute or so, not zero. Our refusal stops our relay, not the artifact. We say "we don't relay it," not "we undo it."
The primary defense sits upstream of that: the drain patterns we detect (SetAuthority / Approve / ApproveChecked) are blocked before the wallet is ever asked to sign, so for those, no signed artifact exists at all. The post-signature diff is a second layer for wallets that modify after signing - and you're right that its refusal is a boundary on our involvement, not a revocation. The residual exposure is real and time-bounded by the blockhash.
2/ "It fixes the reference point." Also correct. Our diff anchors to SpaceSwap's audited intent, not to what the wallet displayed. We can't observe the wallet's UI, so a wallet that shows one thing and returns another is invisible to a byte diff - both sides of our comparison would still agree.
That's precisely why the pre-signature panel exists: it renders the authoritative facts - the minimum out decoded from the instruction, the writable accounts, the delegate - independently of the wallet, from the actual transaction. It gives the user a trusted reference to hold against whatever the wallet shows. The guarantee we can honestly make is "the bytes that leave match the bytes we audited," not "the bytes match what your wallet displayed." A lying wallet display is outside our detection; the panel narrows that gap, it doesn't close it.
3/ Delegate: agreed, and that's exactly where we put it — a read of the token account in the pre-sign view, not in the detector. It outlives the swap, so it has to be surfaced before signing, not after.
The honest framing: this is risk reduction, not a guarantee. Non-custodial means we can't revoke a signature we didn't produce, can't see a wallet's display, and can't stop someone signing elsewhere. What we can do is block the known drains before signing, refuse to relay what changed after, and show the user the real transaction in a form that doesn't depend on the wallet's honesty.
1/ Fair hit. Custody and legibility are different problems, and our line answered the first while implying the second. Non - custodial design says nothing about whether you can read what you're signing.
2/ We're a change detector, not a readability layer: we diff the wallet's returned message against the pre-signature audit - accounts, write rights, instruction order, programs - and refuse to send anything that moves funds differently. Catches substitution, not legibility.
3/ Of your three facts, delegate is the one we don't cover. A swap doesn't create one, but a delegate already on the token account outlives settlement, and non-custodial design does nothing about it. Decoded min-out and the writable list belong in the pre-sign view.
Not "safe forever."
But "lower risk of getting drained during a swap."
SpaceSwap fail-closed on Solana.
Blocks classic wallet-draining attacks
before you sign.
Your wallet.
Your keys.
https://t.co/3NI8AJy7O9
#Solana#SpaceSwap#Crypto#cryptocurrency#BTC