Tendex in Digital Assets: Trading Infrastructure, Market Making, and RPC Reliability

Scope: Which Tendex This Article Covers

The term tendex appears in several unrelated contexts: a black-hole visualization concept in astrophysics, a basketball efficiency formula, a B2B sales platform, a wearable exoskeleton brand, and a Swiss digital-asset trading firm. This article covers only the digital-asset trading context, where tendex refers to a Swiss-based asset manager and market maker that builds proprietary order and execution management systems for crypto markets.

The public material from that firm describes three product areas: market making and liquidity provision for selected partners, a market-neutral quantitative fund, and custom strategy implementation. It also describes order and execution management systems designed to complete trades at the best available prices across multiple venues and product types. Those are documented claims about the firm's own stack, not benchmarks you can verify from outside.

This article does not reproduce proprietary performance figures, fund returns, or venue lists. Instead it explains the infrastructure patterns such a stack implies and gives you a reproducible method for measuring the parts you can control, especially RPC reliability.

• Covered: tendex as a digital-asset trading and market-making operation.
• Not covered: the astrophysics tendex line, the basketball Tendex statistic, the B2B sales platform, or the exoskeleton brand.
• Documented behavior is separated from recommendations and from measurements you must run yourself.

Prerequisites and Assumptions

The procedures below assume you have a working knowledge of HTTP APIs, a shell with curl, and either Node.js or Python for the longer scripts. You need at least one RPC endpoint you are authorized to query, represented here as RPC_URL. If you are evaluating providers rather than a single endpoint, collect several candidate URLs and run the same procedure against each.

You should also know which chain and which methods your strategy actually depends on. A market-making system that only reads prices from centralized venues has very different RPC requirements from one that settles on-chain, monitors mempools, or submits transactions. Write down the methods you call and the latency budget for each before measuring anything.

Finally, assume that any single endpoint can fail. The measurement procedure is designed to expose failure modes, not to prove that an endpoint is perfect.

Mental Model: Where RPC Sits in a Trading Stack

A digital-asset trading stack typically has four layers: market data ingestion, strategy and risk, order and execution management, and settlement or custody. RPC nodes sit at the boundary between the strategy layer and the chain. They serve reads such as balances, nonces, and contract state, and they relay writes such as signed transactions.

For a market maker, the critical path is usually latency-sensitive reads and reliable writes. A stale balance read can cause an order to be rejected; a delayed transaction broadcast can cause a fill at an unintended price; a nonce mismatch can stall an entire account. For a market-neutral fund, the critical path is often consistency across venues and instruments, so the ability to reconcile on-chain state with off-chain positions matters more than raw throughput.

The practical implication is that RPC reliability is not a single number. It is a profile of latency, error rate, consistency, and recovery behavior under the specific method mix your strategy uses.

• Read-heavy strategies care about latency percentiles and cache freshness.
• Write-heavy strategies care about broadcast success, nonce handling, and replacement behavior.
• Cross-venue strategies care about consistency between on-chain state and venue state.

Documented Tendex Capabilities Versus Your Own Measurements

Public descriptions of tendex emphasize proprietary order and execution management systems, integrations that allow quoting across multiple instrument types, and tooling used within its investment products. These are statements about the firm's internal stack. They do not tell you what latency you will see, what error rate is acceptable, or which RPC provider will serve your strategy.

Treat documented capabilities as context for the architecture you might build, not as evidence about your own environment. The measurements that matter are the ones you run against your endpoints with your method mix and your traffic profile.

The table below is a template. Fill it with values from your own runs; do not copy numbers from any article, including this one.

• Documented: proprietary OEMS, multi-venue quoting, market-neutral fund, custom strategies.
• Recommended: measure latency percentiles, error rate, and consistency per method.
• Measured by you: all numeric values in your results table.

Results Table Template for RPC Evaluation

Use a Markdown table like the one below to record results. Run each method at least a few hundred times across different times of day, and record p50, p95, and p99 latency, error rate, and any consistency failures. Leave cells blank until you have real data.

| Endpoint | Method | Samples | p50 (ms) | p95 (ms) | p99 (ms) | Error rate | Consistency failures |

| --- | --- | --- | --- | --- | --- | --- | --- |

| RPC_URL_A | eth_getBalance | | | | | | |

| RPC_URL_A | eth_sendRawTransaction | | | | | | |

| RPC_URL_B | eth_getBalance | | | | | | |

| RPC_URL_B | eth_sendRawTransaction | | | | | | |

The consistency column is where you record cases where two reads of the same state returned different results within a short window, or where a transaction was accepted but not visible after a reasonable delay. Those failures matter more than average latency for execution systems.

Runnable Diagnostic: Latency and Error Rate with curl

Start with a simple loop that measures round-trip time and HTTP status for a read method. This gives you a first-order view of latency and error rate without any dependencies.

