> ## Documentation Index
> Fetch the complete documentation index at: https://docs.intention.xyz/llms.txt
> Use this file to discover all available pages before exploring further.

# DDoS and Sybil Defense

> Network-edge and address-level protections that keep Intention responsive under attack.

This page is for validator operators, edge-infrastructure engineers, and integrators who need to understand how Intention survives flooding and identity attacks. An L1 with protocol-native trading is doubly exposed: both the public RPC surface and the matching engine behind it are hot paths. The design assumes an attacker will try every axis — connections, requests, methods, addresses — and defends each independently.

## Threat model

| Class             | Entry point         | Technique                                                    | Impact                                             |
| ----------------- | ------------------- | ------------------------------------------------------------ | -------------------------------------------------- |
| Connection flood  | TCP, WebSocket      | Rapid connects, slowloris, handshake stalls                  | fd and thread exhaustion                           |
| Request flood     | REST, JSON-RPC      | High-frequency calls, batch abuse                            | CPU and memory pressure, p99 spike                 |
| Method exhaustion | Expensive endpoints | Scripted heavy queries                                       | Single method takes down a service                 |
| Retry storm       | Any                 | Clients retry infinitely after errors                        | Attacker and legitimate traffic amplify each other |
| Address farming   | Multiple addresses  | Split load across many addresses to dodge per-address limits | Bypass address budget                              |
| Role infiltration | Validator or proxy  | Cheap identity registration                                  | Consensus instability                              |

The security goals are concrete:

* Availability at attack peak: $\geq 99.9\%$
* Core trade path (place, cancel, modify) success: $\geq 99.5\%$
* Legitimate-user false-positive rate: $\leq 0.3\%$
* Policy rollout after detection: $\leq 60$ seconds

## Architecture

Traffic flows through a deliberately layered stack so an attacker has to burn through each layer in turn:

```
Internet
  -> Edge Gateway (WAF, L4/L7 load balancer)
  -> API Gateway
      -> Rate Limit Service (Redis-backed)
      -> Sybil Risk Engine
      -> Policy Center
  -> Trade API Service
  -> Node / Sequencer / Validator Network
  -> Observability (Prometheus, ClickHouse, alerting)
```

Key principles: block as far forward as possible, fail each layer independently, hot-update policies, and write every block action to an audit log.

## Connection-layer defense

The edge enforces:

| Control                          | Default  |
| -------------------------------- | -------- |
| New connections / sec / IP       | 20       |
| Concurrent connections / IP      | 120      |
| New WS connections / minute / IP | 40       |
| Total WS connections / IP        | 12       |
| TLS handshake timeout            | 3,000 ms |
| Ban duration on severe abuse     | 600 s    |

Mild breaches return `429` with `Retry-After`. Moderate breaches drop the IP into a graylist at 20% throttle for 10 minutes. Severe breaches blacklist the IP and fire a security alert.

## Request-layer defense

Every request passes four token buckets at once: global, per-IP, per-address, and per-method. Endpoint weights reflect actual cost — trade actions are 1, account reads are 5, heavy history scans are 20, full snapshots are 40.

## Congestion fair-share

When the engine is genuinely saturated, scheduling flips from first-come to maker-share-weighted. Each address is allowed up to `block_capacity * 2 * maker_share` orders per block, so the participants who supply liquidity get the room to manage risk during a crisis. The rule explicitly reverses the "who has the fastest server wins" arms race.

## Sybil controls (V1)

<Steps>
  <Step title="Economic floors">
    High-privilege roles (validator, signer, some bot profiles) require a minimum stake and a cooldown. The goal is not to stop Sybils but to make them expensive enough to be uninteresting.
  </Step>

  <Step title="Relationship analysis">
    A rules engine flags addresses that share funding origin, operate in tight temporal lockstep, or exhibit wash-trade patterns. Flagged addresses are tagged for enhanced monitoring.
  </Step>

  <Step title="Tiered response">
    Low-risk: monitor. Medium: enhanced logging. High: rate-limit reduction. Critical: quarantine and manual review with an appeal path.
  </Step>
</Steps>

<Warning>
  Policy thresholds are runtime-configurable and can be rolled back. Every block action — 429, graylist, blacklist, Sybil flag — is logged for audit and for user appeal.
</Warning>

<Info>
  Chain-side signals that feed this layer are in [monitoring](/validators/monitoring).
</Info>