Latency-Positive ATF

“Doesn’t a firewall make my bot slower?”

That is the natural assumption. Every middleware layer adds processing time, and trading bots compete on execution speed. Any overhead feels like a cost.

The assumption holds if you measure only middleware overhead in isolation. But it breaks down when you measure total workflow latency - the time from intent formation to on-chain submission.

Not if the firewall becomes shared execution intelligence

A standalone bot must independently fetch account state, request DEX quotes, validate routes, simulate transactions, run its own safety checks, sign, and submit. Every bot does this work alone, even when multiple bots need the same data.

ATF serves multiple agents. It maintains shared on-chain state, caches recent quotes, batches overlapping account reads, parallelizes external calls, and pre-computes policy-relevant data. When ATF eliminates more redundant work than its enforcement overhead costs, the protected bot finishes faster.

The correct benchmark is effective time-to-execution versus a bot doing everything itself - not middleware overhead in isolation.

Understanding Latency Types

“Latency” in a trading bot workflow is not one number. It decomposes into distinct components, and ATF affects each differently:

Execution Modes - Strict / Balanced / Turbo

ATF defines three execution modes that let operators choose their position on the safety–speed spectrum. All three modes satisfy the same zero-trust security invariants. The difference is how much pre-computed work is reused, not whether safety checks run.

Freshness values are illustrative. These modes represent a directional design - not current production capabilities.

How Latency-Positive Enforcement Works

The flow below shows how shared intelligence reduces total workflow time:

Standalone Bot (no ATF)              Protected Bot (with ATF)
─────────────────────                ─────────────────────────
1. Fetch account state  ─── RPC     1. Submit intent to ATF
2. Fetch DEX quotes     ─── API         ↓
3. Validate route       ─── RPC     2. ATF serves from shared state
4. Simulate transaction ─── RPC        (cached accounts, quotes,
5. Run safety checks    ─── local      route validation, simulation)
6. Sign                 ─── local       ↓
7. Submit               ─── RPC     3. Policy evaluation (fast-path
                                       if intent is well-classified)
Each bot does all 7 steps               ↓
independently every time.           4. Permit issued
                                        ↓
                                    5. Bot signs + submits

                                    Shared state eliminates
                                    redundant RPC/API calls.

How We’ll Measure This

Latency-positive claims require rigorous measurement, not marketing assertions. ATF will instrument and report:

• cache-hit p95 - fast-path decision latency
• cache-miss p95 - worst-case decision latency
• time-to-safe-decision - intent receipt to permit issuance
• time-to-submission - intent receipt to transaction readiness
• effective bot-latency delta - protected workflow minus standalone baseline

The standalone bot baseline is measured per-flow: the estimated time for an unprotected bot to independently complete the same work. All benchmark results will clearly distinguish measured data from illustrative estimates.

Why This Matters for Trading Bots and Agent Frameworks

Trading bots evaluate infrastructure by one question: does it make me better at my job? “Safer but slower” is a hard sell. “Safer and faster” changes the adoption calculus entirely.

• For bot developers: ATF becomes infrastructure you route through for speed, not infrastructure you tolerate for compliance.
• For agent frameworks: Enforcement stops being a bolt-on cost center and becomes a shared execution layer that improves framework-wide performance.
• For operators: Configurable execution modes let you tune the safety–speed tradeoff per strategy, not per-org.

The long-term vision: ATF as universal capital enforcement for AI agents - deterministic, verifiable, and latency-positive.

Current State vs. Future Direction

This page describes a strategic direction, not shipped capabilities. Here is where things stand:

Security guarantees are non-regressible. No latency optimization will weaken, bypass, or conditionally disable existing deterministic enforcement or verifiable receipts.

Learn More

• ATF Architecture & Enforcement Model - threat model, permit schema, deterministic checks
• First Protected Trade - try ATF in minutes
• Integration Pattern - how agents call ATF before execution

This page is the developer-friendly explainer. For high-level public positioning, see the ATF spec - Latency-Positive Positioning.