FIP: Proof of Quality — Trust-Weighted and Uniqueness-Adjusted Fee Mechanism

Overview

This proposal defines a fee mechanism for Hypersnap that dynamically adjusts per-message fees based on two orthogonal quality signals: trust score (derived from Web of Trust clustering over the social graph) and uniqueness score (derived from content fingerprinting inspired by /r9k/ but with stricter guarantees). The combination ensures that highly trusted users posting genuinely novel content pay near-zero fees, while untrusted accounts or repetitive content face progressively higher costs.

This FIP does not propose a token. It assumes a network-native token exists and defines how fees are computed, collected, and distributed.

1. Motivation

The Spam Economics Problem

Current Snapchain spam prevention relies on two mechanisms:

1. Storage rent: Users purchase storage units on L1, granting a quota of messages per type (e.g., 5,000 casts per legacy unit). This creates a one-time cost barrier but does not penalize low-quality or repetitive content within the quota.
2. Rate limiting: The mempool enforces a token-bucket rate limiter per FID (100 + storage_units/10 messages per hour). This prevents burst flooding but treats all messages as equally costly regardless of quality.

Neither mechanism distinguishes between a thoughtful original post and the thousandth copy of the same spam template. A well-funded spammer can rent storage and stay within rate limits while flooding the network with low-quality, repetitive content. Conversely, a trusted community member posting novel content pays the same implicit cost as a spam bot.

Quality Signals Are Available But Unused

Hypersnap already stores the data needed to assess quality:

• Social graph: LinkAdd messages with type "follow" form a directed graph. Well-connected users in organic clusters are distinguishable from sybil rings.
• Message content: Cast text, embeds, and metadata are available for fingerprinting. Repetitive content is detectable.
• Identity verification: VerificationAdd links FIDs to Ethereum/Solana addresses, providing sybil-resistance anchors.
• Account age: FID registration timestamps and message history provide temporal trust signals.

A fee mechanism that leverages these signals can create an economic gradient where quality is cheap and spam is expensive — without requiring manual moderation or centralized curation.

Design Goals

1. Spam is expensive: Repetitive content from untrusted accounts faces fees that make bulk spam economically unviable.
2. Quality is cheap: Trusted users posting original content pay near-zero fees, preserving the "free to use" feel of the protocol for genuine participants.
3. Progressive, not binary: Fees exist on a continuous spectrum rather than a spam/not-spam binary. Moderate trust or moderate uniqueness still gets a meaningful discount.
4. Sybil-resistant: Trust scores resist manipulation by sybil networks through graph-structural analysis.
5. Permissionless: No trusted third party decides who is "trusted." Trust emerges from the social graph itself.
6. Deterministic: All validators compute the same fee for the same message, enabling consensus on fee validity.

2. Trust Score Computation

Overview

Trust scores quantify how well-embedded a user is in the organic social graph. They are computed per-epoch using the follow graph and verified address data, then committed to the hyper trie for deterministic fee lookups during message validation.

Input Data

The trust computation uses three data sources, all already stored on-chain:

1. Follow graph: All active LinkAdd messages with type "follow". This forms a directed graph G = (V, E) where vertices are FIDs and edges are follow relationships.
2. Verified addresses: VerificationAdd messages linking FIDs to Ethereum addresses. FIDs with verified addresses that hold meaningful on-chain history (token balances, transaction counts, ENS names) receive a sybil-resistance bonus.
3. Account age: Time since FID registration (from IdRegister events).

Step 1: Seed Set Construction

The trust computation begins with a seed set of FIDs that are assumed to be legitimate. This is not a whitelist — it is an algorithmic bootstrap:

• Verified anchors: FIDs with verified Ethereum addresses that hold non-trivial on-chain history (e.g., address age > 1 year, or has > 10 transactions). The verification signature is already validated by the protocol.
• High-age accounts: FIDs registered more than 6 months ago with consistent posting history (>100 messages across >30 days).
• Seed set size: Target ~1% of active FIDs. The exact threshold is a governance parameter.

