# Security Model

## Separate accounting domains

Settlement deposits and tax revenue use different entry points and ledgers:

- `deposit()` creates a fixed BNB bearer liability without selecting a recipient.
- Every successful deposit first sends the Flap-priced `2 USDT` equivalent of the project token to the fixed burn address.
- `receive()` allocates external/tax BNB between donation, operations and maintenance.

The contract never taxes or donates any portion of an explicit settlement deposit.

## Held-balance invariant

```text
vault balance >= outstandingLiability + pendingDonation + operationsBalance + maintenanceBalance
```

User liabilities leave only through a mature address-bound bearer claim or a refund to the original depositor. Operations and maintenance withdrawals cannot consume `outstandingLiability` or `pendingDonation`.

## Donation protection

`DONATION_WALLET` is a compile-time constant. One third of each BNB revenue receipt is sent there immediately. A failed payment is queued in `pendingDonation`; `retryDonation()` can only pay the same fixed address.

There is no method to update the donation address or redirect a pending donation. The public website additionally checks the on-chain getter against its verified configured address before loading the vault.

## Creator authority

The Flap vault creator becomes the immutable `operator`. Only that address can:

- withdraw the operations pool;
- withdraw the maintenance pool; or
- sweep both project pools to itself.

Those calls always pay the operator address stored at creation. They do not accept an arbitrary recipient.

The creator/operator and official Flap Guardian can pause/unpause settlement activity, issue paused emergency refunds to original depositors and sweep only unaccounted forced-transfer excess to the operator. They cannot redirect active liabilities.

## Receipt behavior

The browser-generated Secret is a transferable bearer credential. A claimant first commits a hash bound to its wallet, the Deposit ID, Secret and Salt. The claim can be revealed only in a later block and always pays `msg.sender`. A copied commitment does not validate for a different wallet, and a newly observed Secret cannot be used without a previously matured commitment.

The successful claim stores the final claimant wallet in the deposit record and emits it publicly. Receipt hashes cannot be reused. Anyone who obtains the Secret can prepare a claim, so a receipt should be handled like cash; if it is shared with multiple parties, the first valid mature claim settles the record.

Active receipts do not expire. There is no configured aggregate liability ceiling because each accepted fixed-denomination deposit adds matching BNB collateral in the same transaction.

## Remaining risks

- The creator wallet is a single-key operational authority. Compromise permits withdrawal of operations and maintenance balances and operational disruption, but not redirection of active liabilities or pending donation funds.
- Deposits are permissionless and have no aggregate cap. A large number of permanent unclaimed records can grow contract state and total held liabilities.
- The donation source or campaign status may change after deployment, while the compiled donation address cannot.
- Flap pricing, BNB/USD feed freshness, tax-token liquidation, DEX price impact and RPC availability are external dependencies.
- Spot-price manipulation can change the token quantity representing `2 USDT`; the caller-supplied maximum burn amount limits adverse movement between preview and execution.
- A claimant contract that rejects BNB may require a paused emergency refund to the depositor.
- Frontend compromise can present incorrect information; users should verify contract addresses and wallet calldata.
- Mainnet deployment should follow an independent Solidity audit and a capped initial launch.