𝕸𝖚𝖘𝖎𝖓⭕️莫信

TapeOut 的科技树，又解锁了一格！ 继 TAP-721 之后，最近又花了一些时间研究一个有趣的问题： 如果一台计算机大到区块链根本跑不动，我们还能不能让区块链判断它有没有作弊？ 🤔 于是，我提交了新的标准草案： TAP-7007｜Large Netlists & Verifiable Execution 过去，我们希望把电路放到链上，让它真正运行起来。 但随着电路越来越复杂，从简单逻辑门到 CPU、游戏机，甚至 AI 神经网络，一笔交易的 Gas 已经远远装不下这些计算。 TAP-7007 尝试换一种思路： 🔹 通过 ROM/RAM 与分块存储，让更复杂的电路拥有可验证的链上表示。 🔹 让复杂计算在链下执行，通过挑战机制逐步定位分歧。 🔹 区块链不必重新运行整个程序，只需要裁决发生争议的关键计算步骤。 我还做了两个小实验： 🎮 TAPBOY-8：一台真正运行程序的 8 位游戏机。明明只拿了 34 分，却想谎报 98 分？来，链上对账！😆 🧠 AI Inference：把手写数字神经网络编译成电路，错误的推理结果、被篡改的状态，都可以通过争议机制核对。 更让我兴奋的是，这背后可能打开一张更大的地图： 🎮 可以验证成绩与规则执行的链游 🤖 可以接受计算挑战的 AI Agent 🧬 拥有可执行逻辑的 NFT ⚙️ 由电路驱动的可验证计算服务 从 TAP-721 的电路资产化，到 TAP-7007 的可裁决执行，我越来越觉得，TapeOut 的想象力不应该停留在晶体管、矿机或 NFT 上。 我们或许正在一点点拼出一套全新的可验证计算基础设施。 当然，草案仍在审查，参考实现尚未部署，也没有经过外部审计。挑战机制还需要解决数据可用性、挑战者活性等问题。 但我始终相信，技术的未来不是靠 PPT 描绘出来的，而是靠一行行代码、一次次实验慢慢 Build 出来的。 少一点口号，多一点 GitHub。少一点想象中的未来，多一点真正跑起来的东西。 Build. Prove. Grow. 💙 📜 PR: github.com/TapeOutProtocol/T… 💻 Code: github.com/BruceLanLan/tap-l… #TapeOut #BuilderCulture 🦾 @TapeOutWorld

🎙️ X Layer 中文台 Space｜从社区认证到交易赛：X Layer Meme 社区的下一步 今晚 20:00（UTC+8），邀请到几位获得 X Layer Meme 社区认证的核心建设者，一起聊聊社区发展的最新进展；从社区建设到交易活跃，从 Meme 文化到生态增长，以及 X Layer Meme 生态的下一阶段还有哪些值得期待的机会？ 🎤 主持： @musinoot｜X Layer 中文社区主理人 🎙️ 嘉宾： @biglinzi123｜XDOG 社区核心建设者 @zhouge_155｜LAIKA 社区核心建设者 @jiamibaofu｜IGNIX 社区核心建设者 @bull_bnb｜宝拉社区核心建设者 🎁 Space 互动福利： 参与 Space 互动，有机会获得总价值 $400 的代币奖励！ ✅ 奖励参与要求，转发此推文并关注以下 5 个社区官方 X 账号： X Layer 中文台：@xlayerzh XDOG：@xdogmeme LAIKA：@LaiKa_SpaceX IGNIX：@rwameme_ignix 宝拉：@Polarxlayer ⚠️ 需同时关注以上 5 个账号，方可参与 Space 互动奖励活动。 👉 Space 链接：nitter.cf/i/spaces/1NGarob…

