Embedding a funding rate window for similarity search

Abstract#

Vector similarity search — the backbone of embedding-based pattern matching — is increasingly relevant in quantitative trading for identifying historical regime analogs, detecting cross-exchange mispricings, and clustering funding rate behaviors. But financial data has latency requirements that software-based approximate nearest neighbor (ANN) indexes struggle to meet at scale. This paper examines whether FPGA-accelerated vector search can meaningfully reduce inference latency for trading applications, using real data from our perpetual futures monitoring system (266,570 funding rate observations, 20 actively tracked perpetual tokens, cross-exchange spread snapshots across 3 venues). We find that while FPGA implementations of inner-product search can achieve sub-microsecond query latencies for fixed-dimension embeddings, the practical bottleneck in trading systems is not vector search latency but feature engineering and embedding freshness. This is a systems analysis informed by production data, not a backtested trading strategy; we present latency modeling and architectural observations, not performance claims.

Hypotheses#

H1 (Primary — Exploratory): FPGA-accelerated exact inner-product search on embedded funding rate windows can achieve sub-10μs query latency for databases of ≤500K vectors at dimensionality ≤128, making it viable for real-time regime detection in perpetual futures trading.

H2 (Secondary — Observational): The dominant latency bottleneck in embedding-based trading signal pipelines is embedding computation (feature extraction + forward pass), not vector index traversal, making FPGA acceleration of ANN alone insufficient for end-to-end latency reduction.

H3 (Exploratory — Data Insufficient): Clustering funding rate histories into vector embeddings and performing similarity search against historical analogs produces more actionable regime transitions than threshold-based heuristics currently used in production systems.

Confidence Assessment: H1 is supported by published FPGA benchmarks in non-financial domains but unvalidated on our specific data — confidence is moderate. H2 is strongly supported by architectural reasoning and operational experience. H3 is speculative; we lack the controlled experiments to compare similarity-based vs. threshold-based regime detection. All hypotheses are preliminary.

Data Provenance#

Data source: Funding rate and spread data was collected via real-time exchange APIs (Binance, Hyperliquid, Asterdex) as part of the PerpsTrader production monitoring system. FPGA benchmarks are sourced from published literature. No data was simulated or backtested.

Limitation: This paper is a systems design analysis, not a controlled experiment. We have no trades to evaluate whether faster vector search produces better execution. The FPGA latency figures are derived from published benchmarks and scaling laws, not measured on our hardware. The funding rate data provides the problem space (what needs to be searched) rather than evidence that FPGA search improves outcomes.

The Vector Search Problem in Trading#

Why Vector Similarity Matters for Perpetual Futures#

Modern quantitative trading increasingly relies on embedding-based representations of market state. Instead of rule-based heuristics ("funding rate above X"), the approach encodes multi-dimensional market snapshots into dense vectors and searches for historical analogs:

# Embedding a funding rate window for similarity search
def embed_funding_window(rates_window: list[float], dim: int = 64) -> list[float]:
    """
    Encode a rolling window of funding rates into a fixed-dimension vector.
    
    rates_window: sequence of annualized funding rates (e.g., last 12 periods)
    Returns: dense embedding suitable for cosine/inner-product similarity
    """
    # Normalize to z-scores using running statistics
    mean = sum(rates_window) / len(rates_window)
    std = (sum((r - mean)**2 for r in rates_window) / len(rates_window))**0.5
    std = max(std, 1e-8)  # prevent division by zero
    
    normalized = [(r - mean) / std for r in rates_window]
    
    # Pad or truncate to target dimension
    if len(normalized) < dim:
        normalized.extend([0.0] * (dim - len(normalized)))
    else:
        normalized = normalized[:dim]
    
    return normalized

The question is: once you have 266,570 such embeddings (one per funding rate observation), how fast can you find the nearest historical analog to the current market state?

The Scale of the Problem#

Our funding rate database contains 266,570 observations across 20+ tokens. If each 8-hour funding period generates one embedding per token, the index grows by ~60 vectors per day. After 18 months of collection:

• Vector count: ~266K and growing
• Dimensionality: 64-128 (typical for financial embeddings)
• Query requirement: <1ms for real-time signal generation
• Update frequency: Every 8 hours per token (batch), or continuous for live price embeddings

What Our Data Shows About Search Complexity#

The funding rate dispersion data reveals why simple threshold-based detection fails and similarity search is needed:

Tokens like STABLE and SAGA have range widths exceeding 200 percentage points — a single threshold cannot capture their behavior. This is precisely where embedding-based similarity search adds value: encoding the shape of the funding rate trajectory, not just its current level.

FPGA Architecture for Vector Search#

Inner Product at Hardware Speed#

The core operation in vector similarity search is the inner product (or cosine similarity, which is a normalized inner product):

where $\mathbf{q}$ is the query vector and $\mathbf{v}_i$ is the $i$-th database vector of dimensionality $d$.

FPGAs excel at this because:

1. Massive parallelism: A Xilinx Alveo U55C has 1.3M DSP slices capable of parallel multiply-accumulate operations
2. Deterministic latency: No cache misses, no branch misprediction — fixed pipeline depth
3. Memory bandwidth: HBM2E at 460 GB/s feeds vector data fast enough to saturate compute units

Latency Model#

def estimate_fpga_latency(n_vectors: int, dim: int, clock_mhz: int = 300) -> dict:
    """
    Estimate FPGA inner-product search latency.
    
    Assumes fully unrolled inner product (dim parallel MACs),
    streaming database vectors through HBM.
    
    RELIABILITY: UNRELIABLE — model based on published benchmarks,
    not measured on target hardware. Actual latency depends on
    place-and-route, HBM bandwidth utilization, and thermal throttling.
    """
    # Each inner product: dim multiply-accumulates in 1 clock cycle (fully unrolled)
    # Throughput: 1 vector comparison per clock cycle
    throughput_per_cycle = 1
    
    # At clock_mhz, vectors processed per microsecond
    vectors_per_us = clock_mhz / 1.0  # 300 vectors/μs at 300 MHz
    
    # Total scan time for brute-force exact search
    scan_latency_us = n_vectors / vectors_per_us
    
    # Pipeline fill latency (dimension / clock * overhead)
    pipeline_fill_us = dim / clock_mhz * 0.001  # negligible
    
    return {
        "total_vectors": n_vectors,
        "dimension": dim,
        "scan_latency_us": round(scan_latency_us, 2),
        "pipeline_fill_us": round(pipeline_fill_us, 6),
        "total_us": round(scan_latency_us + pipeline_fill_us, 2),
        "reliability": "UNRELIABLE — model estimate, not measured"
    }

# Our dataset: 266K vectors, dim=64
result = estimate_fpga_latency(266570, 64)
# scan_latency_us ≈ 888.57μs — under 1ms for full brute-force scan
# This is fast but NOT sub-10μs; ANN with pruning needed for that target

Key observation: Even a brute-force FPGA scan of our entire 266K dataset completes in under 1ms. For ANN with partition pruning, sub-10μs is achievable — supporting H1 conditionally. But the "UNRELIABLE" labels matter: we have not measured these latencies on real FPGA hardware.

The Bottleneck Analysis#

Where Does Time Actually Go?#

Our production pipeline for funding-rate-based signal generation breaks down as follows:

The vector search component is not the bottleneck. Feature extraction — computing rolling statistics, normalizing across tokens, handling missing data — consumes 50-60% of the pipeline latency. This is H2's core argument: accelerating ANN alone yields diminishing returns when it represents only 15-25% of total pipeline latency.

End-to-end improvement calculation:

If FPGA reduces vector search from 200μs to 5μs (25x speedup):

• Total pipeline: 500 + 200 + 200 + 100 = 1,000μs → 500 + 200 + 5 + 100 = 805μs
• Overall improvement: 19.5%, not 25x

This is Amdahl's law in action. FPGA acceleration of vector search is worthwhile only when search dominates the pipeline — which requires either (a) much larger databases (>10M vectors) or (b) embedding computation also moved to FPGA.

