Problem
Execution order becomes part of application quality.
Trading applications can expose market makers to stale-quote flow when taker transactions arrive before price-refresh or other critical instructions. BAM's public ACE discussion describes application-level speed bumps as one way to make that ordering explicit.
XGuard does not claim that every market needs a delay. The application must opt in and define the exact fast-path markers appropriate for its own program ABI.
Control model
One rule, three outcomes.
Unrelated flowprogram is not enrolled
normal path
0 ms
Critical marked flowexact bypass marker matched
normal path
0 ms
Protected flowenrolled application, no bypass
bounded delay
10–50 ms
Designed for
Applications where tens of milliseconds can change who absorbs the risk.
Trading applications
Application-owned scheduling rules can separate protected taker flow from explicitly marked critical updates.
Composable programs
Maximum-delay composition avoids allowing a shorter rule to become a bypass path for a longer one.
Non-goals
What XGuard deliberately does not become.
- Not a wallet, RPC endpoint, or custody layer.
- Not a transaction-signing service.
- Not a trading strategy or market-making bot.
- Not an AI classifier in the execution path.
- Not a reverse-engineered BAM production dependency.