# FIP-101: Proposal (revised) Status: Draft 2.0 \ FIP Number: 101 \ Title: Fractal Standard Indexing Service \ Author: UniSat Team \ Created: 2025-12-31 \ Type: Standard Proposal (Consensus Layer) \ License: BSD-2-Clause *** ### Abstract This proposal introduces the [**Fractal Standard Indexing Service**](/for-indexing-service-providers/standard-indexing-service-overview.md), aiming to provide Fractal Bitcoin with an open-source, permissionless, standardized indexing service maintained by core contributors and integrated into the Fractal block reward system. By reallocating block reward distribution and introducing a **Taproot-based non-custodial staking mechanism**, this proposal ensures the long-term stability, decentralization, and sustainable operation of indexing infrastructure, while preserving network liveness and minimizing impact on existing consensus processes. *** ### Proposal Summary * **Open Participation:** Anyone may operate indexing services permissionlessly. Miners and mining pools may also participate by running index nodes or joining the staking mechanism. * **Reward Reallocation:** Adjust block reward distribution from the current **1:2 (Merged Mining : Permissionless Mining)** to **1:1:1 (Merged Mining : Permissionless Mining : Indexing)**. * **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. * **Progressive Activation:** Node support is deployed first and observed across the network. *** ### Motivation 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. *** 1. The Optimal Timing to Introduce Standardized Indexing 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. *** 1. 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. *** ### Design Overview 1. Indexing as the Third Pillar of Network Infrastructure 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. *** 2. Open Participation 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 *** 3. 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 *** 4. 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 *** ### Goals & Non-Goals #### 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 * **Limit changes to consensus structure** and reduce risk exposure *** #### Non-Goals This proposal does **not modify**: * Block size or core block structure * UTXO model * Script language * PoW or difficulty adjustment * Total issuance, emission rate, or halving schedule This proposal does **not attempt to standardize**: * Front-end APIs or SDKs * Specific protocol rule definitions * Application-layer data schemas This proposal focuses solely on **chain-level incentives and indexing infrastructure standards**. *** ### Tokenomics & Incentives 1. Reward Distribution Adjustment (1:2 → 1:1:1) Current distribution: * Merged Mining: 1 * Permissionless Mining: 2 Proposed distribution: * Merged Mining: 1 * Permissionless Mining: 1 * Indexing: 1 Total issuance and emission schedule remain unchanged. 2. Rationale for 1:1:1 Allocation Security, openness, and data availability collectively define Fractal’s long-term sustainability. Indexing infrastructure exhibits strong public-goods characteristics. Reliance on centralized services or short-term subsidies cannot provide durable supply. The proposed ratio represents a **long-term statistical target**, guiding capital allocation and infrastructure investment. It may be evaluated continuously based on network performance and ecosystem feedback. 3. Participation 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 *** ### Specification 1. Reward Allocation Rules * Target ratio: **1:1:1 (Merged Mining : Permissionless Mining : Data Indexing)** * Allocation applies in long-term statistical terms * Emission rate and total supply remain unchanged 2. Staking and Exit * Rewards are distributed proportionally by stake share * Implemented via Taproot scripts * Users may exit without operator cooperation * No slashing is introduced * Minimum stake thresholds apply * Weighting rules, service fee limits, script paths, and exit conditions will be specified in implementation documents 3. Reward Settlement and Delay * Settlement must remain outside the block production critical path * Minimum release delay: **7 days (\~20,000 blocks)** * Operators may charge limited service fees 4. Validity 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 5. Failure Handling and Recovery * 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 *** ### Proposed FIP-101 Execution Process: 1. Introduce the node upgrade that enforces the consensus mechanism change and enables the subsequent reward distribution change. 2. Develop and open-source a lightweight indexer which would ensure data availability and allow anyone to join in the testing of the indexer and staking mechanism. We recommend this step to undergo a longer period of careful development and comprehensive testing to ensure that the system is intact. 3. The full standard indexing system is live with staking and reward distribution activated. *** ### Security & Backward Compatibility #### Security Considerations * **Chain liveness:** Indexing must never block block production * **Reward abuse prevention:** Objective validity rules and delayed settlement * **Fund security:** Non-custodial Taproot staking with user-controlled exits * **Reorg consistency:** Index rollback and replay handling must be deterministic and verifiable *** #### Upgrade Impact After activation: * Block rewards follow 1:1:1 distribution * Mining nodes must upgrade to remain consensus-compatible * Non-upgraded miners may produce invalid blocks rejected by upgraded nodes No changes are made to: * Emission schedule * PoW or difficulty * Block structure * UTXO model * Script language *** ### Reference Implementation Reference implementation will include: * Core indexing engine * Pluggable protocol parsers * Storage layer * RPC query interfaces * Standardized coinbase output templates * Taproot staking script templates Operational documentation will be provided covering: * Index deployment * Staking and exit flows * Migration procedures * Common failure scenarios All components will be maintained as open-source repositories on GitHub. UniSat Team updated: 2026/01/24 --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.fractalbitcoin.io/overview/fip-101-fractal-standard-indexing-service/fip-101-proposal-revised.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.