The seed set is recomputed each epoch. FIDs can enter or leave the seed set as their on-chain history changes.

Step 2: Trust Propagation (EigenTrust)

From the seed set, trust propagates through the follow graph using a variant of EigenTrust:

t(i) = (1 - d) * seed(i) + d * sum_j(t(j) * w(j, i) / out_degree(j))

Where:

• t(i) is the trust score of FID i
• d is a damping factor (0.85, same as PageRank)
• seed(i) is 1.0 if FID i is in the seed set, 0.0 otherwise
• w(j, i) is the edge weight from j to i (1.0 for a follow)
• out_degree(j) is the number of FIDs that j follows

This converges in ~50 iterations for typical social graphs. The result is a probability distribution over FIDs, where higher values indicate stronger trust propagation from the seed set.

Step 3: Spectral Clustering (Sybil Ring Detection)

EigenTrust alone is vulnerable to sybil attacks where a spam ring accumulates follows from a few legitimate users. To defend against this, we apply spectral clustering to detect and penalize structurally anomalous subgraphs:

1. Construct the normalized Laplacian of the follow graph (or a sampled subgraph for scalability).
2. Compute the k smallest eigenvectors (k = governance parameter, default 32).
3. Run k-means clustering in the spectral embedding space.
4. Score each cluster by its internal-to-external edge ratio:
   • Organic clusters: High internal connectivity AND high external connectivity (many edges to other clusters). These are legitimate communities.
   • Sybil clusters: High internal connectivity BUT low external connectivity (isolated cliques with few bridges to the broader graph). These are spam rings.
5. Cluster penalty: FIDs in clusters with external connectivity below a threshold receive a trust penalty:

cluster_penalty(i) = max(0, 1 - (external_edges(cluster(i)) / expected_external_edges))

Where expected_external_edges is calibrated based on cluster size (larger clusters should have proportionally more external connections).

Step 4: Final Trust Score

trust_score(i) = clamp(
    eigentrust(i) * (1 - cluster_penalty(i)) * age_factor(i),
    0.0,
    1.0
)

Where:

• age_factor(i) = min(1.0, account_age_days / 180) — linearly ramps from 0 to 1 over the first 6 months
• The result is clamped to [0.0, 1.0]

Step 5: Epoch Commitment

Trust scores are computed once per epoch (same epoch cadence as hyper validator selection: EPOCH_LENGTH blocks). The proposer for the first hyper block of each epoch computes the trust scores and commits them to the hyper trie:

• Storage key: [RootPrefix::TrustScore] ++ [FID (8 bytes)] → trust_score as a u16 (0-10000, representing 0.0000 to 1.0000)
• Commitment: The hyper trie root after trust score insertion is included in the epoch's first hyper block header, making it consensus-binding.
• Determinism: All validators independently compute the same trust scores from the same graph snapshot (taken at the epoch boundary block).

Scalability

For a network with N users and E follow edges:

• EigenTrust: O(E * iterations) per epoch — ~50 iterations, highly parallelizable
• Spectral clustering: O(E * k) for sparse eigenvector computation via Lanczos iteration
• K-means: O(N * k * iterations) — ~20 iterations on k-dimensional embeddings

At current Hypersnap scale (~500K FIDs, ~50M follow edges), this completes in seconds on modern hardware. At 10M FIDs, it may take minutes — well within the epoch boundary window.

Trust Score Staleness

Trust scores are valid for one epoch. Between epochs, a user's trust score is the last committed value. New accounts registered mid-epoch have a trust score of 0.0 until the next epoch computation — they pay full base fees. This is acceptable because account registration is infrequent relative to messaging.

3. Uniqueness Score Computation

Overview

The uniqueness system ensures that content carrying a lower fee is genuinely novel. It is inspired by /r9k/ (ROBOT9000) — the 4chan experiment where every post had to be unique or the user was muted — but with several key differences:

