Skip to main content
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

The security goals are concrete:
  • Availability at attack peak: ≥99.9%\geq 99.9\%
  • Core trade path (place, cancel, modify) success: ≥99.5%\geq 99.5\%
  • Legitimate-user false-positive rate: ≤0.3%\leq 0.3\%
  • Policy rollout after detection: ≤60\leq 60 seconds

​
Architecture

Traffic flows through a deliberately layered stack so an attacker has to burn through each layer in turn:
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: 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)

1

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.
2

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.
3

Tiered response

Low-risk: monitor. Medium: enhanced logging. High: rate-limit reduction. Critical: quarantine and manual review with an appeal path.
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.
Chain-side signals that feed this layer are in monitoring.