莫信观察｜gang.fun 内盘一天接进 4 个外部交易路由，dev 税可以设成自动回购销毁 10/28 BNB Chain 上的发币平台 gang.fun（@gangdotfun）多签动了四次：凌晨和晚上一共给新发射台加了 4 个外部交易路由，钱包和聚合器以后可以直接买卖内盘币；20:43 又上线 dev 税自动回购，两个小时后已经有 3 个新币用上。 下面按时间把今天的改动和链上第一批使用情况摆出来，数字截至 10/28 22:52。 🐋 gang.fun 一分钟版 - BNB Chain 上的发币平台，只有持 SPACE ID Agent ID（.ai 结尾的 NFT）的钱包能建币、在内盘买卖或打新。用户让自己的 AI agent 跑命令行，在币安 App 里确认交易 - 10/27 22:20 上线新主发射台 GangLaunchpad，曲线币和打新币用同一个合约，曲线币募到约 15 BNB 毕业进 PancakeSwap - 平台合约归一个 2/3 多签管 🐋 今天的时间线 - 01:30、02:06：多签各给新发射台加了 1 个外部路由 - 17:17：上线注册表 GangPadRegistry，给聚合器查币、报价用 - 20:33：多签一笔交易再加 2 个外部路由 - 20:43：交易税处理合约换了管理合约，dev 税自动回购上线 - 21:58：第一笔经外部路由进内盘的买入 - 22:49–22:55：3 个新币开了自动回购 🐋 外部路由：钱包、聚合器可以直接买内盘 之前买内盘币，要么走平台自己的路由 GangRouter，要么直接调发射台。被多签列进白名单的路由，可以替用户在内盘买、卖、打新和卖回，限制照旧：只能替发起这笔交易的钱包操作，Agent ID 门槛和单地址 1% 上限不变。 - 今天列进去 4 个。两个是 BNB Chain 上正在大量使用的交易路由，今天 10:22 到 22:52 分别经手约 5.6 万、9.5 万笔代币转账；另外两个同期都不到 70 笔 - 是哪家的路由，官方没有公布。gang.fun 开源仓库的说明和部署文档到现在还写着「白名单里只有 GangRouter」；审计说明里举的接入例子是 LiquidMesh 和币安 Agentic Wallet 的集成 - 21:58 到 22:51，同一个钱包经凌晨加的那个大流量路由，在内盘买了 4 次 $BOLT，每次 0.0001 BNB。我猜是接入测试 bscscan.com/tx/0x66841d803a2… 🐋 注册表：聚合器怎么认出一个 gang 币 - 输入任意代币地址，注册表返回它在哪个发射台、是曲线币还是打新币，再给出买入、卖出报价。团队用主网数据模拟，在 6 条曲线上各买再卖，报价和真实成交精确到最小单位都一致 - 为什么要它：任何人都能部署一个自称属于 gang.fun 的假币，聚合器照着付钱，钱就进了假合约。注册表只认登记过的发射台，而且要发射台自己的名单里有这个币 - 部署时只登记了 GangLaunchpad，上面有 127 个币 - 注册表由多签直接管，加发射台、升级代码都不用提前公示，多签执行就生效；平台路由 GangRouter 升级要先公示 48 小时 bscscan.com/address/0x4fF77D… 🐋 dev 税：可以设成自动回购销毁 曲线币毕业后，池子里每笔买卖收 1–5% 的税，建币时定好。平台拿成交额的 0.5%，其余分给持币人和接收地址（dev 自己或白名单里的合作方）。 - 新玩法：dev 建币时选回购，接收地址换成这个币专属的回购合约。收到的税按比例拆开，一部分在池子里买回这个币转进黑洞地址，其余给 dev - 比例 dev 随时可以调高，调低要提前 3 天公示。只对新币，已经发出的币不受影响 - 20:43 多签把税处理合约的管理权交给新合约 GangHandlerAdmin，由它给回购工厂开白名单，工厂克隆出来的回购合约自动列入，不用多签一个个批 - 22:49 到 22:55，已有 3 个新币用上：$GQ 和 $GANG球 回购 50%，是同一个 dev 发的；$GANGBALL 回购 100% bscscan.com/tx/0x3a97668130d… 本文未做合约安全审计，以上来自 BNB Chain 链上读数（10/28 22:52）和 gang.fun 开源仓库文档。 今天列进白名单的 4 个路由，分别是哪家钱包和聚合器？ @gangdotfun

