> For the complete documentation index, see [llms.txt](https://gothamcash.gitbook.io/bindowscash/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://gothamcash.gitbook.io/bindowscash/protocol/security-measures.md).

# Security Measures

BindowsCash is designed with a strong emphasis on security, simplicity, and resilience. There is an overview of the technical and architectural safeguards in place to protect users, their funds, and the system as a whole.

***

### 1. ✅ Smart Contract Simplicity

The core pool contract are intentionally kept **minimal** and **auditable**:

* No external dependencies beyond a lightweight internal `ECDSA` utility.
* No use of proxy patterns, upgradability, or complex inheritance trees.
* Each pool handles a **fixed denomination** (e.g., 0.1 BNB).
* Hardcoded:
  * Deposit amount
  * Fee rate (1%)
* No **admin pause**, backdoor, or reentrancy toggles — deposits and withdrawals **cannot be frozen**.

🧩 Simplicity reduces the attack surface and makes auditing easier.

***

### 2. 🧾 No Sensitive Data Stored On-Chain

* User secrets are generated **off-chain** and are never exposed to the blockchain.
* The contract only stores:
  * `commitments` (a SHA256 hash of a random secret)
  * A `nullifiers` mapping to mark withdrawals and prevent reuse
  * A timestamp (for statistics only)
* Even a full blockchain inspection or node operators cannot link deposits to withdrawals.

🔐 BindowsCash enforces **privacy by design** — not by obfuscation.

***

### 3. 🔒 One-Time Withdrawals with Nullifiers

Each note is derived from a **unique secret**:

* Once revealed during withdrawal, its corresponding `commitment` is marked as:
  * **Spent** (`nullifier` set to true)
  * **Removed** from active commitments
* Notes are strictly **non-reusable**.
* This prevents double-spending and replay attacks.

***

### 4. ✍️ Signature-Based Withdrawal

Unlike several other mixers, our protocol enforces **authorization through signatures only**:

* To withdraw, a user must **sign the note** (off-chain).
* The contract verifies that the message was signed by the legitimate secret owner.
* This protects against:
  * Front-running
  * Address hijacking
  * Automated bot interception (MEV)
* The contract verifies this via ECDSA before allowing a withdrawal.

🧾 This step ensures **only the legitimate owner** can withdraw, and only **once authorized**.\
💡 The signature proves intent, even if the transaction is relayed by a third party.

***

### **5. ❌ Rejecting Direct BNB Transfers**

* The contract has **no receive() or fallback()** function.
* Any BNB sent without calling `deposit()` will be **rejected** (transaction reverted).
* This prevents:
  * Accidental fund loss
  * Malicious attempts to interfere with the contract balance

✅ Only valid, verifiable deposits are accepted.

***

### 6. 🛡️ Strict Access Control

Only the contract **owner** can:

* Receive half of the 1% fee (via `setFeesEnabled(bool)`).

The owner **cannot**:

* Change fee **rate** (always 1%) or the address receiving these fees.
* Access user funds directly.
* Withdraw the funds of a pool.
* Pause deposit/withdrawals.
* Modify commitments or nullifiers arbitrarily.
* View your secrets.

All withdrawals are still enforced by cryptographic secrets + signatures.

***

### 7. 🛡️ Signature Verification Logic

* The contract includes a **lightweight internal ECDSA module** to verify signatures:
  * Uses Ethereum’s `ecrecover` to authenticate the signer of a message.
  * Ensures that only the legitimate user (who knows the secret) can trigger a withdrawal.
* Signatures are not stored on-chain — they are used **ephemerally** during withdrawal only.

🧠 This ensures gasless relayers or public broadcasters cannot steal user funds.

***

### 8. 🔍 Transparent Events & Auditable State

All major action emits a clear event:

* `Deposit(bytes32 commitment, timestamp)`
* `Withdrawal(address recipient, bytes32 nullifier)`

All interactions are **public**, **traceable**, and **verifiable** via BscScan or any block explorer. No hidden logs or opaque behaviors. But in order to ensure privacy on-chain, your commitment & nullifier are encrypted. 

📊 Full on-chain traceability — without leaking private data.

***

### 9. ⚠️ Trust Assumptions & Privacy Boundaries

GothamCash is **semi-trusted** and does **not** use zero-knowledge proofs (e.g. zk-SNARKs):

| Limitation                    | Explanation                                                  |
| ----------------------------- | ------------------------------------------------------------ |
| No zk-SNARKs                  | Note unlinkability is limited to commitment hash privacy.    |
| Semi-trusted relayers         | Relayers don't see secrets, but help broadcast transactions. |
| No auto-expiry or admin pause | Users must manage notes and timing themselves.               |
| No anonymity mining/shielding | There's no secondary layer for enhanced obfuscation.         |

**User responsibility is essential:**

* Sign only via trusted wallets (e.g. MetaMask).
* **Store notes safely** (no backup = no recovery). Keep your note secret and secure.
* Use private connections for maximum anonymity.

***

### 🧠 BindowsCash Security Philosophy

> We remove unnecessary complexity to reduce vulnerabilities.\
> We let users retain control, responsibility, and privacy.

🛡️ **Security is built-in — but privacy starts with you.**\
Always generate notes securely, store them safely, and withdraw anonymously.\
We provide the tools — you bring the discipline.\
You own the keys. You own the note.