1. Graduated, not binary: Near-duplicates don't result in rejection — they result in higher fees.
2. Fuzzy matching: Exact-match deduplication is trivially circumvented by adding a character. The system uses locality-sensitive hashing to catch near-duplicates.
3. Per-FID and global: Content is checked against both the user's own history (self-repetition) and the global corpus (cross-user duplication).
4. Content-type aware: Different message types have different uniqueness requirements.

Fingerprinting Method: SimHash

Each message's textual content is fingerprinted using SimHash (Charikar, 2002):

1. Tokenization: Split text into overlapping character n-grams (n=3 for short text, n=5 for longer content). This captures structure without being sensitive to word boundaries or minor edits.
2. Hashing: Hash each n-gram with a fast hash (xxHash64).
3. SimHash construction: For each bit position, sum +1 for each hash with that bit set, -1 otherwise. The final fingerprint is the sign of each sum → a 128-bit fingerprint.
4. Hamming distance: Two fingerprints with Hamming distance ≤ SIMILARITY_THRESHOLD (default: 12 bits out of 128 = ~90% similarity) are considered near-duplicates.

SimHash has the property that similar texts produce fingerprints with small Hamming distance, enabling efficient nearest-neighbor lookups.

Uniqueness Lookup

Global Uniqueness Index

A rolling Hamming distance index of recent message fingerprints:

• Window: Last 30 days of messages (configurable, governance parameter)
• Storage: [RootPrefix::ContentFingerprint] ++ [fingerprint_bucket (8 bytes)] ++ [fingerprint (16 bytes)] → [fid (8 bytes)] ++ [timestamp (4 bytes)]
• Bucket: The first 64 bits of the fingerprint serve as a locality-sensitive hash bucket. Fingerprints in the same bucket are checked for Hamming distance.
• Lookup cost: O(bucket_size) per message — typically O(1) to O(100) for well-distributed buckets.

Per-FID Uniqueness

In addition to global uniqueness, each user's recent messages are checked for self-repetition:

• Window: All messages from the FID in the current epoch
• Threshold: Stricter than global (Hamming distance ≤ 8 = ~94% similarity)
• Purpose: Catches users who repeatedly post variations of the same template

Uniqueness Score Calculation

global_matches = count of messages in global index within SIMILARITY_THRESHOLD
self_matches = count of own messages in current epoch within SELF_SIMILARITY_THRESHOLD

uniqueness_score = clamp(
    1.0 - (global_penalty(global_matches) + self_penalty(self_matches)),
    0.0,
    1.0
)

Where:

• global_penalty(n) = min(0.5, n * 0.1) — each global near-duplicate adds 10% penalty, capped at 50%
• self_penalty(n) = min(0.5, n * 0.15) — each self near-duplicate adds 15% penalty, capped at 50%
• Combined penalty is capped at 1.0 (100% of base fee — no fee beyond base)

Content-Type Rules

Only CastAdd messages are subject to uniqueness scoring. All other message types receive a uniqueness score of 1.0 (maximum uniqueness → no uniqueness penalty).

Exemptions

Certain cast patterns are exempt from uniqueness penalties:

1. Replies: Casts with a parent_cast_id set are replies to specific conversations. Replies may legitimately share content with the parent or other replies (e.g., answering the same question). Replies receive a 50% reduction in global penalty.
2. Embeds-only casts: Casts with empty text but non-empty embeds (link shares, image shares) are fingerprinted on the embed URLs, not text. Sharing the same link is common and receives a gentler penalty curve.

4. Fee Formula

Base Fee

Each message type has a base fee denominated in the network-native token:

Base fees are governance parameters stored in the hyper trie and adjustable per-epoch via a governance mechanism (outside the scope of this FIP).

Discount Formula

effective_fee = base_fee * (1 - trust_discount) * (1 - uniqueness_discount)

Where:

