Fairblock

  • Name: Fairblock
  • URL: https://docs.fairblock.network/docs/welcome/Vision
  • Category: threshold-IBE confidentiality middleware / confidential execution layer / selective-disclosure infrastructure
  • Summary: Fairblock is best understood not as just another privacy wallet or anti-MEV slogan, but as a conditional-decryption and confidential-execution control plane. Its current materials separate a native confidentiality chain (FairyRing), app-facing confidential apps, threshold identity-based encryption (tIBE) for condition-triggered decryption, lightweight homomorphic balance operations, zero-knowledge proof verification, and cross-chain access paths that let users stay on external ecosystems while FairyRing maintains the confidential ledger. That makes Fairblock a useful comparison point for Shutter, drand, shielded-intent systems, confidential stablecoin rails, and other fairness/privacy projects: the real control surfaces are who defines decryption conditions, how validator key shares are generated and released, where confidential balances live, how cross-chain settlement is anchored, and when selective disclosure is allowed.
  • What it does:
    • Runs FairyRing, a native confidentiality execution layer where confidential applications can execute directly and where encrypted balances or transactions can be maintained without exposing plaintext amounts onchain
    • Uses threshold identity-based encryption so transactions or data can be encrypted against condition IDs and decrypted only once a target condition is met
    • Positions lightweight homomorphic encryption and fast ZK-proof verification as the balance-update path for confidential transfers rather than relying on a single offchain coprocessor or opaque TEE relay
    • Supports cross-chain confidential-transfer patterns in which users interact with a minimal escrow contract on an external chain while FairyRing maintains the confidential ledger and proof logic underneath
    • Offers selective disclosure and private-decryption flows, including designs where validator key shares are encrypted to a specific user wallet rather than revealed publicly to all observers
    • Frames the product surface around confidential stablecoin payments, protected trading / intents / auctions, and broader confidential-computing applications
  • Key claims:
    • The current overview page frames Fairblock as a “dynamic, decentralized cryptographic computer” with its own execution layer, and says confidential apps run on FairyRing while remaining accessible from external ecosystems without requiring users to bridge funds or switch wallets.
    • The v1 docs are the clearest mechanism summary for Fairblock’s condition-based confidentiality rail: FairyRing uses lightweight HE and threshold IBE so apps can encrypt transactions with a master public key and have them decrypt and execute automatically once conditions such as block heights, price triggers, or other requests are met.
    • The cryptography docs make the key split explicit. Validators run distributed key generation, hold master-secret-key shares, and derive private-key shares for a specific condition ID; once a threshold of shares is combined, the corresponding encrypted transaction or data can be decrypted.
    • The cross-chain technical overview is analytically useful because it separates settlement custody from confidential execution. An external EVM chain keeps a minimal escrow contract for token locking/unlocking, while FairyRing hosts the confidential ledger, proof verification, and encrypted-balance updates, with IBC/light-client verification used for cross-chain messaging and relayers serving only as packet movers.
    • Fairblock’s materials repeatedly emphasize selective disclosure rather than blanket secrecy: authorized parties can be given scoped access to specific balances or transactions for audits, investigations, or compliance workflows, while avoiding a single always-on audit key.
    • The private-decryption tutorial adds another important layer that generic privacy-project descriptions often hide. In that flow, validator key shares are encrypted to a specific user’s wallet public key, so the resulting master decryption key is not automatically public even after the condition is satisfied.
    • The project clears the corpus bar because it decomposes confidential finance into reusable mechanism layers: condition-ID-based decryption, validator-key-share governance, confidential-ledger hosting, external-chain settlement, selective-disclosure policy, and user-specific versus public decryption modes.
    • One caveat from this pass: the docs mix broad product framing, v1 mechanism docs, and tutorial / future-facing design space. The decomposition is valuable, but production maturity and version boundaries should be checked carefully in any deeper follow-up.
  • Whitepaper: No single current canonical Fairblock whitepaper surfaced in this pass. The strongest materials were the official overview and v1 docs, the cross-chain technical overview, the FairyRing repository summary, and the underlying FairBlock cryptography paper; see ../whitepapers/fairblock-primary-sources-2026-05-12.md.
  • Sources:
  • Last reviewed: 2026-05-12 UTC