Whitepaper

Abstract

Floating Point Protocol (FPP) introduces a novel approach to blockchain privacy payments through the concept of "Floating Random Points" - discrete value units that exist in an anonymous pool. Each point represents a fixed value of $10 USDT, fully collateralized and redeemable. By combining Pedersen commitments, zero-knowledge proofs, and Linkable Spontaneous Anonymous Group (LSAG) ring signatures, FPP achieves strong sender anonymity, receiver anonymity, and amount privacy while maintaining full auditability for regulatory compliance when required.

1. Introduction

2. System Architecture

2.1 Floating Point Structure

Each Floating Point contains the following cryptographic components:

struct FloatingPoint {
  bytes32 id;           // Unique identifier (hash of commitment)
  uint256 value;        // Fixed at 10 USDT (10 * 10^6)
  bytes32 commitment;   // Pedersen commitment: C = vG + rH
  bytes32 nullifierHash;// Hash for double-spend prevention
  uint256 mass;         // Selection weight (increases with age)
  uint256 createdAt;    // Block timestamp of creation
  address owner;        // Commitment to owner (hidden)
}

2.2 Pedersen Commitments

Values are hidden using Pedersen commitments, which provide both hiding (privacy) and binding (integrity):

Where v is the value, r is a random blinding factor, and G, H are generator points on the elliptic curve.

2.3 Nullifiers

Each point has a unique nullifier derived from the owner's secret key. When a point is spent, its nullifier is published and stored on-chain. Attempting to spend the same point twice will produce the same nullifier, which the contract will reject.

3. Token Destruction & Generation Model

FPP uses a unique "Destroy and Generate" model for privacy transfers. Tokens are never directly transferred. Instead, sender's tokens are destroyed and fresh tokens are generated for recipients.

3.1 Why Destroy & Generate?

Traditional transfers create on-chain links between sender and receiver. By destroying sender tokens and creating new ones for recipients, FPP breaks any on-chain connection:

// Privacy Transfer Flow
┌─────────────────────────────────────────────────────────┐
│  SENDER                 PROTOCOL            RECIPIENT   │
│                                                         │
│  Token_A ──────┐                                        │
│  Token_B ──────┼──→ DESTROY ──→ GENERATE ──→ Token_X   │
│  Token_C ──────┘    (nullify)   (fresh)       Token_Y   │
│                                               Token_Z   │
│                                                         │
│  • Nullifiers recorded (tokens marked as spent)         │
│  • Fresh commitments created for recipients             │
│  • USDT remains locked in Treasury (no movement)        │
│  • Zero on-chain link between sender and recipients     │
└─────────────────────────────────────────────────────────┘

3.2 Multi-Recipient Support

A single transaction can distribute tokens to multiple recipients. Each recipient receives independently generated tokens with unique commitments:

// Multi-recipient example
Sender destroys 5 tokens:
├── Recipient A: receives 2 new tokens
├── Recipient B: receives 2 new tokens  
└── Recipient C: receives 1 new token

Each recipient's tokens are cryptographically independent.

3.3 Withdrawal (Token Destruction)

When withdrawing, tokens are destroyed (absorbed into black hole) and USDT is released from Treasury:

// Withdrawal Flow
Token_A ──→ DESTROY ──→ [24h Timelock] ──→ USDT to Wallet
Token_B ──→ (nullify)
Token_C ──→ 

Tokens are burned on-chain, USDT released after timelock.

4. Privacy Mechanisms

4.1 Ring Signatures (LSAG)

FPP uses Linkable Spontaneous Anonymous Group signatures to hide the true sender among a set of decoys. The signature proves that one member of the ring authorized the transaction, without revealing which one.

// Ring signature generation
σ = LSAG.Sign(message, secretKey, ringPublicKeys)

// Verification
LSAG.Verify(message, σ, ringPublicKeys) → true/false