• trust_discount = trust_score * MAX_TRUST_DISCOUNT
• uniqueness_discount = uniqueness_score * MAX_UNIQUENESS_DISCOUNT
• MAX_TRUST_DISCOUNT = 0.80 (trust can reduce fees by up to 80%)
• MAX_UNIQUENESS_DISCOUNT = 0.80 (uniqueness can reduce fees by up to 80%)

The multiplicative combination means both signals contribute independently:

A maximally trusted user posting fully unique content pays 4% of the base fee — effectively free. An untrusted account posting duplicate spam pays the full base fee.

Minimum Fee Floor

To prevent zero-fee abuse even at maximum discounts, a minimum fee floor applies:

final_fee = max(effective_fee, MIN_FEE_FLOOR)

MIN_FEE_FLOOR = 0.001 units — a negligible cost for legitimate users but nonzero for accounting and anti-abuse purposes.

Fee Ceiling for New Accounts

New accounts (trust score = 0.0, registered in current epoch) face a temporary fee ceiling:

new_account_fee = min(base_fee, NEW_ACCOUNT_FEE_CEILING)

NEW_ACCOUNT_FEE_CEILING = 2.0 units — prevents the full base fee from being prohibitively expensive for genuine new users. After the first epoch computation assigns a trust score, the standard formula applies.

5. Fee Collection and Distribution

Collection

Fees are deducted from a per-FID fee balance at message merge time:

1. Fee balance: Each FID has a fee balance stored in the hyper trie: [RootPrefix::FeeBalance] ++ [FID (8 bytes)] → balance (u64, in micro-units)
2. Deposit: Users deposit tokens into their fee balance via an on-chain deposit transaction (similar to StorageRent, but for the fee pool).
3. Deduction: When a message is merged, the effective fee is computed and deducted from the FID's balance. If the balance is insufficient, the message is rejected with InsufficientFeeBalance.
4. Batching: Within a block, all fee deductions for a FID are summed and applied atomically. This avoids per-message balance lookups during high-throughput periods.

Distribution

Collected fees are distributed to incentivize network operation:

Distribution occurs at epoch boundaries. Each epoch's accumulated fees are tallied and distributed proportionally.

Refund on Removal

When a user removes a message (CastRemove, LinkRemove, ReactionRemove), the fee paid for the original message is not refunded. This prevents a fee-avoidance attack where a user posts, gets the fee discount, then immediately removes and reposts.

6. Implementation

New Proto Types

// In hyper.proto

enum HyperMessageType {
  // ... existing types ...
  HYPER_MESSAGE_TYPE_FEE_DEPOSIT = 110;
}

message FeeDepositBody {
  uint64 amount = 1;        // Amount in micro-units
}

message TrustScoreEntry {
  uint64 fid = 1;
  uint32 score = 2;         // 0-10000 (0.0000-1.0000)
}

message EpochTrustCommitment {
  uint64 epoch = 1;
  bytes merkle_root = 2;    // Root hash of all trust scores
  uint64 num_entries = 3;
  uint64 seed_set_size = 4;
  uint32 num_clusters = 5;
}

New Storage Prefixes

// In constants.rs
pub enum RootPrefix {
    // ... existing prefixes ...
    TrustScore = 30,           // [FID] → u16 score
    FeeBalance = 31,           // [FID] → u64 balance (micro-units)
    ContentFingerprint = 32,   // [bucket][fingerprint] → [fid][timestamp]
    FeeParameter = 33,         // [param_key] → value
    EpochFeeAccumulator = 34,  // [epoch] → accumulated fees
}

Trust Score Computation Integration

Trust scores are computed during hyper block proposal at epoch boundaries:

