Why Are We Supporting Alkanes?

Over the past month, we have been gradually adding support for the Alkanes protocol within several of UniSat’s products—most notably in our developer-facing API. Interestingly, after comprehensive research, we found that the actual development effort was less than expected, and progress was slightly faster than anticipated. Below, we briefly analyze the reasons for this and share some of our observations and findings from the work.

A few weeks ago, what truly motivated us to embark on this integration was Alkanes’s ability—after absorbing and refining the strengths of protocols like Runes—to deliver an immediately usable smart-contract execution environment.

Specifically, the Alkanes protocol offers two main advantages:

Inheritance and Optimization of a UTXO-Based Asset Model (Inspired by Runes)

Runes has already demonstrated the practicality and reliability of this model. We were pleasantly surprised to discover that Alkanes, by innovatively integrating the approach pioneered by Runes, creates new advantages within a smart-contract environment.

Because asset ownership is directly bound to UTXOs, users can transfer assets via standard transactions without interacting with a contract for each transfer (unlike ERC-20 tokens, where every transfer calls the token contract). In other words, for the most common operation—a typical transfer—a user can perform a contract-less asset transfer. Compared to non-UTXO virtual machines (e.g., the EVM), this significantly reduces performance overhead and avoids extensive state management. The VM can then devote its limited system resources to more advanced business logic.

Moreover, because Alkanes is fully compatible with Runes’s asset-identification standards (such as the OP_RETURN encoding format), we can achieve low-cost code reuse when building wallets, block explorers, and other infrastructures. In practice, this materially boosts development efficiency and lowers the migration barrier for developers.

A Ready-to-Use, Open-Source Smart-Contract Framework on Bitcoin

Within the Bitcoin ecosystem, many teams have been exploring smart contracts under various monikers—BTCfi, for example. Yet, within a limited development timeframe, Alkanes has leveraged the maturity of the WebAssembly (WASM) ecosystem to deliver a relatively production-ready, open-source smart-contract framework on Bitcoin mainnet—while most others are still in directional exploration. Frankly, we were impressed by the system’s level of completion when we first studied it.

Alkanes’s smart-contract solution extends the boundaries of what is possible within the BTC ecosystem. Its modular architecture allows developers to deploy fully featured contracts (e.g., AMMs, staking, timelocks) without modifying the underlying indexer or protocol rules for each functionality. As long-term maintainers of indexers ourselves, we naturally appreciate the elegance and convenience of this approach.

Summary

Using an external VM rather than Bitcoin’s native scripting to extend Bitcoin’s contract capabilities is becoming a popular trend. Overall, this exploration benefits the system by preserving Bitcoin’s core simplicity, stability, and cohesion, while effectively expanding its capability envelope—granting the system greater freedom (albeit with added complexity). More importantly, after carefully preserving Runes’s existing strengths, Alkanes orthogonally introduces a new dimension (WASM contract capability), positioning itself as an evolutionary step that seeks to unlock greater potential from a functional perspective.

Having covered the two main advantages, we briefly analyze the protocol’s current limitations and areas for improvement:

Potential Risks from Contract Code Security and Robustness

Because the contract development environment is unfamiliar—unlike the mature Solidity/EVM ecosystem—developers must rewrite contracts already battle-tested on EVM, posing a challenge for most. Furthermore, due to the lack of sufficient auditing and contract-verification platforms, users cannot be certain that token contracts are free of hidden backdoors (e.g., undisclosed minting logic). Currently, one must rely on project teams to proactively publish source code; if a contract launches without proper verification, there is a high risk of asset manipulation. This is a concern for both developers and users.

Risk of Asset Burn from Misoperation

The UTXO-based asset model introduces a learning curve for users and wallets not yet adapted to the protocol—raising the risk of inadvertently burning assets. Unlike Runes UTXOs (which, in OP_RETURN-less transactions, send assets to the first non-OP_RETURN output), Alkanes does not inherit this feature, increasing burn risk. Developers and users must be vigilant.