// Key image (linkability tag)
I = secretKey × Hash_p(publicKey)

The key image I is unique per secret key and allows detection of double-signing without revealing identity.

4.2 Zero-Knowledge Proofs

ZK-SNARKs prove the following statements without revealing any private information:

• The sender knows the secret key for one of the input points
• The nullifier is correctly computed from the point and secret
• Input values equal output values (conservation)
• All commitments are correctly formed

4.3 Stealth Addresses

Recipients generate one-time stealth addresses for each transaction. The sender encrypts the output randomness with the recipient's public key, allowing only the recipient to claim the new points.

// Stealth address generation
r = random()
R = r × G                    // Published ephemeral key
P = Hash(r × recipientPubKey) × G + recipientPubKey

5. Gravity-Weighted Selection Algorithm

When spending points, the protocol uses a gravity-weighted random selection algorithm. This ensures older points are more likely to be selected, improving the anonymity set and encouraging circulation.

// Weight calculation
weight(point) = mass × √(age + 1) × GRAVITY_CONSTANT

// Selection probability
P(point) = weight(point) / Σ weights

// Where:
//   mass = initial mass (default: 1.0)
//   age = currentTime - createdAt
//   GRAVITY_CONSTANT = 9.81 (configurable)

This creates a natural "sink" effect where older points gravitate toward selection, while newer points gradually increase their probability over time.

6. Tokenomics & Value Stability

6.1 100% Collateralization

Every Floating Point is backed 1:1 by USDT held in the Treasury contract. The total value of all outstanding FP equals the USDT reserve at all times. This is verifiable on-chain:

6.2 Fixed Denomination

Each FP has a fixed value of $10 USDT. This simplifies privacy by eliminating amount analysis - all points are fungible and indistinguishable by value.

6.3 Fee Structure

7. Security Model

7.1 Threat Model

• Double Spending: Prevented by nullifier set stored on-chain
• Front-running: Mitigated by commit-reveal scheme in ZK proofs
• Sybil Attacks: Economic cost of USDT deposit required
• Timing Analysis: Decoy selection randomized with VRF

7.2 24-Hour Timelock

All withdrawals require a 24-hour waiting period. This provides protection against:

• Flash loan attacks attempting to drain the protocol
• Compromised wallets (user can cancel within timelock)
• Smart contract bugs (governance can pause if needed)

8. Multi-Chain Support: Solana

FPP is expanding to Solana to offer high-throughput, low-cost privacy payments. The Solana implementation maintains identical privacy guarantees while leveraging Solana's performance advantages.

8.1 Solana Advantages

8.2 Technical Implementation

// Solana Program (Anchor Framework)
#[program]
pub mod floating_point_protocol {
    use anchor_lang::prelude::*;
    use light_protocol::groth16; // ZK proofs via Light Protocol
    
    pub fn deposit(ctx: Context<Deposit>, amount: u64) -> Result<()> {
        // Transfer USDC to treasury
        // Generate Pedersen commitment
        // Create new FloatingPoint account
    }
    
    pub fn privacy_transfer(
        ctx: Context<Transfer>,
        nullifiers: Vec<[u8; 32]>,
        output_commitments: Vec<[u8; 32]>,
        zk_proof: Vec<u8>,
    ) -> Result<()> {
        // Verify ZK proof
        // Record nullifiers
        // Create output points
    }
}

8.3 Roadmap

• Q1 2025: Devnet deployment and testing
• Q2 2025: Mainnet launch with USDC support
• Q3 2025: Cross-chain bridge (Ethereum ↔ Solana)

9. Regulatory Compliance

FPP supports optional compliance features for users who require auditability:

7.1 View Keys

Users can generate view keys that allow designated auditors to see their transaction history without gaining spending authority.

7.2 Selective Disclosure

Users can prove specific facts about their transactions (e.g., "I sent X to address Y at time T") without revealing their entire history, using zero-knowledge proofs.