impl HyperEngine {
    fn maybe_compute_epoch_trust_scores(
        &mut self,
        anchor_block_number: u64,
    ) -> Result<Option<EpochTrustCommitment>, HubError> {
        let new_epoch = anchor_block_number / EPOCH_LENGTH;
        if new_epoch <= self.current_trust_epoch {
            return Ok(None);
        }

        // 1. Snapshot follow graph from link store
        let follow_graph = self.snapshot_follow_graph()?;

        // 2. Build seed set from verified addresses + account age
        let seed_set = self.build_seed_set(&follow_graph)?;

        // 3. Run EigenTrust propagation
        let eigentrust_scores = eigentrust::compute(
            &follow_graph,
            &seed_set,
            DAMPING_FACTOR,
            MAX_ITERATIONS,
        );

        // 4. Run spectral clustering for sybil detection
        let clusters = spectral::cluster(
            &follow_graph,
            NUM_CLUSTERS,
        );
        let cluster_penalties = spectral::compute_penalties(&clusters);

        // 5. Compute final scores and commit to trie
        let commitment = self.commit_trust_scores(
            new_epoch,
            &eigentrust_scores,
            &cluster_penalties,
        )?;

        self.current_trust_epoch = new_epoch;
        Ok(Some(commitment))
    }
}

Fee Validation in Message Merge

Fee validation occurs during block proposal and validation, after message validation but before trie update:

impl ShardEngine {
    fn compute_and_deduct_fee(
        &self,
        msg: &proto::Message,
        trust_scores: &TrustScoreIndex,
        txn: &mut RocksDbTransactionBatch,
    ) -> Result<u64, HubError> {
        let fid = msg.data.as_ref().unwrap().fid;
        let msg_type = msg.data.as_ref().unwrap().r#type;

        // 1. Get base fee for message type
        let base_fee = self.get_base_fee(msg_type);
        if base_fee == 0 {
            return Ok(0); // Free message types
        }

        // 2. Look up trust score (0.0-1.0)
        let trust_score = trust_scores.get(fid).unwrap_or(0);
        let trust_discount = (trust_score as f64 / 10000.0) * MAX_TRUST_DISCOUNT;

        // 3. Compute uniqueness score (CastAdd only)
        let uniqueness_score = if msg_type == MessageType::CastAdd as i32 {
            self.compute_uniqueness(msg)?
        } else {
            10000 // 1.0 — full uniqueness for non-cast types
        };
        let uniqueness_discount =
            (uniqueness_score as f64 / 10000.0) * MAX_UNIQUENESS_DISCOUNT;

        // 4. Compute effective fee
        let effective = base_fee as f64
            * (1.0 - trust_discount)
            * (1.0 - uniqueness_discount);
        let final_fee = (effective as u64).max(MIN_FEE_FLOOR);

        // 5. Deduct from balance
        let balance = self.get_fee_balance(fid, txn)?;
        if balance < final_fee {
            return Err(HubError::validation_failure(
                "Insufficient fee balance",
            ));
        }
        self.set_fee_balance(fid, balance - final_fee, txn)?;

        Ok(final_fee)
    }
}

Fingerprint Index Management

The content fingerprint index is maintained as a rolling window:

impl ShardEngine {
    fn compute_uniqueness(&self, msg: &proto::Message) -> Result<u16, HubError> {
        let text = &msg.data.as_ref().unwrap()
            .body.as_ref().unwrap()
            .cast_add_body().text;

        // 1. Compute SimHash fingerprint
        let fingerprint = simhash::compute(text, NGRAM_SIZE);

        // 2. Check global index for near-duplicates
        let global_matches = self.fingerprint_index.query_hamming(
            &fingerprint,
            SIMILARITY_THRESHOLD,
        );

        // 3. Check self-history for repetition
        let fid = msg.data.as_ref().unwrap().fid;
        let self_matches = self.fingerprint_index.query_hamming_by_fid(
            &fingerprint,
            SELF_SIMILARITY_THRESHOLD,
            fid,
        );

        // 4. Compute penalty
        let is_reply = msg.data.as_ref().unwrap()
            .body.as_ref().unwrap()
            .cast_add_body().parent.is_some();
        let reply_factor = if is_reply { 0.5 } else { 1.0 };

        let global_penalty = (global_matches as f64 * 0.1 * reply_factor)
            .min(0.5);
        let self_penalty = (self_matches as f64 * 0.15).min(0.5);
        let total_penalty = (global_penalty + self_penalty).min(1.0);

        // 5. Insert fingerprint into index
        self.fingerprint_index.insert(&fingerprint, fid, timestamp);

        Ok(((1.0 - total_penalty) * 10000.0) as u16)
    }
}