Need for Maturation in Engineering Design and Implementation

Alkanes is still in its early stages and has numerous engineering areas that require improvement. Below, we highlight one design issue and one implementation issue as examples to encourage active evolution of the protocol by drawing the maintainers’ attention to these areas. We would be delighted to support such efforts.

• Design Issue Example: Sequence-number offsets could trigger global misidentification. The protocol relies on sequentially assigned contract IDs; if an indexer version or runtime environment causes an offset, subsequent asset-transfer instructions may fail in a chain reaction. This defect could render all assets temporarily unusable system-wide—a systemic risk not present in Runes (where only localized errors occur).

• Implementation Issue Example: Currently, Alkanes’s official indexer can take 1–2 minutes to process a single block, depending on transaction volume, with processing time scaling linearly as volume increases. If OP_RETURN constraints are lifted and batch OP_RETURN creation is permitted, a denial-of-service vector against indexing could emerge. In a future surge of transactions (e.g., a popular token mint), severe congestion may result, undermining support for high-frequency applications (e.g., DeFi). Indexing performance requires deeper, ongoing optimization to withstand potential future demands.

Inherent Limitations of the Bitcoin Blockchain

• Transaction Ordering Depends on Miner Inclusion: Unlike Ethereum’s nonce-driven sequence, Bitcoin’s transaction order is solely determined by miners’ packaging. This makes contract-interaction ordering unpredictable, risking failures in contracts that require strict sequential operations.

• OP_RETURN Data-Size Limit: Bitcoin currently limits OP_RETURN to 80 bytes, constraining the amount of data per contract interaction and rendering some functions impractical without workarounds.

Summary

For healthy ecosystem growth, significant work remains ahead. As builders and supporters of Alkanes, we advocate for consciously controlling protocol complexity—exercising restraint and carefully evaluating new variables and abstractions before introduction. We must avoid short-term conveniences that risk becoming long-term technical debt.

On Bitcoin Programmability

While actively advancing Alkanes, we must not overlook BestInSlots’s explorations with BRC-20 programmability. This alternative path merits close attention, and we stand ready to offer support. A brief comparison: the EVM-and-Solidity–based BRC-20 programmable module is more familiar to blockchain developers and features more predictable VM behavior—but carries greater historical baggage. Conversely, Alkanes, leveraging WebAssembly as a modern execution environment, has the potential for higher performance and more efficient resource management—though new scripts lack extensive real-world vetting and may harbor unknown risks. We look forward to delivering deeper analyses as both systems mature.

On the Evolution of the Bitcoin Ecosystem

In 2023, various protocols focused on their primitive merits. By 2025, the low-hanging fruits have been harvested, and competition along new dimensions is just beginning. UniSat is warmed up; we maintain close, in-depth collaboration with relevant teams, and we stand ready to provide developers and users with firsthand operational experience and tooling support.

Unlike the summer of 2023, new potential mainnet congestion will meet the robust Fractal Bitcoin network. We will no longer be caught off guard and helpless. In the future, a real-world stress test may reveal which technical solutions can survive on the battlefield and become effective Bitcoin-scaling systems.

Meanwhile, we will progressively increase our investment to further upgrade and adapt Fractal Bitcoin—making it friendlier to modern contract-execution environments. We envision Fractal providing faster confirmations and larger block space capacity, creating a looser environment where diverse contract types face fewer constraints and have greater room to flourish—helping the Bitcoin ecosystem blossom to its fullest.

A great story moves hearts, but what truly transforms and empowers a system is robust, runnable, and extensible code.

Lorenzo
June 8, 2025

(Chinese follows)

翻译版

在过去的一个多月中，我们正在 UniSat 的若干产品内，特别是给开发者的 API 中，逐步实现对于 Alkanes 协议的支持。有趣的是，在充分的调研之后，我们发现实际的开发工作比我们预期的少，进展也比预期的稍快。我们会简单分析其原因，同时也会分享一些工作中的观察和发现。

