> For the complete documentation index, see [llms.txt](https://shakestock.gitbook.io/whitepaper/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://shakestock.gitbook.io/whitepaper/anti-cheat-system.md).

# Anti-Cheat System

The multi-layer anti-cheat system used to limit automated shaking, duplicate accounts, abnormal activity, and reward abuse.

SHAKESTOCK does not rely on one signal to determine whether activity is legitimate. The current design combines a movement threshold, event debounce, a daily activity cap, device fingerprinting, IP rate limiting, and Telegram identity verification.

These controls operate at different levels. Together, they are designed to make automated abuse harder. They do not make cheating impossible.

### Threat model

The anti-cheat layer is intended to limit automated shaking, scripted input, rapid repeated events, multiple accounts on one device, excessive request volume, and fake or artificial movement.

| Threat                   | Relevant control                             |
| ------------------------ | -------------------------------------------- |
| Automated movement       | Shake threshold and future ML classification |
| Event spamming           | 800 ms debounce                              |
| Excessive daily activity | 500-shake daily cap                          |
| Multi-account abuse      | Device fingerprint                           |
| Request flooding         | IP rate limit                                |
| Identity abuse           | Telegram identity verification               |

### Phase 1: Current controls

Whitepaper v1.1 identifies the following rule-based controls as current Phase 1 protections.

#### 1. Shake threshold

**15 m/s²**

A shake event must reach the defined 15 m/s² threshold. The threshold rejects movement that does not meet the intended intensity requirement.

The source specifies threshold behavior only. It does not define a sensor API, accelerometer model, sampling frequency, axis calculation, or operating-system implementation.

#### 2. Debounce

**800 ms**

The debounce window prevents repeated shake events from being registered too rapidly. This makes high-frequency event spamming harder.

The whitepaper does not specify the implementation mechanism for this window.

#### 3. Daily cap

**500 shakes per user per day**

The daily cap limits how many shake events can generate rewards for a user within a day. It is both a reward-economy constraint and an anti-abuse constraint.

This prevents unlimited reward generation through automated input alone.

{% hint style="info" %}
The 500-shake daily cap is part of the shake and reward system. It is separate from the **$10 per user per day** stock-claim limit enforced by the smart contract.
{% endhint %}

#### 4. Device fingerprint

The source defines the device rule as **1 phone = 1 account**. Device fingerprinting creates a device-level uniqueness constraint intended to make multi-account abuse harder.

The whitepaper does not specify the fingerprinting algorithm, identifier format, or persistence mechanism.

#### 5. IP rate limit

IP-level rate limiting adds a control against excessive request activity. It complements movement and device-level checks with a network-level boundary.

No requests-per-second value, timeout, geographic rule, VPN detection, or proxy detection is specified.

#### 6. Telegram identity verification

Telegram identity verification adds an account-level identity signal to the anti-cheat system. It connects activity to the user's Telegram identity context.

This is not KYC. The source does not define Telegram API methods, OAuth behavior, cryptographic signature flows, or biometric verification.

### Detection pipeline

The following is a conceptual representation of the layered controls described in the whitepaper. It shows their relationship. It does not imply every check runs within one synchronous function.

```
Phone movement
  ↓
Movement threshold
  ↓
Debounce check
  ↓
Shake event accepted
  ↓
Daily cap check
  ↓
Device / account check
  ↓
IP rate limit
  ↓
Telegram identity context
  ↓
Shake Coin reward
```

A valid shake can result in a Shake Coin reward. Invalid or rejected activity produces no valid reward event. The source does not define the exact rejection response or backend behavior.

### Parameter reference

| Control            | Parameter                   | Purpose                            |
| ------------------ | --------------------------- | ---------------------------------- |
| Shake threshold    | 15 m/s²                     | Reject insufficient movement       |
| Debounce           | 800 ms                      | Prevent rapid event spam           |
| Daily cap          | 500 shakes/user/day         | Limit reward generation            |
| Device fingerprint | 1 phone = 1 account         | Reduce multi-account abuse         |
| IP rate limit      | Defined control             | Limit excessive request activity   |
| Telegram identity  | Required verification layer | Bind activity to Telegram identity |

### Off-chain security boundary

The controls on this page belong to the application and user-interaction layer. They determine how activity becomes eligible for Shake Coin accounting.

| Anti-cheat layer                                             | Blockchain layer                                                                                            |
| ------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------- |
| Movement, device, IP, Telegram identity, and activity limits | Stock claim transaction, smart-contract claim limit, replay protection, token state, and transaction record |

Anti-cheat does not replace smart-contract security. The anti-cheat layer controls Shake Coin earning. The smart-contract layer controls the on-chain stock claim.

Shake Coins remain off-chain points. They are not an ERC-20 token and are not transferred on-chain as part of a stock claim.

### Phase 2: Machine learning detection

**Future / later phase**

The whitepaper describes a machine learning model intended to distinguish real from fake movement. It is intended to classify stationary, walking, jogging, biking, and vehicle movement.

The described intent is to accept jogging and real shake activity. It is intended to reject a phone on a table, a phone in a pocket, and driving.

This phase aims to distinguish legitimate movement from patterns associated with artificially generated rewards. The source does not specify a model architecture, dataset size, inference location, feature set, confidence threshold, or deployment status.

### Phase 3: Custom anti-cheat model

**Future phase**

The whitepaper proposes a custom model trained on real shake data and cheat data. It references Sweatcoin's large-scale movement data and ML approach as inspiration.

This reference does not mean SHAKESTOCK has billions of data points or a production ML model today. The custom model remains future-facing.

### Current and future controls

| Layer                           | Current | Future                    |
| ------------------------------- | ------- | ------------------------- |
| Movement threshold              | Yes     | Refined by ML             |
| Debounce                        | Yes     | Remains foundational      |
| Daily cap                       | Yes     | Remains foundational      |
| Device fingerprint              | Yes     | May support model signals |
| IP rate limit                   | Yes     | Remains foundational      |
| Telegram identity               | Yes     | Remains foundational      |
| ML movement classification      | No      | Phase 2                   |
| Custom trained anti-cheat model | No      | Phase 3                   |

### Why multiple layers

Each control limits a different abuse pattern. The threshold addresses weak movement. Debounce limits rapid event repetition. The daily cap bounds total reward generation.

Device fingerprinting makes one-device multi-account use harder. IP rate limiting limits excessive request volume. Telegram identity verification adds account context. Future ML adds behavioral movement classification.

No individual control covers every case. The system uses these overlapping boundaries rather than treating any one control as complete.

### Limitations

The current Phase 1 system is rule-based. No anti-cheat system guarantees perfect detection.

Future ML phases are intended to improve movement classification. Device and IP controls resist abuse, but they are not absolute identity proofs.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://shakestock.gitbook.io/whitepaper/anti-cheat-system.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.