Essays

2025.10 Understanding FB Farming from an Engineering Perspective: Principles, Implementation, and Design Trade-offs

The Problem We Wanted to Solve

FB Farming is a non-custodial staking system we built on the Fractal network.
As system designers, our goal was to balance three key objectives:

  1. Ensure users always control their own keys and assets (non-custodial by design);
  2. Provide a practical reward mechanism (supporting long-term holding and participation);
  3. Achieve efficient, auditable reward distribution under Bitcoin’s UTXO model (keeping cost and complexity manageable).

With these goals in mind, we built a staking mechanism that supports locking and unlocking at any time — offering the same flexibility as Fractal Vote without requiring enabling OP_CAT. This means it can be fully supported on Bitcoin mainnet, thus greatly improves the overall compatibility, and that’s why we decided to share the design details through this blog post.

This article is written for technically curious readers. It explains the core components, implementation details, and the design trade-offs behind the system. If you wish to verify or reproduce any part of it, feel free to reach out or check the open-source toolchain linked at the end.

Source Code

Before we start, we would like to share the repository link of the farming source code here for your reference:

System Architecture (High-Level Overview)

FB Farming can be divided into three main layers:

  • On-chain Custody Layer (Non-custodial Addresses): Uses Taproot (P2TR) staking addresses, where funds remain under the user’s private key control;
  • Off-chain Control Layer (Rewards Engine): An off-chain rewards calculator that computes, and schedules payouts;
  • Distribution & UTXO Management Layer: Prepares reward UTXOs, builds and broadcasts batched transactions, and ensures atomic reward delivery.

The core idea is simple: “Security on-chain, logic off-chain, and atomicity in distribution.” This keeps Bitcoin’s on-chain security guarantees intact while allowing reward logic to evolve flexibly and efficiently.

Taproot Address Design and Non-custodial Guarantee (Key Detail)

Each staking operation generates a unique Taproot address in the form:

1

staking_address = P2TR(internal_pubkey, script_tree)
  • internal_pubkey: We use a “provably unspendable pubkey” as defined in BIP-341 — meaning it has no corresponding private key and cannot be directly used to spend;
  • script_tree: Contains only the unlock script [user_pubkey, OP_CHECKSIG] (extensions are possible, but we currently minimize the attack surface).

Why is this secure?

  • The internal_pubkey has no private key and thus cannot be used to sign;
  • The only valid spending path is via the user’s own private key under OP_CHECKSIG, ensuring the non-custodial property;
  • The address generation logic is open-source and deterministic — the same user key always yields the same staking address, so anyone can verify it.

Verification steps (for advanced users/auditors):

  1. Use our open-source generator to derive your staking_address and verify it against the on-chain record;
  2. Confirm that the internal_pubkey is indeed “provably unspendable” as defined in BIP-341;
  3. Inspect the script_tree to ensure it contains only user_pubkey and OP_CHECKSIG;
  4. Optionally, simulate a signature in a safe environment to confirm that only the user’s private key can produce a valid spend.

Full Lifecycle: Staking and Unstaking (Implementation Overview)

Staking Process

  1. The user initiates a staking request via the wallet UI and signs it (without exposing private keys);
  2. The platform generates a Taproot staking address tied to the user’s public key and returns it to the wallet for deposit;
  3. The wallet sends FB to that address (on-chain UTXO); once confirmed, the staking is considered active;
  4. The off-chain rewards engine starts accruing interest based on block height/time, storing metadata such as address, deposit txid, and start height.

Implementation notes:

  • The address generation process is deterministic and open-source.
  • A high-performance indexer (e.g., UniScan) is required to track UTXO states in real time.

Unstaking Process

  1. The user initiates an unstake request and specifies the target receiving address;
  2. The Rewards Calculator computes the final reward based on staking duration, height range, and additional bonuses;
  3. The distribution layer selects suitable UTXOs from the reward pool to cover “principal + reward + estimated fee”;
  4. A transaction is constructed and signed (by the platform for batch processing; user keys are never exposed), combining the reward pool UTXOs to pay both principal and reward;
  5. The transaction is broadcasted, and the staking status is updated.

Key point:

  • The platform does not hold user funds — all staking funds remain under the user’s control at their own staking address.
  • To ensure atomic payout, the system always sends both principal and reward in a single transaction, reducing failure risks.

