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. Privacy Mechanisms

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

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

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

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

5. Tokenomics & Value Stability

5.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:

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

5.3 Fee Structure

6. Security Model

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

6.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)

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