@psklf #4 每个地址首次使用 pumpfun （或者 pump amm ）会支付 0.001SOL 的租金，用于储存地址在 pump 上的交易量，目前没有退租机制
每个地址首次购买某个代币有约 0.002SOL 的租金，卖完了可以退
你看到 0.01SOL 估计是你优先费给太高了

Jupiter 的价格大概率不会比 PumpSwap 差，因为支持更多路由，Jupiter 也不额外收手续费。

不过由于 Jupiter 合约默认固定换入的 token 数量，滑点决定换出的 token 数量下限；
但 PumpAmm 合约写的是固定换出 token 数量，滑点决定换入 token 数量的上限。

这个可能就导致 Jupiter 算路由的时候有点不准确？

如果你实际兑换一下会发现结果类似于
Pump: 1SOL - 48,729.296352 v2ex
Jupiter: 0.99993SOL - 48,725.778901 v2ex

Jupiter 虽然换出来的结果少了一点点，但 SOL 也会少花一点点，其实没差别。

@081 #7 不用担心 sol 解锁的问题，现在 V2EX 和 稳定币的池子已经被抽干了 https://i.imgur.com/io2SM1h.png
而且我看这个网站 https://solana.messari.io/token-unlocks ，SOL 已经解锁 99.8% 了，后续的一个季度也就 4 万 SOL ，远不到 500 万

在 solscan 上看看 $v2ex 各个池子的交易量吧，现在 $pump 对 $v2ex 的价格影响不能说微乎其微，只能说完全没有
虽然你看着 v2ex-pump 池子里 $v2ex 的数量占比不小，实际上因为 $v2ex 最近暴跌，里面的 $pump 都已经被换空了

可以直接填 ALL 的，不用这么麻烦 https://i.imgur.com/Iy0taMy.png
USAGE:
solana transfer [FLAGS] [OPTIONS] <RECIPIENT_ADDRESS> <AMOUNT>
ARGS:
<AMOUNT> The amount to send, in SOL; accepts keyword ALL

如果不走站内打赏，大批量空投建议走 https://airship.helius.dev/
这个需要用户自己去领取空投（支付一点点 gas ，并且自己支付 ATA 的租金），发起空投的不用给接受者付那 0.002 sol 的租金。

@Livid solana 链以申请的 compute unit 来计算 gas 和决定交易优先级，和实际消耗的没有关系。

站长，这 SetComputeUnitLimit 的数量不对啊。设置成 10000 就已经很够了，现在是 600000 还是浪费了很多。

@JoeJoeJoe 其实就算 $v2ex 交易频繁，由于所有的交易（打赏操作，交易 swap 操作）都只获取代币的账户的读锁，相当于打赏操作和愿意给更高 gas 费的交易 swap 操作并没有竞争关系，所以理论上来说 $v2ex 交易是否频繁对打赏交易的速度没有什么影响。

试了下现在的 $v2ex 打赏操作还是没有调用 SetComputeUnitLimit 指令，站长方便加上吗。
加上这条指令后，若保持设置的 Compute Unit Price 不变，总的 gas 费能省不少；若想给相同的 gas 费，平摊下来的 Compute Unit Price 也能提高不少，能够增加验证者处理打赏操作的意愿。
详见 https://v2ex.com/t/1152743#r_16632641

@Cedric341561 #14 设置 cu price 这个指令消耗固定 150 的 cu ，打错了 https://i.imgur.com/Iy0taMy.png

https://solscan.io/tx/29K1qkR9U3v636KyBDyQ8Z49M4HZaJeaMgeLJbugQjffqD6EeYxnW2FhbN4FAkAhdVtUQRNr84EB3pEFJuHvVtfK
以这个打赏 $v2ex 的交易为例，有 4 条指令（设置 cu price ； Token Program 转账；和两条 Phantom 插件生成的断言指令）。

如果不设置 cu limit ，对于 builtin instruction （如设置 cu price/ 设置 cu limit / SOL 转账），默认是 3000 ；
对于非 builtin instruction （如 Token 转账，Phantom 插件生成的断言）默认是 200000.

所以上述交易默认是 3000 + 200000 + 200000 + 200000 = 603000 的 cu 上限。
计算下交易的优先费是 603000 (cu) x 5000 (micro lamports/cu) = 3015 lamports ，和 solscan 上的一致。

但是实际上真正消耗的有用的 cu 只有设置 cu price （固定的 300 ），Token 转账（ 4644 ），总共 4944 ，浪费了超过 100 倍。

建议在提交之前，先用 simulateTransaction 算一下要消耗多少 cu ，然后设置 cu limit ，这样就可以给较高的 cu price 了。

@Cedric341561 #8 诶，不对。构造的交易里应该全是 builtin instruction ，理论上不设置 cu limit 是没问题的。但是 phantom 插件自动给签名的交易加一个 lighthouse 的断言指令，这不是 builtin instruction ，导致增加了额外的 200000 cu limit.

另外现在 websocket 订阅交易状态用的 commitment 是 finalized ，这个需要等 32 个 block 。按平均 0.4s 一个 block 算，就要约 13s 了。其实用 confirmed 也就够了

可以给 txn 加一个 cu limit ，不加默认是 200000 ，但打赏远用不了这么多。这样就可以在保持总优先费不变的情况下给到更高的 cu price

支持一下