Request abuse and replay protection
Development status: Experimental implementation exists — An experimental implementation exists; this page describes the intended public developer capability. The experimental node’s request interface applies per-caller rate limiting and basic request-replay checks; authentication and broader abuse-resistance controls are planned, and keeping protocol messages to their intended context and time window is being explored. The experimental interface is internal, must not be treated as authenticated and must not be relied on for security, and nothing is publicly available for live use.
Before you read: Security model, trust and limitations.
How are interfaces protected from abuse, and how are messages kept from being reused in another context? This page separates two problems — abuse of an interface and replay of messages — and for each states what exists experimentally, what is planned or being explored, and what applications and operators should expect. Protections are named at concept level; values and constructions are not described.
Two different problems
- Interface abuse: callers sending more requests than a node can reasonably serve, or malformed requests, so that service degrades for others.
- Replay: a previously valid request or message being sent again so that it is processed twice, or being used in a context or at a time it was not meant for.
Rate limiting addresses the first problem; replay checks and message scoping address the second. Neither is a complete defence, and both would sit alongside the other intended defences described on Threat model and misbehaviour defences.
Table: protections by problem, with the status of each today.
| Problem | Protection | Status today |
|---|---|---|
| Interface abuse | Per-caller rate limiting | Experimental implementation exists — basic and internal |
| Interface abuse | Broader abuse-resistance controls | Planned |
| Knowing who is calling and what they may do | Authentication and authorisation | Planned |
| Replay | Basic request-replay checks on the experimental request interface | Experimental implementation exists — basic and internal |
| Replay | Keeping protocol messages to their intended context and time window | Being explored |
Per-caller rate limiting
Status of this section: Experimental implementation exists — basic and internal; details are not described.
- The experimental node’s request interface limits how often each caller can make requests.
- Limits, time windows, how callers are told apart and what happens when a limit is reached are not described.
- It is not a claim of resistance to large-scale or coordinated abuse.
- Rate limiting of requests is different from the admission of work under load, which is described on Service levels and admission control.
Basic request-replay checks
Status of this section: Experimental implementation exists — basic and internal; how the checks work is not described.
- The experimental request interface applies basic checks that reject some repeated requests.
- “Basic” means exactly that: no claim of complete or lasting protection against replay is made, and how the checks work is not described.
- These checks concern requests to the experimental interface. They are not a claim that transactions are protected against replay; passing a node’s initial checks is not a protection against replay either. See Transaction lifecycle: from submission to result.
- Applications would not be able to rely on these checks to prevent duplicates in their own logic.
Authentication and authorisation
Status of this section: Planned — not available.
- Authentication — checking who is calling — and authorisation — checking what that caller may do — are planned for interfaces.
- Broader abuse-resistance controls are also planned.
- Until these are released, the experimental interface must not be treated as authenticated or access-controlled. It is internal and not publicly reachable.
- How callers would identify themselves is not described.
Keeping messages to their intended context and time window
Status of this section: Being explored — not part of any released network.
- The design is being explored so that protocol messages and commitments are scoped to their intended context and time window.
- The aim is that a message valid in one context or time window would not be accepted in another.
- How scoping would work is not described.
What applications and operators should expect
Status of this section: Planned developer experience — conditional on interfaces being implemented, enabled and publicly released.
- Refused requests. Once interfaces are released, applications would be expected to cope with refused requests by retrying later at a reduced rate, rather than immediately.
- Duplicates. Applications would be expected to make their own operations safe to repeat where duplicates matter, rather than relying on replay checks in the network. An operation is safe to repeat when carrying it out twice has the same effect as carrying it out once.
- Failure categories. Refused and rejected requests are among the failure categories described on What can go wrong: failure and error concepts. Exact error codes are not yet available.
- Operators. Operator-facing settings for these protections are not yet specified.
Both expectations can shape a design today, because neither depends on details that are still unsettled.
Assumptions, trust and limitations
- Experimental protections are internal and basic, and no independent audit results are published for them.
- Per-caller limits alone do not address abuse spread across many callers.
- The experimental implementation is an early prototype and must not be relied on for security.
Not yet available, and how this page will grow
Exact limits, error responses and authentication methods are not yet available, and further technical reference is not yet available. Once an interface is released, its reference would state the supported protections together with its version identity; see Interfaces and their status. Status changes would be recorded in the Documentation change log.
What this page does not claim
This page does not claim:
- resistance to denial-of-service or coordinated abuse;
- an authenticated or access-controlled interface;
- complete or lasting replay protection;
- any limit values.
Anything not stated here as available or assured should be treated as neither.
Related pages
- Service levels and admission control — admission of work under load, as distinct from request rate limiting.
- What can go wrong: failure and error concepts — failure categories, including refused and rejected requests.
- Cryptographic foundations and trust roots — the cryptography that protections would build on.
- Interfaces and their status — which interfaces exist experimentally and their status.
- Transaction lifecycle: from submission to result — what initial checks on transactions do and do not mean.
- Threat model and misbehaviour defences — the wider set of intended defences.
Glossary
References
No approved public references yet.