余烬世界，今晚开干！ 早鸟试玩开放第一章 5张Pass玩4张图 10张Pass玩22张图 emberworld.net/ @star_okx @okxchinese @wallet @XLayerOfficial @zakk_okx @Blonskr @Ignixbot @Fabx_global #TapeOut

🔥 CRC‑30｜Minting Progress ~85% ⛏️🤖 🔗 crc30.pro/#mint Deep‑Dive into CRC30 🧩🔬 What CRC30 Does & How It Works ⚙️ Simply put: Built atop Bitcoin mainnet 🤯⛓️, CRC30 enables private transfers, private swaps and private issuance participation to share one unified cryptographic state‑machine 🔐. No Bitcoin consensus modifications, no sidechains required 🚫. BTC mainnet functions purely as ordering & data‑availability layer 📜. An indexer runs a note‑centric state‑machine based on encrypted notes 🗂️, consolidating privacy, transactions and launchpad onto one single commitment tree 🌳. I. Problems CRC30 Solves 🎯 Bitcoin comes with an inherent structural contradiction 🧨: transparency builds trust yet exposes trading strategies 👁️. All transfers, trading intents and issuance activities are fully visible inside mempool & block explorers 📡. Front‑runners sniff swap directions ⚔️, snipers anticipate price ramps and inject predatory trades ahead of users 💣. CRC30 does not migrate assets to standalone privacy chains, nor apply shallow privacy hotfixes over transparent ledgers 🩹. It brings three first‑class features natively on Bitcoin mainnet ✅: Private Transfers 🔏: Amounts, senders, receivers and note mappings remain fully concealed. Private Swaps 🔄: Swap intents stay unreadable before settlement; mempool observers cannot pre‑price execution. Private Launchpad 🚀: Linear bonding curve stays fully auditable 📊, while participant identities & timestamps remain hidden 🕵️. All features reuse the same crypto primitives: Notes, Nullifiers and ZK‑Proofs 🧪. II. Underlying Architecture: Meta‑Protocol + Indexer + Notes State‑Machine 🛠️ CRC30 embeds cryptographic data envelopes inside Bitcoin transactions (mainly via OP_RETURN) 📨. Plaintext balances are never stored on‑chain; only encrypted note commitments, nullifiers for spent notes and ZK‑proofs live on‑chain 🔐. Bitcoin miners & full nodes do not validate CRC30 business logic ⛏️; they only order and persist data. Protocol state gets reconstructed by indexers 🔁: replaying envelopes block‑by‑block, verifying proofs, maintaining commitment tree plus spent‑nullifier set. Indexers hold zero user custody. Spend keys remain local on user‑side 🔑; indexers only handle ordering and proof validation. Notes act as encrypted asset containers 🎲 storing value, recipient info & random commitment nonces. Owning assets means controlling a note only you can decrypt & spend. Spending a note only reveals one‑way derived nullifier. Third‑parties cannot trace back to original notes, breaking linkages between actions & addresses 🔗❌. Private transfers, swaps and launchpad all follow the same pattern: consume old notes, generate new notes, differing only in business constraints 📎. This yields a unified global private balance state 🌐. III. Private Transfer: Foundational Building Block 🛡️ Private transfer forms the lowest‑level primitive of the protocol stack 🧱. Swaps and launchpad add extra business constraints, while private transfers only prove note ownership without disclosing which exact note is being spent 🙈. On‑chain Visible Surface 👀 A CRC30 private transfer appears as a regular Bitcoin transaction. Public exposure gets minimized 📉: observers only see transaction occurrence, note consume/create counts, miner fees and the raw BTC transaction itself. Sender, receiver, amount and note mappings are protected under ciphertext & ZK constraints 🔒. Four Mandatory ZK‑Proof Constraints ✅ Ownership: Prover holds the spend key of target note 🔑 Membership: Note exists inside historical commitment tree, attested via Merkle proof 🌿 Nullifier Correctness & Freshness: Nullifier maps to spent note & has never been used, anti‑double‑spend guarantee 🛡️ Value Conservation: Sum of input note values ≥ sum of output note values + protocol fees. Amounts stay encapsulated inside proof, invisible externally 💰❔ Fixed‑size Slots & Change Mechanism 🧩 Private transfers adopt fixed‑slot construction 📝: max 3 input notes consumed, max 3 output notes generated (recipient note, change note, zero‑value dummy note). Every transaction maintains identical on‑chain shape to prevent metadata inference from input/output counting 🔍❌. Commitment layer cannot distinguish payment outputs from change outputs ⚖️. Dual‑Key Model: Spend‑Key / View‑Key Separation 🔑👁️ ‑ Spend‑Key: Controls assets; no valid nullifier or ownership proof can be generated without it ‑ View‑Key: Read‑only permission, decrypt historical notes but cannot spend funds 🔒 CRC30 implements Privacy‑by‑Default, Audit‑on‑Demand 📋 instead of absolute anonymity. Users can disclose history to auditors without surrendering asset control ✅. IV. Private Swap: Native In‑Note‑Domain Trading 🔄⚡ If swaps are executed purely over transparent UTXOs, privacy only covers post‑settlement status while trade intents remain exposed to mempool 🚨. CRC30 swap logic runs natively within the notes state‑machine 🧠. Private swap burns input notes and mints new output notes. On top of private‑transfer constraints, ZK‑proof additionally validates swap ratio complies with pricing rules 📐. Constraints upgrade from simple value equality to verifying minimal output yield defined by bonding curve 📈. Front‑runners inside mempool only receive unvalidated cryptographic commitments with zero readable order data 🤫. Trade direction and volume remain hidden until indexer completes validation 📊❌. Native CRC30 assets skip “transparent‑to‑private” bridging entirely 🌉❌. Both sides hold assets as notes within same privacy domain, eliminating pre‑trade mempool manipulation ✅. V. CRC30 Launchpad Implementation on Bitcoin Mainnet 🚀⛓️ Bitcoin nodes execute zero custom business logic and merely sort transactions 📦. BTC consensus cannot maintain share counters, price tiers or operation validity status 🚫. CRC30 hosts launchpad state‑machine inside BTC transaction payloads 🦠. Off‑chain indexers replay & adjudicate operations block‑wise. Participant identities and actions are encrypted by notes + ZK‑proofs 🔐. Data‑Envelope On‑chain Carrier 📨 CRC30 launchpad deploys no smart contracts and makes zero consensus changes 🚫. Launchpad operations are wrapped as regular Bitcoin transactions. Protocol envelopes embedded inside OP_RETURN / witness contain: nullifier of spent payment note, new share note commitments, ZK‑proof 🧪. Miners do not parse this payload ⛏️; invalid operations may still land on‑chain. Sanity checks belong to indexers, not consensus layer. BTC mainnet delivers deterministic ordering & immutable storage 📜, following Bitcoin meta‑protocol client‑side‑validation philosophy: raw data stored on‑chain, state reconstructed off‑chain by indexers 🔁. Indexer: Arbiter for Linear Bonding Curve ⚖️ Linear price ramp depends on global share counter 🧮. This counter lives outside on‑chain contracts and increments sequentially by indexer following block transaction order 🔄. Indexer performs three checks upon valid launchpad envelope: Validate ZK‑proof correctness Confirm nullifier has not been reused Increment share counter and update commitment‑tree state root 🌳 Subsequent operations must reference latest state root. Transactions referencing stale state root or reused nullifiers get rejected directly ❌. Curve parameters are fully publicly‑recomputable 🔍. Running Bitcoin node + indexer yields identical counter results for everyone. Auditability does not rely on single‑operator trust 🤝❌. Embed Linear‑curve Rules inside ZK Circuits ⚙️🧬 Share price rises linearly alongside counter value 📈. If bids rely only on user self‑declaration, attackers can submit low‑cost transactions for exploitation ⚠️. CRC30 bakes pricing constraints directly into ZK‑circuit instead of on‑chain execution 🔐. Beyond baseline checks, launchpad proof must satisfy two extra conditions: Paid value meets or exceeds current tier price, blocking under‑payment attacks 🛡️ Counter increments exactly one step, state root S correctly transitions to S’, preventing duplicate operations under same state 🔁❌ Essentially a ZK‑Proof of valid state transition 📜: prover proves compliance with linear‑curve rules without revealing identity, funding source or operation details 🤫. Anyone can recalculate counter value at any block height, yet cannot deduce corresponding price tier from unprocessed envelopes 🕵️❔. Share Distribution: Notes as Launchpad Output Vessel 📦 Launchpad never outputs plaintext on‑chain balances. Only recipient‑decryptable notes get emitted 🔐. After indexer validation, new note commitments are appended as tree‑leaf nodes 🌿. Holding shares equals owning a note with valid Merkle proof & unspent nullifier ✅. Indexer maintains append‑only commitment tree plus nullifier set; notes stay fully cipher‑wrapped 🔒. Secondary trades & swaps still consume old notes and produce new notes, no separate external ledger required 📋❌. Launchpad, private transfers and private swaps reuse identical commitment‑tree & validation logic — this is the technical foundation for three‑module integration 🧩. Privacy Scope: Hide Participant Behaviours, Not Curve Math 🎭 Total supply, step parameters and share counter are publicly computable 📊 and remain exposed. Privacy targets the linkage between participants and their operations 🔗❌. ZK‑proof only certifies: some note holder paid sufficient value and triggered counter increment. It leaks zero info about exact note, funding origin or associated address 🙈. This neutralizes classic mempool front‑running vectors ⚔️. Attackers lose actionable trigger signals since user intents are sealed inside encrypted commitments 🚫. Concurrent Conflicts & Architectural Trade‑offs ⚠️ Global counter introduces natural concurrency races 🔀. Multiple transactions broadcast simultaneously based on latest state root. CRC30 adjudication follows indexer processing order, not broadcast time or miner inclusion order 📌. The first valid transaction consumes state root and advances counter ✅. Other transactions within same block built on stale state root get rejected ❌. Launchpad throughput is bounded by indexer serial processing capacity rather than Bitcoin block size 📏. This is inherent engineering overhead for building global state‑machine over Bitcoin transparent layer 💡. Global state demands sequential arbiter; adding distributed consensus will completely shift trust assumptions 🔄. Indexers guarantee service availability but never touch user funds; spend keys belong exclusively to end‑users 🔑. Security comes from reproducible deterministic rules instead of trust in operators 🤝❌. CRC30 launchpad leverages ZK‑Proof & note primitives to upgrade plain‑text rule interpretation into cryptographically‑enforced state transitions 🧬. Conclusion 💡 CRC‑30 pursues an engineering‑heavy yet logically self‑consistent path: without modifying Bitcoin consensus, elevate selective privacy into first‑class capability for issuance & trading ₿🔐. It tests not merely ZK‑proof performance but a fundamental question: on Bitcoin’s default‑transparent ledger, can privacy evolve from a retrospective hotfix into native base‑layer capability 🧪. #CRC30 #Bitcoin #ZK #CRC20

