# Welcome to Fractal Welcome to the official documentation for Fractal Bitcoin! **Fractal Bitcoin — Extending the Utility of Bitcoin.** Fractal Bitcoin is a blockchain built with a modern design mindset, while remaining fully aligned with the core mechanisms of Bitcoin. Fractal is a simple, flexible, fast, and robust extension of Bitcoin. * Simple — It uses native Bitcoin code, without adding extra data layers or abstractions. * Flexible — It can support protocols such as brc-20 and Runes at any time, using the same mechanism as Bitcoin mainnet. * Fast — Instead of Bitcoin's 10-minute block time, Fractal confirms a block every 30 seconds — a 20× faster experience. * Robust — It is secured by 90% of Bitcoin’s global hash power, offering strong and continuous security guarantees. {% content-ref url="/pages/5ZUApKI3KTjnxFcsc6fD" %} [Broken mention](broken://pages/5ZUApKI3KTjnxFcsc6fD) {% endcontent-ref %} {% content-ref url="/pages/H9nkY7BefJVH9E9QHSwA" %} [For Users](/for-users/overview) {% endcontent-ref %} {% content-ref url="/pages/29Eg37b7eWp9V2LLJvDd" %} [For Developers](/for-developers/developer-overview) {% endcontent-ref %} {% content-ref url="/pages/UGRgFhy2ALbb4x3zujk9" %} [For Miners](/for-miners/minning-overview) {% endcontent-ref %} {% content-ref url="/pages/r3Dy2HnNfry6Fbx133Nr" %} [For Indexing Service Providers](/for-indexing-service-providers/standard-indexing-service-overview) {% endcontent-ref %} **Official Resources and Community:** Website: X (Twitter): Telegram: # FIPs FIP (Fractal Improvement Proposal) is an open proposal framework for the Fractal ecosystem, designed to support continuous improvements in areas such as technical standards, protocol upgrades, and ecosystem development and more. Through the FIP process, proposals can be publicly submitted, discussed, and tracked, enabling developers and communities to participate in Fractal’s ongoing development. FIP is not only a way to document specific improvement proposals, but also a transparent and structured framework for advancing technical innovation, strengthening ecosystem infrastructure, and supporting Fractal’s long-term stability and growth. View more details on FIPs: | Number | Title | Owner | Layer | Type | Status | | ----------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------- | ------------ | --------- | ----------------- | ------- | | [FIP-101](https://github.com/fractal-bitcoin/fips/blob/main/fip-101.md) | [Fractal Standard Data Indexing Service](https://github.com/fractal-bitcoin/fips/blob/main/FIP-101/fip-101.md) | Fractal Team | Consensus | Standard Proposal | Rev-1.2 | # FIP-101: Fractal Standard Indexing Service FIP(Fractal Improvement Proposal) -101 introduces an open-source, permissionless, standardized indexing service for Fractal and follows a progressive activation path, with node support deployed first and subsequent components introduced in stages. {% content-ref url="/pages/TsFwC8XBcoDCVvp4TONO" %} [FIP-101: Fractal Standard Indexing Service](/overview/fips/fip-101-fractal-standard-indexing-service/fip-101-fractal-standard-indexing-service) {% endcontent-ref %} {% content-ref url="/pages/QAXWW3WJYLJfIZebUfeo" %} [FIP-101: Community Feedback & Reply](/overview/fips/fip-101-fractal-standard-indexing-service/fip-101-community-feedback-and-reply) {% endcontent-ref %} {% content-ref url="/pages/Pu51Ipd2ghJrV3bBVIo7" %} [FIP-101: Rewards Allocation](/overview/fips/fip-101-fractal-standard-indexing-service/fip-101-rewards-allocation) {% endcontent-ref %} {% content-ref url="/pages/p2wTJVqxPW1YNM4FTGwU" %} [FIP-101: Guide for Staking Users](/overview/fips/fip-101-fractal-standard-indexing-service/fip-101-guide-for-staking-users) {% endcontent-ref %} {% content-ref url="/pages/3YwMVRs2KJ5OZQ2uXDBP" %} [FIP-101: Guide for Indexer Operators](/overview/fips/fip-101-fractal-standard-indexing-service/fip-101-guide-for-indexer-operators) {% endcontent-ref %} # FIP-101: Fractal Standard Indexing Service #### Full Proposal: {% file src="/files/y8J4EgMC7Ou62MSMuI0z" %} #### For more details on FIPs: # FIP-101: Community Feedback & Reply Thanks to everyone who shared feedback on FIP-101. We carefully reviewed every comment—most centered on the *why* and *how* behind the proposal. To address these, we’ve prepared a letter to the community outlining the motivation and design rationale: ### Abstract The current indexing landscape on Fractal is fragmented, which leads to high costs for application integration and ecosystem collaboration. At the same time, as a piece of critical infrastructure, indexing lacks stable incentives; over the long term this can easily result in supply being concentrated among a small number of providers and in ecosystem lock-in. To address this, we propose promoting an open-source, permissionless, replaceable indexing service system with standardized outputs, and adjusting the block reward allocation structure: from the current 1:2 (merged mining : permissionless mining) to 1:1:1 (merged mining : permissionless mining : index mining). This adjustment does not change FB’s total issuance or emission schedule; the goal is to achieve a 1:1:1 distribution in the long-run statistical sense. Implementation details will be released in follow-up publications. The mainnet activation height and timeline will be clarified later and announced in advance. ### Why we want to do this #### Current problems 1. Indexing is too fragmented, making ecosystem collaboration too costly There are already many indexing solutions on Fractal—some commercial, some open-source. When indexing becomes the primary gateway for applications to read the on-chain world, inconsistencies between indexers get amplified into ecosystem-wide friction: * For the same on-chain data, different indexers return different fields, definitions, and results. * Application teams must do extensive adaptation work; maintenance costs are high and errors become more likely. * The ecosystem struggles to form unified developer practices and reusable infrastructure. In the long run, this fragmentation can drag the ecosystem into a pattern of “reinventing the wheel + repeated reconciliation”: slower development, higher maintenance costs, fragmented user experience, and ultimately weaker large-scale collaboration and growth across the Fractal ecosystem. 1. Indexing is foundational infrastructure, but it lacks a long-term, sustainable supply mechanism For applications and the ecosystem, “data availability, queryability, and reusability” are baseline requirements. But if indexing is carried for a long time mainly by a small number of teams or services, the ecosystem can easily become dependent and locked in. If a service becomes unstable, stops being maintained, or changes rules, neither availability nor neutrality can be reliably guaranteed—let alone true decentralization and long-term sustainability. What we need is not to “maintain the status quo of small, non-replaceable supply,” but a mechanism that can run over the long term: standardization + replaceability + open participation + sustainable incentives. #### Why now is the right time Over the past two quarters, the UniSat team has done substantial refactoring work on the indexer system we maintain. Memory usage has been reduced by about 80%, initial synchronization can complete within 24 hours, and hardware requirements have been significantly lowered. This means ordinary users may be able to run this indexing service without enterprise-grade servers. Technology is now mature, and ecosystem demand is becoming increasingly urgent. If we don’t launch a standardized solution soon, fragmentation will only worsen, and unifying standards later will become much harder. Now is the best window to push this forward. ### What we want to do 1. Core idea: make “standardized indexing” an ecosystem-level piece of infrastructure We want to elevate indexing mining to the same level of importance as mining, so it is no longer an auxiliary service maintained by “whoever has time” or “whoever subsidizes it,” but a long-term public capability within the Fractal ecosystem that anyone can participate in providing. It’s already clear to everyone: merged mining provides security, and permissionless mining provides open participation. But for applications to truly run, there must be a stable, unified, reusable data access layer. Indexing provides not just “convenience,” but data availability and composability: whether developers can reliably read what happened on-chain, build features using consistent definitions, and switch smoothly among services often depends on indexing. Therefore, we want to promote a community-usable standardized indexing service system with a very clear direction: * **Open source:** core code, specifications, and implementations should be as open and transparent as possible for auditing, reuse, and secondary development. * **Permissionless operation:** anyone can run an indexing instance without approval or whitelisting, preventing “gateways” from being controlled by a few parties. * **Outputs as standardized as possible:** the same class of on-chain behavior should be expressed with consistent fields, definitions, and semantics, reducing “different narratives for the same transaction.” * **Replaceable:** applications and the ecosystem can migrate across different indexing instances/implementations without being locked into one team or one service. Our goal is not to “force everyone to use a single indexer,” but to give the ecosystem a shared language and interchangeable implementations: you can choose the provider you trust, or run your own, but everyone speaks the same data definitions externally. 1. Bring indexing into block reward allocation Since indexing is public foundational infrastructure for the ecosystem, it should have a long-term, sustainable supply mechanism. The most direct way is to incorporate indexing into chain-level incentives, so that—like mining—it becomes a base network function rather than something kept alive by a team’s enthusiasm or short-term subsidies. We plan to adjust the structure of block rewards: * **Current:** 1 : 2 (merged mining : permissionless mining) * **Proposed:** 1 : 1 : 1 (merged mining : permissionless mining : index mining) Two points must be made clear: * **Total issuance and emission schedule do not change.** FB’s total supply, halving schedule, and other core monetary parameters remain unchanged; we are only reallocating the same block reward across different network roles. * **This is a long-run statistical target.** We aim for a distribution that approaches **1:1:1** over a longer time window, rather than mechanically splitting every single block equally, to avoid excessive rigidity that could harm operational flexibility. Under this design, we also consider three things simultaneously: open participation, fund security, and system stability. #### Open participation: anyone can run it Indexing is permissionless and fully open: individuals, teams, miners, or mining pools can run indexing instances. The indexing software will be open-sourced and accompanied by standards and documentation. No applications or approvals are needed; anyone providing service according to the specification can participate in reward allocation. Users who don’t want to run their own nodes can also participate by staking FB to an indexing node and sharing that instance’s rewards proportionally. #### Fund security: non-custodial staking, exit anytime, no slashing Staking uses a Taproot-based non-custodial mechanism: assets always remain controlled by your own private keys, and operators cannot move them. You can exit or switch indexing instances at any time. We do not introduce slashing: if an indexing service has issues, your principal is not confiscated; at most, rewards during that period are reduced or paused, lowering the participation threshold and risk. #### System stability: indexer failures do not affect block production Indexer reward settlement is asynchronous and not on the critical path of block production. Even if a large number of indexers go offline, the network can still mine and produce blocks normally. After service recovers, it can catch up and settle retroactively; long-run distribution still targets 1:1:1. ### Three WHYs #### Why change the reward structure to 1:1:1? The most directly impacted group by this adjustment is permissionless-mining miners. Their share of block rewards will drop from **2/3** to **1/3**. We make this trade-off because we want the reward structure to better match Fractal’s long-term needs and network division of labor. From practical observation, Fractal’s security is primarily guaranteed by merged mining, inheriting Bitcoin’s hashpower. Permissionless mining is more focused on providing open participation and decentralization. Meanwhile, for applications to truly run, there must be a stable, unified, reusable data access layer. Therefore, by introducing indexer incentives, we hope to expand the network’s benefit structure from a single block-production return to a multidimensional participation path of “mining + indexing (and staking participation),” forming a more long-term, continuous incentive source. Index mining contributes critically to ecosystem growth: every application and every developer needs indexing services. Without reliable indexing, the ecosystem cannot develop healthily. From a resource-allocation perspective, allocating part of rewards to indexing services better serves the ecosystem’s long-term interests. In addition, this change does not necessarily mean “miners will definitely earn less.” Miners/mining pools can also participate in the indexing system: they already have nodes and operational capabilities, and the marginal cost of additionally running an indexer is usually lower. If they participate in indexer supply, their revenue structure expands from “mining only” to “mining + indexing,” and actual returns depend on participation level and operational efficiency. #### Why not make it an “auxiliary mining function” without changing the original allocation? One core issue this proposal aims to solve is that indexing lacks an independent, long-term, sustainable incentive source. If indexing is merely an “auxiliary function” and the reward structure remains unchanged, indexer supply will naturally be squeezed into an optional item: when markets are weak it shrinks, when subsidies end it stops, and the ecosystem returns to the old state of “a few teams carrying the load.” To force an indexing mechanism in without changing allocation, more complex rules are often required—bringing a longer trial-and-error cycle and greater uncertainty. It must be emphasized: independent incentives do not mean “excluding miners.” Miners/mining pools can still join the indexing system as open participants and may even have a cost advantage due to existing infrastructure. #### Why switch directly? We prefer to switch directly once preparation is complete, rather than using a staged, smooth transition. A staged transition appears gentler and reduces the immediate impact on miners. But in practice it introduces more problems. First, technical complexity increases significantly: we would need to design a mechanism to adjust ratios gradually, which not only extends development time but also increases the risk of errors. More importantly, during the transition parameters keep changing, and participants cannot form stable expectations. Miners don’t know what their revenue will be next month; people who want to participate in indexing don’t know when the best time is. This uncertainty makes decision-making harder. The benefit of a direct switch is clarity. We will announce the activation height in advance to give everyone time to prepare. At that height, the new rules take effect. Everyone knows the exact timing and what will change, and can prepare accordingly—whether adjusting mining strategy or preparing to participate in indexing services. 2026-01-24 # FIP-101: Rewards Allocation The FIP-101 Proposal: Fractal Standard Indexing Service (details [here](/overview/fips/fip-101-fractal-standard-indexing-service/fip-101-fractal-standard-indexing-service)) incorporates the Index Mining Service into Fractal's block reward mechanism, forming a long-term and sustainable incentive system. *** ### Index Mining Service Block Rewards This reward is shared among all eligible indexers and stakers proportionally, based on each participant's effective stake share per block.
#### Fractal Block Reward Basics * Fractal block mined structure is 1:1:1 (Merged Mining: 1 | Permissionless Mining: 1 | Index Mining: 1). * The block reward for each Fractal block is 25 FB until the next halving block height (#2100000).
#### For Index Mining Rewards * The official Index Mining block reward is 25 FB per block until the next halving block height (#2100000). This reward is shared among all eligible indexers and stakers proportionally, based on each participant's effective stake share per block. * Block rewards are first sent to a cold wallet address, then allocated to indexing operators and stakers after a settlement window. **📌 Rewards Settlement Period** Please note that rewards from each block will become claimable after a **7-day settlement period (20160 blocks)**. Users will be able to claim rewards after the settlement cycle. Please wait for the 7-day settlement period to complete. **User Staking Yield Estimates Under Different Conditions** Assumptions for estimating Bob's staking yield: * Bob's staked amount: 100,000 FB * Daily Index Mining blocks: 960 * Fractal Official Indexer commission: 10% * Fractal Official Indexer's valid proof submission rate is 100%, with no penalty * Reinvestment: Not included * APR calculation method: daily reward x 365 / staked principal **Daily reward estimates under different total network stake sizes (per 100,000 FB)** In the table below, each value is denominated in **FB / day**.
Total Network Stake100%30%37.50%45%52.50%60%70%80%90%
5m FB432129.6162194.4226.8259.2302.4345.6388.8
10m FB21664.88197.2113.4129.6151.2172.8194.4
15m FB14443.25464.875.686.4100.8115.2129.6
20m FB10832.440.548.656.764.875.686.497.2
30m FB7221.62732.437.843.250.457.664.8
As shown in the table, when total network stake is 20m FB, after decentralized multi-node staking officially launches, each 100,000 FB can receive 108 FB in daily rewards. **APR estimates under different total network stake sizes**
Total Stake100%30%37.50%45%52.50%60%70%80%90%
5m FB157.68%47.30%59.13%70.96%82.78%94.61%110.38%126.14%141.91%
10m FB78.84%23.65%29.57%35.48%41.39%47.30%55.19%63.07%70.96%
15m FB52.56%15.77%19.71%23.65%27.59%31.54%36.79%42.05%47.30%
20m FB39.42%11.83%14.79%17.74%20.70%23.65%27.59%31.54%35.48%
30m FB26.28%7.88%9.86%11.83%13.80%15.77%18.40%21.02%23.65%
*** ### Index Mining Reward Distribution and Settlement #### 🔹Stake Participants All user can participate in index mining and earn rewards. The system continuously generates Index Mining rewards on a per-block basis. Users participate in index mining reward distribution by staking in support of a specific Indexer. Once the Indexer submits a valid proof, the reward for that block enters the distribution process. The rewards for stake participants depend on: * Index Mining block rewards release ratio * Your share of the total stake under that Indexer * The commission set by the Index Operator * Whether the Index Operator submits a valid proof and whether a delayed submission penalty is triggered 👉 Specific reward details can be viewed on the detail page of the index operator you have staked with [https://index-staking.fractalbitcoin.io](https://index-staking.fractalbitcoin.iohttps//index-staking.fractalbitcoin.io)
#### 🔹Index Operators Anyone can sign up their own indexer easily by adopting Fractal's lightweight indexer design and joining Fractal's data indexing network. * Participation requirement: Index Operators are required to submit valid proofs on a regular basis. Only Index Operators that submit valid proofs for allocated blocks are eligible to participate in reward distribution * Reward distribution: After each successful proof submission, index mining block rewards will be distributed to the Index Operator and its stakers * Fee Ratio: An Index Operator may set its own Fee Ratio (the percentage of a indexer's allocated FB staking rewards that is charged by the index operator as a fee) * Indexers can set their commission rate between 0% and 15% * Commission changes take effect after 7 days * Once a commission change is submitted, no further changes can be made until the pending change takes effect * Delayed submission decay: * Indexers must submit a valid hash proof within 720 blocks of block production. * After this deadline, a delay is applied for every additional 120 blocks of delay. Rewards follow a progressive delay schedule, with lighter reductions early and steeper reductions as the delay increases. * Rewards decay to zero at 1,440 blocks past the deadline. * **Settlement period**: Each block reward becomes claimable after a **7-day settlement period**, and the records can be tracked on the My Staking page *** • For every 3 Fractal blocks, 1 block is produced by Index Mining • Each Index Mining block rewards: 25 FB per block • Index Mining block rewards will be distributed among indexer operators and staking participants • Minimum staking requirement will be reduced from 50 FB to 1 FB • Anyone can participate in Index Mining & Staking and earn rewards. Participation Rules * Staking is open to all addresses * Minimum stake per address is 1 FB, no maximum stake limit. • Anyone can run an indexer and participate in Index Mining to earn block rewards. Disclaimer: This page is provided for informational purposes only and is intended to explain the FIP-101 Index Mining reward mechanism. The actual participation requirements, reward calculations, distribution results, and other applicable rules are subject to the live system operation and the information displayed on the relevant page. # FIP-101: Guide for Indexer Operators This guide serves only as a reference for users. #### What Is an Indexer Operator An Indexer Operator is responsible for running a Fractal node and the open-source indexer, periodically submitting block proofs to the indexing coordinator, and receiving the operator's share of rewards from the coordinator. Staking users can choose your node to participate in staking. When your node submits valid proofs and has a higher staking amount, it will receive a higher weight in the reward distribution for the corresponding blocks.
*** ### Deploy Fractal Node & Lightweight Indexer You can refer to the resources below to deploy your own node and configure your commission rate, reward wallet, and proof submission settings.\ Deploy the full indexing service using the open-source repositories: * Lightweight Indexer github repo: * Fractal open-source indexer: * Staking indexer repository: \ The operator must ensure that: * The Fractal node remains properly synced * `brc20` / `stake` related indexed data is continuously updated * Proofs are submitted within the valid window * The reward receiving address and the owner wallet are properly secured * The reward receiving address must maintain a sufficient FB balance to pay gas fees **Submit Proofs** Valid proofs are periodic runtime proofs submitted by an indexer. Only indexers that pass verification can participate in reward distribution. You can refer to the following link for proof submission: [https://github.com/fractal-bitcoin/fractal-indexer-deploy/tree/main/proof-publisher ]()
Indexers are expected to submit valid proof within 100 blocks. \ **Late submission penalty** • Indexers must submit a valid hash proof within 720 blocks of block production. • After this deadline, a delay is applied for every additional 120 blocks of delay. Rewards follow a progressive decay schedule, with lighter reductions early and steeper reductions as the delay increases. • Rewards decay to 0 after 1,440 blocks *** ### Indexer Details Management Visit [https://index-staking.fractalbitcoin.io](https://index-staking.fractalbitcoin.iohttps//index-staking.fractalbitcoin.io), connect your deployment address, switch to the Indexer Operator role, and then view your indexer information, stake addresses, commission settings, proof submission status, and Operation History. \ At the same time, make sure to check whether the deployment information is displayed correctly.
*** ### **Indexer Commission Rules** \ Commission is the percentage of an index operator's allocated FB staking rewards that is charged by the index operator as a fee. • Indexers can set their commission rate between 0% and 15% \ **Commission changes:** • Commission changes take effect after 7 days • Once a commission change is submitted, no further changes can be made until the pending change takes effect
*** ### Reward Allocation Rules & **Settlement** Only indexers that submit valid proofs for the allocated block can participate in reward allocation.\ Index Mining rewards are generated block by block and distributed according to effective staking shares. Rewards during Public Testing will follow the official Index Mining mechanism, allocation and settlement rules, and the block reward of 25 FB per block. \ **Reward Allocation** For the indexer operator, for each successful submission, block rewards are calculated and allocated to each indexer after a settlement window based on their effective stake share. The rewards for each indexer is split between the Operator and the Staker. Indexer Operators will get a share of the rewards as Commission, with the commission rate set individually by each indexer. Stakers will get rewards proportional to their staking amount. \ For stake participants, after users stake FB, they do not receive a fixed yield. Instead, they participate in Index Mining block reward distribution based on the operating status of the corresponding Indexer, the user's effective staking share within that Indexer, and the Indexer's effective share of total network staking. | **User Reward = Block Released Reward x (Indexer Effective Stake / Total Network Effective Stake) x (1 - Indexer Commission Rate) x (User's Stake / This Indexer's Raw Total Stake)** | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | For more details on rewards allocation, please refer to [FIP-101: Rewards Allocation](/overview/fips/fip-101-fractal-standard-indexing-service/fip-101-rewards-allocation) \ **Reward Settlement Cycle** To avoid reward calculation errors caused by block rollbacks or indexing errors, Index Mining rewards are not claimable immediately after they are generated. * Index Mining rewards enter the reward calculation scope 1,000 blocks after the relevant block is produced. * They become claimable 20,160 blocks after the relevant block is produced, or approximately 7 days. *** ### Notes * No security deposit is required, but invalid proofs do not participate in reward distribution for the corresponding block * The owner address and the reward address have different responsibilities; do not confuse them after registration * The stability of proof submission directly affects reward eligibility * The current implementation may differ from the operational rules during the testing period; development and external communication should distinguish between the current implementation and the testing plan # FIP-101: Guide for Staking Users This guide serves only as a reference for users. FIP-101 introduces Fractal's Standard Indexing Service, a framework designed to make indexing more open, permissionless, and economically aligned with the network. It enables indexers to participate in maintaining Fractal’s indexing layer, while FB holders can stake FB to support indexers. Index Mining is the block reward mechanism for this system, distributing FB rewards to eligible indexers and stake participants who help support the indexing network. ### Index Mining Staking Rewards * For every 3 Fractal blocks, 1 block is produced by Index Mining * Fractal block reward: 25 FB per block * Index Mining block rewards will be distributed among indexer operators and staking participants \ **Please note** that rewards from each block will become claimable after a 7-day settlement period; Rewards earned will not be immediately available for claiming. Please wait for the settlement period to complete. 👉 View rewards details [here ](/overview/fips/fip-101-fractal-standard-indexing-service/fip-101-rewards-allocation) *** ### How to Stake in Index Mining? Visit Index Mining website [https://index-staking.fractalbitcoin.io](https://index-staking.fractalbitcoin.iohttps//index-staking.fractalbitcoin.io) and connect your wallet. On the homepage, you will be able to view the current staking overview, including: * Active indexers * Total FB staked * Current allocated block reward * Indexer list * Your personal staking details
*** ## **Start Participating in Index Mining Staking** #### 1. Browse the Indexer List In the Indexer List panel, you can view all current indexers, along with their Stake Share and Fee Ratio. * Stake Share refers to the proportion of FB staked on that indexer compared to the total FB staked across all indexers. * Commission is the percentage of an index operator’s allocated FB staking rewards that is charged by the index operator as a fee. You can click View Details on the right side of each indexer to see more information about that indexer. \ Note: If you are an index operator, you can refer to [FIP-101: Guide for Indexer Operators](/overview/fips/fip-101-fractal-standard-indexing-service/fip-101-guide-for-indexer-operators) to apply as one of the test index operators for Fractal index mining.
*** #### 2. Stake FB and Earn Choose the indexer you want to support, then click Stake Now on the right side of that indexer. On the staking page: * Enter the amount of FB you want to stake * Review the staking details carefully, and then click Stake * Sign the transaction and complete the staking process
Tips: 1. After staking is completed, the system will transfer staked FB to your dedicated staking address and record your association with the selected indexer on-chain. 2. Minimum Stake per Address = 1 FB 📌 Reward allocation takes place after a settlement window of 20160 blocks (\~ 7 days). Users will be able to claim rewards after settlement cycle.
#### 3. View and Claim Your Staking Rewards Staking rewards must be **claimed manually**. Click **My Staking** in the navigation bar to open your staking dashboard. There you will be able to view: * Rewards History — FB staking rewards you have earned * Operation History — your staking-related activity records
*** ### How to Unstake * There is no lock-up period, and you can unstake at any time. * To unstake, simply transfer FB out of your staking address to any address. * The system will automatically detect the balance change and update your staking status.
# FlP-101: Roadmap
### **Phase 1:** FIP-101 Proposal and Fractal Node Upgrade #### 1. FIP-101 **Proposal Initiated (December 9, 2025)** FIP-101 was introduced as a proposal for a standardized, open-source, and permissionless indexing service for Fractal. Its goal is to support the long-term stability, decentralization, and sustainable operation of indexing infrastructure, while preserving network liveness and minimizing impact on existing consensus processes. #### 2. Community Feedback and Proposal Finalized **(9 Dec- 24 Jan 2026)** The proposal was opened to community discussion to gather feedback on the mechanism, incentives, and implementation direction. Following community feedback and refinement, the proposal framework and core design were finalized in the revised FIP-101 draft.The revised proposal defines the Fractal Standard Indexing Service, including open participation, reward reallocation, non-custodial staking, non-blocking settlement, and progressive activation. [More details](/overview/fips/fip-101-fractal-standard-indexing-service/fip-101-fractal-standard-indexing-service). #### 3. Development & Preparation for Node Upgrade (25 Jan- 11 Feb 2026) After the proposal was finalised, the team worked with Fractal mining pools and node operators to prepare and implement the node upgrade required for the FIP-101 consensus change. #### 4. FIP-101 Node Upgrade Activated (February 11, 2026） On February 11, the Fractal Node upgrade was already activated at block height 1,500,000, which enforces the consensus mechanism change (Adjusted block reward distribution from the 1:2 (Merged Mining : Permissionless Mining) to 1:1:1 (Merged Mining : Permissionless Mining : Index Mining) and enables the subsequent reward distribution change. * Fractal node v0.3.0 Release: [https://github.com/fractal-bitcoin/fractald-release/releases/tag/v0.3.0](https://t.co/UiuYOyReiH) * Source code changes (v0.3.0): [https://github.com/fractal-bitcoin/fractal/commits/fractal-29.x/](https://t.co/j8NCY260LA) * Technical notes: [https://github.com/fractal-bitcoin/fips/blob/main/fip-101-technical-notes-part-1-node-changes.md](https://t.co/WIeIpOPCYR) * More details on FIP-101: [https://github.com/fractal-bitcoin/fips/blob/main/fip-101.md](https://t.co/C7P79O1Vrb) *** ### **Phase 2:** Build & Validate FIP-101 is currently in the core development stage, focused on shipping key components: #### **1. Open-Sourced Lightweight Indexer Development** The team is developing an open-sourced lightweight indexer implementation for Fractal. The goal is to make it easier for third-party operators to run their own indexer and participate in the indexing network. #### **2. Staking Mechanism Development** The staking mechanism is being developed to support decentralized participation in Index Mining. This includes stake registration, reward eligibility, operator-staker relationships, and reward sharing logic. #### **3.** Internal Validation Internal validation will test the stability, accuracy, and performance of the lightweight indexer, staking mechanism, and Index Mining reward flow before wider public participation. *** ### Phase 3: Public Testing Public testing will be introduced in stages. We are aiming for this phase to begin in late May 2026 and continue for at least 8 weeks, pending development and testing progress. **Stage 1: Capped Staking with Single Indexer** Public testing will begin with a controlled setup using a single indexer and capped staking participation. This stage is designed to validate the staking flow, reward release mechanism, and user participation process under limited conditions. **Stage 2: Multi-Indexer Testing - now in Progress** The system will expand to support multiple indexers, allowing third-party indexer participation to be tested in a broader environment. This stage will help validate proof submission, reward competition, and network behavior before the full rollout. • Continued System Optimization Based on Testing and Feedback. *** ### **Phase 4:** Full Rollout #### Official Launch of Index Mining and Staking Following public testing and optimisation, FIP-101 Index Mining and staking will be officially launched on Fractal. * Third-party indexer operators will be able to join permissionlessly * Users will be able to participate as stakers * Index Mining block rewards will be fully distributed according to the official mechanism. * Detailed rules and final reward distribution arrangements will be announced separately # FIP-101: Technical Notes FIP-101: Lightweight indexer is open source -> Lightweight Indexer: [https://github.com/fractal-bitcoin/fractal-indexer](https://t.co/lnD3BYVmzW) -> Stake Indexer: [https://github.com/fractal-bitcoin/stake-indexer](https://t.co/mVpY8vUIkc) -> Deployment Docs: [https://github.com/fractal-bitcoin/fractal-indexer-deploy](https://t.co/jdPvw1vdAn) To provide an additional safeguard for stakers under extreme situations and further reinforce the non-custodial nature of staking, we have open-sourced and deployed a standalone emergency unstake tool for index mining. -> Repository: -> Web Tool: {% content-ref url="/pages/vCTvVI6EaZxPbzeEaAhj" %} [FIP-101: Technical Notes - Node Changes](/overview/fips/fip-101-fractal-standard-indexing-service/fip-101-technical-notes/fip-101-technical-notes-node-changes) {% endcontent-ref %} {% content-ref url="/pages/i5RZnW38NgBIPrEvt6Ft" %} [brc-20 Index State Hash Verification Scheme v2 (MuHash Version)](/overview/fips/fip-101-fractal-standard-indexing-service/fip-101-technical-notes/brc-20-index-state-hash-verification-scheme-v2-muhash-version) {% endcontent-ref %} # FIP-101: Technical Notes - Node Changes ### Abstract This proposal introduces a third block type to the Fractal Bitcoin network—the Indexer Block—designed to incentivize providers running Bitcoin Layer 2 data indexing services. This block type replaces traditional Proof of Work with Schnorr signature verification, implementing secure and decentralized indexer incentive distribution through a cold-hot wallet separation architecture and cursor range mechanism. ### Motivation #### Background Fractal Bitcoin currently supports two block types: * **Legacy blocks**: Traditional PoW mining, 45-second target interval * **AuxPoW blocks**: Merged mining, 90-second target interval With the rapid growth of Layer 2 applications such as Ordinals inscriptions in the Bitcoin ecosystem, the demand for high-quality indexing services has increased significantly. These indexing services require: * Continuous operation of full nodes and block data parsing * Maintenance of large-scale index databases * Provision of highly available API services However, there is currently no effective on-chain incentive mechanism to support operators of these critical infrastructure services. #### Goals This proposal aims to: 1. **Incentivize Indexing Services**: Create sustainable economic incentives for inscription data indexing service providers 2. **Decentralized Distribution**: Support fair participation of multiple indexing service providers through the cursor range mechanism 3. **Security Assurance**: Employ cold-hot wallet separation architecture to ensure authorization mechanism security 4. **Minimal Changes**: Reuse existing AuxPoW mechanisms to reduce implementation complexity and risk ### Specification #### Block Type Identification Indexer blocks reuse the `VERSION_AUXPOW` flag (0x100), distinguished by Chain ID: | Block Type | Chain ID | VERSION\_AUXPOW | nVersion Example | | ---------- | -------- | --------------- | ---------------- | | Legacy | - | No | 0x00000001 | | AuxPoW | 0x2024 | Yes | 0x20240101 | | Indexer | 0x2026 | Yes | 0x20260101 | #### Indexer Proof Structure (CIndexerProof) Indexer blocks contain a 168-byte proof structure: | Field | Size | Description | | -------------- | -------- | ----------------------------------------- | | hotPubKey | 32 bytes | Hot wallet x-only public key | | nAuthTimestamp | 4 bytes | Authorization expiry timestamp (Unix) | | nRangeStart | 2 bytes | Authorized cursor range start (inclusive) | | nRangeEnd | 2 bytes | Authorized cursor range end (inclusive) | | coldSignature | 64 bytes | Cold wallet Schnorr signature | | hotSignature | 64 bytes | Hot wallet Schnorr signature | #### Signature Mechanism **Cold Wallet Signature**: ``` message = SHA256(hotPubKey || nAuthTimestamp || nRangeStart || nRangeEnd) coldSignature = SchnorrSign(coldPrivKey, message) ``` **Hot Wallet Signature**: ``` message = blockHash (Double-SHA256 of block header) hotSignature = SchnorrSign(hotPrivKey, message) ``` #### PoW Hash Indexer blocks still require proof of work, using the following hash: ``` powHash = SHA256(hotPubKey || blockheader) ``` * `hotPubKey` binds the PoW work to a specific hot wallet, preventing work theft * `blockheader` contains nonce and time for mining adjustment * Authorization parameters (nAuthTimestamp, nRangeStart, nRangeEnd) are already verified through the cold wallet signature, so they don't need to be included in the PoW hash #### Cursor Range Mechanism The cursor value is calculated from the lower 2 bytes of the previous block hash: ``` cursor = prevBlockHash[0] | (prevBlockHash[1] << 8) Range: 0 ~ 65535 ``` Indexing service providers are authorized a range `[nRangeStart, nRangeEnd]` and can only produce blocks when the cursor falls within that range. **Example**: Three providers each allocated 1/3 of the range * Provider A: \[0, 21844] ≈ 33.3% * Provider B: \[21845, 43689] ≈ 33.3% * Provider C: \[43690, 65535] ≈ 33.3% #### Validation Rules **CheckProofOfWork Phase (Context-free)** 1. Verify Chain ID == 0x2026 2. Verify indexerProof exists 3. Verify authorization not expired: blockTime <= nAuthTimestamp 4. Verify cursor within authorized range: nRangeStart <= cursor <= nRangeEnd 5. Verify PoW Hash: GetProofOfWorkHash(header) < target (nBits = powLimit) 6. Verify cold wallet signature is valid 7. Verify hot wallet signature is valid **ContextualCheckBlockHeader Phase (Context-required)** 1. Verify block height >= activation height (1,500,000) 2. Verify previous block is not an Indexer block (no consecutive blocks) 3. Verify quantity constraint: Indexer count cannot exceed both Legacy and AuxPoW counts #### Quantity Constraint Let post-activation block statistics be: * L = Legacy block count * A = AuxPoW block count * I = Indexer block count A new Indexer block is rejected if and only if `I > L && I > A`. This constraint ensures the three block types trend toward a 1:1:1 ratio. #### Difficulty Adjustment Indexer blocks are treated as Legacy blocks in ASERT difficulty calculation: * Use Legacy target interval (45 seconds) * Counted in Legacy block statistics Indexer blocks have nBits set to powLimit, and PoW verification uses the hash calculated by `GetProofOfWorkHash`. ### Rationale #### Why Reuse VERSION\_AUXPOW 1. Chain ID already exists in nVersion, no new flag bits needed 2. Maintains simple version number structure 3. Reuses existing serialization mechanism 4. Reduces implementation risk #### Why Cold-Hot Wallet Separation 1. **Security**: Cold wallet private key stored offline, never touches network 2. **Flexibility**: Hot wallet authorization can have expiry time, limited impact if leaked 3. **Manageability**: Node maintainers can adjust authorizations at any time #### Why Cursor Range Mechanism 1. **No block height needed**: Validation can be completed in CheckProofOfWork 2. **Natural randomness**: Based on previous block hash, unpredictable 3. **Flexible allocation**: Supports arbitrary ratio distribution 4. **No single point of failure**: One provider going offline doesn't affect others #### Why Indexer Blocks Use Legacy Difficulty Track Indexer blocks are treated as Legacy blocks in difficulty calculation for the following reasons: 1. **Keep AuxPoW track stable**: AuxPoW blocks are produced by large mining pools through merged mining; their difficulty adjustment should only reflect changes in merged mining hashrate 2. **Incentive balance**: Indexer blocks share the 45-second target interval with Legacy blocks; counting them in the Legacy track maintains competitive balance between the two 3. **Simplified implementation**: No need to create a third difficulty track for Indexer blocks ### Security Considerations #### Authorization Security * **Cold wallet offline**: Cold wallet private key never touches the network, only used for issuing authorizations * **Authorization expiry**: Each authorization has an expiry time, limiting the impact of leaks * **Range limitation**: Authorizations are only valid for specific cursor ranges, further limiting risk #### Abuse Prevention * **Quantity constraint**: Indexer block count cannot exceed both Legacy and AuxPoW, preventing single entity network control * **No consecutive blocks**: Two consecutive Indexer blocks not allowed, ensuring other miners have block production opportunities * **Cursor randomness**: Cursor is based on previous block hash, cannot be predicted or manipulated #### Attack Vector Analysis | Attack Type | Mitigation | | ---------------------- | ----------------------------------------------------------------------- | | Cold wallet leak | Can replace cold wallet public key via hard fork | | Hot wallet leak | Expiry mechanism limits impact; can immediately revoke and re-authorize | | Provider collusion | Quantity constraint ensures Indexer blocks don't exceed 1/3 | | Timestamp manipulation | Authorization expiry check performed in CheckProofOfWork | ### Backward Compatibility This proposal is a **hard fork**. After activation height 1,500,000: * Old version nodes cannot parse Indexer blocks * Old version nodes will reject chains containing Indexer blocks * All nodes must upgrade before activation ### Activation * **Activation Height**: 1,500,000 * **Activation Method**: Hard fork, height-based activation ### Reference Implementation See Fractal Bitcoin codebase: * `src/primitives/indexer.h` - Indexer proof data structure * `src/primitives/indexer.cpp` - Indexer proof implementation * `src/validation.cpp` - Validation logic * `src/rpc/indexer_miner.cpp` - RPC interface # brc-20 Index State Hash Verification Scheme v2 (MuHash Version) #### 1. Background and Design Evolution **1.1 Limitations of the v1 Scheme** The v1 scheme uses a dual Merkle Tree plus chained structure. Although it can locate differences precisely, it has the following issues: * **Chained dependency**: `prev_commitment_hash` causes any difference in an intermediate block to propagate to all subsequent blocks. * **Version incompatibility**: after indexer code upgrades or rule changes, hashes of intermediate blocks may differ even when the final state is the same. * **Incremental calculation**: only changed addresses are committed, requiring additional delta calculation logic. * **Poor fault tolerance**: differences in intermediate processing cannot be tolerated; every block must match exactly. **1.2 Core Idea of the v2 Scheme** Inspired by the MuHash mechanism used for the Bitcoin UTXO set, this scheme uses a full-state commitment: * **Full state**: each block commits to the complete BRC-20 balance state, not only the changed addresses. * **Independent calculation**: each block hash is calculated independently and does not depend on the previous block. * **Final consistency**: as long as the final balance state is the same, the hash is the same, tolerating differences in intermediate processing. * **Version compatibility**: different versions of indexer code can produce the same hash as long as they eventually converge to the same state. This design is especially suitable for index mining scenarios: indexers with different implementations and different versions are allowed, as long as their final states are consistent. #### 2. Introduction to the MuHash Mechanism **2.1 What Is MuHash** MuHash (Multiplicative Hash) is a commutative hash function with the following properties: * **Commutativity**: the order in which elements are added does not affect the final result. * **Incremental updates**: elements can be added or removed efficiently. * **Determinism**: the same set always produces the same hash. **2.2 Mathematical Principle of MuHash** MuHash is based on a multiplicative group over a finite field: 1. Serialize each element into a byte string. 2. Hash the byte string and map it to an element in a large prime field. 3. Multiply all elements in the field. 4. Hash the final result once more to obtain a fixed-length output. Key properties: * Multiplication is commutative: a x b = b x a. * Therefore, element order does not affect the result. * Incremental updates are possible: to add element c, multiply by c; to remove element d, divide by d. **2.3 Bitcoin Implementation Reference** Bitcoin uses MuHash3072 to calculate the hash of the UTXO set: * It uses a 3072-bit prime field. * Each UTXO is serialized and mapped to a field element through ChaCha20. * The field elements of all UTXOs are multiplied together. * The final result is output as a 32-byte hash through SHA-256. #### 3. v2 Scheme Design **3.1 Data Input** Use the full balance state after merging the overlay: **TokenUsersBalanceData**: `map[string]map[string]*BRC20TokenBalance` * `[ticker][pkscript] -> balance` * Contains all addresses with non-zero balances, not only addresses changed in the current block. * This is the final state after processing the current block. **BRC20TokenBalance structure:** ``` type BRC20TokenBalance struct { Ticker string PkScript string // Raw bytes, not hex AvailableBalance uint128.Decimal TransferableBalance uint128.Decimal } ``` **3.2 Balance Entry Serialization** Each balance entry (ticker + pkscript + balance) is serialized into a byte string and used as an input element to MuHash. **Serialization format:** ``` balance_entry = ( len(ticker) [4 bytes, little-endian] ticker [variable length, UTF-8 bytes] len(pkscript) [4 bytes, little-endian] pkscript [variable length, raw bytes] len(available_balance_str) [4 bytes, little-endian] available_balance_str [variable length, UTF-8 bytes, generated by AvailableBalance.String()] len(transferable_balance_str) [4 bytes, little-endian] transferable_balance_str [variable length, UTF-8 bytes, generated by TransferableBalance.String()] ) ``` **Key points:** * All integers use little-endian encoding. * Variable-length fields use a 4-byte length prefix. * Balances use the `Decimal.String()` method to ensure determinism. * The ticker uses lowercase form (BRC-20 is case-insensitive). * Only entries with non-zero balances are serialized (a zero balance is treated as nonexistent). **3.3 MuHash Calculation** **Steps:** 1. **Collect all balance entries** * Iterate through `TokenUsersBalanceData`. * Skip zero-balance entries (both `AvailableBalance` and `TransferableBalance` are zero). 2. **Serialize each entry** * Serialize it into a byte string according to the format above. 3. **Map to field elements** * For each serialized byte string, use ChaCha20 or SHA-256 to map it to a MuHash3072 field element. * Specific mapping method: `domain_element = Hash(balance_entry) mod prime`. 4. **Field multiplication** * The initial value is 1 (the multiplicative identity of the field). * Multiply each field element: `result = result x element mod prime`. * Because multiplication is commutative, order does not matter. 5. **Final hash** * Serialize the field element into a byte string (3072 bits = 384 bytes). * Apply SHA-256 to obtain the 32-byte `brc20_state_hash`. **3.4 Block Commitment Structure** ``` BlockCommitment { version: uint8 // Protocol version number, v2 = 0x02 height: uint64 // Block height block_hash: [32]byte // Block hash brc20_state_hash: [32]byte // Balance state hash calculated by MuHash } ``` **Final commitment hash:** ``` commitment_hash = SHA256( version + height + block_hash + brc20_state_hash ) ``` **Notes:** * `prev_commitment_hash` is not included; each block is independent. * `brc20_state_hash` depends only on the final balance state of the current block. * The same balance state always produces the same `brc20_state_hash`. #### 4. Verification Protocol **4.1 Fast Verification** Two nodes exchange `commitment_hash` (32 bytes) to determine whether their BRC-20 states at the given height are consistent. If `commitment_hash` matches, it means: * The block height is the same. * The block hash is the same. * The full BRC-20 balance state is exactly the same. **4.2 Divergence Localization** Because MuHash does not support hierarchical localization like a Merkle Tree, divergence localization requires other strategies: **Option 1: Ticker-level MuHash** Calculate a separate MuHash for each ticker: ``` ticker_state_hash[ticker] = MuHash(all balance entries of this ticker) ``` When the global `brc20_state_hash` does not match: 1. Exchange the lists of all tickers. 2. Compare the `ticker_state_hash` of each ticker. 3. Locate the specific ticker that is inconsistent. 4. Exchange all balance entries of that ticker and compare them entry by entry. **Option 2: Direct comparison** If `brc20_state_hash` does not match: 1. Exchange the lists of all tickers and the address count for each ticker. 2. For tickers with different counts, exchange the complete address lists. 3. For tickers with the same counts but possible differences, exchange all balance entries and compare them. **Recommendation:** * Use Option 1 (ticker-level MuHash) in production environments to support efficient localization. * Simpler implementations can use Option 2 for direct comparison. **4.3 Checkpoint Mechanism** It is recommended to publish a checkpoint every 1000 blocks: ``` Checkpoint { height: uint64 block_hash: [32]byte commitment_hash: [32]byte brc20_state_hash: [32]byte // Optional, for fast localization version: uint8 timestamp: int64 signature: []byte // Optional } ``` New nodes can start synchronization from a checkpoint and verify the commitments of subsequent blocks. #### 5. Performance Analysis **5.1 Computational Overhead** Assume the full state contains: * 1000 tickers * An average of 1000 addresses with balances per ticker * 1 million balance entries in total **MuHash calculation:** * Serialization: 1 million operations (about 100 bytes each) * Field mapping: 1 million ChaCha20 or SHA-256 operations * Field multiplication: 1 million 3072-bit big integer multiplications * Final hash: 1 SHA-256 operation **Estimated time:** * Serialization: \~100 ms * Field mapping: \~500 ms (SHA-256) or \~200 ms (ChaCha20) * Field multiplication: \~2000 ms (3072-bit big integer operations) * Total: \~2-3 seconds Compared with the time required for block indexing itself (usually 1-10 seconds), this overhead is acceptable. **Optimization strategies:** * Use incremental updates: perform add/remove operations only for changed addresses. * Cache the MuHash state of the previous block and calculate the current block incrementally. * Use a more efficient big integer arithmetic library (GMP). **5.2 Storage Overhead** Store one `BlockCommitment` per block: ``` version: 1 byte height: 8 bytes block_hash: 32 bytes brc20_state_hash: 32 bytes commitment_hash: 32 bytes Total: 105 bytes/block ``` 1 million blocks are approximately 105 MB, which is fully acceptable. If ticker-level localization needs to be supported, additionally store the hash of each ticker: ``` Each ticker: ticker_name (variable length, 4 bytes on average) + ticker_state_hash (32 bytes) ~= 40 bytes 1000 tickers x 40 bytes = 40 KB/block 1 million blocks ~= 40 GB ``` This can be stored on demand, with detailed data retained only for the most recent 10000 blocks. #### 6. Advantages of the Scheme **6.1 Final Consistency** * As long as the final balance state is the same, the hash is the same. * Differences in intermediate processing are tolerated (different event parsing orders, temporary states, etc.). * Suitable for coexistence of multi-version indexers. **6.2 Version Compatibility** * After indexer code upgrades, the hash remains consistent as long as the final state converges. * Differences in intermediate blocks will not cause all subsequent blocks to become inconsistent. * Supports progressive upgrades and rollbacks. **6.3 Independent Calculation** * The hash of each block is calculated independently and does not depend on the previous block. * Hashes of multiple blocks can be calculated in parallel. * Verification can start from any checkpoint. **6.4 Full-State Commitment** * Commits to the complete balance state, not only changed addresses. * More intuitive and easier to understand and verify. * Can be used directly for state synchronization and snapshots. **6.5 Incremental Updates** * MuHash supports incremental updates (add/remove). * The MuHash state of the previous block can be cached, updating only changed parts. * Actual computational overhead is much lower than a full recalculation. #### 7. Limitations of the Scheme **7.1 Weaker Localization Capability** * MuHash itself does not support hierarchical localization. * Additional ticker-level MuHash or direct comparison is required. * Localization efficiency is lower than with a Merkle Tree. **7.2 Higher Computational Overhead** * Full-state MuHash calculation involves big integer operations. * It is more time-consuming than Merkle Tree SHA-256 calculation. * Optimization is required (incremental updates, efficient libraries). **7.3 Does Not Verify Correctness** * Same as v1, it only proves that "the results are consistent"; it does not prove that "the results are correct". * Other mechanisms, such as majority consensus, are needed to ensure correctness. **7.4 Zero-Balance Handling** * Zero-balance entries do not participate in MuHash calculation (they are treated as nonexistent). * The semantics of "zero balance" must be clearly defined (both `AvailableBalance` and `TransferableBalance` are zero). #### 8. Edge Case Handling | Scenario | Handling | | ---------------------------- | --------------------------------------------------------------------------------------------------------------------------- | | Block has no BRC-20 activity | The balance state is the same as the previous block, and `brc20_state_hash` is the same. | | All balances are zero | The MuHash result is 1 (the multiplicative identity), and the final `brc20_state_hash` is a specific value. | | Ticker is an empty string | This should not occur. If it does, process it normally (length prefix is 0). | | pkscript is empty | This should not occur. If it does, process it normally (length prefix is 0). | | Balance is zero | It does not participate in MuHash calculation (skip this entry). | | Block reorg | Recalculate `brc20_state_hash` for blocks after the reorg. Calculation is independent; no chained state rollback is needed. | #### 9. Comparison with the v1 Scheme | Feature | v1 (Merkle Tree) | v2 (MuHash) | | ------------------------- | --------------------------------------------------------------------------- | ------------------------------------------------------------------------- | | State commitment | Incremental (commits only changed addresses) | Full (commits all non-zero balances) | | Chained dependency | Yes (`prev_commitment_hash`) | No (each block is independent) | | Final consistency | No (intermediate differences propagate) | Yes (only the final state needs to match) | | Version compatibility | Poor (intermediate block differences cause all subsequent blocks to differ) | Good (tolerates intermediate differences and only checks the final state) | | Localization capability | Strong (hierarchical localization to a specific address) | Weak (requires an additional mechanism or direct comparison) | | Computational overhead | Low (SHA-256) | High (big integer operations) | | Incremental updates | Not supported (Merkle Tree must be rebuilt) | Supported (MuHash naturally supports add/remove) | | Implementation complexity | Medium (Merkle Tree construction) | High (MuHash big integer operations) | | Applicable scenarios | Strict consistency requirements, precise localization needed | Final consistency, intermediate differences tolerated | #### 10. Implementation Recommendations **10.1 MuHash Library Selection** * Use Bitcoin Core's MuHash3072 implementation (C++). * Or use Go's `big.Int` to implement a custom MuHash. * GMP (GNU Multiple Precision Arithmetic Library) is recommended for better performance. **10.2 Incremental Update Strategy** ``` Pseudocode: 1. Cache the MuHash state of the previous block. 2. For addresses changed in the current block: - If the previous balance is non-zero: remove the old entry. - If the current balance is non-zero: add the new entry. 3. Obtain the MuHash state of the current block. 4. Cache it for use by the next block. ``` **10.3 Ticker-level MuHash (Optional)** To support efficient localization, a separate MuHash can be maintained for each ticker: ``` ticker_muhash[ticker] = MuHash(all balance entries of this ticker) ``` The global MuHash can be obtained by combining the MuHash values of all tickers (this requires special design). Alternatively, the global MuHash and ticker-level MuHash can simply be calculated independently. **10.4 Zero-Balance Cleanup** Clean up zero-balance entries periodically to prevent `TokenUsersBalanceData` from growing without bound: * When both `AvailableBalance` and `TransferableBalance` are zero, delete the entry from the map. * This does not affect the MuHash result (zero balances do not participate in the calculation anyway). #### 11. Migration Path **11.1 Migrating from v1 to v2** * v1 and v2 can run in parallel without affecting each other. * New blocks calculate both v1 and v2 commitments at the same time. * Gradually transition to using only v2. **11.2 Version Identifiers** * v1: `version = 0x01` * v2: `version = 0x02` * Commitment hashes of different versions will not be confused. #### 12. Summary Through the MuHash mechanism, the v2 scheme provides a more flexible and more fault-tolerant state commitment scheme for the BRC-20 index of Fractal Bitcoin. **Core advantages:** * Final consistency: intermediate differences are tolerated as long as the final state is the same. * Version compatibility: supports coexistence of multi-version indexers and progressive upgrades. * Independent calculation: each block is independent and does not rely on a chained structure. * Full-state commitment: more intuitive and easier to understand and verify. **Applicable scenarios:** * Index mining: allows indexers with different implementations and different versions to participate. * Multi-version coexistence: transition periods during indexer code upgrades. * Final consistency verification: cares only about the final state, not the intermediate process. **Trade-offs:** * Higher computational overhead (but it can be optimized through incremental updates). * Weaker localization capability (but it can be supplemented by ticker-level MuHash). The v2 scheme is more suitable for Fractal's index mining ecosystem. It allows a more diverse set of participants while ensuring consistency of the final state. # FIP-101: Fractal Standard Indexing Service (Draft) * **Status:** Draft * **FIP Number:** 101 * **Title:** Fractal Standard Data Indexing Service * **Author:** UniSat Team * **Created:** 2025-12-09 * **Type:** Standard Proposal (Consensus Layer) * **License:** BSD-2-Clause *** ### Abstract This proposal introduces the Fractal Standardized Data Indexing Service, aiming to introduce a set of standardized data indexing services for Fractal Bitcoin that are maintained by core contributors, open-source, and permissionless to join and operate, while integrating them into the Fractal block reward system. By reallocating the block reward proportions and introducing a non-custodial staking mechanism based on Taproot scripting, this ensures the long-term stability and sustainability of the indexing service. *** #### Abstract This proposal introduces the Fractal Standardized Data Indexing Service, aiming to introduce a set of standardized data indexing services for Fractal Bitcoin that are maintained by core contributors, open-source, and permissionless to join and operate, while integrating them into the Fractal block reward system. By reallocating the block reward proportions and introducing a non-custodial staking mechanism based on Taproot scripting, this ensures the long-term stability and sustainability of the indexing service. *** #### Motivation The current Fractal ecosystem faces prominent issues in data indexing: 1. **Lack of Standardization for High-Performance Indexing** Currently, the community has various indexing solutions, including both commercial and open-source ones, but: * Protocol parsing methods and output structures are inconsistent * Maintenance costs for each are high * The community struggles to form consensus on standard interfaces and data formats This results in significant uncertainty and high adaptation costs in practical application development on the Fractal network. 2. **The Optimal Timing to Introduce Standardized Indexing** Over the past two quarters, the core contributor UniSat Team has conducted a series of ongoing refactorings on their maintained commercial indexer, enabling the system to gradually achieve the following features: * Memory usage reduced by approximately 80%, achieving a lightweight architecture * Initial synchronization can be completed within 24 hours (much faster than some existing open-source solutions in the community) * Significantly lower hardware requirements, greatly reducing the operational threshold The system's maturity is now sufficient to support a fully open, community-oriented standardized indexing service. 3. **Urgency for Standardization** * The protocol layer may fragment due to inconsistencies in software implementations and parsing methods * Developers would need to manually maintain parsing logic across multiple protocols, increasing error probability and hindering the formation of unified development experiences and ecosystem foundations Therefore, launching a standardized indexing service has become a necessary step for the continued expansion and order maintenance of the Fractal ecosystem. *** #### Specification 1. **Indexing Service Overview** The Fractal Standardized Data Indexing Service has the following features: * Fully Open-Source: Hosted in the official Fractal GitHub repository, maintained in the same manner as Fractal node codebase * Fully Permissionless: Anyone can run the indexer without needing approval * Modular and Extensible: Core indexing engine + protocol parsers + data storage layer * Unified Parsing and Output Structure: Ensuring consistent data presentation for different protocols in the ecosystem This indexing service will continuously support various protocols within the Fractal ecosystem, including but not limited to: * Inscription-type protocols * Token-type protocols * Custom on-chain metadata protocols * Extensions for parsing future new protocols The indexer will output parsed results in a standardized data structure, providing developers with a consistent and stable data foundation. In the future, this indexer can also serve as the basis for providing high-performance indexing services on the Bitcoin mainnet. 2. **Tokenomics Adjustment (Block Reward Allocation)** **Current Block Reward Distribution**: * Merged Mining: 1 * Permissionless Mining: 2 **Proposed New Distribution**: | Component | New Block Allocation | | --------------------- | -------------------- | | Merged Mining | 1 | | Permissionless Mining | 1 | | Data Indexing | 1 | The total supply and producing rate remain unchanged; only the allocation structure is adjusted. The 1:1:1 allocation structure is adopted because, from the perspective of Fractal's network structure, merged mining (security), permissionless mining (autonomous participation), and indexing service (data availability) constitute the three core pillars for the network's long-term sustainable operation. As infrastructure for ecosystem operation, the indexing service's availability and stability are of the same level of importance as network security, and thus should receive relatively equal economic incentives as miners. 3. **Staking** To ensure long-term robustness of the indexing service, this proposal introduces a non-custodial staking mechanism based on Taproot scripting: * General users can stake FB to a specific indexing service instance * Block Rewards are distributed proportionally based on staking shares * Operators can charge a certain service fee * All staked assets remain under user private key control via Taproot paths * Users can withdraw at any time, independent of operator actions This mechanism is fully compatible with the verified model in FB Farming and can be directly reused. *** ### Rationale 1. General Justification * A unified indexing standard can resolve protocol parsing fragmentation issues * Integrating indexing into block reward allocation can form long-term stable ecosystem infrastructure * Lightweight mechanisms reduce community operation costs, making the indexing system more decentralized * Non-custodial staking ensures fund security without introducing centralization risks * Technically, it maintains minimal intrusion to the existing chain structure 2. Non-Goals This FIP does **not** modify: * Block size or main block structure logic * UTXO model * Scripting language * Difficulty, PoW, or core anti-attack mechanisms * Total block reward supply, issuance rate, halving mechanism/timing This FIP does **not** involve: * Standardization of frontend APIs or SDKs * Specific protocols to support or their rule definitions * Application-layer data format specifications This proposal focuses solely on chain-level incentive mechanisms + standardization of the indexing service's foundational architecture. *** ### Activation The activation process will include two phases: #### Phase 1: Node-Level Support * New versions of Fractal Node will include built-in logic for indexing allocation handling * Once nodes are widely upgraded, an observation period will begin #### Phase 2: Determining Activation Height * Observe based on network-wide node upgrade status and announce the activation height * Execute the new block reward allocation starting from this height * The activation height will be announced in advance with at least 30 days reserved for unupgraded nodes to upgrade This process is similar to BIP-9 / BIP-8 versioned activation models but better suited to Fractal's governance structure. *** ### Security & Backward Compatibility * This proposal does not modify FB total supply, difficulty algorithm, or block structure * After the new activation height, non-block-producing nodes do not need to upgrade. Only block-producing nodes require additional constraint rules * **Delayed Reward Release**: Indexing-related rewards are released with at least 7-day delay (approximately 20,000 blocks at least) * **Offline Suspension of Allocation**: If an indexing node is offline for more than N blocks or fails to produce valid indexing results, its reward allocation is automatically suspended; * Users can withdraw stakes at any time and migrate to other nodes * This proposal does **not** introduce slashing; staked assets are always controlled by users * The Taproot non-custodial design of staking scripts ensures that indexing service providers cannot access user assets *** ### Reference Implementation The open-source implementation will include: * Core Indexing Processing Engine * Pluggable Protocol Parsers * Data Storage Layer * RPC Query Interface * Standard Coinbase Output Templates * Taproot Staking Script Templates All components will be publicly maintained and versioned on GitHub. UniSat Team 2025-12-09 #### # FIP-101: FAQ ### **Building the infrastructure layer applications can depend on** Fractal was built to support Bitcoin-native assets and applications at greater scale. Faster blocks, Bitcoin-compatible infrastructure, and native asset support are important foundations. As the ecosystem grows, however, one layer becomes increasingly important: indexing. Wallets, explorers, marketplaces, analytics tools, and application interfaces all rely on indexed data to understand balances, ownership, transfers, inscriptions, and protocol states. Without reliable indexing, users may see inconsistent information across products, while developers face a hidden infrastructure cost before they can even start building. In many ecosystems today, indexing is still built and operated as application-specific infrastructure. Teams duplicate similar work. Products rely on private or centralized APIs. Edge cases may be interpreted differently across services. New builders often need to solve a complex data problem before they can ship a useful product. For an early ecosystem, this model can work for a while. But as usage grows, indexing becomes a shared dependency. And shared dependencies need stronger standards, broader participation, and better incentive alignment. FIP-101 is designed around this problem. *** ### **Why permissionless indexing is genuinely hard** The goal of FIP-101 is not simply to have more teams run indexers, but to create an indexing network where independent operators can participate under a shared standard, and where the network can recognize valid indexing work and reward contributors. That is difficult for several reasons: * First, the indexing logic needs to be standardized. If different indexers follow different rules, the ecosystem does not get a common data layer. Wallets, explorers, marketplaces, and applications need to build around the same interpretation of network activity. * Second, the software needs to be accessible. A permissionless network only works if independent operators can realistically join. If participation requires heavy infrastructure or specialized internal knowledge, the system may be open in principle but limited in practice. * Third, the network needs a way to verify submitted indexing results. Without verification, incentives cannot be safely distributed, and the system has no reliable way to distinguish valid work from invalid submissions. * Fourth, the incentive model needs to be sustainable. Indexing is not a one-time contribution. It requires continuous operation, maintenance, and reliability. Operators need an economic reason to support this infrastructure over time. * Finally, indexing must not become a bottleneck for block production. The network needs to reward indexing work without making block generation depend on the immediate completion of indexing verification. *** ### **The lightweight indexer: making participation realistic** A key component of FIP-101 is the development of an open-source lightweight indexer. Permissionlessness depends on practical accessibility- if only well-resourced teams can run indexing infrastructure, the network may be open in theory but narrow in practice. A lightweight, open-source implementation lowers the operational barrier for independent operators, ecosystem teams, and technically capable community participants. It also gives developers a clearer reference implementation, reduces the cost of participation for operators, and creates a more consistent data foundation for applications. For the network as a whole, this increases the realistic possibility of a broader and more resilient indexing layer. *** ### **Integrating data indexing into Fractal’s block reward economy** The second major component of FIP-101 is economic integration. Instead of treating indexing as an external service that applications must separately fund or privately operate, FIP-101 incorporates indexing into Fractal’s block reward structure. Indexer operators can provide standardized indexing services, submit valid results, and receive rewards according to the network’s rules. FB holders can support indexers through staking, creating a direct economic relationship between token holders, operators, and the data infrastructure the ecosystem depends on. This is a meaningful design choice. Block rewards are one of the strongest coordination mechanisms in a blockchain network. By allocating a portion of rewards to indexing, Fractal recognizes that data infrastructure is not secondary to application growth. It is part of what makes application growth sustainable. The result is a more complete network economy. Miners secure block production. Indexers support standardized data availability. Stakers help allocate economic weight to indexer operators. Developers and users benefit from a more consistent infrastructure layer. Critically, index verification and reward settlement are kept off the block production critical path. This allows the network to support indexing as a rewarded role without compromising liveness. *** ### **What this means for the ecosystem** For developers, FIP-101 reduces one of the biggest hidden costs of building Bitcoin-native applications: maintaining reliable indexed data infrastructure. A shared indexing standard means less duplicated work and a clearer foundation for wallets, explorers, markets, analytics products, and future application layers. For users, better indexing means a more reliable experience. Balances, ownership records, and protocol states should feel consistent across products, rather than depending on which data provider a specific application uses. For FB holders, index staking creates a deeper connection to Fractal’s infrastructure layer. Supporting indexer nodes becomes a way to participate in maintaining the data infrastructure the ecosystem depends on. *** ### **Development status** FIP-101 is currently in Public Testing Stage 2. The lightweight indexer, staking mechanism, and reward distribution workflow are now live for public testing, allowing anyone to deploy an indexer, become an Indexer Operator, and participate in the Index Mining and Staking system. During this stage, the FIP-101 is validating the complete indexing lifecycle in a real network environment, including indexer deployment, proof submission, staking, and reward distribution. Feedback from operators and developers will continue to guide refinements as the protocol moves toward its official launch. # FIP-102: Native FB on Bitcoin Mainnet **Full Proposal:** {% file src="/files/S80yVIbXgDqmc3Jxgb3Z" %} #### For more details on FIPs: # FIP-102: Community FAQ Thank you to everyone who has reviewed FIP-102 and shared questions, concerns, and suggestions on Github and during our Community AMA. We have read and thought over every piece of feedback meticulously. The discussion has raised important considerations around Fractal’s emission structure, miner and indexer incentives, Bitcoin-mainnet distribution, and the potential role of existing infrastructure. This FAQ addresses the main questions raised so far. Not every suggestion can necessarily be adopted, but all feedback will be carefully considered and will contribute to our strategy and implementation going forward. *** #### Does FIP-102 increase FB’s supply? No. FIP-102 does not increase FB’s maximum supply or create a separate supply on Bitcoin mainnet. It changes where part of the post-halving emission budget is distributed. At full rollout, the combined emission path continues to follow the original progression of 25 → 12.5 → 6.25 FB, while the budget is divided between Fractal and Bitcoin mainnet. *** #### Why bring the two Fractal-side reward reductions together? Introducing Bitcoin-mainnet distribution without reducing the corresponding Fractal-side reward would create additional issuance. For example, retaining 12.5 FB on Fractal while adding another 6.25 FB for Bitcoin mainnet would produce a combined budget of 18.75 FB, exceeding the original post-halving emission budget. FIP-102 instead proposes bringing forward the second Fractal-side reduction and redirecting the corresponding 6.25 FB budget to Bitcoin mainnet. This allows FB to reach Bitcoin users without increasing the combined target emission budget. *** #### Why does Fractal need to update its distribution model? Fractal’s original tokenomics were designed for the network’s initial mainnet launch. Since then, the ecosystem and broader market have evolved. FIP-101 began expanding FB distribution beyond traditional mining by introducing Index Mining. FIP-102 continues this evolution by proposing a native distribution path for Bitcoin-mainnet users. The objective is to broaden participation, support new uses of FB, and create a more sustainable long-term distribution structure across both Fractal and Bitcoin mainnet. *** #### Could the lower Fractal reward push miners or indexers away? This is a valid concern, and the impact on miners, indexers, stakers, and other existing participants should not be understated. However, a larger nominal reward does not necessarily guarantee sustainable participation. Mining and infrastructure operators ultimately depend on whether the economic value of their rewards can justify their operating costs. FIP-102 seeks to improve the long term value and utility of FB, which will benefit the miners despite its short-term impacts. Merged Mining, Permissionless Mining, and Index Mining would all remain active after FIP-102, and the existing 1:1:1 allocation among these three Fractal infrastructure roles would not change. *** #### Why will Bitcoin-mainnet distribution not begin immediately at block 2,100,000? The Fractal-side reward change requires a coordinated consensus upgrade at a defined block height. Bitcoin-mainnet distribution, however, requires separate infrastructure, development, testing, and operational preparation. FIP-102 establishes the consensus change and emission-allocation framework that makes Bitcoin-mainnet distribution possible. It does not require the Bitcoin-mainnet distribution mechanism to become operational at the same moment that the Fractal-side reward change takes effect. After FIP-102 is activated at block 2,100,000, the new emission structure will need to be observed for a period of time to ensure that the transition is operating safely and as intended. Additional development and testing on the Bitcoin-mainnet side will also be required before distribution can begin. The Bitcoin-mainnet distribution mechanism is therefore expected to launch after an implementation and research period of approximately three to six months, with a target launch in Q1 2027. *** #### Why was the timeline for Bitcoin mainnet distribution (FIP-103) changed to a longer implementation period? The earlier concept assumed that Bitcoin-mainnet distribution would begin after FIP-102 activation and progressively reach its target rate over approximately three months. Following further consideration, the implementation plan has been revised. The priority is now to ensure that FIP-102’s consensus and emission changes are activated smoothly, observed in operation, and supported by sufficient Bitcoin-mainnet infrastructure before distribution begins. This approach provides additional time for research, development, testing, security review, and operational preparation. It also separates the activation of the emission framework from the launch of the user-facing Bitcoin-mainnet distribution mechanism. The revised timeline does not change the intended target allocation. It changes the order and timing of implementation so that Bitcoin-mainnet distribution can be introduced with stronger safety and operational integrity. The current expectation is for FIP-103 research and development to continue for approximately three to six months after FIP-102 activation, with Bitcoin-mainnet distribution targeted for launch in Q1 2027. *** #### Could existing FIP-101 indexers participate in Bitcoin-mainnet distribution? Community members have suggested that FIP-101’s standardized, lightweight indexing infrastructure could potentially support parts of the Bitcoin-mainnet distribution mechanism. This is a constructive and technically relevant suggestion. However, FIP-102 does not assign a new role to existing indexers, and the architecture of FIP-103 has not yet been finalized. Whether FIP-101 indexers or related decentralized indexing infrastructure could participate meaningfully is one of the possibilities that may be explored during the design of FIP-103. *** #### Does this make Fractal’s future monetary policy less predictable? FIP-102 is a significant proposed adjustment, and this is precisely why it has been presented through an open community review process. Under the proposal, future halving milestones would remain defined in advance, with the Fractal and Bitcoin-mainnet allocations reducing proportionally. The intention is to update the current distribution structure while maintaining a clear and predictable long-term emission path. *** #### Is FIP-102 already final? Yes. FIP-102 has been finalized as a proposal. However, the implementation process, rollout details, and the development of Bitcoin-mainnet distribution will remain subject to community review and feedback, particularly through the preparation of FIP-103. This does not mean that every proposed change or suggestion will automatically be adopted. However, every piece of feedback will be seriously considered because it helps identify concerns, clarify trade-offs, improve the implementation, and strengthen the final system. Thank you again to everyone who has contributed to the discussion. Constructive feedback—whether supportive, critical, or technical—is an important part of improving Fractal’s long-term design. # Fractal Tokenomics At Fractal, we have meticulously designed a comprehensive tokenomics model that establishes the long-term sustainability of our project while delivering maximum value to our community and investors. Our approach ensures that every participant in the ecosystem—ranging from miners to developers—has a positive vested interest in the growth and success of the network. **TL;DR: 80% of all tokens are allocated to the community, with just 20% for the team and contributors (with lock up periods) to ensure ongoing support and stability.** \ \ **Total supply: 210 million** ### **Token Allocation**
Our token distribution strategy is carefully designed to promote network security, incentivize growth, and reward key contributors across the ecosystem. The allocation is as follows: **Proof of Work Mining (50%)** Half of the total token supply is allocated to Proof of Work (PoW) mining, aligning Fractal closely with Bitcoin’s security model. This is critical for maintaining network security and ensuring reliable block production. Please see the chart below for the estimated Proof-of-Work Mining Schedule:
**Ecosystem Treasury (15%)** 15% of the tokens are reserved for the Ecosystem Treasury, dedicated to investing in the Fractal ecosystem. This treasury supports and funds initiatives that improve the ecosystem, and provides for ongoing core improvements to Fractal. A maximum of 10% of the total pool may be used each year, over a period of 10 years. **Community Grants (10%)** 10% of the tokens are allocated to community grants, which will be used to establish partnerships and liquidity programs. These initiatives are aimed at boosting network engagement over time, and will be community-directed. A maximum of 10% of the total pool may be used each year, over a period of 10 years. **Pre-sale (5%)** Only 5% of the tokens are allocated for the pre-sale, targeting early investors. These funds are crucial for covering initial development and operational costs, as well as conducting security audits to ensure the robustness of the network. All tokens are locked up for a period of seven (7) months, and will be linearly released until the twelve (12)-month mark. This ensures that pre-sale participants are invested in the long-term growth of the ecosystem, while balancing out the immediate effects of proof-of-work (PoW) block production. **Advisor (5%)** Another 5% of the tokens are currently reserved for present and future advisors who will provide strategic advice and support for the ongoing development of the Fractal network. Please refer to the following link for details: **Core Contributors (15%)** The remaining 15% of tokens are allocated to core contributors who build and maintain Fractal's core software. All tokens are locked up for a period of seven (7) months, and will be linearly released until the twelve (12)-month mark. As PoW networks do not inherently provide direct funding for development, this allocation ensures a dedicated pool of resources for ongoing improvements, attracting top talent and supporting the network's stability and growth. By funding development in this way, Fractal can continue to innovate and adapt, providing a secure, efficient platform that benefits the entire community. With our well-balanced tokenomics design, Fractal lays the foundation for sustainability and security of the network, while providing meaningful incentives for all participants. As we continue to grow, our tokenomics model will evolve to meet the changing needs of the ecosystem, ensuring that Fractal remains a vibrant and thriving network for years to come. We welcome all Fractal users to participate in ongoing governance processes and provide your input and ideas as we build Fractal together. ### Fractal Addresses For full transparency, you may track the official addresses below upon Fractal’s mainnet launch: * **Ecosystem Treasury (15%)** * (check out the table below for more details about 10 years locking) * **Community Grants (10%)** * (check out the table below for more details about 10 years locking) * **Pre-sale (5%)** * bc1put2rhzx0cwz552epm25dt2rexg2tzx9sws2sjcezsjm9y7h7ct8svhpzf2 * **Advisor (5%)** * bc1pm2h0420vmgayhzs59d5nf0mzjlf3q6vrnlpqytefe3rk6a8ku3zq59walm * **Core Contributors (15%)** * bc1ppvqe8ugt27kgw4trvnzjvcfzn52702tq2ahe7cgzw0jsv67vrhysvgnndz ### 10 years time-locked funds > As previously disclosed, the Fractal Foundation will disburse the funds in Ecosystem Treasury and Community Grants over 10 years, with a maximum of 10% of the total pool allocated per year. As such, the amounts will be time-locked (using OP\_CLTV) until they reach the corresponding block heights. Funds cannot be accessed or moved until Fractal Bitcoin's blockchain reaches that specific block. These funds are completely secured by Fractal Bitcoin's network, and any attempt to move them before the specified block will be invalid. #### Ecosystem Treasury locked for 10 years
No.YearAmountHeightDateAddress
120243,039,999 FB--bc1pukzhdkdghqajp3zvwkx65e7uv5zma6lzalet4xauf3p5c0vdg8wqk2avv6
220253,150,000 FB10512002025-09-09bc1pf6826e9eaf7re627z8j03uzx3msdzckws7amg9patds5msvzzg0se703w4
320263,150,000 FB21024002026-09-09bc1p428mfc6qsqkgdzwqw0a6yxrydrhfpkx035nqzm0tum86hp5r5g5qqzfk4d
420273,150,000 FB31536002027-09-09bc1pnjvh50sp0sqr3pg3476m9swkvrmaufxnek9w0lpfs3xwfc6atnms5kflyy
520283,150,000 FB42048002028-09-09bc1pezgyfz48djf260jsp2jssa02fa0vaxlma58xf7p5skz0mp6w2g6spsm50e
620293,150,000 FB52560002029-09-09bc1p7p0d8zq2847dfr3fs6ac42wvj0xglv5xftlmc9gzpapftgnt83uqvnafx6
720303,150,000 FB63072002030-09-09bc1pxgp0g9nan748z4w6hsfczjkpva2rreauz4pqw7dxd0s228v97zjsaqpygj
820313,150,000 FB73584002031-09-09bc1p2992nj7zkmewt8ejtsfl092dsx0ahczxsldn85mnmtczhtfp5a9q0g8xsp
920323,150,000 FB84096002032-09-09bc1plh9wvjevzgxnefhxq60t20nxuxtrq0tzyy7a8wx5agretkp974fqjqk330
1020333,150,000 FB94608002033-09-09bc1pag9pzdsgflt4gdkdh94x95yttjja6p78unygmvla5cf6sg8lxy0sxzmf7d
#### **Community Grants** locked for 10 years
No.YearAmountHeightDateAddress
120241,093,999 FB--bc1pdrqk5xv3tfpmdsuegnt5a63xucf475r3l0vqg6zulwmtzezg7h6sd2pqx3
220252,100,000 FB10512002025-09-09bc1p4ltv2p9dpnqayp9e457we7k2wm8pffavec4ma6fjncf39gz8ev2qrpdysp
320262,100,000 FB21024002026-09-09bc1p75vjcwhz0z7f65y6s0e4534rrtxssf7kmytsn33h2zdzz3cw2w0s4mwmre
420272,100,000 FB31536002027-09-09bc1pqjcwzxs84le6xym6qmwyawrjm6vrjze52hcchzv9xax584svtx9sg05nhh
520282,100,000 FB42048002028-09-09bc1pdyasc9n6ma5nf3a3tk3nuz5s6ekte4t55cdynh46tnue2erlx76q09cs43
620292,100,000 FB52560002029-09-09bc1pdhz2r77et4nvwxv20chqydklfv3t6vu8q2xz245d7fe0ls83gprslyjqfn
720302,100,000 FB63072002030-09-09bc1pzncvenplgyqxmq7pwjff5rsqa7hpcj0f42qfsc8xmy0w5p3l5xkqrxye7y
820312,100,000 FB73584002031-09-09bc1prmhwn5c2u7zxhk7p332a7dd2sfhlvgsx36wdzuhr9qjgwq0jlygstj0p6q
920322,100,000 FB84096002032-09-09bc1pjmvnss0jemrqsmh6r2x5m7qqzvhuwwtsyhwc33493n44eqfd5jqsycpskk
1020332,100,000 FB94608002033-09-09bc1pycewydr5llunqvwgsssrlc6c9qtagkl9uf0pmppeffj46dg2h4gqp38f88
# Overview This guide serves only as a reference for users. Please do your own research. Regular users can participate in Fractal through a growing ecosystem of applications and services. Depending on their needs, users can manage assets, explore on-chain activity, swap tokens, join farming activities, and interact with ecosystem applications. This section introduces the main user-facing products in the Fractal ecosystem and explains what each application is for and how users can participate through them. ### Wallet * **UniSat Wallet** UniSat is the first open-source Bitcoin extension wallet that supports Ordinals. Send & receive FB and Fractal assets. Access DApps, tools and more. → [Learn more](#inswap) * **Safnect Wallet** Explore how their state-of-the-art Non-Custodial MPC Wallet outperforms traditional models. → [Learn more](https://safnect.com/) *** ### Applications * **InSwap** The first open-source AMM DEX for Bitcoin-native assets, built natively on Bitcoin and Fractal. → [Learn more](#inswap) * **FB Farming** A revolutionary native ecosystem incentive program on Fractal Bitcoin that's fully open-sourced and secured by Taproot script. → [Learn more](/for-users/overview/application/fb-farming) * **SatWorld** A Gaming World buidl on Bitcoin Ecosystem, connecting players and offering a unique immersive interactive experience → [Learn more](/for-users/overview/application/satworld) * **ZeroBit Gate** A pool based automated gateway built for Fractal Bitcoin ecosystem. → [Learn more](/for-users/overview/application/satworld) *** ### Explorer * **UniScan** The all-in-one block explorer for Fractal. Get real-time insights into addresses, transactions, blocks, assets and trends, powered by high-performance indexing. → [Learn more](/for-users/overview/application/fb-farming) * **Mempool (Fractal)** Mempool (Fractal) is a public block explorer for the Fractal network. It helps users view blocks, transactions, addresses, and fee-related network activity in a clear and accessible way.→ [Learn more](https://mempool.fractalbitcoin.io/) # Wallet This guide serves only as a reference for users. Please do your own research. Several wallets currently support Fractal-related functions such as sending and receiving FB and other Fractal assets. Among them, UniSat Wallet and Safnect Wallet are two available options for users who want to access the Fractal ecosystem, manage assets, and interact with supported services and applications. Below is a brief introduction to each wallet and its key features. ## UniSat Wallet UniSat is the first open-source Bitcoin wallet that supports Ordinals/Runes/Alkanes. It serves as a gateway for users interacting with the Fractal ecosystem. Send & receive FB and Fractal assets. Access DApps, tools and more. With UniSat Wallet, users can: * Create or import a wallet * Send & receive FB and Fractal assets * Access UniSat service on Fractal, such as: Marketplace, Inscribe, InSwap, UniScan, and more * Connect to Fractal ecosystem DApps and tools, like Satworld **Key Features** For Fractal users, UniSat Wallet’s public materials highlight these core capabilities: * Bitcoin and Fractal network support, one-click network switching * 100% open-source and non-custodial Control * Encryption & security, privacy First * Integration with ecosystem services such as InSwap and Farming * Available on iOS, Android, and web browsers **Related Links** * Download UniSat Wallet: * UniSat Wallet Docs: *** ## Safnect Wallet Safnect uses advanced Multi-Party Computation (MPC) technology to securely protect your digital assets. Your private key is split into 3 separate shards, which are stored independently. Even if one shard is lost, your assets remain safe. This ensures that only you can fully restore and control your private keys. With Safnect wallet, you can easily send and receive your BTC, Runes, Fractal Bitcoin, and CAT **Key Features** * Protect Your Assets with MPC Technology * Easily Manage Your Crypto Assets in Wallet * Cold Wallet for Secure, Offline Transactions **Related Links** * Download Link: * Safnect Wallet Docs: **Disclaimer:** This page is provided for informational purposes only and does not constitute investment, financial, legal, or tax advice. Users should review the relevant official documentation carefully and are solely responsible for the security of their wallets, private keys, passwords, and recovery phrases when accessing any Bitcoin- or Fractal-related services. # Application {% content-ref url="/pages/A0TtgfjxPVOelxKuHyO5" %} [InSwap](/for-users/overview/application/inswap) {% endcontent-ref %} {% content-ref url="/pages/bvvDdLBo65M9WjsfxajM" %} [FB Farming](/for-users/overview/application/fb-farming) {% endcontent-ref %} {% content-ref url="/pages/Pb2jNwEUi0dSV2b4x05S" %} [Satworld](/for-users/overview/application/satworld) {% endcontent-ref %} # InSwap This guide serves only as a reference for users. Please do your own research. InSwap, developed by the UniSat team, is the first open-source AMM DEX for Bitcoin-native assets, built natively on Bitcoin and Fractal. It enables users to seamlessly swap, provide liquidity, and earn brc-20 assets with no block waiting time. ### What Users Can Do With InSwap, users can: * Swap supported assets, including Bitcoin & Fractal native assets * Provide and remove liquidity * Earn rewards as liquidity providers * Join and earn on InSwap activities, like InSwap Trading Campaign, LP fest ### How It Works UniSat introduces a mechanism that enables users to swap their balances within the module in a seamless and secure way, under the brc-20 module. All swap-related operations can be seen as a list, updated only by the module’s sequencer, and each event includes the signature of the initiating user. This ensures maximum security and order throughout the swap process. This proposal defines two operations within the brc-20 module: commit and approve. ### Fees Each swap on InSwap includes a 1.5% transaction fee: * 1/6 goes to the platform * 5/6 goes to liquidity providers ### Related Links * InSwap Website: [https://inswap.cc](https://inswap.cc/swap) * InSwap introduction: * InSwap Guide: This page is for informational purposes only and does not constitute investment, financial, legal, or tax advice. Digital assets are volatile and involve risk. Actual rewards are subject to the platform's settlement rules and do not constitute any guarantee or promise. Please assess the risks carefully before participating. # FB Farming This guide serves only as a reference for users. Please do your own research. FB Farming is a native ecosystem incentive program on Fractal Bitcoin introduced by UniSat. It is fully open-sourced and secured by Taproot script, designed to reward long-term FB holders while supporting ecosystem participation. FB Farming allows users to stake FB and receive incentives based on different participation periods. Rewards can also be boosted through Gems, while actual rewards remain subject to the UniSat's rules. ### What Users Can Do With FB Farming, users can: * Stake FB to earn incentives, around 1.2% to 9.8% apy based on farming duration * Choose different staking periods * Use Gems to boost rewards, up to about 37% apy * Track live APY and rewards * Unstake at any time ### How It Works FB Farming uses a tier-based reward model, where longer staking periods unlock higher APY tiers. UniSat also states that Gems can further boost rewards. The basic flow is simple: choose an amount, select Gems, sign the transaction, and start farming. When unstaking, users can choose a full or partial amount, and the system calculates rewards before confirmation. ### Key Features FB Farming is designed to offer flexibility and user control, including: * No on-chain time lock * Partial unstaking * No freeze period * Real-time APY and rewards tracking ### Related Links * FB Farming Website: [ https://fractal.unisat.io/farming](< https://fractal.unisat.io/farming>) * FB Farming Intro: This page is for informational purposes only and does not constitute investment, financial, legal, or tax advice. Digital assets are volatile and involve risk. Actual rewards are subject to the platform’s settlement rules and do not constitute any guarantee or promise. Please assess the risks carefully before participating. # Satworld This guide serves only as a reference for users. Please do your own research. SatWorld is an ecosystem application that combines avatars, social interaction, and lightweight game experiences. It is designed as a space where users can join activities, interact with others, and explore community-driven experiences in the Bitcoin ecosystem. ### **What Users Can Do** With SatWorld, users can: * Create and use their own avatars to enter SatWorld’s interactive and gameplay environments * Join community events, themed activities, and limited-time campaigns while interacting with other users * Experience lightweight in-app game content and complete different types of social and gameplay-based tasks * Participate in ecosystem collaborations and co-branded themed content while exploring an evolving community experience ### **How It Works** SatWorld is positioned as an interactive application layer experience rather than a financial protocol. Its public-facing content highlights avatar-based participation, social connection, and recurring in-app events, with updates and campaigns announced through its official channels. ### **Key Features** SatWorld’s public content currently highlights the following: * Avatar-based gamified experiences * Community-oriented interaction and social connection * Ongoing gameplay experiences driven by events and themed content ### Related Links * SatWorld: [https://beta.satworld.io/ ]() * Official X: This page is for informational purposes only. Features, events, and availability may change over time based on the project’s official updates. Please refer to SatWorld’s official website and official X account for the latest information before participating. # ZeroBit Gate This guide serves only as a reference for users. Please do your own research. ZeroBit Gate is a pool based automated gateway built for Fractal Bitcoin ecosystem. It was independently developed by The Lonely Bit team, an active developer team within the Fractal community. It serves as a fast and reliable on-ramp/off-ramp, allowing users to seamlessly exchange Fractal Bitcoin (FB) and brc-20 assets with a wide range of cryptocurrencies from other blockchains. Focused on secure and efficient cross-chain experiences, connecting different blockchain ecosystems. Users can instantly buy $FB or popular brc-20 tokens by paying with assets such as SOL, TRX, ETH, USDT, BTC, XRP, and many others (15+ supported chains and tickers). Conversely, users can sell $FB and receive payout directly to wallets on supported chains. brc-20 tickers purchases are settled directly into the user’s balance on InSwap, the native brc-20 DEX on Fractal Bitcoin, enabling immediate trading and management within the Fractal ecosystem. **Key Features:** * Pooled liquidity model for fast, efficient, and reliable transactions * Support for multiple Bitcoin address formats (Legacy, SegWit, Taproot) * Real-time order tracking, expired order recovery (within 7 days), and secure payout system using TSS (Threshold Signature Scheme) * Built-in points and tiered rewards system (Bronze/Silver/Gold) based on trading volume to incentivize community participation By lowering the barrier to entry, ZeroBit Gate makes it significantly easier for users from Solana, Tron, Ethereum, and other ecosystems to access Fractal Bitcoin and its growing ecosystem in just a few steps. **Related Links** * Website: **Disclaimer**\ ZeroBit Gate is a community-driven, third-party experimental project developed by TheLonelyBit team. It is not developed or operated by the Fractal Bitcoin core team. Users interact with the service at their own risk. Please conduct your own due diligence, and only use funds you can afford to lose. # Explorer This guide serves only as a reference for users. Please do your own research. Block explorers that support Fractal include UniScan and Mempool (Fractal). These explorers help users view on-chain data, search transactions and addresses, track blocks, and better understand network activity on Fractal. ### UniScan UniScan is the all-in-one block explorer for Fractal, built by UniSat team. Get real-time insights into addresses, transactions, blocks, assets and trends, powered by high-performance indexing. For Fractal users, UniScan serves as a public explorer for checking chain data and monitoring network activity. And search and track transactions, wallet addresses on Fractal. **Key Features** For Fractal users, UniScan’s publicly visible features include: * Fractal network explorer support * Search any Bitcoin address and explore transaction history * Track on-chain activity by protocol * Block and Mining Block data access * Integration within the broader UniSat product ecosystem, such as UniSat Wallet, Inscribe, Marketplace, and InSwap. **Related Links** * UniScan for Fractal: *** ### Mempool (Fractal) Mempool (Fractal) is a public block explorer for the Fractal network. It helps users view blocks, transactions, addresses, and fee-related network activity in a clear and accessible way. For Fractal users, it serves as another useful option for checking on-chain data, tracking transaction status, and monitoring overall network conditions. **Key Features** For Fractal users, Mempool (Fractal) provides: * Fractal network explorer support * Block, transaction, and address search * Transaction status and confirmation tracking * Network activity and fee market visibility \ **Related Links** \ Mempool (Fractal): [https://mempool.fractalbitcoin.io](https://mempool.fractalbitcoin.io/) This page is for informational purposes only and does not constitute investment, financial, legal, or tax advice. Digital assets are volatile and involve risk. Please assess the risks carefully before participating. # FAQs This FAQ is designed to address common questions from the community, offering clear and concise answers about Fractal's features, future developments, and overall ecosystem. **What is Fractal Bitcoin?** Fractal - Extending the utility of Bitcoin This allows Bitcoin to support faster, cheaper, and more expressive applications — all while staying fully compatible with Bitcoin’s rules and infrastructure. Fractal is not a fork or a separate ecosystem; it is a programmable extension of Bitcoin. [→ Learn more](https://fractal-bitcoin.notion.site/2025-11-what-is-fractal-bitcoin)
**Why is it called Fractal Bitcoin?** What’s in a name? A fractal is a self-similar, recursive property. We believe that scaling Bitcoin requires every layer to possess the essence of fractals: consistent across all layers, with as many layers as required to scale, and logically sequenced. Essentially, fractals of Bitcoin!
**Why was Fractal created?** Fractal emerged in response to rising Bitcoin mainnet congestion — especially during the BRC-20, Ordinals, and Runes boom in 2023–2024. It offers a native, scalable, and secure environment for Bitcoin activity to grow without compromising mainnet reliability.
**Why does Fractal care about virtualization?** Fractal believes it is extremely important that applications are self-consistent with Bitcoin in order to scale effectively. Just as other chains care about chain compatibility and equivalence, Bitcoin applications should have their own standards that work perfectly with Bitcoin as well.
**Is Fractal a sidechain or Layer 2?** Fractal functions as a system of recursive Bitcoin Core instances — not a traditional sidechain or L2. While it is merge-mined and operates independently, we retain full compatibility with Bitcoin’s rules, logic, and address formats. It’s more accurate to call Fractal an **extension of Bitcoin**, not a bridge away from it. Our core tenet is to be an extension of Bitcoin, enabling the growth and adoption of Bitcoin itself. We are only interested in solutions that are truly Bitcoin native.
**What are some use cases of Fractal?** Stablecoins and other DeFi applications native to Bitcoin, Ordinals, large-scale games, and other applications are all easily supported on Fractal. All applications built on Fractal are completely compatible with Bitcoin natively. # Token Utility **What is the utility of the Fractal Token?** The Fractal Token is called FB (Fractal Bitcoin). It’s used to: * Enable transaction fees * Access to nodes and services * Project launchpads * Govern ecosystem grants and upgrades * Bridge between recursive Fractal layers via the Fractal Elevator [→ View tokenomics](https://docs.fractalbitcoin.io/fractal-tokenomics) **Why not just use BTC for fees?** FB allows deterministic fee logic, avoids bridge risk, and ensures reliable settlement across recursive layers — all while preserving optional Bitcoin mainnet finality. **Where can I get FB tokens?** FB is available on exchanges like [HTX,](https://www.htx.com/tokens/fb/)[Gate.io](https://www.gate.com/price/fractal-bitcoin-fb), [KuCoin](https://www.kucoin.com/price/FB), and [Bybit](https://www.bybit.com/en/coin-price/fractal-bitcoin/), and can be earned via mining, ecosystem participation, or liquidity provision. # For Builders **How do I start building on Fractal?** Visit [docs.fractalbitcoin.io](https://docs.fractalbitcoin.io/doc/developer-home) to access developer guides, tutorials, and API references. You can launch tokens, and integrate BRC-20 and Runes natively. **Can I port my dApp from Ethereum or Solana?** Fractal doesn’t run EVM code, but many application patterns — such as swaps, vaults, or staking — can be replicated using OP\_CAT and covenant logic. Fractal is more expressive than Ethereum in some dimensions and more minimal by design. **What kind of apps can I build on Fractal?** Builders have launched: * Decentralized exchanges (PizzaSwap) * Runes & Ordinals marketplaces * zk-based verifiers and atomic swaps * Infrastructure for OP\_CAT scripting * On-chain games and virtual economies Head on to - the community-driven ecosystem directory to explore more. # Mining & Network Design **What is Cadence Mining?** Fractal uses a hybrid model: * **1/3 Merged Mining** with Bitcoin (SHA256d, zero setup) * **1/3 Permissionless Mining** for decentralization and new participants * **1/3 Index Mining** for indexer operators and stake participants This model ensures both high security and open participation. Read more about [cadence mining here](https://fractalbitcoin.io/mine). **How does merged mining work?** Bitcoin miners can mine Fractal blocks simultaneously, earning FB without additional energy or hardware. Over 50% of Bitcoin’s hashrate is currently merge-mining Fractal. [Read more about merged mining here.](https://fractalbitcoin.io/learn/merged-mining) **Can anyone mine Fractal?** Yes — you can solo mine or join permissionless pools using standard SHA256d ASICs. Fractal is designed to welcome new, independent miners while still benefiting from Bitcoin’s hashpower. More details [here](/for-miners/minning-overview) # Bridging, Wallets & Swaps **How do I bridge assets to Fractal?** You can currently bridge brc-20 tokens from Bitcoin mainnet to Fractal using whitelisted apps like UniSat's InSwap at . Bridging is trustless, protocol-compatible, and doesn’t rely on wrapped assets or EVM-based infrastructure. **What wallets support Fractal?** [UniSat Wallet](https://unisat.io/) is fully integrated with Fractal. Because Fractal uses the same address format as Bitcoin, wallet compatibility is seamless — no new setup or conversions required. **What is InSwap?** [InSwap ](https://inswap.cc/)is Fractal’s native AMM and liquidity layer. It supports brc-20, and other Bitcoin-native assets — enabling fast, cheap, and trustless swaps. # Governance & Ecosystem **Is Fractal governed by the community?** Yes. Governance happens through [**Fractal Vote**](https://vote.fractalbitcoin.io/), a fully on-chain voting system powered by OP\_CAT. Token holders can stake FB to propose upgrades, vote on treasury grants, and shape protocol evolution. **Is Fractal open source?** Yes — all source code, documentation, and network tools are public and on GitHub. Fractal encourages open development, transparency, and community contributions. [→ View code](https://github.com/fractal-bitcoin/fractal) **How do ecosystem grants work?** Fractal offers retroactive and milestone-based grants. Projects are evaluated based on innovation, technical quality, and community contribution. [→ Apply for a grant](https://fractalbitcoin.io/ecosystem-grant-evaluation) # Fractal Vote **Q: How long do I need to lock my FB to vote? Does the FB automatically return to my wallet after unlocking?** A: Once you've cast your vote, you can unlock your FB anytime. However, please note that unlocking will trigger a cooling period of 21,000 blocks(\~7 days). After this period ends, you’ll be able to claim your FB back. **Q: Does voting consume FB?** A: When performing lock, unlock, or claim actions, you will need to pay gas fees. However, no other actions will result in FB being spent. To participate in voting, you must lock FB. Once your vote is cast, you can unlock your FB at any time. **Q: What’s the purpose of participating in Fractal Vote?** A: Participating in Fractal Vote allows you to take part in governance decisions. In the future, voting will be used for making important decisions that affect the Fractal ecosystem. **Q: I’ve already voted. Can I unlock my FB now? Is my vote still valid?** Yes, your vote is still valid even if you unlock your FB. You can unlock your FB anytime after casting your vote. **Q: Are there any rewards for voting or expected future rewards?** Voting allows you to participate in governance, and in the future, it will be used for important decision-making. However, there are no specific rewards expected at this time. # Bitcoin Concepts **What is OP\_CAT and why does it matter?** OP\_CAT is a re-enabled Bitcoin opcode that allows concatenation of data in script. On Fractal, OP\_CAT powers secure smart contracts, recursive covenants, and modular logic across Bitcoin-native assets. [→ Learn about OP\_CAT](https://fractalbitcoin.io/learn/what-is-op-cat) **What are Bitcoin covenants?** Covenants let you restrict how UTXOs can be spent — enabling things like vaults, decentralized governance, or time-locked contracts. Fractal supports expressive covenants through OP\_CAT. [→ Learn more](https://fractalbitcoin.io/learn/bitcoin-covenants) **What’s the difference between BRC-20, and Runes?** * **BRC-20**: Simple inscription-based token format that originated on Bitcoin, now supported natively on Fractal * **Runes**: Lightweight, inscription-based token protocol supported on both Bitcoin and Fractal All three standards are **natively supported** on Fractal. # Community AMA Review ### Fractal Telegram AMA Review - Mar. 15 ### Fractal Community Q\&A Summary - Sept. 22 # Fractal Telegram AMA Review - Mar. 15 ### PizzaSwap #### Q: When will PizzaSwap launch its visualization features? **A:** Swap functionality is being iteratively developed. This issue is noted and tracked here: [UniPulse/UniPulse#18](https://github.com/UniPulse/UniPulse/issues/18) comment or create new ones if it doesn't describe well enough. #### Q: Will PizzaSwap open its nodes for public deployment? **A:** Yes. It should be done after the upgrade being accomplished on both fractal and bitcoin mainnet. It can be tracked here: [UniPulse/UniPulse#21](https://github.com/UniPulse/UniPulse/issues/21) #### Q: Currently, to deposit inscriptions into PizzaSwap, users need to first inscribe. Can this be enhanced? **A:** Single-step transfers will solve this issue. This feature will change some people's stereotypical impressions about inscriptions (it changed ours). *** ### Technical Questions #### Q: Can the mempool browser's block chain status be optimized? When viewing a transaction, the indicator arrow often remains on the left side even after the block has passed, making the experience less smooth. **A:** This is somewhat challenging because it's developed by mempool.space, and we've only deployed their system without making significant modifications. However, we are continuously improving and optimizing the UniSat Explorer. *** ### Ecosystem & Partnerships #### Q: How is Fractal supporting its DeFi, NFT, and gaming ecosystems? **A:** This year, we've adjusted our strategy to focus on supporting key projects while paying attention to community and meme development. We're developing deep partnerships with projects like SatWorld and Babylon to provide more comprehensive support. We’re actively thinking of events and ways to better support memes and communities. #### Q: Is SUSD deposit in PizzaSwap based on mainnet inscriptions or Fractal inscriptions? **A:** We will initially support the deposit of SUSD from Bitcoin mainnet into PizzaSwap, with Fractal versions planned for the next phase. #### Q: What's happening with Cat20 in the OKX market, where it has been in maintenance for a long time? Do you have any insights? **A:** We don't have much information about this. You might need to check with OKX directly about their situation. #### Q: Is Cat20 still a unique part of the Fractal ecosystem? **A:** We're still monitoring Cat20's progress and hope to see positive development in both the protocol and its ecosystem. A lot hinges on the CAT20 team. #### Q: Has the Fractal team had recent technical discussions with the Cat20 team? **A:** Yes, we have had technical exchanges with the CAT20 team. *** ### Team & Development #### Q: What is the current team size at UniSat and Fractal, and are there plans for expansion? **A:** The current team has fewer than 30 people. A smaller team has both upsides (more cohesive and agile) and downsides (we could always use more hands). There is definitely room for improvement in time and project management. This year, product updates will be more clearly defined with the wallet, browser, and trading services developing independently according to their own logic to avoid confusion. #### Q: Is there any token launch planned for Fractal? **A:** No, there are currently no plans to launch a new token for Fractal itself. Fractal Bitcoin is the native token of Fractal. #### Q: Is Fractal planning to attract institutional investors? **A:** The Bitcoin ecosystem is inclusive and decentralized with diverse participants. We've already experimented with partnerships like Babylon and will explore more approaches in the future. # Fractal Community Q\&A Summary - Sept. 22 This FAQ summarizes key questions from the Fractal community, answered by core contributor- Lorenzo on September 22, 2024. #### **Fractal Testnet Activities and Rewards** **Q: Are there any rewards for participating in past testnet activities?** A: Testnet activities are valuable and provide great reference data for ecosystem partners to understand how to collaborate with the community. We shall definitely help them more on this. A feedback tab is great to have and you may write feedback in the fractal [GitHub repositories](). *** ### **PizzaSwap** **Q: Will the "green ramps" for liquidity on the L1 swap be available on day one for sending assets to PizzaSwap? and when can I withdraw assets deposited into the BRC20-swap?** A: The green channel will be available shortly after the swap opens, likely one or two days later, based on the release schedule. Once it’s available, you’ll be able to transfer your assets and withdraw them anytime. **Q: Will LP rewards from the L1 swap be distributed when PizzaSwap goes live?** A: Yes, this feature will be enabled in the initial iterations. We’re taking it step-by-step to address any issues quickly instead of releasing everything all at once. **Q: Will there be significant improvements in PizzaSwap's UI and functionality, or is the current testnet version final?** A: Software development is an iterative process, and we will continue improving over time. Expect further enhancements down the road. **Q: Does the protocol designate specific tokens for creating liquidity pools, or is it up to the community?** A: It’s completely permissionless, like the way BRC-20 deploy/mint/transfer works. More details can be found in the given links in the [Medium article](https://unisat-wallet.medium.com/2024-07-unisat-swap-product-important-update-e974084074a1). *** ### **CAT-20** **Q: Are there plans to release tools for minting/deploying CAT-20 tokens and creating a marketplace similar to BRC-20 on Fractal?** A: We won’t be releasing minting/deploying tools since others have done a great job already. But we are researching marketplace support and will keep you posted. **Q: Will CAT-20 tokens be included in PizzaSwap? If so, when?** A: Technically, it’s achievable with existing constructs, but it’s not currently the best approach. We are conducting more research and will update accordingly. *** ### **Stablecoins** **Q: Is there a plan to introduce stablecoins on the Fractal network?** A: Stablecoins have been a hot topic. Fractal is still relatively small for major players to take notice, but we’re always open to ideas. If you have a great plan, we’d love to hear it. *** ### **Names and Assets** **Q: When will .fb domain names be supported in the UniSat wallet?** A: The .fb domain is encouraged for DID purposes on Fractal to prevent potential re-minting of popular names like .btc and .sats. We hope to introduce more functions for .fb names soon. **Q: Will there be a tracker to monitor how much of the old 4/5-byte BRC20 tokens are bridged to Fractal?** A: Yes, it’s reasonable for bridges to implement such a feature. *** ### **Bitcoin and other protocols in the Fractal Ecosystem** **Q: How is Bitcoin (BTC) utilized in the Fractal ecosystem?** A: BTC can be bridged and used in specific cases, for example, being used in the swap for some btc-based trading pairs **Q: Will Bitcoin Layer-1 inscriptions be supported for cross-chain transfers to the Fractal network? Are there any limitations?** A: Absolutely. This is one of the main reasons we built Fractal Bitcoin. **Q: Is it possible for protocols like Atomicals to use open-source technologies on Fractal for development and implement VM functionality?** A: Of course, it basically equals working on bitcoin mainnet, with OP\_CAT enabled. *** ### **Fractal Module Transfers** **Q: Will Fractal enable sending assets to multiple wallets simultaneously in module transfers?** A: It would be a great possibility that we want to explore. it does help greatly and serves for many useful scenarios. but we respect and follow the protocol creator's decision on this and move forward cautiously. # Developer Overview #### **Node** * Source Code: [https://github.com/fractal-bitcoin/fractal ](< https://github.com/fractal-bitcoin/fractal >) * Binary Release: * chainId: 0x2024 * Message Magic Number: d99e94b9 **The Ordinals on Fractal implementation** * GitHub Repository: [https://github.com/fractal-bitcoin/ord]() * Release Version: * Ordinals on Fractal (Mainnet): **Mempool Browser**
MainnetTestnetMainnet
https://mempool.fractalbitcoin.io https://mempool-testnet.fractalbitcoin.iohttps://mempool.fractalbitcoin.io
**Explorer**
MainnetTestnetMainnet
https://uniscan.cc/fractalhttps://uniscan.cc/fractal-testnethttps://explorer.unisat.io/fractal-mainnet
* **API Support** * Open API: * API-KEY application: * **Wallet Support - UniSat wallet** * UniSat Wallet Download Link: * UniSat Chrome Extension: * GitHub: * Demo: * **Ordinals Support** | Mainnet | Testnet | | :----------------------------------------------------------: | :------------------------------------------------------------------------: | | [https://fractal.unisat.io/ ]() | [https://fractal-testnet.unisat.io]() | # brc-20 on Fractal To avoid conflicts with existing assets on Bitcoin mainnet, the rules for brc-20 on Fractal have been specifically tailored. 1\. Ticker names on Fractal Mainnet will be limited to **6 - 12 bytes**. Tickers with 4 or 5 characters will not be permitted, as they are already in use on the Bitcoin mainnet. 2\. For brc-20 on Fractal, ticker names can include letters (both uppercase and lowercase: **a-z/A-Z**), numbers (**0-9**), and underscores (**\_**). In total, you have 63 different characters to work with. Ticker names are not case-sensitive. For example, "Aaaaaaaaaaaaaa" is treated the same as "aaaaaaaaaaaaaa." 3\. Both fair-launch and self-issuance are supported for all brc-20 assets on Fractal. "self-issuance" means these assets can only be minted by the holder of deploy inscription. Since deployment inscription can be transferred, whoever holds the deployment inscription has the right to mint the ticker. * In addition to the three rules mentioned above, brc-20 rules on Fractal are consistent with the brc-20 rules on Bitcoin mainnet. # Runes on Fractal Runes on Fractal follows the same set of rules as the Bitcoin mainnet. If you're familiar with the runes protocol on Bitcoin, you'll find that the structure and functionalities on Fractal are fully aligned with it. Here's what you need to know: #### 1. **Same Rules as Bitcoin Mainnet** The Runes protocol on Fractal follows the same fundamental rules as on Bitcoin, with all phases completed within one halving cycle (it takes 4 years on Bitcoin, and takes 2 years on Fractal) There are 12 phases on both networks. Therefore, any single phase takes 120 days on Bitcoin, and 60 days on Fractal. #### 2. **Ticker Names on Fractal** On the Fractal mainnet, all Runes tickers are displayed in **lowercase** letters. For more detailed information on the Runes protocol, you can refer to the official documentation here: [Runes Protocol Documentation](https://docs.ordinals.com/runes.html). # Minning Overview Halving cycle: 2,100,000 blocks. The genesis block generates 50 BTC to Satoshi Nakamoto's address, but this amount is unspendable. In the first block after the genesis block, a total mining output of 105 million will be pre-allocated to a spendable address. Starting from the second block, each block will generate 25 FB, with the decimal precision remaining at 8 decimal places. The total mining supply is calculated as 2 \* 25 \* 2,100,000 = 105 million FB. **Consensus mechanism** Fractal’s consensus mechanism is Proof-of-Work — consistent with Bitcoin. Miners can use existing ASICs and other hardware devices to mine blocks. (standard **SHA256d**) **Cadence Mining** Fractal uses an innovative mining method called Cadence Mining to balance the benefits of merged mining and permissionless mining. Providing a balance of security and inclusivity. This hybrid model enables miners to bolster the network's security while also engaging in the economic benefits offered by Fractal. * The block interval for mining is 30 seconds. For every three mined blocks, one block will be permissionlessly-mined, one block will be merged-mined, and one block will be indexing-mined. * This preserves the permissionless, freely-available mining opportunities for the Fractal community, while tapping into the impressive security of the Bitcoin main chain through merged mining at the same time. Fractal Bitcoin supports merged mining with Bitcoin, allowing miners to mine Fractal Bitcoin blocks simultaneously while mining the Bitcoin mainnet. The integration mechanism is identical to Namecoin’s. Initial **Difficulty & Hashrate Requirements** * Permissionless Mining: * nbits: 0x1900cfff * Difficulty: ≈5G * Hashrate: ≈500 PH/s * Merged Mining: * nbits: 0x180cffff * Difficulty: ≈400G * Hashrate: ≈20 EH/s (Equivalent to 3.2% of BTC's). # Cadence Mining Guide Understanding Cadence Mining: How Fractal Innovates on Bitcoin's Security Model When it comes to blockchain security, Bitcoin's Proof of Work (PoW) remains the gold standard. At Fractal, we've developed a unique approach called Cadence Mining that builds upon Bitcoin's proven security model while enabling greater scalability and participation. ### The Architecture of Cadence Mining Fractal uses an innovative mining method called Cadence Mining to balance the benefits of merged mining, permissionless mining and Index mining. Providing a balance of security and inclusivity. This hybrid model enables miners to bolster the network's security while also engaging in the economic benefits offered by Fractal. * **One-third merged-mining with Bitcoin**: Leveraging existing Bitcoin mining operations and security * **One-third permissionless mining**: Opening participation to a broader range of miners * **One-third index mining:** Enabling data availability, composability, and application usability This preserves permissionless and openly accessible mining opportunities for the Fractal community, while benefiting from the security of Bitcoin through merged mining and introducing standardized indexing as a core infrastructure layer for data availability, composability, and application usability. *** ### The Technical Implementation 🔧 Cadence Mining's implementation involves several sophisticated components that differentiate it from traditional mining approaches: #### 1. Difficulty Adjustment and Block Time * Dynamic difficulty adjustment for both mining types * 30-second block time (20x faster than Bitcoin) * Intelligent balancing of rewards between merged and permissionless mining #### 2. Security Reinforcement * Layered protection against various attack vectors * Complementary security models that strengthen each other #### 3. Architecture Design * Compatibility with existing mining hardware * Streamlined integration process *** ### Merged Mining Merged mining allows Bitcoin miners to simultaneously mine both Bitcoin and Fractal blocks using the same computational work. This creates a unique value proposition: * Primary mining effort goes to Bitcoin * Additional rewards earned from Fractal * No significant increase in operational costs * Profit addition to existing mining operations *** ### Permissionless Mining While merged-mining provides significant advantages by leveraging Bitcoin's security, permissionless mining and indexing represent equally important components of Fractal's consensus mechanism. The permissionless component of Fractal mining previously reached approximately 1 EH/s of hash rate — a significant figure that surpasses many standalone PoW networks. This impressive participation demonstrates the strength of Fractal's mining incentives and creates several key benefits: * Greater Decentralization: By enabling participation from miners who aren't already invested in Bitcoin mining, Fractal expands its security provider base. * Network Resilience: The dual mining approach provides redundancy and ensures the network remains secure even if one component faces challenges. * Broader Geographical Distribution: Permissionless mining enables participation from regions that may have different economic considerations for mining operations. * Flexibility in Mining Options: Miners can decide which approach to mining they prefer at various times, optimizing for efficiency, difficulty, and other economic factors at any time. *** ### Index Mining Fractal Standard Indexing Service is a standardized, open-source, and permissionless data indexing system and integrated into Fractal's block reward mechanism to ensure long-term, incentivized data availability across the ecosystem. * Indexing software will be open-source. Participation is permissionless. Anyone may operate indexing services permissionlessly. Miners and mining pools may also participate by running index nodes or joining the staking mechanism. * Standardized data output provides developers with consistent, reliable data structures across all supported protocols. * Non-custodial Staking: Users stake FB through Taproot scripts. Funds always remain under user private-key control. Users may exit and migrate between indexing instances without operator permission. * Non-blocking Settlement: Index verification and reward settlement must not enter the block production critical path. Index rewards may be processed asynchronously or with delay to preserve chain liveness. ⚠️ We are currently developing and open-source a lightweight indexer to ensure data availability and open for anyone who might want to test the indexing and staking mechanism. Please stay tuned. *** ### Advanced Security Considerations #### 1. Multi-Vector Attack Resistance Cadence Mining's hybrid approach creates unique security characteristics that significantly enhance the network's resistance to attacks. An attacker would need to control substantial portions of both mining components simultaneously to compromise the network, creating a multi-layered defense mechanism. The economic cost of attacking both vectors at once is prohibitively high, requiring massive resources across different mining approaches. This dual approach creates security redundancy not found in single-vector systems, ensuring that even if one component experiences challenges, the overall network remains secure and operational. #### 2. Game Theory Advantages The design of Cadence Mining creates positive-sum incentives that benefit all participants in the ecosystem. Permissionless miners benefit from the security inherited from Bitcoin's established network, adding legitimacy and trust to their operations. Bitcoin miners gain additional revenue streams without compromising their primary operations, enhancing their overall profitability. The broader ecosystem benefits from both increased security through multiple mining vectors and greater decentralization through diverse participation models. This alignment of incentives creates a virtuous cycle that strengthens the entire network over time. #### 3. Economic Self-Balancing Mechanism The Cadence Mining approach also creates a natural economic equilibrium that benefits the entire ecosystem. Since both Fractal and Bitcoin mining use compatible hardware and software infrastructure, miners can fluidly distribute their hash power between permissionless Fractal mining and Bitcoin mining (with merged mining rewards) based on the relative prices and profitability of FB and BTC. This dynamic allocation optimizes mining efficiency across both networks: when FB value increases, more hash power shifts toward permissionless Fractal mining; when BTC strengthens, miners emphasize Bitcoin mining while still collecting merged mining rewards. This self-balancing system ensures optimal resource allocation, maintains network security through varying market conditions, and maximizes returns for miners regardless of which token is currently more valuable. *** Cadence Mining represents a significant innovation in blockchain consensus design. By integrating the security advantages of Bitcoin merged mining, the accessibility and decentralization of permissionless mining, and the data availability, composability, and application usability provided by indexing mining, Fractal has created a uniquely balanced and robust infrastructure model. This hybrid approach ensures that Fractal benefits from Bitcoin's security while maintaining its own independent mining ecosystem. The combination creates greater security, decentralization, sustainable operation, and resilience than either approach could achieve alone. # Merge Mining A Win-Win for Bitcoin Miners The integration of merged mining has been one of Fractal's most successful innovations, with approximately 70% of Bitcoin's hash rate now participating in merged mining on our network. This remarkable adoption isn't by chance — it's the result of carefully designed economic incentives that create a win-win situation for Bitcoin miners. Let's dive deep into the economics that make this possible. ### Understanding Merged Mining Economics #### The Basic Principle Merged mining allows Bitcoin miners to simultaneously mine both Bitcoin and Fractal blocks using the same computational work. This creates a unique value proposition: * Primary mining effort goes to Bitcoin * Additional rewards earned from Fractal * No significant increase in operational costs * Profit addition to existing mining operations ### Real-World Economics: Breaking Down the Numbers Let's analyze the economics with real-world figures (note: actual numbers may vary based on market conditions): #### Cost Structure for Bitcoin Mining ``` Daily Operational Costs: - Electricity: $X per kWh - Hardware Depreciation: ~0.2% daily - Facility Costs: Fixed overhead - Staff and Maintenance: Fixed costs Daily Revenue (Bitcoin Only): - Block Rewards: 3.125 BTC per block (current reward after the 2024 halving) - Transaction Fees: Variable - Blocks per day: ~144 (one block every ~10 minutes) ``` #### Additional Revenue from Fractal Merged Mining: ``` Daily Additional Benefits: - FB Token Rewards: 25 FB per block - Transaction Fees: Variable (using the same consensus mechanism as Bitcoin) - Fractal Blocks: ~2,880 per day (30-second block time, 20x faster than Bitcoin) - Additional Computational Overhead: <0.1% - Additional Electricity Cost: Negligible ``` ### Profitability Analysis #### 1. Return on Investment (ROI) For a typical mining operation, the economics of merged mining create a compelling value proposition. The base Bitcoin mining ROI (X%) forms the foundation of mining economics, covering the costs of electricity, hardware, and operations. When Fractal's merged mining is added to the equation, miners experience an additional ROI (Y%), significantly enhancing their overall returns to (X+Y)%. What makes this proposition particularly attractive is that this substantial boost in returns requires virtually no additional investment – miners use the same hardware, electricity, and infrastructure they've already deployed for Bitcoin mining. #### 2. Risk-Adjusted Returns When evaluating mining opportunities from a risk-adjusted perspective, Fractal's merged mining stands out as an excellent option. Miners face zero additional capital risk, as they don't need to purchase new equipment to start mining. The operational risk is minimal, with negligible impact on existing mining operations and no significant increase in complexity. The result is significant upside potential with limited downside exposure. Additionally, by earning both BTC and FB tokens, miners gain valuable portfolio diversification benefits, reducing their exposure to single-asset volatility and creating a more stable revenue stream across varying market conditions. #### 3. Dynamic Revenue Optimization Fractal's merged mining approach works in tandem with Bitcoin's mining mechanism to create a self-balancing economic system for miners. Because both networks use compatible mining hardware and software, miners can strategically shift their resources between merged mining and focused mining on either network based on market conditions. When FB price rises relative to BTC, miners may allocate more resources to Fractal's permissionless mining; when BTC strengthens, they can emphasize Bitcoin mining while still collecting additional FB rewards through merged mining. This flexibility allows miners to continuously optimize their revenue streams and maximize profitability regardless of market volatility, adding another layer of economic benefit beyond the straightforward additional rewards. ### Game Theory of Participation The decision to participate in Fractal merged mining can be analyzed through game theory: #### Nash Equilibrium AnalysiS ``` Strategy Options: 1. Mine Bitcoin only 2. Mine Bitcoin + Fractal (merged mining) Dominant Strategy: - Merged mining emerges as the dominant strategy due to: * Minimal opportunity cost * Additional, significant reward potential * Network effect benefits ``` ### Market Impact and Network Effects #### 1. Hash Rate Growth on Fractal * Initial adoption by major pools * Rapid growth to current 60+% participation and holding steady * Network effect driving further adoption #### 2. Market Dynamics * Increased mining efficiency * Better resource utilization * Enhanced network security ### Mining Pool Economics #### Pool Operator Perspective: 1\. Implementation Costs: * Minimal integration effort due to similarity to Bitcoin infrastructure * Minimal ongoing maintenance * Software updates and monitoring 2\. Benefits: * Additional revenue stream * Competitive advantage * Miner retention through enhanced rewards #### Pool Participant Perspective: 1. Individual Miner Benefits: * Automatic participation in Fractal mining * Proportional reward distribution * No additional setup required * Profit increases ### ### Comparative Analysis with Other Mining Opportunities #### vs. Bitcoin-Only Mining: ``` Bitcoin-Only: - Revenue: 3.125 BTC rewards per block + fees - Costs: Full operational costs - Net: Standard mining returns Bitcoin + Fractal: - Revenue: 3.125 BTC rewards per block + fees + 25 FB per block + Fractal fees - Costs: Same operational costs - Net: Enhanced returns with no extra cost ``` ### Risk Considerations and Mitigation #### 1. Technical Risks * Pool integration challenges * Network upgrades * Technical dependencies #### 2. Market Risks * FB token price volatility * Mining reward variations * Competition from other protocols #### 3. Risk Mitigation Strategies * Robust testing frameworks * Community feedback integration The economics of merged mining on Fractal present a compelling case for Bitcoin miners. With 70% of Bitcoin's hash rate already participating, the model has proven its value proposition. The combination of: * Zero additional costs * Pure profit potential with increases ranging from several basis points to double-digit percentages * Strong network effects * Growing ecosystem value Creates an economic environment where participation becomes increasingly attractive over time. Crucially, merged mining with Fractal directly contributes to Bitcoin's security budget. By providing miners with additional revenue streams that can increase profits, Fractal helps ensure their profitability, especially during periods of market volatility or after halvings when block rewards decrease. This enhanced profitability encourages miners to maintain or increase their Bitcoin mining operations, strengthening the overall security of the Bitcoin network. This symbiotic relationship was a fundamental consideration in Fractal's design, creating a system where both networks benefit from each other's success. As Fractal continues to evolve and grow, these economic benefits are likely to become even more pronounced, further reinforcing Bitcoin's long-term security and sustainability. # Permissionless Mining Beyond merged mining, Fractal (FB) can also be permissionlessly mined on its own. This accessibility ensures that miners can flexibly participate directly in the Fractal network, depending on market conditions. The permissionless mining component represents approximately one-thirds of Fractal's mining structure, complementing the one-third that comes from merge mining and indexing mining. This dual approach creates opportunities for diverse participants, from individual miners to specialized mining operations focused specifically on Fractal. By maintaining this permissionless access, Fractal ensures a more decentralized and robust network, while still leveraging Bitcoin's security when possible through merged mining. This approach maximizes both accessibility and security, creating a balanced ecosystem that welcomes participants of all interests and sizes. ### Unique Aspects of Permissionless Mining While merged-mining offers a way to participate while mining Bitcoin, permissionless mining provides its own distinct benefits: #### 1. Independent Participation Model * Miners can focus exclusively on Fractal * Opportunity for specialized mining operations * Lower barriers to entry compared to Bitcoin mining #### 2. Competitive Advantages * Direct FB token rewards (25 FB per block) and fees * Reduced competition compared to Bitcoin mining * Potential for higher ROI for efficient operations #### 3. Mining Pool Diversity * Multiple pool options specifically for Fractal mining * Diverse ecosystem of mining service providers * Community-driven mining initiatives # Index Mining Fractal Standard Indexing Service is a standardized, open-source, and permissionless data indexing system and integrated into Fractal's block reward mechanism to ensure long-term, incentivized data availability across the ecosystem. * Indexing software will be open-source. Participation is permissionless. Anyone may operate indexing services permissionlessly. Miners and mining pools may also participate by running index nodes or joining the staking mechanism. * Standardized data output provides developers with consistent, reliable data structures across all supported protocols. * Non-custodial Staking: Users stake FB through Taproot scripts. Funds always remain under user private-key control. Users may exit and migrate between indexing instances without operator permission. * Non-blocking Settlement: Index verification and reward settlement must not enter the block production critical path. Index rewards may be processed asynchronously or with delay to preserve chain liveness. ⚠️ We are currently developing and open-source a lightweight indexer to ensure data availability and open for anyone who might want to test the indexing and staking mechanism. Please stay tuned. # How to Mine Fractal Bitcoin (FB) To mine Fractal Bitcoin, it is important that you have relevant expertise, specialized equipment and mining software. We recommend ensuring you possess the necessary technical knowledge and tools before proceeding. **Understanding the Mining Process.** Mining involves solving complex mathematical problems to validate transactions on the blockchain. However, simply running a node isn’t enough to successfully mine. Here’s a general breakdown: * **Running a node ≠ Mining.** Running a node allows you to participate in the network but doesn’t enable block mining. * You can use traditional programs like CPU Miner or GPU Miner to connect to a node and begin mining. However, these programs are typically only effective at low difficulty levels; at normal difficulty, mining is nearly impossible. * **Specialized Mining Hardware:** The most efficient mining method involves using ASIC miners connected to a mining pool. The mining pool retrieves work tasks from the node -> distributes them to the miners -> miners submit their work to the pool -> the pool sends the valid work to the node. Finally, the mining pool distributes the mining rewards to the miners based on their contributions. **How to Mine Fractal Bitcoin?** To mine Fractal Bitcoin, follow these steps: 1️⃣ Set up a Fractal Bitcoin node and update the `bitcoin.conf` file with the necessary configurations. ```JSON rpcport=8332 rpcuser=fractal rpcpassword=fractal_1234567 ``` 2️⃣ Use the UniSat Wallet to generate a Bitcoin address (e.g., `bc1qrcxxxxxxxxxxxxxxxxxxxxn772gm`). 3️⃣ You can start mining using various mining programs, Fractal’s mining algorithm is SHA256d. Here, we'll use cpuminer as an example. ```Shell ./miner -o http://172.0.0.1:10332 -u fractal -p fractal_1234567 --coinbase-addr=bc1qrcxxxxxxxxxxxxxxxxxxxxn772gm -a sha256d -t 1 --no-longpoll ``` > **Note:** Direct mining with these setup is unlikely to be successful due to the high difficulty level. Joining a mining pool is necessary for effective mining. **What Is a Mining Pool and How Does It Work?**\ \ A mining pool is a network of miners that combine their processing power to mine assets. You connect your client to the pool, the pool assigns work to you based on its criteria, and you receive payouts based on the work your mining rig submits to the pool. **How to start fractal mining in a mining pool?** Generally, mining pool software only requires you to configure the node RPC’s IP and port, the authorized account and password, and the address for receiving assets. Let's take the ViaBTC mining pool software as an example: For **Merged Mining**, the node provides the `createauxblock` and `submitauxblock` RPCs related to merged mining, but it does not support the older `getauxblock` RPC. The integration mechanism is identical to connecting to Namecoin, with `ChainID` set to `0x2024`. The software needs to be configured as follows: ```JSON "main_coin": { "name": "BTC", "host": "192.168.1.10", "port": 8332, "user": "btc", "pass": "btc_xxxxxx" }, "aux_coin": [ { "name": "FB", "host": "192.168.1.11", "port": 8332, "user": "fractal", "pass": "fractal_1234567", "address": "bc1q1wxxxxxxxxxxxxx9mukymc" } ], "aux_merkle_nonce": 0, "aux_merkle_size": 16, "aux_job_timeout": 10, ``` For **permissionless mining**, configure as follows: ```JSON "main_coin": { "name": "FB", "host": "192.168.1.11", "port": 8332, "user": "fractal", "pass": "fractal_1234567" }, "aux_coin": [ ], ``` **Resources** * **Node Software:** The latest version of the node software can be downloaded from the [FractalBitcoin GitHub repository](https://github.com/fractal-bitcoin/fractald-release/releases/tag/v0.2.1). * **Explorers:** * UniScan: # Fractal Bitcoin (FB) Mining FAQ #### **1. Potential Factors Affecting Block Production Efficiency and Solutions** **1.1 Running an outdated node version** Ensure that your mining node is updated to the latest version: [ Release](https://github.com/fractal-bitcoin/fractald-release) **1.2 High orphan block rate due to poor pool connectivity** To reduce the orphan block rate, mining pool nodes should establish connections with each other. Please contact the official team through the Telegram group and provide your mining node's IP address. The team will whitelist your IP, enabling your node to connect to the nearest designated node. This improved connectivity will help reduce orphan blocks. Recommended addnodes: * Singapore: addnode=34.87.61.167:8333 * Hong Kong: addnode=34.92.14.221:8333 * United States: addnode=35.235.106.223:8333 * United Kingdom: addnode=35.189.95.174:8333 **1.3 Mining machine polling intervals** Shorter polling intervals for mining tasks can significantly improve mining efficiency. Based on consultation with established pools like F2Pool, we recommend a 3-second polling interval for FB mining. Other mining machine parameter settings: * Start diff & max diff: Configure these based on your miners' hashrates. Optimal settings should allow miners to submit shares approximately every 20 seconds. * Nonce parameter: No adjustments required. *** #### **2. Empty Blocks: Causes and Solutions** **2.1 Insufficient mintxfee setting** When the mintxfee parameter is set too low on the mining pool side, the system may produce empty blocks. To resolve this issue, either increase the mintxfee parameter value or remove the restriction entirely. This adjustment will allow normal transaction inclusion in blocks, and regular block production. *** #### **3. Reducing Storage Requirements for Rapidly Growing Fractal Data** If you're concerned about disk space usage, consider running your node in pruned mode. Mining pool nodes typically don't require the complete blockchain history and can operate efficiently with pruned data. To enable pruning, add the following line to your bitcoin.conf file: prune=100000 Important note: Enabling txindex will prevent pruning from working. If you need to fetch UTXO data for specific addresses, use the UniSat API as an alternative to maintaining a full transaction index. *** #### **4. Merge-Mining Multiple Coins Simultaneously** You can merge-mine multiple coins at the same time. AuxPow (Auxiliary Proof of Work) is specifically designed to be compatible with multiple coins. To clarify: You typically won't earn rewards for multiple auxiliary coins from the exact same blockid. This is because different coins have varying difficulty levels and block times. During your Bitcoin mining process, you'll find solutions that meet the requirements for different coins at different times. In practice, this means your mining operation can search for Bitcoin solutions while simultaneously collecting rewards from multiple auxiliary chains like Fractal, SYS, and others. *** #### **5. How to Display Your Pool's Name and Logo in the Block Explorer** To have your mining pool's name and logo appear in the block explorer, you need to submit this information manually to the official GitHub repository: * Submit mining pool name:[ GitHub Link](https://github.com/fractal-bitcoin/mining-pools) * Submit mining pool logo:[ GitHub Link](https://github.com/fractal-bitcoin/mempool/tree/fractal/frontend/src/resources/mining-pools) \
# Full Node Configuration In the blockchain technology, Bitcoin full nodes play a crucial role in maintaining the network's security, integrity, and transparency.
#### What is a Full Node? A full node is a program that independently verifies all transactions and blocks in the Bitcoin network, enforcing every rule in the Bitcoin protocol. Beyond just keeping a complete copy of the blockchain, full nodes contribute to network security by receiving, validating, and relaying transactions and blocks to other nodes.Most full nodes also assist lightweight (SPV) clients by broadcasting their transactions and notifying them of relevant activity in their wallets. Without enough full nodes providing these services, SPV clients would need to rely on centralized services to connect to the network, potentially compromising the decentralized nature of Bitcoin.
#### Why Full Nodes Matter 1. Verification of Transactions: Full nodes validate all transactions and blocks, ensuring that only valid transactions are added to the blockchain. 2. Network Security: Each full node independently verifies and cross-checks data, which prevents tampering and ensures that no fraudulent transactions are allowed. 3. Decentralization: Full nodes prevent reliance on central authorities. Since anyone can run a full node, control over Bitcoin remains distributed and open. 4. Privacy Protection: Full nodes don’t require trust in third-party servers, allowing users to interact with the Bitcoin network privately and directly. #### Recommended System Requirements for Running a Full Node For optimal performance and long-term stability, the following hardware specifications are recommended for a Bitcoin full node: Memory (RAM): 8 GB Disk space: * Mainnet: 2TB (Based on the current scale, the data is growing by approximately 2TB per year. Please plan for expansion accordingly.) * Testnet: 300 GB Processor (CPU): 2 cores While it's possible to run a full node on lower specifications, these recommended resources will help ensure that your node operates smoothly and can keep up with the Bitcoin network’s growth. \ For more information on how to set up and operate a full node, you can refer to # Standard Indexing Service Overview Fractal Standard Indexing Service is designed to provide Fractal Bitcoin with an open-source, permissionless, standardized indexing service and integrated into the Fractal block reward system. FIP-101 proposal introduces Fractal Standard indexing service. It details the complete mechanism and implementation path for introducing standardized indexing service on Fractal Bitcoin. Read the full proposal [here](/overview/fips/fip-101-fractal-standard-indexing-service). ### Why Indexing Service Matters For every three mined blocks, one block will be permissionlessly-mined, one block will be merged-mined, and one block will be produced via indexing service. From a network architecture perspective: * Merged Mining provides security * Permissionless Mining ensures openness and decentralization * Indexing enables data availability, composability, and application usability Indexing reliability and availability are infrastructure-level requirements comparable to network security and decentralization, and therefore require long-term economic incentives. In other words, indexing is not only a developer convenience layer. It is part of the infrastructure that allows the network to remain usable, composable, and scalable as the ecosystem expands. ### The Problem It Solves 1. **Lack of Standardization in High-Performance Indexing** Currently, multiple indexing solutions exist within the Fractal community, including both commercial and open-source implementations. However: * Protocol parsing logic and output formats are inconsistent * Maintenance costs remain high * No unified standard interface or data structure has emerged This fragmentation introduces uncertainty and significantly increases integration costs for application developers. 2. **The Urgent Need for Standardization** Without timely standardization: * Protocol interpretation may fragment across different implementations * Developers will be forced to maintain redundant parsing logic * Integration errors and ecosystem inconsistency risks will increase Standardized indexing has become a necessary foundation for Fractal’s sustainable expansion. ### Why Now Over the past two quarters, UniSat Team, as a core contributor to Fractal Bitcoin, has conducted extensive refactoring of its production indexing system, achieving: * Approximately 80% reduction in memory usage * Initial synchronization completion within 24 hours, significantly faster than many existing open-source solutions * Substantially reduced hardware requirements and operational barriers The maturity of this infrastructure now enables a transition toward a fully open, community-operated standardized indexing framework. ### Core Design Principles #### 1. Open Participation and Replaceability The Fractal Standard Indexing Service is built around openness and replaceability: * Indexing software will be open-source * Participation is permissionless * Standardized output formats allow applications to switch between different implementations, reducing vendor lock-in risks #### 2. Non-custodial Staking and Exit Guarantees * Users stake FB to specific indexing instances to participate in reward distribution * Staking is implemented using Taproot scripts * Funds remain under user private-key control at all times * Users may exit and migrate between indexing services * No slashing mechanism is introduced in this proposal #### 3. Non-blocking Block Production and Asynchronous Settlement Indexing infrastructure may experience downtime, network partitions, or temporary verification issues. Therefore: * Indexing failures must not affect block production * Index reward settlement may be delayed * Long-term reward distribution converges toward target ratios without impacting chain liveness Settlement must remain outside the block production critical path. ### Incentive Structure The Fractal Standard Indexing Service introduces a reward distribution adjustment from 1:2 (Merged Mining : Permissionless Mining) to 1:1:1 (Merged Mining : Permissionless Mining : Indexing). Activated distribution: * Merged Mining: 1 * Permissionless Mining: 1 * Indexing: 1 Total issuance and emission schedule remain unchanged. The rationale is straightforward: security, openness, and data availability collectively define Fractal’s long-term sustainability. ### Participation Roles The system includes two primary roles: * **Index Operators:** Any entity (individuals, teams, miners, pools, institutions) may operate indexing instances and charge service fees * **Stakers:** Any user may stake FB into indexing services to participate in reward distribution This structure is intended to lower operational barriers, encourage decentralized participation, and support sustainable indexing infrastructure at scale. ### Reliability and Verification The system must define: * Objective criteria for valid indexing results * Automatic reward suspension for invalid or offline instances * Reorg handling and rollback consistency * Proof formats, dispute resolution processes, and verification cycles Chain must remain operational even during large-scale index downtime. Rewards pause automatically when indexing instances fail. Recovery mechanisms allow catch-up settlement and long-term convergence. These rules are designed to make the indexing layer verifiable, fault-tolerant, and operationally sustainable. ### Fractal Standard Indexing Service Goals: * Reduce indexing fragmentation through unified base standards * Establish sustainable incentives for long-term indexing operation * Lower operational barriers to encourage decentralized participation * Minimize trust assumptions via non-custodial staking The Fractal Standard Indexing Service is intended to reduce indexing fragmentation through unified base standards, establish sustainable incentives for long-term indexing operation, lower operational barriers to encourage decentralized participation, and minimize trust assumptions via non-custodial staking. Standard indexing has become a necessary foundation for Fractal’s sustainable expansion. # Security Notice: Beware of Unauthorized Promotions and False Claims of Affiliation Dear Fractal Community, The team was recently made aware of certain third-parties using the Fractal brand name or logo without authorization to promote unofficial activities, events, or investment-related content. Such behavior is misleading to users, damages trust in the ecosystem, and may expose participants to unnecessary security or financial risks. If an event or activity was not released through the Fractal official X account, it means that it has NOT been approved, endorsed, or authorized by Fractal in any form. \ 📌 Please stay cautious and follow these basic principles: #### Only trust Fractal's official channels Please rely only on announcements, updates, and event information published through Fractal’s official channels, including: * Our official website: [https://fractalbitcoin.io](https://fractalbitcoin.io/) * Our official X (Twitter) account: * Our official Telegram group: #### Do not trust unverified claims of cooperation or endorsement If any third party claims to be "partnered with Fractal", "authorized by Fractal", or "working with Fractal", please do NOT assume this is true unless it has been publicly confirmed by us through official channels.This also applies to: * Unofficial offline/online campaigns * Investment programs * Reward schemes * Private offers * Community-led promotions using the Fractal name \ Fractal does NOT permit unauthorized parties to use our brand for misleading promotions.For any individual, group, or platform that misuses the Fractal name, damages Fractal’s reputation, or harms user interests, we reserve the right to pursue legal action where appropriate. \ We encourage all users to stay alert, strengthen their ability to identify false claims, and avoid engaging with unofficial promotions. \ Fractal Team # Fractal Roadmap 2025 Fractal Roadmap for Q3 & Q4 2025 ### Q3 2025 `Software`\ Fractal Node upgrade 👉 ✅ Completed `Protocol`\ brc-20 Upgrade - Single-Step Transfer initially debut on Fractal Bitcoin and then on Bitcoin 👉Single-Step Transfer activated on Fractal — ✅ Completed `Community`\ Build [Fractal Common Ground](#user-content-fn-1)[^1] `Ecosystem`\ Fractal Liquidity Program (I) `Ecosystem`\ Fractal Developer Program (I) ➕ Q3 Beyond Roadmap * Fractal Bitcoin 1st Anniversary: FB Farming Launch & 1,000,000 FB Bonus Rewards * Announced Wrapped FB (WFB) on Ethereum ### Q4 2025 `Software`\ Fractal Node - New op-code research and experiments `Protocol`\ Support Alkanes experiments `Ecosystem`\ Fractal Liquidity Program (II) `Ecosystem`\ Fractal Developer Program (II) ### Fractal Ecosystem Outlook 2025 * Alkanes activated on PizzaSwap on Fractal Bitcoin * UniHexa - UniSat Next-gen Trading Engine initially debut on Fractal Bitcoin and then on Bitcoin * Simple Bridge Revamped - an easier, safer, and faster bridging between Bitcoin and Fractal. * UniSat Wallet 2.0 *** For further elaborations, please check out this blog post from Lorenzo: * [^1]: An initiative to gradually increase user involvement in Fractal ecosystem decisions. # Introduction ### Fractal’s Vision: Scaling Bitcoin as a recursive system Fractal emerges as a groundbreaking solution to one of Bitcoin's most persistent challenges: scalability. As the demand for Bitcoin transactions and applications grows, Fractal offers a way to expand Bitcoin's capabilities without compromising its core principles. Fractal is a system designed to enable the scaling of Bitcoin in the past, present, and future. It recognizes the historical debates and implementations surrounding Bitcoin scaling but takes a fresh approach tailored to the user needs of today. #### Fractal started as a way to ease network congestion for Bitcoin. The motivation behind Fractal stemmed from the issues with Bitcoin mainnet congestion, particularly highlighted during the rise of Ordinals, BRC-20, and Runes in 2023 - 2024. 1. This congestion posed an existential threat to services running on Bitcoin, as repeated congestion could undermine confidence in the Bitcoin mainnet. Without a reliable solution, users might lose faith in Bitcoin’s scalability. 2. Fractal’s core contributor team explored various alternatives to address this issue, but none were satisfactory, until Fractal as a concept was developed — being philosophically aligned with Bitcoin, while also simple to explain and implement. 3. The name Fractal Bitcoin reflects its recursive nature, inspired by the mathematical concept where a pattern repeats infinitely on different scales, symbolizing Bitcoin's ability to scale through recursive extensions. Fractal published its [technical litepaper in January 2024](https://fractal-bitcoin.notion.site/2024-01-Fractal-Bitcoin-v0-0-9-04c62c379d6846c7b6163fcd1fb9d566). Following that, the mainnet was planned for September 2024, and was indeed released on September 9, 2024. Fractal acknowledges that many Bitcoin users want to do more with their holdings. They're looking for ways to be more active participants in the ecosystem, whether through new protocols like Ordinals, BRC20s, Runes, or the Fractal-enabled CAT20. Fractal supports these native protocols, allowing users to innovate and experiment within a familiar framework under the Bitcoin umbrella. What sets Fractal apart is its seamless integration with existing Bitcoin infrastructure. Users can interact with Fractal using the same address format as their Bitcoin wallets, eliminating the need for new addresses or complex conversions. This user-friendly approach has led to rapid adoption, with over 900,000 active holders across various addresses on Fractal within just a month of its mainnet launch. #### Fractal is a pragmatic way to extend Bitcoin into a system. Fractal’s mainnet is a meticulously designed virtualization of the Bitcoin core code. The careful balance of parameters maintain the compatibility with Bitcoin, while enabling scale. Fractal’s block time is 30 seconds, 20x faster that Bitcoin’s. However, Fractal's approach to scaling isn't just about increasing transaction throughput. It's about creating a playground for innovation, where developers and users can push the boundaries of what's possible with Bitcoin. From decentralized exchanges to stablecoins and even advanced cryptographic implementations, Fractal is becoming a hotbed of Bitcoin-native innovation. Additionally, faster block confirmations drastically reduces wait times for transactions, offering a significantly improved user experience, particularly for trading and applications that require quicker confirmations. Fractal was designed to solve Bitcoin's problems using Bitcoin itself, without introducing new variables or technologies that would fundamentally change its nature (unlike solutions based on other blockchain technologies like Solana or Ethereum). Why this is important? This is because, if you extend Bitcoin using some other modern blockchain technology, then it’s not actually Bitcoin-based anymore — and loses the advantages of Bitcoin, including the efficiency, parallelism, compatibility, and stability of the model. Hence, Fractal aims to solve the scaling problem in a pragmatic way without introducing foreign constructs. As an extension of Bitcoin, Fractal is far less limited by historical limitations on the main Bitcoin chain, which exist for a reason. Fractal can do more, including activating opcodes such as OP\_CAT and beyond, to actually extend Bitcoin from a single blockchain into a system. The blockchain itself doesn't scale, but the system can scale in many ways. #### How does Fractal enable infinite scalability? A fractal is a geometric shape or pattern that displays similar structures at many different scales. Fractal achieves infinite scalability through a recursive approach to blockchain virtualization. By virtualizing the Bitcoin Core into deployable instances of Bitcoin Core Software Packages (BCSP), Fractal enables multiple instances to run in parallel, each with its own capacity, without departing from Bitcoin's original architecture. This creates a network of interconnected layers that can expand indefinitely. Fractal is recursively scaling Bitcoin, which means it is, in essence, creating recursive layers using Bitcoin core software. This is what makes Fractal natively compatible with Bitcoin, and able to support multiple opcodes (such as OP\_CAT), and core Bitcoin protocols such as Ordinals, BRC-20, Runes, RGB++ and more, without any complex or expensive reconfiguration by any developer team that wants to build on Bitcoin. The concept of recursivity is also very familiar to most developers, who may write functions that can repeat themselves indefinitely. In practical scaling terms, the cloud is a good illustration of the scaling instances. As an example, let’s say you run a prototype instance for your initial customers. As your app gets more popular, you will have to scale and to build or add more instances for more customers beating a path to your app. The cloud enables you to run numerous instances to deal with dynamic scaling situations. That is the intention behind Fractal, and why a development team may need many instances in a layered way. It can be done recursively, or horizontally or vertically. It depends on the user requirement and situation, and you can have different configurations and different sets of parameters to fit a variety of scenarios. In upcoming iterations of Fractal, there will be more examples showing how internet-scale applications can scale up and down with Fractal layers. This is what will enable large-scale, on-chain applications that truly bring mass adoption on the robust Bitcoin network. #### Fractal’s native token is FB. On Fractal, Fractal’s native token (FB) is used as the transaction fee. While the core contributor team initially considered using Bitcoin as transaction fees, they realized that having a native token would ensure stability and reliability in the network's operation. The primary reason for introducing a native token was to avoid reliance on a bridge for BTC, which could lead to issues if the bridge becomes unstable or is compromised. Other possible use cases of FB include: 1. Inter-layer bridging between the infinitely scalable Fractal layers via the Fractal Elevator (as described in the Fractal technical litepaper). 2. Community governance tool for Fractal Bitcoin, playing a role in guiding development and incentivizing contributions to the Fractal network 3. Use in certain services or tools within the Fractal ecosystem that require holding or spending Fractal tokens. 4. As the most basic measuring unit of programmable execution cost on the platform, enabling more innovative use cases for contracts. #### Fractal can be purely characterized as a infinitely scaling system for Bitcoin. At the moment, Fractal operates in a much simpler manner compared to other approaches, especially in terms of settlement between the Bitcoin mainnet and Fractal. * **Optional Settlement on Bitcoin Mainnet:** Fractal transactions are not required to settle on the Bitcoin mainnet permanently. Users have the option to settle on Bitcoin layer one if they choose, but it’s not necessary for every transaction. This allows Fractal to function autonomously without constantly relying on the Bitcoin mainnet for transaction settlement, unlike EVM-based layer twos that depend completely on a bridge to layer one. At the same time, Fractal is secured by merged-mining, where miners who mine Bitcoin also contribute to Fractal’s security — this means that Fractal inherits extremely strong security as a network, now with 50-60% of the Bitcoin network hash rates. * **Lower Fees, More Transactions:** Fractal’s core philosophy is to enable more transactions with lower fees compared to Bitcoin’s mainnet, providing greater scalability. * **An Extension of Bitcoin:** Developers and users are free to choose only critical or large Fractal transactions for settlement on Bitcoin layer one, making Fractal an extension of Bitcoin rather than an isolated ecosystem, enhancing Bitcoin's utility without adding unnecessary complexity. While Fractal is considered a sidechain by some observers, in the long-run, it cannot be characterized as such. While it may appear similar to a sidechain at first glance, Fractal's long-term vision is far more transformative. Rather than being a single, parallel chain, Fractal aims to extend Bitcoin into a scalable, multi-layered system with an infinite and dynamic number of instances. This approach allows for unprecedented flexibility and scalability, adapting to the ever-changing demands of a global digital economy. Each Fractal instance can be tailored to specific use cases or requirements, creating a rich, diverse ecosystem built on Bitcoin's fundamental principles. By enabling this multi-instance architecture, Fractal paves the way for Bitcoin to evolve from a single blockchain into a comprehensive, infinitely scalable system. #### **Philosophically, Fractal was created to solve problems for Bitcoin.** Fractal exists in service of Bitcoin. Fractal is meant to be a long-term project; our treasury has been planned such that we continue to invest in the ecosystem over 10 years. The aim is to make the pie bigger so that more can be shared in the future, where more can participate in the growth and prosperity of the Bitcoin network. In the [Fractal tokenomics](https://docs.fractalbitcoin.io/welcome-to-the-fractal-documentation/fractal-tokenomics), the team lays out exactly how the allocations may be spent over the next 10 years, with a full list of the reserve addresses transparently listed at the end of the doc. This means anyone can track these addresses and find out where the funds are going and when. It is Fractal's intention to be fully transparent at all times, so that the community can be confident in the governance of the network. Fundamentally, Fractal is focused on scaling Bitcoin as-is. The key is not to get into debates about what should be, but to provide tools and the right environment for experimentation. Fractal believes the future is all about accelerating progress and improvements, keeping up with what real Bitcoin users want. ### Fractal is all about empowering Bitcoin retail users At its core, Fractal is driven by a vision to empower retail users in the Bitcoin ecosystem. While many blockchain projects focus on institutional players or "whales," Fractal is firmly focused on the needs of the everyday Bitcoin user, aiming to provide them with more opportunities for active engagement and experimentation. This focus on retail users is evident in several aspects of Fractal's design and approach: 1. **User-Friendly Integration:** Fractal uses the same address format as Bitcoin, making it easy for regular users to interact with the platform without learning new systems or managing multiple addresses. 2. **Diverse Functionality:** By supporting multiple protocols like BRC20, Runes, Ordinals, and CAT, Fractal allows retail users to explore a wide range of Bitcoin-based applications and assets. 3. **Active Engagement:** Fractal is designed for users who want to do more with their Bitcoin, whether it's participating in DeFi, exploring digital collectibles, or engaging with new forms of Bitcoin-native assets. 4. **Accessibility:** The platform's design lowers barriers to entry, making it easier for average users to participate in more advanced Bitcoin use cases. 5. **Community-Driven Growth:** Fractal's growth has been organic and through word-of-mouth, reflecting its appeal to grassroots users rather than relying on paid promotions or partnerships. This retail-centric approach sets Fractal apart in the blockchain space. Fractal is building for the everyday crypto user interested in exploring the full potential of Bitcoin. By creating a platform where retail users can actively participate, innovate, and experiment, Fractal is democratizing access to advanced Bitcoin functionality. This approach not only broadens the appeal of Bitcoin but also fosters a more diverse and robust ecosystem. As Fractal continues to evolve, its commitment to empowering retail users remains at the forefront. By providing a playground for innovation and experimentation, Fractal is helping to shape a future where Bitcoin is not just a store of value, but a dynamic, interactive ecosystem accessible to all. ### Fractal’s Cadence Mining, designed to balance security and inclusivity At the heart of Fractal's consensus mechanism lies an innovative approach known as "[cadence mining](https://www.fractalbitcoin.io/mining)." This hybrid system combines the security benefits of Bitcoin's proven mining security with the accessibility of permissionless mining, creating a balanced and robust network. Fractal uses of the SHA256d mining algorithm, the same algorithm employed by Bitcoin. This choice ensures compatibility with existing Bitcoin mining infrastructure and expertise, allowing miners to easily participate in securing the Fractal network. By adopting SHA256d, Fractal leverages the robust security and decentralization that has made Bitcoin the gold standard of cryptocurrency networks. Cadence mining comprises two components: 1. **One-third Merged Mining:** This portion allows Bitcoin miners to simultaneously mine Fractal blocks while mining Bitcoin. It leverages the enormous hash power of the Bitcoin network, providing Fractal with a high level of security from day one. Currently, about 50-60% of Bitcoin's hash rate is engaged in merge-mining Fractal, demonstrating strong miner support for Fractal, with concrete economic contribution and input. 2. **Two-thirds Permissionless Mining:** This component opens up mining participation to a broader range of individuals and entities. It allows for greater decentralization and provides opportunities for those who may not have the resources to compete in Bitcoin mining directly. The balance between these two approaches offers several advantages: * **Security:** By tapping into Bitcoin's hash power, Fractal benefits from the world's most secure blockchain network. * **Decentralization:** The permissionless component ensures that mining is largely accessible to anyone who wants to participate in mining Fractal and contributing to its security. * **Flexibility:** Miners can choose how they want to participate, either through their existing Bitcoin mining operations or as solo Fractal miners. The success of this approach is evident in the numbers. The permissionless side of Fractal's mining has seen one of the highest hash rates of any proof-of-work networks. #### Fractal provides alternatives and seeks to protects Bitcoin’s security. Fractal provides an alternative source of revenue to Proof-of-Work miners, who are operating in a difficult macro environment of rising costs and decreasing profitability. Miners can continue to operate and contribute to the security of Bitcoin, while participating in the growth on Fractal. Fractal introduces network-level diversity, allowing miners to deploy resources across multiple platforms. The ability to allocate computing power across different networks, like on Bitcoin and Fractal, creates a more resilient and prosperous ecosystem for miners. Similar to diversifying a financial portfolio, this approach makes the system more robust and less reliant on a single source of economic activity. Cadence mining represents a thoughtful solution to the challenges of launching a new blockchain network. It provides strong security through merge mining, while also fostering a diverse and decentralized mining community through its permissionless component. This innovative approach exemplifies Fractal's commitment to creating a scalable, secure, and accessible extension of the Bitcoin ecosystem. ### Fractal for Developers: An Innovation Playground Fractal has quickly established itself as a vibrant ecosystem for developers looking to build Bitcoin-native applications. Its design and features make it an attractive platform for a wide range of projects, from decentralized finance (DeFi) to advanced cryptographic implementations. One of Fractal's key strengths is its support for multiple native protocols. Developers can work with BRC20, Runes, Ordinals, and CAT20, providing a rich toolkit for creating diverse applications. This multi-protocol support allows developers to choose the best fit for their specific use case while remaining within the Bitcoin ecosystem. #### Fractal is uniquely completely compatible with Bitcoin. For developers looking to build on Bitcoin, Fractal offers a seamless transition and familiar environment. The mechanism behind Fractal is intentionally designed to mirror Bitcoin's, ensuring developers can work as freely as they would on the Bitcoin mainnet. Historically, developers have found Bitcoin development more challenging compared to platforms like Ethereum, which offer more modern and accessible programming languages. However, Fractal bridges this gap by providing a comprehensive set of APIs and libraries that support various protocols such as BRC20, Runes, and Ordinals. This robust toolkit allows developers to build on Bitcoin without getting bogged down in the intricacies of transaction composition or UTXO management. Developers can start with Fractal's user-friendly APIs to quickly launch their projects, gradually delving deeper into blockchain specifics as they scale. This approach facilitates a smooth pathway for projects to evolve from Fractal prototypes to full-fledged Bitcoin mainnet applications, or vice versa, with minimal code changes. Adapting existing Bitcoin projects to work on Fractal can be remarkably efficient, often requiring less than an hour of modifications. This compatibility and ease of integration underscore Fractal's commitment to enhancing Bitcoin's ecosystem while maintaining its core principles and functionality. As a result of the way Fractal is architected, developers don't have to worry: anything built on Fractal will always work on Bitcoin, because the compatibility is carefully maintained. Fractal is designed to grow both horizontally and vertically, creating a dynamic hierarchy of instances that can adapt to new requirements and use cases as they emerge. This flexible architecture allows developers to strategically place new functionalities within the system, balancing load and optimizing performance across different layers. Much like cloud computing, Fractal is working towards a self-balancing, intelligent system capable of handling complex, diverse scenarios. While this is an ambitious, long-term goal, this approach will ultimately unlock Bitcoin's full potential as a foundation for a wide range of applications and services. #### Fractal brings new capabilities to the Bitcoin ecosystem. 1. **Smart Contracts and Modular Architecture:** Fractal introduces new opcodes like OP\_CAT, enabling developers to create complex smart contracts directly on Bitcoin. It supports building internet-scale applications with a modular architecture that integrates Bitcoin-native protocols like BRC-20. 2. **Lower Transaction Costs:** Fractal offers significantly lower transaction fees compared to Bitcoin, making it easier for projects to test and operate on Fractal. Developers can run their businesses on Fractal and move only the most valuable aspects back to the Bitcoin mainnet when necessary. This creates a flexible ecosystem where high-value assets settle on Bitcoin, while lower-cost and more time-sensitive transactions remain on Fractal. 3. **Balanced Ecosystem:** Over time, Fractal and Bitcoin can form a harmonious ecosystem. Fractal handles frequent, lower-value transactions, while Bitcoin serves as the hub for high-value assets. This balance allows applications to operate efficiently on both networks, enhancing scalability without compromising security. 4. **An Innovation Playground:** Fractal provides a fertile ground for developers to experiment and push the boundaries of Bitcoin. It’s a space for testing new ideas and applications, offering a sandbox for innovation while Bitcoin remains the anchor for core value. The platform has already seen the emergence of several noteworthy projects: * Infrastructure and tooling around OP\_CAT, to enable developers to create more interesting smart contract-like covenants and applications, as a testbed for what happens on the Bitcoin mainnet. * Decentralized exchanges are bringing DeFi capabilities to the Bitcoin ecosystem through Fractal. * Advanced cryptography like zk-based verifiers demonstrates the platform's capability to support cutting-edge cryptographic solutions, while zk-based atomic swaps are in deployment. * Cross-chain bridges are enhancing interoperability between Fractal and other networks. * Large scale games, virtual worlds, and new creative art and collectibles are pioneering a new wave of artistic innovation on Fractal. Fractal's compatibility with existing Bitcoin infrastructure makes it easier for developers to port their skills and projects. The familiar address format and similar development paradigms lower the barrier to entry for Bitcoin developers looking to expand their horizons. Applications that work on Bitcoin will work on Fractal, and vice versa. Furthermore, Fractal maintains a public roadmap at [build.fractalbitcoin.io](http://build.fractalbitcoin.io/), providing developers with insight into upcoming features and improvements. This transparency allows developers to plan their projects in alignment with the platform's evolution. The rapid growth of the Fractal ecosystem, with numerous projects launching within a month of the mainnet going live, speaks to the platform's appeal to developers. By providing a Bitcoin-native environment for innovation and experimentation, Fractal is fostering a new wave of creativity in the cryptocurrency space. Additonally, Fractal offers [ecosystem grants](https://www.fractalbitcoin.io/ecosystem-support) for developers building on Fractal. The grants are heavily weighted for innovation and technical implementation, with a component of community engagement. This is to reward developers who are pushing the envelope of what’s possible on Bitcoin and Fractal. All grants are retroactive, fostering a meritocratic environment where real impact is rewarded. As Fractal continues to evolve, it promises to remain a fertile ground for developers seeking to push the boundaries of what's possible in the Bitcoin ecosystem. ### Summary: Fractal convenes all Bitcoin users Fractal's design philosophy centers around creating a solution that harmoniously integrates with various stakeholders in the Bitcoin ecosystem. This approach ensures that Fractal not only scales Bitcoin but does so in a way that benefits all participants. #### Fractal has three major priorities: 1. Ensure that it continues to enable scaling while being completely rooted in Bitcoin. 2. Stability of the Fractal network overall. 3. Ensuring that ecosystem projects are successful, and achieve the adoption they seek. #### Fractal’s philosophy is to get Bitcoin-based innovations out the in the world as quickly as possible. Ultimately, Fractal's philosophy is a pragmatic, action-oriented approach to blockchain development. Rather than engaging in theoretical debates, Fractal has focused on creating a platform that comes "with batteries included" — ready for immediate, practical use. Fractal is versatile and provides comprehensive support for various protocols. The best way to understand Fractal's potential is to see it in action. It is a flexible, powerful extension of Bitcoin that enables developers to build a wide array of applications and services without limitations. By providing a robust foundation that supports multiple protocols out of the box, Fractal is empowering creators to focus on innovation rather than infrastructure. Fractal continues to be committed to advancing the Bitcoin ecosystem through practical, ready-to-use solutions. (Find out more about the [Zen of Fractal](https://www.fractalbitcoin.io/build).) #### Fractal aims to make Bitcoin innovative and fun for all users. For regular users, Fractal opens up a world of possibilities. It supports multiple native protocols including BRC20, Runes, Ordinals, and CAT20, allowing users to engage with Bitcoin in new and exciting ways. This expanded functionality satisfies the growing demand for more interactive and diverse use cases within the Bitcoin ecosystem. Service providers find integrating Fractal to be a seamless process. The use of the same address format as Bitcoin means that existing infrastructure can be easily adapted to support Fractal. This compatibility significantly lowers the barrier to entry for service providers looking to offer expanded functionality to their users. Miners, a crucial component of any blockchain ecosystem, benefit from Fractal's innovative "cadence mining" approach. This hybrid system combines one-third merged mining with two-thirds permissionless mining, striking a balance that appeals to different types of miners. The merged mining component has attracted a significant portion of Bitcoin's hash rate, while the permissionless side provides opportunities for a wider range of participants. For developers, the platform provides a abundant playground for creating and deploying a wide range of Bitcoin-based applications. This developer-friendly environment is crucial for the long-term growth and diversification of the ecosystem. By carefully considering and accommodating the needs of various Bitcoin stakeholders, Fractal has positioned itself as more than just a scaling solution. It's a bridge that connects different parts of the Bitcoin ecosystem, fostering innovation and collaboration while maintaining the core principles that make Bitcoin valuable. #### Closing thoughts: Fractal is an extension to Bitcoin’s vision. Fractal is driven by a vision that aligns closely with Satoshi Nakamoto's original concept of Bitcoin — not just as a digital currency, but as a comprehensive electronic cash system. Over the past decade, while Bitcoin has made significant strides, it hasn't fully realized its potential to address real-world financial needs on a global scale. Fractal sees itself as an extension of Bitcoin, designed to evolve it into the robust, multi-faceted system that the original Bitcoin whitepaper envisioned. The goal is to bridge the gap between Bitcoin's foundational principles and the practical demands of the real world. Fractal is not just scaling Bitcoin in terms of transaction capacity; it is expanding Bitcoin’s capabilities to interact with and solve problems across various industries. This approach allows Bitcoin to grow beyond a single construct into a versatile, problem-solving ecosystem. In essence, Fractal is creating a system that can truly serve as the backbone of a new, more efficient, and inclusive global financial infrastructure. Fractal is not reinventing the wheel; it is simply following through on the revolutionary idea that Satoshi set in motion, adapting it to meet the complex needs of our modern world. # How to... Welcome to the Fractal User Guides Fractal is the only native scaling solution completely and instantly compatible with Bitcoin. In this documentation, you'll find step-by-step tutorials, feature overviews, and best practices for interacting with Fractal’s key components. # How to send / receive FB with self-custody wallets? Please do your own research. This guide serves only as a reference for users. 🔸 **UniSat Wallet Instructions** **Step 1: Download the Chrome Extension** • **Download UniSat Wallet**: Visit the official Chrome Web Store link for **UniSat Wallet** and verify that it has a large number of reviews and a verified checkmark to ensure it’s not a phishing site. Download link: [Here](https://unisat.io/download) *Please make sure you are using the latest version of the extension.* **Step 2: Set Up Your Wallet** • Install the extension and **set up your wallet**. During the setup process, **securely back up your seed phrase** and make sure **not to share** it or store it online. • \[Optional] **Connect a hardware wallet**: If you have a hardware wallet like **Keystone**, you can connect it to UniSat Wallet as well.
**Step 3: Select a Taproot Address** • Ensure that you select a **Taproot address** to be compatible with Fractal Bitcoin. Other address like Native Segwit are supported as well. **Step 4: Toggle to Fractal Bitcoin** • In the wallet interface, navigate to the **top-right corner** and switch from **BTC Mainnet** to **Fractal Bitcoin Mainnet**.
**Step 5: Check Your FB Balance** • Once you’ve toggled to **Fractal Bitcoin**, your balance will be displayed. • To **receive FB**, click **Receive** and copy your Fractal Bitcoin receiving address to share with others.
**Step 6: Send FB** • To **send FB**, click **Send**, enter the recipient’s Fractal Bitcoin address, and confirm the amount of FB you wish and the fees to send.
**🔸 OKX Wallet Instructions** **Step 1: Download the Chrome Extension** • **Download OKX Wallet**: Visit the official Chrome Web Store link for **OKX Wallet** and ensure it has a verified checkmark and good reviews to avoid phishing scams. Chrome Extension download link: [Here](https://www.okx.com/web3) *Please make sure you are using the latest version of the extension or wallet.* **Step 2: Set Up Your Wallet** • After installing the extension, **set up your wallet**. Be sure to **securely back up your seed phrase** and do not store it online or share it. • **Connect a hardware wallet**: For added security, you can connect a hardware wallet like **Keystone** to OKX Wallet.
**Step 3: Toggle to Fractal Bitcoin** • Inside the wallet, navigate to the **top-right corner** and switch from **BTC Mainnet** to **Fractal Bitcoin Mainnet**.
**Step 4: Check Your FB Balance** • Once you’ve switched to **Fractal Bitcoin**, your FB balance will be displayed. • To **receive FB**, click **Receive** and choose one of the following address types to receive it. Each type of address supports Fractal Bitcoin. We recommend you use taproot address or Segwit Native address. • Copy the provided address to share with others for fund transfers.
**Step 5: Send FB** • To **send FB**, click **Send**, enter the recipient’s Fractal Bitcoin address, specify the amount of FB, and cnfirm the transaction.
With this guide, you are now ready to send and receive Fractal Bitcoin (FB) on either UniSat or OKX Wallet. Always ensure that you verify official links, secure your seed phrase, and use the right address format for compatibility with Fractal Bitcoin. # How to inscribe Ordinals？ Welcome to the Fractal Bitcoin! Follow this step-by-step guide and begin your inscribing journey. **Step 1: Understand brc-20 Rules on Fractal**\ Click [here](https://docs.fractalbitcoin.io/doc/brc-20-on-fractal) for detailed brc-20 rules on Fractal. **Step 2: Setting Up Your Fractal Bitcoin Wallet** *Users are free to inscribe on platforms like OKX or UniSat. In the following guide, we will use UniSat as an example.* * Open the UniSat Wallet extension. You can download it by clicking [here](https://fractal.unisat.io/download). * Click the network dropdown in the top-right corner and switch to **Fractal Bitcoin Mainnet**.
Now, you can start inscribing! The inscribing process is similar to Ordinals on Bitcoin mainnet. **Step 3: Start Inscribing** * Go to the UniSat site: and click "Connect" in the top-right corner and sign in with your wallet address. * Navigate to the Inscribe page via the top navigation bar or click [here](https://fractal.unisat.io/inscribe). You can inscribe brc-20, Names, Files, and Text, and experience the brc-20 deploy process.
**Inscribing Steps:** 1. Input the ticker name you want to inscribe, the amount, and the number of inscriptions to mint in bulk (Repeat Mint). Once you've filled in these details, click "Next" to proceed.
2. Review the minting details, click "Next" if everything is correct, then read and acknowledge the “Risk Warning”.
3. In the pop-up window, input your receiving address. You can use the connected wallet address or enter another one manually. * Set the fee rate. You can use the suggested fee or enter a custom fee. * Once you’ve confirmed that all the information is correct, click "Submit & Pay Invoice." Please note that by clicking "Submit & Pay Invoice," you are confirming that you have read and agreed to the Risk Warning statement.
4. Confirm your payment method. The default option is "Pay with Wallet," but you can manually select another payment method if necessary.
5. After comfirming your payment method, a signature details page will appear. Before clicking "Sign & Pay," carefully review the inputs, outputs, and other transaction details. Make sure everything is accurate, then click "Sign & Pay" to finalize the transaction.
6. At this point, your minting order has been created and will begin processing. * The status "Inscribing" means that the inscription is currently in progress and awaiting confirmation. Once the process is complete, the status will change to "Inscribed." * It's important to note that if mempool fees are high or the ticker is particularly popular, your transaction might be front-run. This means that if the ticker supply is out before your transaction is confirmed, your order may still show as "Inscribed," but you won't receive the token because the supply has already been depleted. Gas fees are non-refundable, as they are paid to the miners for processing the transaction.
*** **brc-20 on Fractal Full List** * Go to , scroll down to see the full list of BRC-20 assets and you can also inscribe directly by typing the name of the ticker you want to inscribe in the search box.
# How to trade Ordinals？ In this guide, we will walk you through the process of buying and selling ordinals. *Users are free to trade on platforms like OKX or UniSat. In the following guide, we will use UniSat Marketplace on Fractal as an example.* *** **1. Accessing UniSat Marketplace on Fractal** * Go to the UniSat Marketplace on Fractal: . * Click the **Connect** button to link your wallet to the marketplace.
*** **2. Supported assets on UniSat Marketplace on Fractal** On the UniSat Marketplace, you can trade the following assets: * **brc-20 tickers** * **Names (.fb)** * **Collections** For this guide, we'll use the example of trading brc-20 tickers. *** ### **Buying brc-20 Tickers** **Step 1: Select Ticker and Choose an Order** 1. Select the ticker category you want to trade with, then enter the ticker name you want to buy. 2. A list of available buy orders will appear. Choose an order that suits your requirements and click the **Buy** button. > You can buy brc-20 tickers individually, or use the slider at the bottom-left corner to purchase them in bulk.
*** **Step 2: Confirm Details** On the purchase details page, carefully check the following: * **Ticker name** (case-sensitive) * **Amount** of tickers * **Fee** Once all the details are confirmed and correct, click **Confirm** to proceed.
*** **Step 3: Signature and Payment** After clicking confirm, the system will prompt you to sign the transaction. Double-check the **input** and **output** details to ensure everything is correct. Once verified, click **Sign** to complete the purchase.
*** ### **Selling brc-20 tickers** **Step 1: Select Ticker and List** 1. Select the ticker category and enter the **ticker name** you want to sell. 2. On the right-hand side of the new page, click **My Assets**, then find the ticker you want to list and click the **List** button.
*** **Step 2: Inscribe Transfer** Before listing your tickers for sale, you need to perform an **Inscribe Transfer**. Follow these steps: 1. Click the **+** button on the page to perform the Inscribe Transfer. 2. A signing page will appear—enter the **amount**, **output value**, and **fee rate** and click **Next.** 3. Once all details are correct, click **Next**. Review the **inputs** and **outputs**, and then click **Pay & Sign** to complete the transaction. > Note: You will need to wait for **3 confirmations** before you can list the ticker for sale.
*** **Step 3: List Your Ticker** Once the transfer is completed and confirmed, follow these steps to list your ticker: 1. Select the transfer you want to list for sale and click **List**. 2. Enter the **selling price** and click **List for sale**. 3. Review and confirm the details, then click **Sign** to finalize the listing.
*** **Step 4: Manage Your Orders** After listing, you can check your orders by navigating to the **My Orders** section. From here, you can: * **Change the price** of your listed orders. * **Unlist** tickers if you want to remove them from the marketplace.
By following this guide, you should be able to effectively buy and sell ordinals on the UniSat Marketplace for Fractal. If you encounter any issues, please feel free to contact our support team on [Discord](https://discord.gg/fractalbitcoin). # How to interact with InSwap？ InSwap is the first DEX to be built concurrently on both Bitcoin and Fractal, aiming to support all asset types across these networks, and more! Try it out: *** * InSwap is compatible with **Native Segwit (P2WPKH)** and **Taproot (P2TR)** addresses. Make sure your wallet is configured to use one of these address formats. * For more details about InSwap, click the link: *** 1. **Wrap assets to InSwap** As mentioned earlier, you need to wrap assets into the InSwap module before swapping. Let's take the example of BTC, after connecting to your wallet, click "**Wrap"** tab, Select BTC or another asset from the dropdown list, then choose a transfer to wrap it. For brc20 tickers, if there is no transferable amount available, please click "**Inscribe TRANSFER**" to inscribe a transfer inscription first. Wrapping requires block confirmations. Please be patient during this process. *** 2. **Adding Liquidity to Earn Rewards** * Click the **"Trading Pairs"** button and search for the trading pair you want add liquidity. * If the pair is available, click the **"Add"** button on the right to add liquidity. ![](https://docs.unisat.io/~gitbook/image?url=https%3A%2F%2F3523236551-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FJ4NHAHIVnWQiEecvs1By%252Fuploads%252F8qi9N27amcf237Q38eyE%252F2.png%3Falt%3Dmedia%26token%3D0c11d153-9369-4406-b2a7-c20e272495e1\&width=768\&dpr=4\&quality=100\&sign=f5a4aa00\&sv=2) * Input the amount of liquidity you wish to contribute, then click the "**Supply**" button. ![](https://docs.unisat.io/~gitbook/image?url=https%3A%2F%2F3523236551-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FJ4NHAHIVnWQiEecvs1By%252Fuploads%252FtTBsM9F5HdE5ZKz7uDIa%252F15.png%3Falt%3Dmedia%26token%3D76091cb9-4a2a-4950-9bff-753e0e604604\&width=768\&dpr=4\&quality=100\&sign=dd148e\&sv=2) * Confirm your transaction by clicking the "**Confirm Supply**" button and signing in your wallet. ![](https://docs.unisat.io/~gitbook/image?url=https%3A%2F%2F3523236551-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FJ4NHAHIVnWQiEecvs1By%252Fuploads%252FOQahRS4w9re156XfPkpG%252F16.png%3Falt%3Dmedia%26token%3D29d5b36d-927a-41d2-8318-6e986720ffef\&width=768\&dpr=4\&quality=100\&sign=df7af17b\&sv=2) **Tips: Creating a Liquidity Pool** If you can’t find the trading pair you want, it means the liquidity pool doesn’t exist yet. To create a new pool, click **"Create Trading Pair"**, select the brc-20 asset from the dropdown list, and then click **"Create"** to set up a new pool. ![](https://docs.unisat.io/~gitbook/image?url=https%3A%2F%2F3523236551-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FJ4NHAHIVnWQiEecvs1By%252Fuploads%252F4SSsvnzGhaS1lvlfkOn7%252F3.png%3Falt%3Dmedia%26token%3D607ec37a-2ac8-4fd2-88ea-a05d13c78a17\&width=768\&dpr=4\&quality=100\&sign=963a86a\&sv=2)![](https://docs.unisat.io/~gitbook/image?url=https%3A%2F%2F3523236551-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FJ4NHAHIVnWQiEecvs1By%252Fuploads%252FTBgCyzPXQjFbTrVEvKSn%252F4.png%3Falt%3Dmedia%26token%3Deafff286-75be-4d8a-a436-59dae5303cd0\&width=768\&dpr=4\&quality=100\&sign=7420fba7\&sv=2) *** 3. **Swapping Assets** Click on the **Swap** button to begin the asset swapping process. Choose the asset you want to pay with. Then input the amount you wish to pay. Review the swap details and click the **Swap** button to initiate the transaction. ![](https://docs.unisat.io/~gitbook/image?url=https%3A%2F%2F3523236551-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FJ4NHAHIVnWQiEecvs1By%252Fuploads%252Fy6MoApiytcju1vDnfCuk%252F5.png%3Falt%3Dmedia%26token%3Defb84c73-95d8-4b27-a58c-4457c36aa9cb\&width=768\&dpr=4\&quality=100\&sign=74591b9d\&sv=2) Confirm the swap information, then click the "Swap" button. And then sign in your wallet. ![](https://docs.unisat.io/~gitbook/image?url=https%3A%2F%2F3523236551-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FJ4NHAHIVnWQiEecvs1By%252Fuploads%252FxxPm1Oc1UPXj7V6a5sps%252F18.png%3Falt%3Dmedia%26token%3D642ad849-b83c-4d1d-bd2f-df4a421457cc\&width=768\&dpr=4\&quality=100\&sign=888e4879\&sv=2) *Every swap incurs a 1.5% transaction fee. 5/6 allocated to liquidity providers (LPs) rewards, 1/6 used to support platform maintenance.* *** 4. **Unwrap Assets** To unwrap assets from InSwap, simply go to the **"Unwrap"** page and follow the instructions: Click the "**Swap**" button, then click the "**Unwrap**" tab. Click on the asset you want to unwrap, input the unwrap amount. Then click "**Unwrap**" button. # How to use the Simple Bridge? This guide provides detailed instructions on how to use Simple Bridge. Please do your own research. This guide serves only as a reference for users. Simple Bridge, developed by UniSat, is a small service designed to securely and efficiently connect assets from different protocols to PizzaSwap. By integrating the latest cryptographic algorithms, Simple Bridge enhances the security and performance of cross-chain asset transfers, bringing innovation to the blockchain ecosystem. Try it out: *** ### **Understand Simple Bridge Rules** * Before you begin, make sure to familiarize yourself with the [Simple Bridge rules](https://docs.unisat.io/fractal-services/simple-bridge-cross-chain-asset-transfers). ### **Setting Up Your Fractal Bitcoin Wallet** * Open the UniSat Wallet extension. You can download it by clicking [here](https://fractal.unisat.io/download). ### **Using Simple Bridge** #### **Step 1: Access the Simple Bridge Page** * Go to Simple Bridge Page [https://fractal.unisat.io/bridge ]() and click "Connect" in the top-right corner to sign in with your wallet.
#### Step 2: Bridge BTC or Inscribe Transfer for brc-20 * For BTC: Select BTC and simply input the amount you wish to bridge in the "You Pay" section.
* For brc-20: First, you need to perform an Inscribe Transfer. Select the ticker you want to bridge from the dropdown menu next to the ticker name, then choose a transfer to bridge.
If you haven't completed an Inscribe Transfer yet, follow the steps below: * In the "You Pay" section, select the ticker you wish to bridge and click + to start the Inscribe Transfer. * In the pop-up signature window, enter the Amount, Output Value, and Fee Rate. After verifying the information is correct, click "Next." * Confirm the signature details, and click "Next" again. * Double-check the inputs and outputs in the signature window. Once everything is correct, click "Sign & Pay" to complete the Inscribe Transfer. * After inscribe transfer, you need to patiently wait for 3 block confirmations. * Make sure the amount for the Inscribe Transfer is not less than the minimum value specified on the interface.
#### **Step 3: Bridge Operation** 1. In the Simple Bridge page, select the asset you want to bridge and input the amount in the You Pay field. 2. The system will automatically calculate and display the amount you will receive in the You Receive field. Verify the Receiving Address and Fee. If everything is correct, click Deposit. 3. In the signature window, confirm the inputs and outputs, then click Sign to complete the operation.
**Step 4: View Bridge Details** * After signing, you'll be taken to the Bridge Details page. The system will automatically complete the bridge operation.
### Withdraw from Simple Bridge The operations for withdrawing and depositing through the bridge are the same. First, click the 🔁 icon on the page to switch to withdraw mode.
#### **Step 1: Inscribe Transfer** * First, you need to perform an Inscribe Transfer. Select the ticker you want to withdraw from the dropdown menu next to the ticker name, then choose a transfer to withdraw.
* If you haven't completed an Inscribe Transfer yet, follow the steps below:In the "You Pay" section, select the ticker you wish to withdraw and click + to perform the Inscribe Transfer. * In the pop-up signature window, enter the Amount, Output Value, and Fee Rate. After verifying the information is correct, click "Next." * Confirm the signature details, and click "Next" again. * Double-check the inputs and outputs in the signature window. Once everything is correct, click "Sign & Pay" to complete the Inscribe Transfer. * After inscribe transfer, you need to patiently wait for 3 block confirmations. * Make sure the amount for the Inscribe Transfer is not less than the minimum value specified on the interface.
#### Step 2: Withdraw Operation 1. In the "You Pay" section, select the ticker you want to withdraw, and click the amount you previously Inscribe Transferred. 2. 2.The system will auto-fill the "You Receive" field with the corresponding amount. Double-check the Receiving Address and Fee. Once confirmed, click "Withdraw." 3. In the signature window, confirm the inputs and outputs, then click "Sign" to complete the process.
#### **Step 3: View Withdraw Details** * After signing, you'll be redirected to the Withdraw Bridge Details page. The system will automatically complete the bridge operation.
### View Bridge History You can view your Bridge Deposit and Withdraw history anytime by visiting the Bridge History page:
# How to use the Bool Bridge? #### What is Bool Bridge? Bool Bridge allows transferring BTC from the mainchain to Fractal as a BRC-20 token and vice versa. This enhances interoperability and unlocks opportunities for decentralized applications. The assets that are available for transfer are: * BTC <> bBTC * ordi <> bORDI * sats <> bSATS Please do your own research. This guide serves only as a reference for users. ### Connect your UniSat wallet Step 1: Go to . Step 2: Click “Connect wallet”.
Step 3: Ensure you have the UniSat Wallet installed on your browser. You can download it through or [the Chrome web store](https://chromewebstore.google.com/detail/unisat-wallet/ppbibelpcjmhbdihakflkdcoccbgbkpo?pli=1). *Please make sure you are:* 🔶 *using the latest version of the extension.* 🔶 *using a Taproot wallet. Understand the different types of* [*wallet addresses here*](https://docs.unisat.io/services/unisat-wallet/unisat-wallet-address-type)*.*
### Bridging Bitcoin to Fractal Assets (e.g. bBTC) Step 1: Choose the asset that you would like bridge from the Bitcoin mainnet to Fractal.
Step 2: Enter the amount you would like to bridge to Fractal.
Step 3: Press “Deposit” when you are ready.
Step 4: In the pop-up window, check if the input and output addresses correspond to your desired destination. If the details are right, click “Sign” to confirm the transaction.
Step 5: The transaction is now sent. You can track your transaction on the mempool explorer by clicking “View on explorer”.
### Bridging Fractal Assets (e.g. bBTC) to Bitcoin Step 1: Click this arrow to switch to transfer from the Fractal BItcoin mainnet.
Step 2: a. Click ”Refresh” to transfer your inscriptions. b. A pop-up window will appear, allowing you to select your desired output value and fee rate. To prioritize your transaction during periods of high network congestion, you can enable the "Replace-By-Fee (RBF)" option, which allows you to modify the transaction fee for quicker processing. After configuring your settings, click "Next" to proceed.
Step 3: Check if the details of your transfer are correct. Click “Next”.
Step 4: Once your inscriptions are successfully processed, it may take a few minutes for them to be indexed and appear on the interface.
Step 5: Once your inscriptions have been indexed, they will appear as selectable options in the interface. Click on the inscription you wish to transfer, as shown below, to confirm your selection.
Step 6: To confirm your transfer, click “Withdraw”.
Step 7: In the pop-up window, check the details and sign the transaction.
Step 8: The transaction is now sent. You can track your transaction on the mempool explorer by clicking “View on explorer”.
### Viewing Your Transaction on The Explorer **Option A:** Click the link on the transaction confirmation page
**Option B:** Click "History”.
a. To view the transaction in the Bitcoin mempool explorer, click the link located below the BTC amount. b. To view the transaction in the Fractal mempool explorer, click the link located below the Fractal asset.
#### Block Confirmation Times Please note that the Fractal Bool Bridge requires four confirmation blocks on Bitcoin before it shows in your Fractal balance. This is to ensure the security of the assets. In general, it will take between 30-40 minutes for you to receive your bBTC on Fractal. ### Checking bBTC Assets in Your UniSat Wallet To check all bBTC addresses, access this link:
To check your bBTC assets, access this link: . Step 1: Connect your wallet.
Step 2: If your wallet holds any bBTC, it will be displayed in the interface under the BRC-20 section, showing the available and transferable amounts.
# How to Interact with Runes? Back in 2023, Bitcoin developer Casey Rodarmor introduced **Runes**, a new protocol aimed at expanding the Bitcoin ecosystem. Known for his work on **Ordinals**, Rodarmor took a different approach with Runes. In his own words, "[Runes were built for degens and memecoin](https://x.com/rodarmor/status/1774613900119699701)," signaling that the protocol was designed with a lighter, more playful spirit compared to traditional Bitcoin projects. ### What are Runes? The Runes protocol was activated at Bitcoin’s 4th halving, around 840,000 blocks. Unlike Ordinals, Runes brings a fresh approach to how assets and tokens can be integrated into Bitcoin’s ecosystem. To grasp the significance of Runes, it is essential to understand several key concepts integral to Bitcoin's broader ecosystem. * **Sats**: Short for satoshis, these are the smallest divisible units of Bitcoin, often minted at specific times. They represent a foundational element of Bitcoin's value system. * **Inscriptions**: According to the [Ordinal Theory Handbook](https://docs.ordinals.com/inscriptions.html), “inscriptions inscribe sats with arbitrary content, creating bitcoin-native digital artifacts, more commonly known as NFTs. Inscriptions do not require a sidechain or separate token.”. * **Ordinals**: A system that assigns unique serial numbers to individual satoshis (the smallest unit of Bitcoin), allowing users to track and differentiate between specific sats. ### Runes unlock table
Runenames Unlock ScheduleEstimated DateStart BlockEnd Block
12-26 charactersOct 07 202484,000259,000
11 charactersDecember 6, 2024259,000434,000
10 charactersFebruary 5, 2025434,000609,000
9 charactersApril 7, 2025609,000784,000
8 charactersJune 7, 2025784,000959,000
7 charactersAugust 6, 2025959,0001,134,000
6 charactersOctober 6, 20251,134,0001,309,000
5 charactersDecember 6, 20251,309,0001,484,000
4 charactersFebruary 5, 20261,484,0001,659,000
3 charactersApril 6, 20261,659,0001,834,000
2 charactersJune 6, 20261,834,0002,009,000
1 characterAugust 6, 20262,009,0002,184,000
### **Benefits of the rune protocol** #### Efficiency * Avoids creating unspendable UTXOs. * The OP\_RETURN opcode consumes only 80 bytes compared to 4MB for BRC-20. * Allows for better compression compared to using BRC-20’s JSON on blockspace. * Allows open minting within terms set by the etcher. #### Liquidity * Attracts high-risk investors from other platforms to Bitcoin. * Boosts transaction fee revenue on the Bitcoin network for miners. #### Simplicity * Enables the issuance of native fungible tokens on Bitcoin. * Promotes innovation in the Bitcoin ecosystem. * Operates entirely on-chain, avoiding the need for off-chain complexities. ### Limitations of Runes Since its introduction, the daily etching of Runes has experienced a decline following an initial surge of interest. More insights on this trend can be explored via the Rune Dune [dashboard here](https://dune.com/cryptokoryo/runes). While Runes have generated significant excitement, it's important to approach them with caution, as the focus so far seems more centered on short-term interest rather than proven long-term utility. However, the protocol may still hold untapped potential. As the ecosystem evolves, new innovations could reveal meaningful use cases, allowing Runes to contribute to Bitcoin’s ongoing development. ### Innovate with these Token Standards on Fractal Runes are currently live, and by extension, can also be implemented on Fractal. Fractal Bitcoin encourages such innovations, pushing the limits of what Bitcoin can accomplish. As an innovation playground for developers, Fractal is dedicated to fostering a continuously evolving ecosystem of standards and applications. Building Runes on Fractal? Refer to our [resources here](https://docs.fractalbitcoin.io/doc/runes-on-fractal). Building BRC20 on Fractal? Refer to our [resources here](https://docs.fractalbitcoin.io/doc/brc-20-on-fractal). ***Disclaimer:** Runes, BRC 20, and Ordinals are not affiliated with Fractal. This blog post is for informational purposes only, and intended to help users understand the technology. Readers and community members are advised to do their own research before engaging with any projects or technologies mentioned. Fractal assumes no responsibility for any decisions made based on this information.* # How to Etch Runes? This guide will walk you through the step-by-step process of etching with Runes. This guide will use the UniSat Runes service on Fractal as a reference. You may visit to get the page. Input the parameters as needed. ***For example***： The ***Rune*** Name is everyone.loves.nature.forever, ***Symbol*** is E, It is ***Mintable***, and ***Amount*** was settled as 500, ***Cap*** for 4,000,000. The ***Premine*** is 15,000. **With Logo** option, select whether to add a logo for Runes. And leave other fields empty.Then you could input the above needed text as shown below,
*Please note: you need to wait for 5 blocks confirmations for etching.* After the Rune is confirmed as valid, the etcher will get 15000E everyone.loves.nature.forever. Meantime, the others can mint Rune everyone.loves.nature.forever. Following is the introduction for each parameter: ***Rune:*** Runes name, (currently you can etch 13-26 characters long, can be separated by a middle dot ·, and the separator does not count towards the character limit). ***Symbol (optional):*** The symbol after the number of runes, which can be A-Z or empty. If empty, a general symbol ¤ will be used. ***Mintable:*** Toggle off to disable further minting. Runes are only premine upon creation. ***Amount:*** The Amount field contains the amount of runes each mint transaction receives. ***Cap:*** The number of times a rune may be minted is its cap. A mint is closed once the cap is reached. ***Advanced options:*** Set up premining, divisible figures, and the starting or ending block where minting is possible (optional). ***Premine :*** The etcher of a rune may optionally allocate to themselves units of the runes being etched. This allocation is called a premine. ***Divisibility (optional):*** A rune's divisibility is how finely it may be divided into its atomic units. Divisibility is expressed as the number of digits permissible after the decimal point in the amount of runes. A rune with divisibility 0 may not be divided. A unit of a rune with divisibility 1 may be divided into ten sub-units, a rune with divisibility 2 may be divided into a hundred, and so on. ***Absolute Height:*** The absolute block height (based on the current block height). ***Relative Height：***The range of relative block heights (based on the block of etching real). ***Start Height：***A mint is open starting in the block with the given start height. ***End Height：***A rune may not be minted in or after the block with the given end height. # How to Mint Runes? This guide will use the UniSat Runes service on Fractal as a reference. Step 1: find the mint interface * Go to the Mint option on page .
Or you could explore Rune information on , search the ticker you want to mint and then Click ‘Mint’ -> ‘Mint Directly’ button if the rune can be mintable for more convenience.
Step 2: Start minting Runes * You could input the ***Rune or Rune ID*** as below. * You can input the number of ***Repet Mint*** or use the slide bar for batch minting.
After your transaction is confirmed on chain, you may check your runes balance in your wallet. # How to Trade Runes？ This guide will walk you through the step-by-step process of trading with Runes. Please do your own research. This guide serves only as a reference for users. Go to , and search for rune.
You can buy the Rune one by one or in batches. You can also list/unlist or update prices for your rune assets by clicking ‘My Assets’. * List Runes: Click ‘My Assets’ and then click ‘List’ button beside Rune, then you will get the List page as below,
* After setting the price and signing via Wallet, it will be listed. * You may go to My Orders to view the listed order, update price or unlist your Rune asset.
# Understanding CAT Protocol The Bitcoin ecosystem has a new innovator: **Covenant Attested Token (CAT) Protocol**. [CAT20](https://catprotocol.org/cat20), released by [CAT Protocol](https://x.com/ProtocolCAT), emerges as a fungible token standard, designed to enhance token functionalities on chains with OP\_CAT enabled, such as Fractal Bitcoin. Unlike existing protocols, CAT is fully validated by miners and operates using smart contracts, specifically **recursive covenants**, all enforced by Bitcoin’s built-in scripting language at Layer 1. CAT721 will likely be released at a later date. ### What is CAT20? #### Key Facts * **Bitcoin’s Security** * It is enforced by Bitcoin's consensus rules, inheriting its Proof-of-Work security. * **Requires OP\_CAT** * It is only available on OP\_CAT-enabled networks, such as Fractal. * **UTXO-based** * It is UTXO-based, and enforced by Bitcoin Script on L1 without the need for external or off-chain indexers. * **Allows for Innovation** * Its modularity and programmable minting enable flexible and composable rules for complex decentralized apps such as AMMs, lending, and staking. * **Miner Verified** * It is fully verified by miners for robust security and native enforcement. * **Interoperable** * It is cross-chain interoperable, which allows interoperable dApps to be built on Fractal Bitcoin. * **Lightweight** * It supports SPV and enables light clients to verify transactions efficiently, preserving decentralization and accessibility. ### Comparing CAT Protocol to the Existing Bitcoin Protocols
### What is Unique About CAT20? What makes CAT20 unique is that it allows tokens to be minted under specific conditions, **without changing the underlying protocol**. This can be done as it **does not need an indexer**. These conditions include: * Predetermined time * Block height * Time locks * Proof-of-work (PoW) verifications * Payment confirmation * Exclusive mints Through these minting conditions, additional functionalities are added. This opens the door to possible use cases using smart contracts and decentralized applications such as: * Automated Market Makers (AMMs) * Lending protocols * Staking protocols * Cross-chain interoperability #### Harnessing OP\_CAT for AdVanced Scripting A major innovation in the CAT protocol is its use of the **OP\_CAT** opcode. [Read more here](https://www.fractalbitcoin.io/updates/what-is-op-cat). OP\_CAT, short for "concatenate," combines two items into one within a Bitcoin transaction script. By utilizing OP\_CAT, CAT enables more complex operations without additional data storage or bloating transactions. #### Fully Verified by Miners Another standout feature of CAT Protocol is that its transactions are **fully verified by miners**. Unlike token standards that may rely on external or third-party validation, CAT20 ensures that all transactions are confirmed directly by Bitcoin’s miners. **Significance of being miner verified:** * **Secure:** Backed by PoW mechanism * **Decentralized:** No third-party validators or intermediaries such as indexers * **Direct Network Enforcement:** Direct contact with Bitcoin L1 #### Why should the dependencies on indexers be reduced? After all, indexers are off-chain, which means the data source comes from a third party, making it vulnerable to indexer inconsistencies or manipulation. Being verified solely by miners eliminates this risk. The ideal token transaction should remain transparent, reliable, and fully integrated into the Bitcoin network, which could be achieved through CAT. ### Impact of CAT Protocol on Fractal #### Managing Network Congestion The Fractal network went under pressure from the growing demand for blockspace driven by the CAT protocol. Designed to optimize blockspace, the **CAT protocol** aims to increase efficiency, but with the current surge in demand, these optimizations may not be enough to prevent rising fees. While the protocol offers robust security and eliminates the need for indexer dependencies, it faces challenges related to network congestion and rising transaction costs, especially for high-volume applications. Balancing high transaction volumes with effective blockspace utilization remains a critical challenge for the network. #### Further Developments of CAT20 As the protocol is still in its infancy there are still many open questions about the feasibility of the protocol. One thing is for sure — the community is excited about this new development in the Bitcoin protocol. It also serves as a lesson if and when OP\_CAT is being enabled on Bitcoin. ### Innovation on Fractal For CAT Protocol to function on Bitcoin, OP\_CAT must be activated. With CAT’s use of recursive covenants enabled by the OP\_CAT opcode, CAT Protocol presents new and exciting development possibilities. With the activation of OP\_CAT on Fractal, Fractal can support more complex, on-chain smart contracts and decentralized applications. This brings new opportunities for developers to create innovative products with greater utility directly on Bitcoin. ### The Future of Bitcoin Tokens on Fractal Fractal Bitcoin fosters innovations like CAT Protocol to push the boundaries of what Bitcoin can achieve. By being an innovation playground for developers, Fractal is committed to nurturing an evolving ecosystem of standards and applications. ***Disclaimer:** CAT20 and CAT Protocol are not affiliated with Fractal. This blog post is for informational purposes only, and intended to help users understand the technology. Readers and community members are advised to do their own research before engaging with any projects or technologies mentioned. Fractal assumes no responsibility for any decisions made based on this information.* # How to send / receive CAT20? Please do your own research. This guide serves only as a reference for users. ### How to send / receive CAT20? \ **Step 1: Download the Chrome Extension** • **Download UniSat Wallet**: Visit the official Chrome Web Store link for **UniSat Wallet** and verify that it has a large number of reviews and a verified checkmark to ensure it’s not a phishing site. Download link: [Here](https://unisat.io/download) *Make sure you are using the latest version of the extension, which must be at least v1.5.0 or higher.* \ **Step 2: Set Up Your Wallet** • Install the extension and **set up your wallet**. During the setup process, **securely back up your seed phrase** and make sure **not to share** it or store it online.
**Step 3: Select a Taproot Address** • Ensure that you select a **Taproot address** to be compatible with Fractal Bitcoin. Only **Taproot and Native Segwit** wallet addresses are supported to transfer CAT20 tickers.
**Step 4: Toggle to Fractal Bitcoin**• In the wallet interface, navigate to the **top-right corner** and switch from **BTC Mainnet** to **Fractal Bitcoin Mainnet**.
**Step 5: Check Your CAT20 Balance** • Once you’ve toggled to **Fractal Bitcoin**, your balance will be displayed. • To **receive CAT20**, click **Receive** and copy your Fractal Bitcoin receiving address to share with others. (Taproot and Native Segwit wallet addresses only)
**Step 6: Send CAT20** * To **send CAT20**, please click on the specific **CAT20 ticker** you want to send and then click on Send. * Carefully review the transaction details, including **inputs** and **outputs**, before confirming. Once verified, click **Next** and sign the transaction. > **Note**: You can send up to **4 UTXOs** in one transaction. After sending, the UTXOs will automatically merge into one.
*** ### **How to Merge CAT20 UTXOs** \ Merging multiple CAT20 UTXOs into a single UTXO can only be done if they share the same genesis transaction. Follow these steps to merge your UTXOs: \ **Step 1: Select the CAT20 Ticker** Select the CAT20 TickerClick on the specific **CAT20 ticker** you want to merge. In the pop-up menu, select **Merge UTXOs**.
#### **Step 2: Choose UTXOs to Merge** * In the **Merge** window, select the number of UTXOs you wish to merge and set your fee rate. * Review the transaction details to ensure accuracy, then click **Start Merging** to initiate the merging process. > **Note**: You can merge up to **100 UTXOs** in one go.
**Step 3: Confirm and Start the Merge** * Once you’ve reviewed all the details, click **Start** to begin the UTXO merge. After the transaction is confirmed, you’ll see the progress in the wallet interface.
# How to Buy and Sell CAT on UniSat CAT Market？ This article is from UniSat, it is for reference purposes only, and we recommend conducting your own research before making any trades. *** CAT Market is compatible with **Native Segwit (P2WPKH)** and **Taproot (P2TR)** addresses on UniSat. Make sure your wallet is configured to use one of these address formats. Transaction fees are paid in FB Service fee: 0.3% ### **1. Accessing UniSat CAT Market** * Go to the UniSat Marketplace on Fractal: * Click the **Connect** button to link your wallet to the marketplace.
The CAT Market interface is designed with a DEX-style layout to suit the trading preferences of most users. Click on the specific ticker you want to trade, and you’ll be able to see its **price**, **price chart**, **volume**, and **market cap** for better insights into your asset.
*** ### 2. How to Buy CAT Use the search bar on the right side of the market interface to find the ticker you wish to trade with, or scroll to find it directly.
**Buying Method 1: Take Order** This is a fast way to buy from the existing order book. a) Click on the desired buy order from the order book (buy side) that matches your preferred price and amount, confirm the details (price and amount), and click the **Buy** button at the bottom of the page. b) Review the **inputs** and **outputs** information, and if everything looks correct, sign the transaction.
Once the transaction is signed and confirmed, the purchase will be processed. You can view your purchase history under the **My Activities** section at the bottom of the page.
**Buying Method 2: Make Order** If you prefer to place a custom order instead of buying from the existing order book, follow these steps: a) Choose **Make Order**, then click **Buy**. b) Enter your ideal buy price and quantity, and confirm the details before clicking **Make Order**. *Note: the total value should be bigger than 0.1 FB.* c) As in the first method, review the transaction details (inputs, outputs), and sign it to confirm the order.
**Bulk Buy** You can select multiple orders for bulk purchasing: * Click **Take Order - Buy** on the marketplace, and choose multiple orders from the order book. * Once selected, click **Buy** and sign the transaction to complete the purchase.
*** #### 3. How to Sell CAT Use the search bar or scroll through the marketplace to find the ticker you want to sell. **Selling Method 1: Take Order** This is a fast way to sell by accepting an existing buy order from the order book. a) Click on the available sell order (sell side) in the order book that matches your desired price and quantity. b) Confirm the price and quantity, and click **Sell** at the bottom of the page. c) Review the inputs and outputs information, then sign the transaction. **Note:** You can place up to 3 orders in bulk.
**Selling Method 2: Make Order** You can sell up to **3 UTXOs at once**. If you wish to sell more CAT20 in one go, you need to merge the UTXOs in your wallet. For detailed steps on how to do this, please refer to this operation [guide](https://docs.fractalbitcoin.io/user-guides/understanding-cat-protocol/how-to-send-receive-cat20). If you prefer to place a sell order instead of taking one from the existing order book: a) Choose **Make Order**, then click **Sell**. b) Enter the quantity and price you wish to sell for, and confirm the details before clicking **Make Sell**. *Note: the total value should be bigger than 0.1 FB.* c) As in the previous steps, review the transaction information (inputs, outputs), and sign to confirm the order.
**Bulk Sell** You can also sell multiple UTXOs in one go: * Click **Take Order - Sell**. * Select the orders you wish to fulfill, click **Sell**, and sign the transaction to complete it. * Note: You can sell up to 3 UTXOs at once.
*** #### 4. How to View and Cancel Orders After placing your orders, you can view your order history under **My Activities** on the main page. To cancel an open order, click the **Cancel** button next to the order you wish to remove.
**Please note:** CAT20 transactions require confirmed UTXOs. If there are multiple unconfirmed UTXOs in your orders, you will not be able to spend the same UTXO again. In such cases, the page will display the following prompt. Please click "Confirm" to proceed to the next step.
# How to Participate in the Fractal Vote? This guide provides a detailed explanation of the process to participate in Fractal Vote. Please note: * This guide is for reference purposes only, before engaging in trading or locking FB for voting, we encourage you to do your own research before trading. * Fractal Vote currently only supports Native SegWit and Taproot wallet addresses. Please check before transacting. *** ### Step 1: Connect Your Wallet Visit and connect your UniSat or OKX wallet.
### Step 2: Lock Your FB for Voting Power Voting power refers to the amount of FB you can use for voting, calculated on a 1:1 ratio, meaning each FB equals one unit of voting power. Once voting begins, all locked FB will become available vote. If you unlock before your first vote, you won't have any available vote. 1. On the right-hand side of the voting page, you will see the **lock section**. If you wish to lock FB, enter the amount you want to vote with and click **lock**. 2. A pop-up window will appear showing the details of your lock. Once confirmed, click **confirm**, complete the signing process, and you will receive voting power.
Once locking is complete, you can view the details of your lock, your voting power, and the option to unlock your FB on the **View Details** page.
### Step 3: Cast Your Vote Once you have locked FB, you can participate in voting. 1. On the left-hand side of the voting page, you will see the **voting section**, which displays the current voting topics and options. 2. Select your preferred option and click **"Vote"**. 3. Enter the amount of voting power you wish to use, click **"Confirm"**, and sign the transaction to complete the signing process.
Please note: * The minimum lock amount is **0.001 FB**. * Please ensure that you keep at least **0.0001 FB (10,000 satoshis)** in your wallet to cover the network fees. Once voting is complete, you can view the details of your vote on the **My Votes Records** page on the right-hand side. View all voting history in the **"All Voting Records"** section.
### Unlock FB There is no fixed locking period, and you can unlock your FB at any time. However, take note of the **cooling period**, which is 21,000 blocks (approximately 7 days) when unlocking. 1. By clicking '**Unlock**,' you can see all the records available for unlocking. Simply click on any record to unlock it.
2. After unlocking, please wait patiently for the countdown to finish before claiming your FB. Unlocking your FB will initiate a cooling period of 21,000 blocks (approximately 7 days). Once the cooldown ends, you must manually claim the FB in the "View Details" section.
3. After confirming, the page will display a countdown timer for the unlock, allowing you to track the remaining time for your unlock period.
### Claim Your FB After Cooling Period Once the cooling period ends, go to **"Voting Power - View Details"**. In the "Voting Power and History" section, click **"Claim"** and confirm the transaction to receive your unlocked FB.
To further understand the mechanics of Fractal Vote, visit # How to participate in Public Testing? Welcome to the Fractal Bitcoin Testnet! Follow this step-by-step guide and begin your testing journey. \ 1️⃣ **Setting Up Your Fractal Bitcoin Wallet** *Please use only the UniSat wallet for testing. We recommend creating a new UniSat wallet specifically for testing.*
* Open the UniSat Wallet extension. * Click the network dropdown in the top-right corner and switch to **Fractal Bitcoin Testnet**. * Copy the wallet address displayed on the page.
*** 2️⃣ **Claim Your Testnet assets**
* Visit the faucet page: [https://explorer-testnet.fractalbitcoin.io/faucet]() and pass the verification. (*the only official testnet URL*). * Paste your Fractal wallet address in the **Receiving address** field. * Click **Claim** to receive your testnet assets.
*** \ 3️⃣ **Understand brc-20 on Fractal Rules** \ 🔸 Ticker names on this public testnet will be limited to **6 - 12 bytes**. Tickers with 4 or 5 characters will not be permitted, as they are already in use on the Bitcoin mainnet. 🔸 For brc-20 on Fractal, ticker names can include letters (both uppercase and lowercase: **a-z/A-Z**), numbers (**0-9**), and underscores (**\_**). In total, you have 63 different characters to work with. Ticker names are not case-sensitive. For example, "Aaaaaaaaaaaaaa" is treated the same as "aaaaaaaaaaaaaa." 🔸 Both fair-launch and self-issuance are supported for all brc-20 assets on Fractal. "self-issuance" means these assets can only be minted by the holder of deploy inscription. Since deployment inscription can be transferred, whoever holds the deployment inscription has the right to mint the ticker.
*** 4️⃣ **Start testing**
The testing operations are similar to those on Ordinals: * Go to the official testnet site: [https://fractal-testnet.unisat.io/]() * Click **Connect** in the top-right corner and sign in with the wallet address you used to claim your assets. Navigate to the **Inscribe** page via the top navigation bar or click [https://fractal-testnet.unisat.io/inscribe](). Here, you can inscribe brc-20, Files, Text, and experience the brc-20 deploy process.
**Inscribing Steps:** 1. Input the ticker name you want to inscribe, the amount, and the number of inscriptions to mint in bulk (Repeat Mint). Once you've filled in these details, click "Next" to proceed.
2. Review the minting details, click "Next" if everything is correct, then read and acknowledge the “Risk Warning”.
3. Input your receiving address. You can use the connected wallet address or enter another one manually. * Set the fee rate. You can use the suggested fee or enter a custom fee. * Once you’ve confirmed that all the information is correct, click "Submit & Pay Invoice." Please note that by clicking "Submit & Pay Invoice," you are confirming that you have read and agreed to our Risk Warning statement.
4. Confirm your payment method. The default option is "Pay with Wallet," but you can manually select another payment method if necessary.
5. After comfirming your payment method, a signature details page will appear. Before clicking "Sign & Pay," carefully review the inputs, outputs, and other transaction details. Make sure everything is accurate, then click "Sign & Pay" to finalize the transaction.
6. At this point, your minting order has been created and will begin processing. * The status "Inscribing" means that the inscription is currently in progress and awaiting confirmation. Once the process is complete, the status will change to "Inscribed." * It’s important to note that if the mempool fees are high or the ticker is particularly popular, your transaction might be front-run. This means that if the ticker supply is out before your transaction is confirmed, your order may still show as "Inscribed," but you will not receive the assets due to being front-run.
**brc-20 on Fractal Full List** * Go to , scroll down to see the full list of BRC-20 assets and you can also inscribe directly by typing the name of the ticker you want to inscribe in the search box.
*** \ 📌Additional Notes: * This is a testnet environment, and testnet assets have no real value. * Always use the official testnet site and follow these instructions carefully to avoid any issues. \ Happy testing, and enjoy your journey with Fractal Bitcoin! # Mining Overview Halving cycle: 2,100,000 blocks. The genesis block generates 50 BTC to Satoshi Nakamoto's address, but this amount is unspendable. In the first block after the genesis block, a total mining output of 105 million will be pre-allocated to a spendable address. Starting from the second block, each block will generate 25 FB, with the decimal precision remaining at 8 decimal places. The total mining supply is calculated as 2 \* 25 \* 2,100,000 = 105 million FB. **Consensus mechanism** Fractal’s consensus mechanism is Proof-of-Work — consistent with Bitcoin. Miners can use existing ASICs and other hardware devices to mine blocks. (standard **SHA256d**) **Cadence Mining** Fractal uses an innovative mining method called Cadence Mining to balance the benefits of merged mining and permissionless mining. Providing a balance of security and inclusivity. This hybrid model enables miners to bolster the network's security while also engaging in the economic benefits offered by Fractal. * The block interval for mining is 30 seconds. For every three mined blocks, one block will be permissionlessly-mined, one block will be merged-mined, and one block will be indexing-mined. * This preserves the permissionless, freely-available mining opportunities for the Fractal community, while tapping into the impressive security of the Bitcoin main chain through merged mining at the same time. Fractal Bitcoin supports merged mining with Bitcoin, allowing miners to mine Fractal Bitcoin blocks simultaneously while mining the Bitcoin mainnet. The integration mechanism is identical to Namecoin’s. Initial **Difficulty & Hashrate Requirements** * Permissionless Mining: * nbits: 0x1900cfff * Difficulty: ≈5G * Hashrate: ≈500 PH/s * Merged Mining: * nbits: 0x180cffff * Difficulty: ≈400G * Hashrate: ≈20 EH/s (Equivalent to 3.2% of BTC's). # Wallet Integration This document is intended for wallet application providers that have already integrated the BTC mainnet, to facilitate the integration of the Fractal testnet into their applications. ## **Node** Fractal Bitcoin and Bitcoin have the following differences and notes on nodes: * Solo mining uses the same mechanism as Bitcoin. * Merged mining operates similarly to Namecoin. * Blocks from merged mining contain the BTC block header data. The data structure has changed. * However, to maintain compatibility with existing applications, the block data will be removed in the getblock and getblockheader methods of the RPC interface. Nevertheless, analyzing local block files will reveal this data. ## **Protocol** We remain neutral regarding the competition of different protocols. **Ordinals** * The activation height of the ordinals index is 21000. **BRC20** * Ticker names on this public testnet will be limited to **6 - 12 bytes**. Tickers with 4 or 5 characters will not be permitted, as they are already in use on the Bitcoin mainnet. * For brc-20 on Fractal, ticker names can include letters (both uppercase and lowercase: **a-z/A-Z**), numbers (**0-9**), and underscores (**\_**). In total, you have 63 different characters to work with. * All byte lengths of BRC-20s on Fractal can enable the self\_mint field. **Runes Protocol** * The activation height for runes is 84000. * More rules will be announced later. ## ## **RPC & API** \ **Mempool API** * * The latest official version of Mempool can be used for deployment and operation. **Ord** * * Use the latest official version of Ord, configure ordinals to the activation height of 21000. **UniSat Open API** * API Swagger: * How to get API-KEY: * Endpoint: # Articles # Fractal Vote Explained Fractal Vote is a feature that demonstrates yet another advanced capability achieved through Bitcoin scripts. As Fractal Bitcoin continues to evolve, more use cases will emerge, unlocking a broader range of possibilities. This post aims to break down its features for non-technical users, showcasing what makes Fractal Voting unique. *** ### Key Features 1. Flexible Lock/Unlock with Arbitrary Time Length 2. Fully On-Chain Contract-Based Custody 3. Secure Isolation of Individual User Stakes *** ### Flexible Lock/Unlock with Arbitrary Time Length Traditional Bitcoin timelock enables assets to be locked until a specific block height or timestamp, restricting access until the designated time has passed. Fractal Voting enhances this by locking assets in independent Taproot script addresses. Users have the flexibility to unlock their assets at any chosen time. This unlock behavior can also incorporate additional controls, such as introducing a cooling period or requiring special signatures for unlocking. This flexibility ensures that users are not constrained by time-based restrictions while still maintaining security. *** ### Fully On-Chain Contract-Based Custody Before the implementation of Fractal Voting, it wasn’t possible to entrust assets to a specific contract using Bitcoin scripts. By enabling contract-based asset custody, Fractal Voting offers significant benefits: * The ownership of funds is securely transferred between the user and the contract throughout the custody period. * There is no reliance on third parties, eliminating the need for trust in intermediaries. This approach fundamentally aligns with Bitcoin’s ethos of decentralization and trustless operations. *** ### Secure Isolation of Individual User-Locked Assets In Fractal Voting, each user’s assets are locked into separate UTXOs, ensuring physical isolation at the blockchain level. If one user’s locked assets encounter risks, this isolation prevents any impact on others. This feature contrasts sharply with Ethereum’s contract-based models, where all user funds are pooled into a single contract. In Ethereum: * A contract vulnerability can jeopardize all user assets. * Transactions with the contract occur sequentially, meaning execution order can influence outcomes, creating performance bottlenecks. By leveraging UTXO-based isolation, Fractal Voting eliminates these risks. Moreover, the UTXO model naturally lends itself to parallel processing, making it easier to improve system performance in the long run. *** More details: How Fractal Vote Works: A Deep Dive Technical Features of Fractal Voting: # Understanding BRC20: Experimenting with the Bitcoin Script ### What is BRC-20? [**BRC-20**](https://domo-2.gitbook.io/brc-20-experiment/) is an experimental token standard built natively on the Bitcoin blockchain, leveraging advancements such as the Taproot upgrade and the Ordinals Protocol. It enables the creation, minting, and transfer of fungible tokens on the Bitcoin network through **Ordinals** and **Inscriptions**, concepts introduced to enhance the functionality. #### Key Concepts Behind BRC-20 1. **Fungible**: * BRC-20 tokens are **fungible**, meaning each token is identical to every other token of the same type. 2. **Utilizes Ordinals and Inscriptions** * Ordinals is a protocol that allows for numbering and tracking individual satoshis (the smallest unit of Bitcoin), making them unique. * Inscriptions involve attaching arbitrary data, such as text or scripts, to satoshis using the Ordinals protocol. BRC-20 tokens use these inscriptions to create and manage tokens on Bitcoin. #### How BRC-20 Works * **Deploy**: A user deploys a new BRC-20 token by inscribing data that defines the token's supply, name, and mintable amount onto the blockchain using Ordinals. * **Mint**: Other users can mint new tokens according to the rules defined in the initial deployment. * **Transfer**: Once tokens are minted, users can transfer them to others by inscribing transfer instructions onto satoshis. #### Example of a BRC-20 Token: A simple example of a BRC-20 deployment inscription might look like this (in JSON format):
This example defines a BRC-20 token called "EXAMPLE" with a maximum supply of 21,000,000 tokens and a mint limit of 1,000 tokens per transaction. ### Features of BRC20 **1. Experimental Nature**: BRC-20 is still in an experimental phase. Its use cases are being explored primarily by Bitcoin developers and enthusiasts interested in adding additional layers of utility to Bitcoin. **2. Limited Functionality** Due to Bitcoin’s limited scripting capabilities, BRC-20 tokens do not support advanced functionality such as automated smart contracts. Functions such as decentralized exchanges (DEXs), staking, and complex logic are more challenging to implement directly on Bitcoin with only the BRC-20 protocol. **3. Storage and Network Impact** The introduction of BRC20 and Ordinals has raised concerns about the increased data storage and network congestion on Bitcoin, as more arbitrary data is inscribed onto the blockchain, potentially increasing fees and block space usage. While some see this as a way to support miners as block rewards decline, others worry about its impact on cost-sensitive users. ### Current Use Cases and Outlook * BRC-20 is primarily used to experiment with fungible tokens on Bitcoin. * BRC-20 applications are nascent with their utility and traction. * Scalability and network impact are key considerations when implementing. #### **Innovate with These Token Standards on Fractal** **BRC-20** is an innovative experiment that brings fungible token functionality to the Bitcoin network. Fractal Bitcoin encourages such innovations, pushing the limits of what Bitcoin can accomplish. As an innovation playground for developers, Fractal is dedicated to fostering a continuously evolving ecosystem of standards and applications. Building **Runes** on Fractal? Refer to our [resources here](https://docs.fractalbitcoin.io/doc/runes-on-fractal). Building **BRC-20** on Fractal? Refer to our [resources here](https://docs.fractalbitcoin.io/doc/brc-20-on-fractal). ***Disclaimer:** BRC-20, and Ordinals are not affiliated with Fractal. This blog post is for informational purposes only, and intended to help users understand the technology. Readers and community members are advised to do their own research before engaging with any projects or technologies mentioned. Fractal assumes no responsibility for any decisions made based on this information.* # Understanding Runes: Making BITCOIN Fun Again Back in 2023, Bitcoin developer Casey Rodarmor introduced **Runes**, a new protocol aimed at expanding the Bitcoin ecosystem. Known for his work on **Ordinals**, Rodarmor took a different approach with Runes. In his own words, "[Runes were built for degens and memecoin](https://x.com/rodarmor/status/1774613900119699701)," signaling that the protocol was designed with a lighter, more playful spirit compared to traditional Bitcoin projects. ### What are Runes? The Runes protocol was activated at Bitcoin’s 4th halving, around 840,000 blocks. Unlike Ordinals, Runes brings a fresh approach to how assets and tokens can be integrated into Bitcoin’s ecosystem. To grasp the significance of Runes, it is essential to understand several key concepts integral to Bitcoin's broader ecosystem. * **Sats**: Short for satoshis, these are the smallest divisible units of Bitcoin, often minted at specific times. They represent a foundational element of Bitcoin's value system. * **Inscriptions**: According to the [Ordinal Theory Handbook](https://docs.ordinals.com/inscriptions.html), “inscriptions inscribe sats with arbitrary content, creating bitcoin-native digital artifacts, more commonly known as NFTs. Inscriptions do not require a sidechain or separate token.”. * **Ordinals**: A system that assigns unique serial numbers to individual satoshis (the smallest unit of Bitcoin), allowing users to track and differentiate between specific sats. ### **Benefits of the rune protocol** #### Efficiency * Avoids creating unspendable UTXOs. * The OP\_RETURN opcode consumes only 80 bytes compared to 4MB for BRC-20. * Allows for better compression compared to using BRC-20’s JSON on blockspace. * Allows open minting within terms set by the etcher. #### Liquidity * Attracts high-risk investors from other platforms to Bitcoin. * Boosts transaction fee revenue on the Bitcoin network for miners. #### Simplicity * Enables the issuance of native fungible tokens on Bitcoin. * Promotes innovation in the Bitcoin ecosystem. * Operates entirely on-chain, avoiding the need for off-chain complexities. ### Limitations of Runes Since its introduction, the daily etching of Runes has experienced a decline following an initial surge of interest. More insights on this trend can be explored via the Rune Dune [dashboard here](https://dune.com/cryptokoryo/runes). While Runes have generated significant excitement, it's important to approach them with caution, as the focus so far seems more centered on short-term interest rather than proven long-term utility. However, the protocol may still hold untapped potential. As the ecosystem evolves, new innovations could reveal meaningful use cases, allowing Runes to contribute to Bitcoin’s ongoing development. ### Innovate with these Token Standards on Fractal Runes are currently live, and by extension, can also be implemented on Fractal. Fractal Bitcoin encourages such innovations, pushing the limits of what Bitcoin can accomplish. As an innovation playground for developers, Fractal is dedicated to fostering a continuously evolving ecosystem of standards and applications. Building Runes on Fractal? Refer to our [resources here](https://docs.fractalbitcoin.io/doc/runes-on-fractal). Building BRC20 on Fractal? Refer to our [resources here](https://docs.fractalbitcoin.io/doc/brc-20-on-fractal). ***Disclaimer:** Runes, BRC 20, and Ordinals are not affiliated with Fractal. This blog post is for informational purposes only, and intended to help users understand the technology. Readers and community members are advised to do their own research before engaging with any projects or technologies mentioned. Fractal assumes no responsibility for any decisions made based on this information.* #### Further Reading Hell Money by Creator of Runes: See what is trending on Runes: Data on Runes: # Understanding CAT Protocol: The Latest Player in Bitcoin Token Standards The Bitcoin ecosystem has a new innovator: **Covenant Attested Token (CAT) Protocol**. [CAT20](https://catprotocol.org/cat20), released by [CAT Protocol](https://x.com/ProtocolCAT), emerges as a fungible token standard, designed to enhance token functionalities on chains with OP\_CAT enabled, such as Fractal Bitcoin. Unlike existing protocols, CAT is fully validated by miners and operates using smart contracts, specifically **recursive covenants**, all enforced by Bitcoin’s built-in scripting language at Layer 1. CAT721 will likely be released at a later date. ### What is CAT20? #### Key Facts * **Bitcoin’s Security** * It is enforced by Bitcoin's consensus rules, inheriting its Proof-of-Work security. * **Requires OP\_CAT** * It is only available on OP\_CAT-enabled networks, such as Fractal. * **UTXO-based** * It is UTXO-based, and enforced by Bitcoin Script on L1 without the need for external or off-chain indexers. * **Allows for Innovation** * Its modularity and programmable minting enable flexible and composable rules for complex decentralized apps such as AMMs, lending, and staking. * **Miner Verified** * It is fully verified by miners for robust security and native enforcement. * **Interoperable** * It is cross-chain interoperable, which allows interoperable dApps to be built on Fractal Bitcoin. * **Lightweight** * It supports SPV and enables light clients to verify transactions efficiently, preserving decentralization and accessibility. ### Comparing CAT Protocol to the Existing Bitcoin Protocols
### What is Unique About CAT20? What makes CAT20 unique is that it allows tokens to be minted under specific conditions, **without changing the underlying protocol**. This can be done as it **does not need an indexer**. These conditions include: * Predetermined time * Block height * Time locks * Proof-of-work (PoW) verifications * Payment confirmation * Exclusive mints Through these minting conditions, additional functionalities are added. This opens the door to possible use cases using smart contracts and decentralized applications such as: * Automated Market Makers (AMMs) * Lending protocols * Staking protocols * Cross-chain interoperability #### Harnessing OP\_CAT for AdVanced Scripting A major innovation in the CAT protocol is its use of the **OP\_CAT** opcode. [Read more here](https://www.fractalbitcoin.io/updates/what-is-op-cat). OP\_CAT, short for "concatenate," combines two items into one within a Bitcoin transaction script. By utilizing OP\_CAT, CAT enables more complex operations without additional data storage or bloating transactions. #### Fully Verified by Miners Another standout feature of CAT Protocol is that its transactions are **fully verified by miners**. Unlike token standards that may rely on external or third-party validation, CAT20 ensures that all transactions are confirmed directly by Bitcoin’s miners. **Significance of being miner verified:** * **Secure:** Backed by PoW mechanism * **Decentralized:** No third-party validators or intermediaries such as indexers * **Direct Network Enforcement:** Direct contact with Bitcoin L1 #### Why should the dependencies on indexers be reduced? After all, indexers are off-chain, which means the data source comes from a third party, making it vulnerable to indexer inconsistencies or manipulation. Being verified solely by miners eliminates this risk. The ideal token transaction should remain transparent, reliable, and fully integrated into the Bitcoin network, which could be achieved through CAT. ### Impact of CAT Protocol on Fractal #### Managing Network Congestion The Fractal network went under pressure from the growing demand for blockspace driven by the CAT protocol. Designed to optimize blockspace, the **CAT protocol** aims to increase efficiency, but with the current surge in demand, these optimizations may not be enough to prevent rising fees. While the protocol offers robust security and eliminates the need for indexer dependencies, it faces challenges related to network congestion and rising transaction costs, especially for high-volume applications. Balancing high transaction volumes with effective blockspace utilization remains a critical challenge for the network. #### Further Developments of CAT20 As the protocol is still in its infancy there are still many open questions about the feasibility of the protocol. One thing is for sure — the community is excited about this new development in the Bitcoin protocol. It also serves as a lesson if and when OP\_CAT is being enabled on Bitcoin. ### Innovation on Fractal For CAT Protocol to function on Bitcoin, OP\_CAT must be activated. With CAT’s use of recursive covenants enabled by the OP\_CAT opcode, CAT Protocol presents new and exciting development possibilities. With the activation of OP\_CAT on Fractal, Fractal can support more complex, on-chain smart contracts and decentralized applications. This brings new opportunities for developers to create innovative products with greater utility directly on Bitcoin. ### The Future of Bitcoin Tokens on Fractal Fractal Bitcoin fosters innovations like CAT Protocol to push the boundaries of what Bitcoin can achieve. By being an innovation playground for developers, Fractal is committed to nurturing an evolving ecosystem of standards and applications. ### Resources Explore CAT20 tokens on UniSat here: Building BRC-20 on Fractal? Refer to our [resources here](https://docs.fractalbitcoin.io/doc/brc-20-on-fractal). Building Runes on Fractal? Refer to our [resources here](https://docs.fractalbitcoin.io/doc/runes-on-fractal). ***Disclaimer:** CAT20 and CAT Protocol are not affiliated with Fractal. This blog post is for informational purposes only, and intended to help users understand the technology. Readers and community members are advised to do their own research before engaging with any projects or technologies mentioned. Fractal assumes no responsibility for any decisions made based on this information.* # What is OP\_CAT? #### Summary * OP\_CAT was part of the Bitcoin’s scripting language but was disabled in 2010. Now, Tapscript solves this issue. * OP\_CAT is expected to drive innovation in Bitcoin's code by introducing smart contract functionalities and expanding the potential for Bitcoin Layer 2 applications. * Critics favor simpler code and alternative softforks. ### I. What is OP\_CAT? OP\_CAT was originally part of Bitcoin’s scripting language. The opcode concatenates two stack items, combining them into a single item. For example, if you have two strings or numbers on the stack, OP\_CAT would merge them into one. #### **Why was OP\_CAT disabled previously?** OP\_CAT was disabled starting from early Bitcoin versions because it could lead to scripts using excessive memory, creating very large stack values from small inputs. For example, a script with OP\_CAT and OP\_DUP could expand a 1-byte value into over 1 terabyte. Tapscript now prevents this issue by limiting stack elements to 520 bytes. ### II. **Impact of OP\_CAT** Often referred to as the code that can enable native smart contract functionalities on Bitcoin, OP\_CAT has garnered significant interest from developers building Bitcoin Layer 2 solutions. **Here is how OP\_CAT could pave the way for innovation on Bitcoin:** #### 1. **Enhanced Script Capabilities** **BigInt and Numbers Handling —** By allowing concatenation, developers can construct and manipulate larger integers more easily within Bitcoin scripts. This is particularly useful for applications that require large number operations. #### 2. **Zero-Knowledge (ZK) Applications** **zkProofs —** Concatenation can be crucial for creating and verifying zero-knowledge proofs. With OP\_CAT, constructing complex data structures that represent proofs becomes more straightforward. #### 3. **BitVM** **Smart Contract Functionality —** BitVM is a concept for bringing more expressive smart contract capabilities to Bitcoin. OP\_CAT can aid in developing more complex scripts, potentially enabling functionalities similar to those found in Ethereum’s virtual machine (EVM). #### 4. **Staking** **Slashing Conditions —** Babylon aims to create decentralized staking mechanisms with robust slashing conditions to penalize malicious actors. OP\_CAT can help construct and evaluate these conditions by enabling the concatenation of evidence or conditions that trigger slashing. ### IV. Concerns — Resistance and Alternatives 1. **Community Resistance** Implementing major changes like OP\_CAT requires consensus within the Bitcoin community. Resistance may come from those who prefer simpler, minimalist approaches and those concerned about potential risks. **2. Alternative Softforks** There may be a preference for prioritizing other soft forks that address core issues such as scalability or privacy over introducing new functionalities like OP\_CAT. ### V. Future of **OP\_CAT** In conclusion, OP\_CAT is making a comeback with the community rallying behind it. The excitement around innovations, such as Ordinals and Runes, shows that Bitcoin's future is looking bright, with OP\_CAT potentially playing a big role in pushing its capabilities further. # Alkanes on Bitcoin: Fueling Smart Contracts on Bitcoin Natively Bitcoin is programmable. Not someday — today. Thanks to Alkanes, developers can now build more expressive apps on Bitcoin. It’s simple, powerful, and 100% Bitcoin-native. ### 1. What are Alkanes? **What is Alkanes?** Alkanes is a smart contract system built natively on Bitcoin. Think of it like Ethereum-style smart contracts — but without leaving the Bitcoin chain. It allows developers to create and deploy decentralized applications (dApps) using Bitcoin’s native security and transaction system. At the core of Alkanes: * Contracts are written in **Rust** and compiled to **WebAssembly (WASM)**. * They’re deployed **onchain** using Bitcoin’s witness data (like Ordinals inscriptions). * They run through **Protorunes**, a messaging protocol encoded in Bitcoin transactions using OP\_RETURN. * All data and executions are indexed by **Metashrew**, an open-source stack purpose-built for Bitcoin smart contracts. ### How Do Alkanes Smart Contracts Work? Alkanes contracts are self-contained programs that operate natively on Bitcoin. Each contract can: * Store persistent **state** (e.g., balances, logic conditions) * Execute functions based on **opcodes** (numeric instructions) * Accept inputs via **cellpacks** (formatted data packets) * Handle **both** BTC and Alkanes-native tokens These contracts are triggered using **Protorunes** — messages embedded in Bitcoin transactions that tell contracts what to do, such as updating a balance or triggering a lending action. Want to query a contract without changing state? Alkanes supports **off-chain simulations**, making it easy to fetch data or test logic before pushing to the blockchain. ### Why Alkanes is Fuel for Bitcoin Programmability Here’s what sets Alkanes apart in the Bitcoin ecosystem: **1. Native UTXO Integration** Alkanes works directly with Bitcoin’s UTXO model, unlocking new ways to move, manage, and program BTC. **2. Modular and Composable** Contracts can interact with one another, enabling complex dApps built from smaller, reusable parts — like DeFi legos, but on Bitcoin. **3. Developer-Friendly** Rust and WebAssembly are already familiar to many Web3 devs. If you’ve built on Ethereum or Polkadot, you’ll feel right at home. **4. Transparent and Indexable** Every contract and execution is tracked and searchable via Metashrew, ensuring full auditability and trust. ### Conclusion Alkanes transform Bitcoin from a static, value-holding asset into a fully programmable platform — without compromising Bitcoin’s core values of decentralization, transparency, and security. With Alkanes, Bitcoin isn’t just digital gold — it’s programmable fuel. \ More details: # Bitcoin Script: A Comprehensive Primer for Developers ### Introduction Bitcoin Script is the purposefully limited programming language that powers the logic behind Bitcoin transactions. As a stack-based, Forth-like language, it's designed with determinism, predictability, and security as its core principles. For developers working in the Bitcoin ecosystem, understanding Bitcoin Script is essential for creating secure transactions, building Bitcoin-based applications, and leveraging the full potential of the Bitcoin network. **Key Characteristics:** * Stack-based execution model with deterministic behavior * Carefully curated set of opcodes for enhanced security * Intentional omission of loops and complex control structures * Emphasis on cryptographic operations and condition verification * Maximum script size of 10,000 bytes for standard transactions Bitcoin Script is the foundation for creating programmable money on the Bitcoin network. While it may appear limited compared to general-purpose languages, these constraints are intentional design choices that prioritize security and predictability in an environment where mistakes can be costly. ### History and Evolution Bitcoin Script has evolved thoughtfully since its introduction by Satoshi Nakamoto in 2009. Understanding this evolution helps developers appreciate the current state of the language and anticipate future developments. **Key Milestones:** **1. 2009: Initial Implementation** * Introduced with Bitcoin's launch * Included numerous opcodes, many of which were later disabled for security * Established the basic stack-based execution model **2. 2010-2012: Security Hardening** * Deactivation of potentially vulnerable opcodes (OP\_CAT, OP\_SUBSTR, etc.) * Implementation of strict verification rules * Introduction of standardness rules for relay policies **3. 2015-2016: Time-based Controls** * Introduction of OP\_CHECKLOCKTIMEVERIFY (BIP 65) * Enabled native time-locked transactions * Crucial for trustless contracts and vaults * Addition of OP\_CHECKSEQUENCEVERIFY (BIP 112) * Enabled relative time locks * Essential for Layer 2 protocols like Lightning Network **4. 2017: SegWit Integration** * Introduced segregated witness programs * Increased effective block size while maintaining backward compatibility * Enabled future script upgrades through version numbers * Fixed transaction malleability **5. 2021: Taproot Activation** * Introduced Schnorr signatures for enhanced privacy and efficiency * Enabled Merkelized Alternative Script Trees (MAST) for complex scripts * Improved multi-signature efficiency through key aggregation * Reduced transaction sizes for complex contracts ### Basic Concepts Understanding the fundamental concepts of Bitcoin Script is essential for effective development. #### 1. Stack-Based Execution Bitcoin Script uses a stack data structure for all operations, with specific rules and limitations: **Key Points:** * Maximum stack size of 1,000 elements * Individual stack elements limited to 520 bytes * Stack items are processed in reverse order * No storage outside the stack during execution **Example of Stack Operation:** ``` Copy Initial stack: [] Push 10: [10] Push 20: [10 20] OP_ADD: [30] ``` #### 2. Opcodes Opcodes are the instruction set of Bitcoin Script, each serving a specific purpose: **Categories of Opcodes:** * Constants (OP\_0 through OP\_16, OP\_1NEGATE) * Flow control (OP\_IF, OP\_ELSE, OP\_ENDIF) * Stack operations (OP\_DUP, OP\_SWAP, OP\_ROT) * Bitwise logic (OP\_EQUAL, OP\_EQUALVERIFY) * Arithmetic (OP\_ADD, OP\_SUB, limited to 32-bit integers) * Cryptographic (OP\_HASH160, OP\_CHECKSIG) * Timelock (OP\_CHECKLOCKTIMEVERIFY, OP\_CHECKSEQUENCEVERIFY) #### 3. Script Construction Bitcoin transactions use two complementary scripts: **Locking Script (scriptPubKey):** * Specifies spending conditions * Part of the UTXO set * Maximum size of 10,000 bytes * Must be standard format for relay **Unlocking Script (scriptSig):** * Provides data to satisfy the locking script * Size limited by standard transaction rules * Executed before the locking script #### 4. Script Execution Script validation follows specific rules and steps: 1. The unlocking script is executed first 2. The locking script executes with the resulting stack 3. The script succeeds if: * Stack contains exactly one value * Top stack value is non-zero * No invalid operations occurred * Script length limits weren't exceeded * All verify operations succeeded ### Common Opcodes and Their Usage Understanding common opcodes is crucial for writing effective Bitcoin Scripts. Here's a detailed examination of key opcodes: #### Cryptographic Operations **OP\_CHECKSIG** * Validates a transaction signature against a public key * Consumes exactly 2 stack items (signature and public key) * Returns true (1) or false (0) * Signature must be in DER format ``` Copy Initial stack: Final stack: <0/1> ``` **OP\_CHECKMULTISIG** * Validates M signatures against N public keys * Limited to 20 public keys in standard scripts * Contains a historical bug requiring an extra value to be dropped ``` Copy Initial stack: ... ... Final stack: <0/1> ``` #### Stack Operations **OP\_DUP** * Duplicates the top stack item * Fails if stack is empty ``` Copy Initial stack: Final stack: ``` **OP\_HASH160** * Performs RIPEMD160(SHA256(x)) * Commonly used for address generation ``` Copy Initial stack: Final stack: ``` #### Time Lock Operations **OP\_CHECKLOCKTIMEVERIFY** * Ensures output can't be spent until specified time * Time can be block height or Unix timestamp * Fails if nLocktime is disabled ``` Copy OP_CHECKLOCKTIMEVERIFY OP_DROP ``` **OP\_CHECKSEQUENCEVERIFY** * Enforces relative timelock * Measured in blocks or 512-second intervals * Essential for Lightning Network channels ``` Copy OP_CHECKSEQUENCEVERIFY OP_DROP ``` ### Example: P2PKH Script Analysis Pay-to-Public-Key-Hash (P2PKH) remains one of the most common Bitcoin transaction types. Here's a detailed analysis: #### Complete Script Structure ``` Copy scriptSig: scriptPubKey: OP_DUP OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG ``` #### Execution Flow with Stack States 1. Initial stack: \[] 2. Push signature: \[\] 3. Push public key: \[\ \] 4. OP\_DUP: \[\ \ \] 5. OP\_HASH160: \[\ \ \] 6. Push pubKeyHash: \[\ \ \ \] 7. OP\_EQUALVERIFY: \[\ \] (fails if hashes don't match) 8. OP\_CHECKSIG: \[0/1] #### Technical Constraints * Signature must be valid DER format * Public key must be valid SEC format * Total script size typically under 225 bytes * Standard transaction rules must be met for relay ### Modern Script Types Recent developments have introduced new script types and capabilities: #### 1. Native SegWit (P2WPKH/P2WSH) ``` Copy // P2WPKH witness program scriptPubKey: OP_0 <20-byte-key-hash> // P2WSH witness program scriptPubKey: OP_0 <32-byte-script-hash> ``` Benefits: * Reduced transaction weight * Fixed transaction malleability * Enhanced script capability through witness program versioning #### 2. Taproot (P2TR) ``` Copy // Key path spending scriptPubKey: OP_1 <32-byte-pubkey> // Script path spending witness: