XGuard / Security
Security model

Minimize authority. Bound every decision.

XGuard is designed to influence scheduling only for explicitly enrolled applications. It does not sign, mutate, simulate, or custody transactions or funds.

Invariants

The rules that should never be ambiguous.

  • Non-enrolled programs are never delayed by XGuard.
  • Configured delay remains within 10–50 ms.
  • Bypass requires an explicit marker on every matching top-level call.
  • Indirect / CPI-style references are handled conservatively.
  • Composed transactions use the maximum matching delay.
  • The critical-path decision is deterministic.
  • XGuard never signs, mutates, or takes custody of a transaction.
Resource bounds

Configuration is deliberately finite.

The reference engine rejects more than 4,096 application rules, more than 32 bypass markers per rule, or markers longer than 16 bytes. BAM may choose tighter production limits.

Failure behavior

Plugin faults must not become network faults.

The core itself has no external dependencies. A production adapter should preserve an operator-defined fallback so an XGuard fault cannot disrupt unrelated transaction ingestion.

Production fallback semantics must be agreed with BAM. The public reference implementation does not pretend to define operator policy for BAM nodes.
Abuse controls

Think about the registry and queue, not just classification.

Registration spam

A permissionless registry needs economic or governance controls to prevent unbounded registrations.

Delayed-pool pressure

The BAM adapter must enforce hard queue and memory limits where transaction size and scheduler pressure are visible.

Marker ambiguity

Markers use exact byte matches at explicit offsets. There is no heuristic or prefix guessing.

Report

Security contact

Responsible disclosure can be sent to mo.elayyan2023@gmail.com. The canonical security file is available at /.well-known/security.txt.