宇宙那么大，先要探个头！🐶

莫信解读｜X Layer 上的 TapeOut：FabX 开挖两周，矿机能拆着卖，meme 的交易税也开始买矿机 今晚 21:03，@Ignixbot 上线了 FAB 挖矿金库：在 Ignix 发币时选这个模式，代币的一部分交易税会自动去买 @Fabx_global 的矿机，挖出来的 $FAB 分给持币人。这是两家四天里的第二次合作，第一次是 10 月 23 日的矿机碎片化。 FabX 10 月 13 日开挖，到今天两周，X Layer 上的 TapeOut 生态多了三样东西：能挖矿的电路、能拆开买卖的矿机份额、能用交易税买矿机的 meme。先简单介绍 FabX 和 Ignix，再把碎片化、挖矿金库和第一批 meme 的链上数据摆出来。 🐋 FabX：在 X Layer 上用电路挖矿 FabX 是 X Layer 上基于 TapeOut 协议的社区矿机。不用买硬件，在画布上用 NAND 和 LATCH 两种晶体管设计电路，电路流片之后就是一台矿机，同一道题用的元件越少，算力越高。 - $FAB 总量 2,100 万枚，每天排放 7,200 枚，约 4 年减半 - 99% 的产出按算力分给已验证矿机，1% 给未验证矿机 - 5% 的 FAB 和 1,700 枚 BEM 锁进了流动性，其余 95% 靠挖 - 质押 OKB、质押 BEM、燃烧 OKB、DeWEB 流量都能给矿机加速 10 月 13 日 20:02 开挖，到今晚 23:07，全网 6,597 台矿机，其中已验证 6,484 台，累计挖出约 6.43 万枚 FAB。FAB 现价约 0.487 美元。 🐋 Ignix：X Layer 上的发射台，玩法在金库 Ignix 是 X Layer 上的代币发射台，代币先在曲线上卖，募满后自动进 Uniswap。每个代币发币时要选一个金库，决定交易税怎么用，选了就不能改。现在页面上有 7 种： - 按比例分给发币方和持币人（默认） - 把税换成代币化股票，给持币人分红 - 分给多个地址，或者全部给一个地址 - 在 Uniswap V4 池子里直接收计价币，代币本身不带税 - 定时回购销毁，加流动性，再分红 - 今晚新加的挖矿分红金库 🐋 第一次合作：矿机拆成份额 10 月 23 日上线的碎片化，是把 FabX 矿机存进 Ignix 的金库，按算力换成份额 $FABS。FABS 在 FABS/OKB 池子里零买零卖；金库每天挖到的 FAB，85% 分给 FABS 持有人，5% 给流动性激励，10% 是服务费。烧掉足够的 FABS，可以从金库里换回一台矿机。 金库这几天的变化： - 10/23 21:41：60 台矿机，占全网已验证算力 4.7% - 10/24 21:45：214 台，6.9% - 10/27 23:07：113 台，6.77% 台数比 10/24 少了 101 台，算力总量只少了约 0.2%。现在 FABS 共 2.51 亿枚，持有人每天合计分到约 410 枚 FAB；池子里有 347 OKB 和 1.57 亿枚 FABS，100 万枚 FABS 约 2.21 OKB，每天分到约 1.64 枚 FAB。 web3.okx.com/explorer/x-laye… 10/25 中文台的 Space 上，Ignix 说在考虑给碎片化金库里的矿机做官方质押加速，也在准备 BEM 矿机的碎片化。 🐋 第二次合作：meme 的交易税去买矿机 据 Ignix 发币页面： - 发币时选「Miner Dividend Vault」，计价可以选 FAB、OKB 或 BEM - 买入税、卖出税各 1%–10%，平台从每笔税里收 10%；剩下的发币方最多拿 50%，其余进 Ignix 的共享矿场，页面默认发币方 10%、矿场 90% - 进矿场的税换成 OKB，自动买已验证、能挖的矿机。每投入 1 OKB 记 1 份，投进去不能取出 - 矿场挖到的 FAB 按份数分给各个代币，再按持币权重分给持有人，随时可以领；持有人销毁代币，可以临时提高自己的权重 别的金库把税分掉、换成股票或者烧掉；这个金库把税变成矿场里的份数，投进去不能取出，热度过了，矿机还在挖，产出还按持仓分。 矿场现在的状态（Ignix 矿场数据，23:04）： - 矿场合约 18:47 部署，还没有买进矿机，份数是 0 - 页面筛出 153 台能买的矿机，最便宜的一台挂 13.8 OKB，每天能挖约 18.02 枚 FAB - 按 FAB 现价约 0.00448 OKB 算，这台矿机每天挖出约 0.081 OKB 的 FAB，不算全网算力增长和减半，回本约 171 天 web3.okx.com/explorer/x-laye… 🐋 已经发出来的 meme：10 个，毕业 1 个 矿场合约登记的代币，截至 23:07： - 19:08 到 22:37 一共 10 个代币选了挖矿金库：FAB 计价 5 个，OKB 计价 3 个，BEM 计价 2 个 - 毕业的只有 $FMM（FAB Mining Machine）：19:28 创建，FAB 计价，21:18 募满 5,000 FAB，进了 FMM/FAB 的 Uniswap V2 池子 - 其余 9 个还在曲线上，卖得最多的两个卖出了总量的 26.8% 和 26.0% FMM 的盘子： - 总量 10 亿枚，池子里 1.26 亿枚 FMM 和 8,154 枚 FAB，1 FMM 约 0.0000649 FAB，按这个价算全部代币约 6.5 万枚 FAB，约 3.2 万美元（22:56） - 毕业后买卖税各 1%，曲线阶段收的税是 FAB，毕业后收的是 FMM - 持币地址 136 个（22:52） web3.okx.com/explorer/x-laye… 10 个代币的分税合约里，现在一共存着 211.8 枚 FAB、1,551 万枚 FMM、2.25 OKB 和 2.26 枚 BEM，大头是 FMM 那份。这些税还没换成 OKB 打进矿场，按现价全部折算约 8.2 OKB，扣掉协议费和发币方那份之前，也还买不起最便宜的那台 13.8 OKB 的矿机。 🐋 对 BEM - FAB 的主交易对是 BEM/FAB 池，10/23 占 FAB 全部流动性的 96% - 挖矿金库支持 BEM 计价，已经有 2 个 BEM 计价的代币 - Ignix 在准备 BEM 矿机碎片化。据 @Blonskr 今晚发布的进展，TapeOut 矿机已经支持 X Layer 和 BNB Chain 双向跨链；OKX 浏览器上 X Layer 的 BEM 现在约 43.2 万枚 🐋 两周的时间线 - 10/13 FabX 开挖：电路就是矿机，产出 FAB - 10/23 Ignix 矿机碎片化：矿机拆成份额，一台矿机值多少有了随时能查的价格 - 10/27 FAB 挖矿金库：发币的交易税自动买矿机，产出按持仓分 三步都在 X Layer 上，Ignix 两个产品用到的矿机数据，都是从 FabX 的挖矿合约里直接读的。 分税合约里的税什么时候换成 OKB 打进矿场，是按时间，还是攒够一台矿机的钱再转？ @Ignixbot @Fabx_global @TapeOutWorld @Blonskr

