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.

  1. 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.

  1. 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.

  1. 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.

  1. 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

  1. 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

Last updated