7. Anti-Gaming Measures

Trust Score Gaming

Attack: Create a sybil ring and follow legitimate users to accumulate trust.

Defense: Spectral clustering detects subgraphs with abnormally low external connectivity relative to their internal density. A sybil ring of 100 accounts that all follow each other but collectively only receive follows from 2 legitimate accounts will be identified as a low-external-connectivity cluster and receive a severe trust penalty.

Attack: Gradually build trust by posting unique content, then switch to spam.

Defense: Trust scores are recomputed each epoch. A sudden shift in behavior (high-volume posting of near-duplicate content) will increase fees immediately via the uniqueness score, even if the trust score remains high until the next epoch. The multiplicative formula means that even a trust score of 1.0 only provides 80% discount — a spammer still pays 20% of base fee per message, which adds up at spam volumes.

Uniqueness Gaming

Attack: Append random characters to spam templates to evade SimHash detection.

Defense: SimHash with character n-grams is robust to suffix/prefix additions. A 200-character spam template with 5 random characters appended will produce a fingerprint within Hamming distance ~4 of the original — well within the detection threshold of 12. The attacker would need to modify ~25% of the content to evade detection, at which point the content is arguably "different enough."

Attack: Use a large language model to rephrase the same message thousands of ways.

Defense: SimHash catches structural similarity but not semantic similarity. This is an acknowledged limitation. However:

1. LLM rephrasing at scale is expensive — the attacker is already spending compute resources.
2. If the rephrased content is genuinely different in structure, it arguably provides more value than exact copies.
3. Future enhancements could add semantic fingerprinting (embedding-based similarity), but this adds significant computational cost and is deferred.

Attack: Post unique but valueless content (random strings, generated nonsense).

Defense: Uniqueness score only provides a discount — it cannot make fees negative. Random nonsense from a low-trust account still pays base_fee * 0.20 (80% uniqueness discount, 0% trust discount). Combined with rate limiting, this is sufficient deterrent.

Fee Balance Gaming

Attack: Deposit minimal fees and drain the balance with discounted messages, then abandon the account.

Defense: New accounts (trust score = 0.0) pay higher fees. Building trust requires time (6-month age factor) and organic social graph integration. The cost of acquiring trust exceeds the fee savings.

Attack: Buy/sell high-trust accounts.

Defense: Trust scores are non-transferable — they are tied to FID, which is tied to custody address. Transferring an FID (via IdRegister TRANSFER event) resets the trust score to 0.0 for the new custodian. The previous custodian's social graph remains, but the trust score recalculation at the next epoch will reflect the change in behavior and custody.

Cluster Manipulation

Attack: Create a sybil cluster that mimics the connectivity patterns of organic clusters to avoid detection.

Defense: To achieve external connectivity comparable to organic clusters, sybil accounts need follows from many legitimate users across multiple real communities. This is expensive in social capital and indistinguishable from "actually being a legitimate community" if achieved. The attack degrades into the attacker genuinely participating in the network, which is the desired outcome.

8. Parameter Summary

Trust Parameters

Uniqueness Parameters

Fee Parameters

9. Migration Strategy

Phase 1: Observation Mode

Deploy trust score computation and uniqueness fingerprinting without fee enforcement. Log what fees would have been charged for each message. This provides:

1. Calibration data for parameter tuning (are the right users getting discounts?)
2. Baseline for fee revenue projections
3. Detection of edge cases before they affect users

Duration: 2 epochs (~2 days at current block time).

Phase 2: Optional Fee Mode

