会漏掉什么？

pancake V3 是 fork 的 Uniswap V3 么？

Uniswap V3 貌似只能在链下计算。

我看了你的代码， 有些是 V2 有些是V3 ，V2 和 V3 有不同的池子， 不能一起用。

transferFrom 错误， 要么没有持有人足够的币（检查 balanceOf）， 要么没有授权对。

你是授权给 router02 合约么(检查 allowance )？

签名问题 基本上没法 debug 。

只有自己一点点检查， 需要每一个字符匹配上。

用其他语言试试也可以。

用 chaintool 工具， 提供解码功能： https://chaintool.tech/calldata

如果在其他网络可以， 在以太坊上不行， 大概率是依赖地址不对。

另外不同的链上的Token的 decimals 也可能不同。

remix 出问题的可能性太小了， 你可以用hardhat试试。

貌似还没有。

这个专栏有挺多关于gas 优化的文章： https://learnblockchain.cn/column/1

通常在前端会对比池子的流动性，哪个池子可以获得更多的兑换代币，就选哪一个。

这个是英文 init_code_hash 没有匹配。

在 UniswapV2Factory 添加一句代码获取 init_code_hash：

bytes32 public constant INIT_CODE_PAIR_HASH = keccak256(abi.encodePacked(type(UniswapV2Pair).creationCode));

然后把获取的 code hash 替换掉 router 合约里面的 code hash.

Type0 交易 给的gasprice 在扣除 base fee 的部分后，全部作为小费。

这里有一些岗位： https://learnblockchain.cn/jobs

如果是 Web 程序， 应该是在前端签名的。

opensea 有 SDK 可以挂单。

个人理解： 这个其实和区块链没什么关系，只要设备可以连网，你就可以上传数据。和用 HTTP 上传数据没多大区别。

写一个定制程序来上传数据即可。

只要有独立的 公网IP，是可以的。

当你通过合约 A 与 合约 B 交互时， 在 合约 B 的交易列表里（Transactions）本来就看不到这个交易记录的。

就是在 utxo 脚本上面

通常脚本是直接与合约交互而不是在etherscan上操作。

如果要做控制，通常的方案是：前端请求后端获取一个签名，前端拿到签名后传给合约，合约检查是否是指定项目方的签名， 如果是才可以 mint

使用的是 gnosis safe？

有 API 可以直接用

具体问题是什么？

与是否开源无关。 你还是可以调用合约方法，获取交易收据里面的事件。