Run it against each candidate endpoint and save the output. The script below uses a placeholder RPC_URL and a JSON-RPC payload for eth_blockNumber, which is cheap and widely supported.

for i in $(seq 1 50); do
  start=$(date +%s%3N)
  status=$(curl -s -o /tmp/rpc_out.json -w "%{http_code}" \
    -X POST "$RPC_URL" \
    -H "Content-Type: application/json" \
    -d '{"jsonrpc":"2.0","id":1,"method":"eth_blockNumber","params":[]}')
  end=$(date +%s%3N)
  echo "$i $status $((end-start))"
done

Runnable Diagnostic: Percentiles and Consistency in Python

The curl loop gives you raw samples. A short Python script turns them into percentiles and checks consistency by comparing repeated reads of the same block. This is the procedure you should adapt to your own method mix.

The script below uses only the standard library plus requests. Replace RPC_URL and adjust the method list to match your strategy. Record the output in the results table above.

import time, statistics, requests

RPC_URL = "RPC_URL"
METHODS = ["eth_blockNumber", "eth_getBalance"]
SAMPLES = 200

def call(method, params):
    payload = {"jsonrpc":"2.0","id":1,"method":method,"params":params}
    start = time.perf_counter()
    r = requests.post(RPC_URL, json=payload, timeout=5)
    elapsed = (time.perf_counter() - start) * 1000
    return r.status_code, elapsed, r.json()

for method in METHODS:
    params = [] if method == "eth_blockNumber" else ["0x0000000000000000000000000000000000000000", "latest"]
    latencies, errors = [], 0
    for _ in range(SAMPLES):
        try:
            status, ms, body = call(method, params)
            latencies.append(ms)
            if status != 200 or "error" in body:
                errors += 1
        except Exception:
            errors += 1
    latencies.sort()
    p50 = statistics.median(latencies)
    p95 = latencies[int(len(latencies) * 0.95) - 1]
    p99 = latencies[int(len(latencies) * 0.99) - 1]
    print(method, "p50", round(p50,1), "p95", round(p95,1), "p99", round(p99,1), "errors", errors)

Expected Verification Result

A healthy endpoint should return HTTP 200 with a valid JSON-RPC result for every sample, and latency percentiles should be stable across runs. If you see p99 latency far above p50, or intermittent errors, the endpoint is not suitable for execution-critical paths without a fallback.

For consistency, repeated reads of the same block height should return identical results. If they do not, record the discrepancy and investigate whether the endpoint is load-balanced across nodes with different states.

Do not treat a single successful run as proof. Repeat the procedure at different times of day and under load that resembles your production traffic.

Troubleshooting Common Failure Modes

The most common failure modes in trading RPC usage are nonce mismatches, stale reads, rate limiting, and silent failover to a lagging node. Each has a different signature in your measurements.

Nonce mismatches usually appear as rejected transactions with a nonce error. Stale reads appear as balances or block numbers that lag behind other endpoints. Rate limiting appears as HTTP 429 responses clustered under load. Silent failover appears as consistency failures where the same query returns different results within a short window.

For each failure mode, decide whether your strategy can tolerate it. A market maker may accept occasional stale reads if it has a reconciliation loop, but it cannot tolerate nonce mismatches that stall an account.

• Nonce errors: check pending transaction handling and replacement logic.
• Stale reads: compare block height across endpoints before trusting a balance.
• Rate limiting: measure error rate under realistic concurrency, not single requests.
• Consistency failures: log the block height and result for every read.

Limitations and Tradeoffs

No RPC endpoint is perfect. Higher reliability usually costs more, and dedicated infrastructure trades flexibility for control. A single endpoint is simpler to operate but has no redundancy; a pool of endpoints adds complexity and requires consistency checks.

The measurement procedure in this article is a starting point, not a complete evaluation. It does not cover mempool monitoring, transaction replacement, or cross-chain behavior. If your strategy depends on those, extend the method mix and rerun the procedure.

Finally, public descriptions of any trading firm's stack, including tendex, are not a substitute for your own architecture review. Use them as context, then measure your own environment.

Next Steps: From Measurement to Infrastructure Choice

Once you have a results table, the next step is to decide whether you need shared endpoints, dedicated nodes, or a mix. Shared endpoints are appropriate for read-heavy, latency-tolerant workloads. Dedicated nodes are appropriate when you need predictable performance and control over the node software.

For concrete endpoint and provider recommendations, use the RPC Assistant rather than this article. For background on node hosting and endpoint design, see the Learn guides on blockchain node hosting and multi-chain RPC endpoints.

If you are evaluating OnFinality specifically, review the API service, RPC pricing, supported networks, and dedicated node pages, then run the measurement procedure against the endpoints you are considering.

• Start with the RPC Assistant for endpoint and provider choices.
• Use Learn guides for architecture and measurement background.
• Rerun the procedure after any infrastructure change.