Enable fee deposits and deductions, but make them optional. Messages without sufficient fee balance are still accepted but flagged as "unverified quality" in the trie. Clients can use this flag for display prioritization. This creates demand for fee deposits without breaking existing usage patterns.

Duration: 2 epochs.

Phase 3: Mandatory Fee Mode

All messages require sufficient fee balance. Base fees start at 50% of the target values and ramp to 100% over 4 epochs. This gives users time to deposit tokens and adjust to the new economics.

EngineVersion Gate

pub enum ProtocolFeature {
    // ... existing features ...
    ProofOfQualityObservation,  // Phase 1: compute + log
    ProofOfQualityOptional,     // Phase 2: optional enforcement
    ProofOfQualityMandatory,    // Phase 3: full enforcement
}

10. Impact on Dependent Systems

Storage Rent

Storage rent continues to exist alongside Proof of Quality fees. Storage rent controls capacity (how many messages of each type a user can store), while Proof of Quality controls cost per message. The two systems are complementary:

• A user with large storage rent allocation but low trust and duplicate content pays high per-message fees
• A user with minimal storage rent but high trust and unique content pays low per-message fees but has limited total capacity

Rate Limiting

The existing mempool rate limiter (token bucket per FID) continues to operate as a DoS protection layer. Proof of Quality fees operate at the economic layer — above rate limiting but below consensus.

Hyper Trie

Trust scores, fee balances, and content fingerprints are stored in the hyper trie (RootPrefix 30-34). This keeps them isolated from snapchain state while benefiting from the hyper trie's persistence and consensus properties.

Read Nodes

Read nodes receive trust scores and fee data via hyper block sync. They can serve fee balance queries and trust score lookups to clients without being validators.

Light Clients

Light clients need to know a user's trust score and fee balance to construct valid messages. These can be queried from any hub node's API (new endpoints: getTrustScore(fid), getFeeBalance(fid), estimateFee(message)).

11. Open Questions

1. Seed set governance: Who decides the seed set criteria? A static algorithm (this FIP's proposal) is simple but may not adapt to changing network dynamics. Should the seed set criteria be a governance parameter, or should it be hardcoded?

2. Trust score visibility: Should trust scores be publicly queryable? Transparency aids debugging and user understanding, but could also enable social attacks ("your trust score is low, therefore your opinions don't matter"). Consider making scores queryable but not prominently displayed.

3. Fee denomination: What is the unit? This FIP uses abstract "units" — the actual denomination depends on the token design (outside scope). The fee parameters should be calibrated so that a normal user's daily posting costs are negligible (< $0.01 USD equivalent).

4. Computational cost: Trust score computation at epoch boundaries adds CPU load to hyper proposers. At scale (10M+ users), spectral clustering may require sampling or approximation. Should approximate algorithms (e.g., power iteration clustering instead of full spectral decomposition) be specified now, or deferred?

5. Cross-shard uniqueness: Content fingerprints are per-shard (since casts are routed by FID to specific shards). A sophisticated spammer could register FIDs across shards and post the same content on each. Should the fingerprint index be global (cross-shard) or is per-shard sufficient?

6. Embed fingerprinting: Should embeds (URLs, cast references) be included in the SimHash fingerprint? Including them catches link-spam more effectively but may penalize legitimate sharing of popular links.

7. Trust score delegation: Should a high-trust user be able to "vouch" for a new user, temporarily lending them a trust score? This could help onboarding but creates a new attack surface (compromised vouchers).

8. Fee-free allowance: Should each FID receive a small daily allowance of fee-free messages (e.g., 5 casts/day) regardless of trust or uniqueness? This preserves the "free to use" property for casual users while still taxing high-volume posting.

9. Language sensitivity: SimHash with character n-grams may behave differently across languages (CJK characters produce different n-gram distributions than Latin scripts). Should fingerprint parameters be language-adaptive?

10. Retroactive trust adjustment: If a user's trust score drops significantly between epochs (e.g., they were removed from the seed set), should fees retroactively increase for messages already in the mempool but not yet committed?