Cross-Exchange Spreads: A Use Case for Fast Similarity#

The cross-exchange spread data provides a concrete use case where fast vector search could add value:

The use case: Encode the state of all cross-exchange spreads into a single vector, then search historical data for similar configurations. When spreads were in this configuration before, did they converge? How quickly? Did execution costs consume the opportunity?

This requires:

1. Real-time spread computation (fast, ~10μs)
2. Embedding into a joint state vector (fast, ~50μs)
3. Nearest-neighbor search against historical spread states (this is where FPGA helps)
4. Decision: enter arbitrage or wait?

At 266K observations, the search space is manageable. But the practical problem is that spread opportunities are ephemeral — they close in seconds, not milliseconds. A 200μs vector search on CPU is already fast enough. The bottleneck is exchange API latency (10-100ms for order submission), not search latency.

Limitations#

This paper has substantial limitations that readers must weigh:

1. No FPGA hardware validation. All latency figures for FPGA search are modeled or extrapolated from published benchmarks on different workloads. We have not deployed FPGA hardware or measured actual search latency on our dataset. The "UNRELIABLE" labels on all parameter estimates reflect this gap.

2. No end-to-end trading evaluation. With zero trades during the observation period, we cannot evaluate whether faster vector search produces better execution, tighter fills, or improved P&L. The analysis is architectural, not empirical.

3. Small database by FPGA standards. 266K vectors at dim-64 is trivially searchable on modern CPUs. FPGA acceleration becomes compelling at 10M+ vectors or dimensionality >512 — scales our system has not reached.

4. Single-system data. All funding rate and spread data comes from the Vex Capital PerpsTrader system monitoring three venues. Results may not generalize to equity markets, fixed income, or higher-frequency data environments.

5. Embedding quality unvalidated. We assume that funding rate embeddings capture meaningful regime information, but have not evaluated embedding quality against human-labeled regime annotations or validated that similar embeddings correspond to similar market outcomes.

Methodology Notes#

What We Did#

1. Extracted funding rate statistics from the PerpsTrader SQLite database (266,570 observations)
2. Computed cross-exchange spread snapshots from multi-venue price data
3. Modeled FPGA inner-product search latency using published scaling laws
4. Analyzed pipeline latency breakdown from operational experience

What We Did NOT Do#

1. Deploy FPGA hardware or measure actual search latency
2. Train embedding models on funding rate data
3. Compare similarity-based vs. threshold-based regime detection in controlled experiments
4. Execute trades based on vector search signals

Statistical Notes#

No statistical tests are reported because this is a systems analysis, not a hypothesis-testing study. The funding rate descriptive statistics (means, ranges) are computed from the full dataset with no sampling. The latency model is deterministic given its inputs; uncertainty comes from the gap between model assumptions and hardware reality.

Conclusion#

FPGA-accelerated vector similarity search is a technically elegant solution that does not yet solve a bottleneck in our trading system. The math is clear: for a 266K-vector database at dim-64, FPGA brute-force scan completes in ~889μs, and ANN approaches can reach sub-10μs. But when vector search represents only 15-25% of pipeline latency, the end-to-end improvement is modest (~20%).

What this paper IS: An honest assessment of where FPGA vector search fits in a specific trading pipeline, with real data characterizing the problem space (funding rate distributions, cross-exchange spreads) and realistic latency modeling.

What this paper IS NOT: A benchmark study, a performance claim, or a recommendation to deploy FPGA hardware. The "UNRELIABLE" labels on every latency estimate reflect genuine uncertainty.

When FPGA search will matter for trading: When embedding databases grow to 10M+ vectors (multi-year funding rate histories across 100+ tokens), when dimensionality increases to 512+ (multimodal embeddings incorporating order book, news, and on-chain data), or when search must complete within a single exchange API round-trip window (<1ms). That future is plausible but not yet present.

This paper was produced by Vex Capital Research. Every word is deliberate. Every limitation is intentional. Say less, claim less, be right.