100%和10%，不是同一个数字 今天突然刷到一条帖子说flap硬抽10%的钱然后隐藏起来，看到之后深挖了一下， Flap官推说“100% of taxes are routed into the Vault”。合约写的是10%进feeReceiver。这两个数字不可能同时为真。当一个平台在最基本的资金流向问题上，官方说法和链上代码对不上的时候，用户该怎么相信其他承诺？ 100%和90%之间差了整整10个百分点——这不是笔误，不是翻译问题，是根本性的信息不对称。 @webhogwatrs @eth_cedric @irene_cc06 Web3常说“Don‘t trust, verify”，但当一个平台连“verify”所需的基本信息都不主动提供时，用户能verify什么？ #flap# #web3# #feeReceiver#

一个开发者，揭开了一件离谱的事 - Meme发射台生意的暗线 最近在陪跑一个 Agent + 税币的发射台项目，做竞调的时候把市场上几个主流 launchpad 的税费机制都研究了一遍。 看完之后有个感受：发射台这个生意，表面卷的是流量、资产和玩法，长期看卷的是费用结构。 🤖pumpfun内盘 Bonding Curve 每笔交易总费率 1.25%，其中 0.95% 给 Protocol，0.30% 给 Creator；毕业后，交易费按市值/池子规模动态下降，费率逐步降到 0.30%，Protocol fee 就是平台收入的重要来源。 👿Fourmeme分了两种模式：普通 token 和 Tax Token。Tax Token 允许 设置交易税率，税收进入项目方地址，平台本身不从中抽成。 的收入主要来自token 创建费、毕业费这类一次性收入，和交易税是两条线。 🟦Base 链上的几个发射台（Virtuals、Zora、banker）就有点乱了——有的收创建费、有的收交易手续费、有的抽毕业流动性，费率也不固定，没有统一标准。 这些平台模式不一样，但共同点是：协议费收入已经是发射台的重要收入来源，而且都是明码标价的。 然后就是 Flap🦋，这波税币发射台里跑得最久的，在 BSC 上发育了两年，存在感越来越强。 它的税币机制设计得挺巧妙：creator 可以给 token 自定义交易税率（1%、3%、5%、10%），交易产生的税进入一个 TaxSplitter 合约，再分配到营销、分红、回购、金库等用途。 我本来想重点学习一下它税币的分配机制，看看费用结构，结果发现了几个值得讨论的小细节。 1⃣细节1，税收并非官方说的100％ Flap 的税币机制大概是这样：创作者可以给 token 设置交易税，比如 1%、3%、5%、10%。用户交易时产生税费，这笔税再进入营销、分红、回购、金库等用途。 但flap税币的 TaxSplitter合约中，都出现了同一个参数： feeReceiverAmount = balance − balance × 9000 / 10000 意思是，税收进入后会被拆成两部分：90% 进入项目方设置的 recipient，另外 10% 进入 feeReceiver。 而这个 feeReceiver，指向同一个地址： 0x8a08D98CBB218fceB318Ecf3aBc1BA43D8A7aB0E 也就是说，交易者看到的税收去向是Marketing/Burn/Dividend/Liquidity 四项，官方说法是100%，但协议费构成是隐形的。税收的10％被Flap抽走了，但却没有任何提示和信息高知。 2⃣细节2，两年吞了13,547个BNB 用Agent顺着 0x8a08查资金来往，发现从 2024年7月收到2026年7月，连续两年，累计进账13,547 个 BNB，大概总价值10M吧。 这13,547 BNB里，来自税币10%抽成的部分约 7,900 BNB，大概价值5M；剩下是内盘 1% 曲线费，这个Fee是flap之前公布过的。 1,224 万笔流入，平均每笔 0.0011 BNB，不到一块钱。但连续两年这样流，竟然也流出了500万美元，说明这不是偶发收入，而是一套长期存在的协议级收费入口...... 而且这些资金大部分进入两个Gnosis Safe多签地址，其中一个地址持有 6,912 BNB，价值约 460 万美元，多签签名人中还包含了 Flap 部署钱包。 平台收费当然不是问题，但当一条资金管道长期运转，并累计到几千 BNB 规模时，它就必须成为用户明确知情的产品规则。 3⃣细节3，Robinhood 链上同样的剧本 在查完 BSC 上的合约后，我又去看了 Flap 在 Robinhood 链上部署的合约，结果一模一样。同样的 TaxSplitter 逻辑和feeReceiverAmount 参数，税费90:10 分账比例。 说明两件事：第一，这不是 BSC 合约的偶然疏漏，而是在多链部署时复用的同一套协议逻辑；第二，Robinhood 链上的 Flap 用户和 BSC 用户一样，对这个 10% 的存在并不知情。 4⃣细节4，流水的盘子，不对称的信息 平台协议收入进入团队多签，可以有很多合理解释，比如产品开发、运营维护、安全支出、市场推广。 但合理不等于无需解释，恰恰因为它可以被合理解释，所以更应该解释清楚。 Flap 官方在各个渠道的口径都说税费是100％，但合约写的是90％，如果是遗漏的话，希望官方能补全一下，以免误解。 普通创作者和 holder，如果不懂合约代码，根本不可能知道这个机制的存在，而他们恰恰是最信任 Flap 的那群人。 Web3 常说链上能看到一切，去中心化，代码即规则。 但对绝大多数用户来说，前端、官方解释、社区公告才是规则，作为一个面向 meme 散户的平台，不能只对专业用户透明，协议收入也不是问题，讲清楚写明白就OK。 可能发射台项目真正需要卷的，不只是功能和流量，还有规则透明度。用户并不要求平台永远完美，但至少希望在涉及收费、分账和资金流向时，项目方能把规则一次讲明白。 对 Web3 产品来说，真诚不是态度包装，而是一种产品能力：把钱讲清楚，把规则讲清楚，把用户本该知道的东西放到阳光下，这才是产品应有之道。