回到若干周前，真正打动我们开展相关工作的是，Alkanes 在消化和吸收了 Runes 等协议的优点之后，所构造出的一个即时可用的合约执行环境。

具体地说，Alkanes 协议具有如下两个主要的优势：

对类似 Runes 的基于 UTXO资产模型的继承和优化

Runes 已经向我们展示了这种模型的实用性和可靠性。我们惊讶地发现，Alkanes 通过创新性地融合Runes协议的方案，在合约的环境下建立起了新的优势。

由于资产的所有权与 UTXO 直接绑定，用户仅通过普通交易就可以发送资产，无需像 ERC20 这样的协议那样，每一笔转账都需要与合约交互。也就是说，作为最常见的操作，一笔典型的转账可以做到无智能合约调用（contract-less asset transfer）。与非 UTXO 虚拟机（如 EVM) 相比，这极大地降低了性能开销，避免了大量的状态维护。使得虚拟机可以把有限的系统资源用在更高级的业务逻辑上。

同时，由于 Alkanes 完全兼容 Runes 的资产识别标准（如 OP_RETURN 编码格式），我们在实现钱包、浏览器等基础设施时，可以基本做到较低成本的代码复用，在实际工作中，这可以显著提高开发效率，降低开发者的迁移门槛。

已然可用的创新比特币智能合约开源框架

我们知道，在比特币生态中，有很多团队在进行智能合约相关的探索和开发，他们为自己的工作起了很多有趣的名字，如 BTCfi等等。而Alkanes 在有限的开发时间内，通过巧妙地利用 WebAssembly 的相对成熟的基础设施，在其他大部分团队还在做方向性的探讨和摸索时，已经在比特币主网上落地了一套相对可用的智能合约开源框架。不得不说，我们在研究时，对系统的完成度是比较吃惊的。

Alkanes 提供的智能合约方案，扩展了BTC生态的能力边界。其模块化架构允许开发者直接部署功能完备的合约（如AMM、质押、时间锁等），无需为每类功能修改底层索引器或协议规则。作为索引器的常年维护者，我们很自然地对这样的方案感到亲切和方便。

小结

使用外部虚拟机而非比特币自身的脚本来扩展比特币的合约能力，这正在成为一个流行的做法。总的来说这种探索对于系统是有益的，特别是它在维护了比特币内核的简单，稳定和内聚力的同时，有效扩展了系统的能力边界，使得系统拥有更大的自由度（当然也带来了相应的复杂度）。进一步说，在小心地覆盖了 Runes 已有优势的基础上，通过正交地展示一个新的维度（WASM 合约能力），Alkanes 可以被认为是一个从功能角度试图挖掘更多潜力的进化版本。

说完了两个主要的优势，这里我们也简要分析一下其目前存在的不足和改良空间：

合约代码的安全性和健壮性带来的潜在风险

由于合约不是常见的 Solidity 开发环境，开发者会需要重新写出那些在EVM上已经成熟的合约代码，这对于大多数开发者来说构成了挑战。并且由于缺少足够的审计和合约代码验证平台，用户无法确认代币合约是否被恶意植入后门（如隐藏增发逻辑）。当前仅能依赖项目方主动提供源码，若合约未经验证即上线，存在资产被操控的高风险，这是需要开发者和用户注意的。

操作不当导致的资产烧毁风险

选择使用基于UTXO的资产模型，为用户的理解和管理带来一定的挑战，对于尚未准确识别该协议的钱包而言，这会带来烧毁的风险，Runes的UTXO在没有携带OP_RETURN的交易下，会把资产转移到首个非OP_RETURN输出上，Alkanes没有继承这个特性，所以烧毁风险更高，这也是需要开发者和用户注意的。

工程设计和实现的成熟度亟需提升

目前Alkanes处于早期，在工程上有大量亟需改善之处。以下我们在设计和实现各举一例，以引起协议维护者的注意，积极推动协议的改良和进化。