莫信观察｜TapeLaunch 交易税 5% 给 BEM 基金会，发币可选 BEM 计价：第一天分到 0.15 BNB TapeLaunch（@TapeLaunch）10/26 22:10 发了官宣线程，项目代币的交易税有 5%「支持 BEM 基金会」，收款地址是 TapeOut 社区基金会（@TapeOutCF）的多签。从第一个项目 10/26 14:30 创建到 10/27 0:27，四个项目给基金会分到 0.15 BNB；按比例算，项目币每成交 100 万美元，基金会分到 500 美元。发布合约里还写着，发币可以选 BEM 计价。 先讲讲 TapeLaunch 怎么发币，再把交易税的去向、回购金库、$TAPE 的盘面和筹码摆出来。 🐋 TapeLaunch 一分钟版 - 用 AI 对话生成网站，发布时把网站文件写进 TapeOut（@TapeOutWorld）的 DeWEB，同时在 Flap 上发一个币；之后改网站，沿用原来的币 - 发布合约已开源，几条规则写在里面：一个项目对应一个容器、一个币；买卖税各 1%，收 365 天；发币时不接受首买；计价可以选 BNB 或 BEM - 内盘卖出 8 亿枚（总量的 4/5）后毕业，迁到 PancakeSwap V2 bscscan.com/address/0x4ed118… 🐋 交易税分去了哪 每个项目有一个自己的收入合约，交易税全部进这里，各方自己来领。四个项目的收入合约读出来是同一套比例，和官推一致： - 70% 给创作者 - 15% 进入平台代币回购金库 - 10% 用于协议运营 - 5% 支持 BEM 基金会 截至 0:27，四个收入合约一共收到 3.06 BNB：创作者 2.14、回购 0.46、协议 0.31、基金会 0.15。其中 $TAPE 一个就占了 2.96 BNB。 比例只能由收入合约的工厂来改，改动只影响之后进来的钱，已经进账的按原比例算。工厂的管理员是 TapeLaunch 的部署地址 0xc01a…8c26。 bscscan.com/address/0x8796dd… 🐋 回购金库：15% 回购 $TAPE - 0.46 BNB 约 342 美元，按 PancakeSwap 上 $TAPE 现价、算上池子滑点，能买约 470 万枚，占总量的 0.47% - 这 0.46 BNB 里，0.44 来自 $TAPE 自己的交易税 - 换算下来，项目币每成交 100 万美元，回购分到 1,500 美元 - 官推的说法是「回购资金在满足执行条件后使用」。目前 0.46 BNB 还在四个收入合约里，没有转进金库 - 链上现在这个金库登记的平台代币还是 BEM，项目方回复是合约写错了，正在改 bscscan.com/address/0x42b8b7… 🐋 $TAPE：平台自己发的币 TapeLaunch 目前一共 4 个项目，创建者都是 0xc01a…8c26，也就是部署发布合约、收入合约工厂和回购金库的同一个地址。$TAPE 是其中之一，交易税和别的项目一样分：70% 给这个地址，15% 进回购金库。这个地址已经从 $TAPE 的收入合约领走 1.08 BNB。 时间线（10/26，UTC+8）： - 14:30 在 Flap 上创建 - 14:38 部署地址在内盘买入 0.03 BNB - 16:22 内盘打满毕业，用时约 1 小时 52 分；2 亿枚 + 16 BNB 进 PancakeSwap，LP 转进黑洞地址。X 上能搜到的最早一条带合约地址的帖，是同一分钟的自动信号号发的 - 17:54、18:25 部署地址在外盘再买 0.15、0.1 BNB，现在持有 982 万枚（0.98%），没有卖过 - 22:10 官推发线程，当时市值约 2.5 万美元 - 23:09 市值最高约 9.2 万美元 - 10/27 0:27 市值约 7.0 万美元，池子流动性约 2.6 万美元 毕业以后外盘成交 3,747 笔、305.8 BNB，约 22.7 万美元。 🐋 筹码在谁手里 - 毕业那一刻，143 个地址拿着内盘买到的币；现在其中 55 个还拿着，合计占总量 33.1% - 前十大地址（不含池子）合计占 19.8% - 持币地址 314 个 bscscan.com/token/0xBb300d79… 🐋 另外三个项目 Specimen Archive（$SPCM）、曦能 Solar（$XSOL）、留白设计节（$BLANK）还在内盘，进度 7.0%、2.3%、4.0%，市值都在 5 千美元上下，三个收入合约合计收到 0.098 BNB。 到目前为止，还没有部署地址以外的人用 TapeLaunch 发过币，BEM 计价的发射也还没人用过。 本文未做合约安全审计，费率和分成比例来自 BscScan 上已开源的发布合约源码，收入、成交和持币数字来自 BNB Chain 链上读数（10/27 0:27）。 「满足执行条件」指的是什么条件？买到的 $TAPE 打算怎么用？ @TapeLaunch @TapeOutWorld @TapeOutCF

1/ On 25 Oct, DotSwap V1, our original 2024 swap platform, was attacked. The attacker used V1's legacy server-side signing path to drain roughly 8.5 BTC (~$685k) from V1 liquidity pools and V1 accounts over about four hours.