Reward Engine and UTXO Pool Management

Rewards Engine

  • Runs off-chain — allows rapid iteration on reward algorithms (e.g., tiered interest, time-based bonuses, event incentives);
  • Data source — relies on high-performance indexers to track staking UTXOs in real time;
  • Decoupled architecture — reward rules can evolve without changing the on-chain custody model.

Reward Flexibility: A Practical Example

For example, staking 10,000 FB may yield a composite reward combining:

  1. Tiered, time-based base rewards;
  2. Additional bonuses tied to specific gem types.

A composite reward combining example
A composite reward combining example

You can experiment with this on the Farming page using the Rewards Calculator.

UTXO Pool (Reward Pool)

  • Pre-allocation: UTXOs are pre-generated daily/weekly based on expected demand and optimized for fee efficiency;
  • Dynamic scheduling: The pool adjusts in size based on staking activity and redemption history;
  • Batch distribution: Multiple unstake requests are aggregated into batch transactions to reduce average fee cost;
  • Atomic payout: Principal and reward are sent in one transaction to minimize user friction;
  • Failure recovery: Includes rollback and retry logic to maintain consistency under exceptional conditions.

Engineering trade-off:

Managing the UTXO pool means balancing between transaction cost and payout flexibility.
Smaller UTXOs increase management complexity, while overly large ones waste fees and reduce efficiency.

Security Design and Emergency Recovery

Mathematical and Script-Level Security

  • The internal_pubkey design (BIP-341 provably unspendable) prevents platform or third-party access to internal keys;
  • The minimal Taproot script tree (user_pubkey + OP_CHECKSIG) minimizes attack surface;
  • All logic and tools are open-sourced for community audit.

Emergency Recovery Tool

We provide fb-farming-tools (open-source, [link in appendix][1]) for users or trusted third parties to recover control of funds offline in case the platform becomes unavailable. It is designed to be permissionless, network-independent, and automated to minimize human error.

fb-farming-tools the Recovery Tool
fb-farming-tools the Recovery Tool

Audit Steps (for Verification)

Advanced users or auditors are encouraged to:

  1. Generate the staking address locally and compare it with the platform display;
  2. Inspect the Taproot internal_pubkey to confirm it’s unspendable;
  3. Verify that the script includes only user_pubkey and OP_CHECKSIG;
  4. Test the recovery flow on testnet to confirm toolchain integrity.

Extensibility: Multi-Asset and Pluggable Reward Engines

The system was designed to be modular from the start. Future directions may include:

  • BRC-20 support — Token staking and token-denominated rewards;
  • NFT (Ordinals) staking — Reward models based on rarity or holding history;
  • Parallel reward engines — Independent engines for different asset types to avoid interference.

Technically, we focus on two key aspects:

  1. Pluggable reward engines — clear interface standards for flexible integration;
  2. Multi-asset compatibility — ensuring the distribution layer and UTXO pool can support cross-asset or bridged payments.

For Developers: Testing, Auditing, and Toolchain

We actively encourage community participation in auditing and development. Developers can:

  • Explore the code and tools — run fb-farming-tools in offline/testnet mode;
  • Simulate load tests — create concurrent staking/unstaking scenarios to observe reward engine behavior;
  • Audit address generation — compare locally generated staking addresses with on-chain records to ensure transparency and determinism.

Conclusion

As engineers, we designed FB Farming around one guiding principle: “Keep security on-chain, keep flexibility off-chain.”

We believe this approach offers Fractal — and the broader Bitcoin ecosystem — a staking framework that preserves native security while remaining adaptable and future-proof.

If you are a developer, researcher, or auditor, you’re warmly invited to explore our repos, run the tools, and share your insights or improvements. We’ll continue open-sourcing more details, examples, and documentation to help the community replicate and learn from this design.

Let’s make Bitcoin more useful, more secure, and more accessible — together.

UniSat Team (Engineering Perspective)
October 2025

Additional Resources

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

Essay
Licensed under Creative Commons BY-NC-ND 4.0
© 2024 - 2025 Creative Commons BY-NC-ND 4.0 (Lorenzo)
Built with Hugo
Theme Stack designed by Jimmy