（设计问题一例）序号偏移可能引发全局错误识别的风险。协议依赖连续编号分配合约ID，一旦某个序号因故障偏移（如索引运行版本或者运行环境等因素），后续所有资产转移指令将连锁失效。此设计缺陷可能临时性地导致后续所有资产暂时不可用，这要求各个索引方需要保持高度一致，对比Runes等协议（仅局部代币错误）存在系统性隐患。

（实现问题一例）目前Alkanes 官方索引的单区块处理耗时根据Alkanes交易数量可能高达1-2分钟，且随交易量增加呈线性上升趋势。如果OP_RETURN的限制被解除，允许批量构造OP_RETURN，可能会存在针对索引的DDOS攻击，若未来交易激增（如热门代币铸造），可能引发严重拥堵，难以支撑高频应用场景（如DeFi交易）。索引性能需要进一步持续而深入的优化，以应对未来潜在应用可能带来的挑战。

比特币区块链本身存在的固有限制

交易顺序依赖矿工打包。以太坊中，交易可以通过nonce来保证一定的先后顺序。但BTC上则退化为交易自身被打包的顺序，这导致了Alkanes协议下的合约交互的顺序完全无法保证。一个用户的两笔连续操作在区块打包前无法确定，在对顺序有较高要求的合约上，比较容易出现合约交互失败的情况。

OP_RETURN数据段的容量限制。比特币当前OP_RETURN限制80字节，这对合约单次交互所能传递的数据有较大的限制，使得某些功能无法使用一般的方式实现。

再次小结

从积极面对和解决问题的角度出发，我们认为当前系统还存在大量可以改进的空间，为了系统的健康发展，还有很多工作需要被完成。我们的期望和建议是，应当有意识地控制系统的复杂度，保持克制，谨慎地增加系统的控制变量和抽象维度；不要贪图一时的方便，引入太多可能成为历史包袱的负担。

关于比特币的可编程性

在积极推动Alkanes发展的同时，我们不应忽视 BestInSlots 在 brc-20 上的可编程性探索。这是一条不寻常的道路，我们对于其进展保持密切的关注，并随时准备好为其提供支持。一个简单快速的比较是，应用了 EVM 和 Solidity 的 brc-20 programmable module 对区块链开发者更加友好，虚拟机行为更稳定可预测，但继承了更多的历史负担；而使用 WebAssembly 的 Alkanes 拥有的潜在优势是，（作为现代执行环境）有机会实现更高的性能，更有效的资源管理，同时新写出的脚本代码未经实战检验，也可能带来更多未知的风险。我们期待着随着各自系统的交付与完善，能够做出更深入的分析和总结。

关于比特币生态的发展

2023 年，不同协议关注的焦点还在各自的原始特性上。时间推移至2025 年，低垂的果实已经摘完，新的维度的竞争才刚刚拉开序幕。UniSat 已经做好了热身，我们与相关的团队保持密切和深入的交流，并准备好随时积极地为开发者和用户提供来自一手的战地经验和工具支持。

与那个夏天不同的是，这一次主网的潜在拥堵发生时，有了健壮的 Fractal Bitcoin 网络，我们将不再像那时一样，面对拥堵目瞪口呆，束手无策。在不远的未来，也许会有一次实战机会，让我们得以检验哪些技术方案可以在真实的战场上存活下来，得以成为比特币的有效扩展系统。

同时，我们会逐步加大投入，对Fractal Bitcoin 做进一步的升级和改造，以使得它对于现代的合约执行环境更加友好。我们期望Fractal在提供了一个能够更快速确认，区块容量更大的宽松环境的基础上，让更多不同类型的合约受到更少的约束，得到更多更充分的发挥的机会，从而帮助比特币生态更充分地绽放。

好听的故事打动人心，而能够深刻改变和成就系统的，是健壮的，可以运行，可以扩展的代码。

Lorenzo

2025.06.08

E-2506 (Lorenzo’s Library)
Creative Commons BY-NC-ND 4.0