> For the complete documentation index, see [llms.txt](https://docs.lpp-minduniverse.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.lpp-minduniverse.org/lingua-pactum-protocol-lpp-documentation/8.-security-and-enforcement/8.6-replay-protection.md).

# 8.6 Replay Protection

A previously legitimate authorization must not automatically authorize a second execution.

This is the replay problem.

Suppose:

```
Action A
        ↓
ADMIT
        ↓
Permit P
        ↓
Execution succeeds
```

An attacker must not be able to reuse P indefinitely:

```
P
→ execute again
→ execute again
→ execute again
```

### Nonce

The current execution model uses a nonce or equivalent unique execution value.

Conceptually:

```
Permit_ID
+
Nonce
+
Execution Intent
```

creates a replay-sensitive authorization context.

### Permit Reuse

At verification time, the system checks whether the relevant Permit / nonce combination has already been consumed under a single-use profile.

If it has:

```
Replay detected
        ↓
Execution blocked
```

### Intent Binding

Replay protection is strengthened by binding the authorization to the intended execution hash.

A previously valid Permit must not be reusable for a different execution proposal.

### Time-Bound Authorization

Permit expiry limits the period in which stolen or copied authorization material may be presented.

Time limitation does not replace nonce enforcement.

The two address different replay dimensions.

### Terminology Boundary

Some earlier security documents describe replay resistance using language such as:

```
Reuse(AdmissionArtifact)
⇒ Deny
```

The current canonical execution model distinguishes:

* **Permit = operational execution credential**
* **Admission Artifact = evidence object**

Accordingly, GitBook v2.0 treats execution replay primarily as a Permit / nonce reuse problem.

The Artifact may later provide evidence that replay occurred.

It is not itself the normal execution credential.

### Current MVP Boundary

Replay rejection is part of the current **six core execution-scenario set**.

The demonstrated scenario is:

```
Previously consumed authorization
        ↓
Replay attempt
        ↓
DENY / execution blocked
```

This supports the current implementation claim for the tested replay path.

It does not establish universal replay resistance across every possible distributed deployment topology.

### Distributed Deployment Considerations

Distributed execution introduces additional state-coordination requirements.

If multiple executors can accept the same Permit, replay-state consistency may require mechanisms such as:

* shared consumption state,
* coordinated nonce registries,
* bounded distributed replay windows,
* or other profile-specific synchronization mechanisms.

The existing architecture identifies distributed replication and higher-assurance deployment as possible extensions.

GitBook v2.0 does not claim that the present MVP has validated all distributed replay-consistency cases.