# SAAX Security

*Last updated: 2026-10-06*

SAAX is experimental software. This document describes the security posture of the SAAX Protocol and the SAAX Router, the threats they are designed to defend against, and how to report a vulnerability.

## Scope

SAAX protects four properties:

- **Commitment integrity** — a commitment record, once issued, cannot be silently altered; its terms, parties, evidence, and references are attributable and auditable.
- **Settlement correctness** — value moves only when the settlement requirement of a valid commitment is satisfied, and moves exactly as the commitment specifies.
- **Reputation integrity** — reputation signals are derived from verifiable on-chain behavior and signatures, not from self-declared claims.
- **Availability of the routing layer** — the routing service remains responsive to legitimate requests under load and resets cleanly after overload or operator action.

## Threat model

SAAX defends against the following attack classes. They are described generically; the precise controls are shared with operators and reviewers under coordinated disclosure.

- **Duplicate charges** — an attacker replays a payment authorization to extract value more than once. Mitigated by idempotency keys bound to each commitment.
- **Gas abuse and denial of service** — an attacker floods the routing layer with requests to exhaust computational or network resources. Mitigated by per-origin rate limiting.
- **Nonce replay** — an attacker replays a signed transfer authorization whose nonce has already been consumed. Mitigated by nonce-bound idempotency: each authorization is tied to a unique nonce and can settle at most once.
- **Spoofed buyer reputation** — an attacker fabricates a reputation signal for an address they do not control. Mitigated by deriving reputation from signatures and on-chain records rather than claimed identity.
- **Signature forgery** — an attacker forges an authorization or attestation. Mitigated by typed, domain-separated signature schemes (EIP-712) and contract scanning that is aware of proxy upgrade patterns.
- **Prompt injection via untrusted input** — an attacker embeds instructions in free-text fields that a downstream system might execute. Mitigated by a sanitization gate that strips control content from untrusted input before it is processed.
- **Supply-side fraud** — a provider advertises capabilities it cannot deliver. Mitigated by a capability floor and reputation weighting that ranks providers on verified performance rather than self-declaration.
- **Credential leakage** — an operator's secret material is exposed to the network. Mitigated by a non-custodial design: the protocol never requires buyer funds to be held by the routing layer, and secret material is handled under a non-leakage architecture.

## Mitigations in place

The following controls are deployed on the live routing service:

| Control | What it does |
|---|---|
| Idempotency | Duplicate requests carrying the same idempotency key return the cached response and do not re-process value movement. |
| Rate limiting | Requests in excess of the per-origin window are rejected with HTTP 429. |
| Nonce-bound settlement | Payment authorizations are bound to unique nonces; a spent nonce cannot be replayed. |
| Signature-derived reputation | Reputation resolves from signatures and on-chain feedback, not from claimed identity or client-supplied headers. |
| Typed verification | Authorizations use typed, domain-separated signing (EIP-712); contract interactions are scanned with proxy-upgrade awareness. |
| Input sanitization | Untrusted fields are sanitized at the boundary; empty or malformed payloads are rejected with HTTP 422. |
| Trusted-proxy handling | When deployed behind a reverse proxy, client addressing is read from the proxy-provided header so rate limits cannot be bypassed by proxy rotation. |
| Kill switch | An operator-controlled halt returns HTTP 503 before any value movement or external call. |

These descriptions are intentionally generic: they state what is protected, not the internal mechanics of how.

## Residual risks

SAAX does not fully eliminate the following risks, and users should assume they exist:

- **Smart contract risk** — the settlement contracts and the tokens they move may contain undiscovered defects; on-chain behavior is final.
- **Key compromise at the user layer** — if a participant's own keys are compromised, no protocol control can prevent loss.
- **Censorship and liveness** — routing availability depends on the operators of the routing node and on the Base network; neither SAAX nor any user can force either to remain available.
- **RPC dependency** — settlement correctness depends on the RPC providers serving on-chain data; a malicious or degraded provider can delay or distort observed state.
- **Reputation gaming** — colluding parties can manufacture on-path reputation over time; reputation weighting reduces but does not eliminate this.
- **Social engineering** — operators and integrators can be induced to misconfigure deployments; no technical control fully prevents operator error.

## Out of scope

SAAX is not designed to protect against:

- Compromise of a user's own private keys or wallet software.
- Malicious behavior of counterparties that is outside the commitment's terms (e.g., off-protocol fraud, delivery of defective goods despite passing acceptance criteria).
- Financial loss from market movement, token volatility, or failed external systems.
- Legal or regulatory consequences of using the protocol in a given jurisdiction.
- Attacks on the underlying networks (Base), the USDC contract, or the RPC infrastructure SAAX depends on.
- Losses arising from user error, including sending funds to the wrong address or misreading commitment terms.

## Reporting a vulnerability

If you believe you have found a security issue in SAAX, please report it by email:

**security: security@saax-protocol.com**

Please include in your report:

- A description of the vulnerability and its impact.
- The component affected (protocol, routing service, contracts, or docs).
- Steps to reproduce, including any payloads or request sequences.
- Your contact details if you would like a reply.

What we commit to:

- **Acknowledgment** within five business days of receipt.
- **Triage and a first response** within ten business days.
- **Coordinated disclosure** — we will work with you on a disclosure timeline (typically up to 90 days) before public discussion, unless the issue is already public or being actively exploited.

Do not test against production accounts, live funds, or the mainnet settlement contracts beyond what is necessary to demonstrate an issue. Use small amounts. Reports are handled under best-effort, non-guaranteed timelines; this is experimental software maintained by a small team.

*— SAAX Protocol*