# 大表哥: Flap pre-audit compliance evidence

Date: 2026-08-20
Target: BNB Chain mainnet (chain ID 56)
Status: source-only; factory, vault and token are NOT deployed

This is implementation evidence for Flap's reviewers. It is not an independent
security audit and not a guarantee of safety.

## Official launch boundary

- `BigCousinVaultUpgradeable` inherits Flap's `VaultBaseV3`; canonical Flap base
  files under `src/flap/` are included unmodified.
- `BigCousinVaultBeaconFactory` inherits Flap's `VaultFactoryBaseV2`.
- `vaultSpecVersion()` returns `v3`; `factorySpecVersion()` returns `v2.3`,
  opting into Flap's ERC-20 quote validation flow.
- `newVault()` is callable only by the canonical BNB VaultPortal
  (`0x90497450f2a706f1951b5bdda52B4E5d16f34C06`).
- `vaultDataSchema()` declares zero creator-controlled fields and `newVault()`
  rejects any non-empty `vaultData`. A token creator cannot redirect a vault at
  a different treasury or quote token.
- Launch validation requires the exact BNB Chain QQQB quote token, non-zero buy
  AND sell tax, 100% of post-protocol tax allocation to the vault, and zero
  deflation / dividend / LP allocation.
- The intended creation call is `VaultPortal.newTokenV6WithVault()` with
  `TOKEN_TAXED_V3`, producing a `...7777` token.

## Revenue and safety boundary

- QQQB dispatch uses Flap's transfer-first / wake-after semantics. The
  lightweight `receive()` recognises only the positive delta between the actual
  QQQB balance and `accountedQuote`; a zero-delta wake is a silent no-op, never
  a revert.
- Public `sync()` recognises direct transfers or funds left unrecognised after a
  failed or missed wake. Every revenue-dependent write syncs before acting.
- `processRevenue()` decrements `accountedQuote` BEFORE the QQQB outflow in the
  same transaction. A downstream revert atomically restores both accounting and
  funds, avoiding the accounting deadlock a decrement-after design can reach.
- `processRevenue()` is permissionless and rate-limited by an immutable
  `maxProcessQuote` per call.
- **There is no swap route, no router, no pool, no TWAP, no oracle and no
  slippage surface.** The token is quoted in QQQB and the game pays out in
  QQQB, so revenue never changes denomination. This removes the entire class of
  price-manipulation findings that a converting vault carries.
- The split is `GAME_SHARE_BPS = 3000`, a **constant, not a setter**. The public
  site states that 30% of fees fund the game; that promise is enforced by the
  bytecode. Changing it requires a Guardian-controlled beacon upgrade.
- Both destinations (`gameTreasury`, `projectTreasury`) are immutable factory
  configuration, set once at construction and unreachable from any setter.
- The vault has no treasury withdrawal path, no creator commission, no route
  setter, no fee setter and no keeper role. Flap's canonical Guardian alone can
  enable non-reverting native receive forwarding and rescue native/ERC-20
  balances during an incident. A QQQB rescue resets the accounting baseline.
- Beacon upgrade and the permanent upgrade-lock are callable only by Flap's
  canonical BNB Guardian (`0x9e27098dcD8844bcc6287a557E0b4D09C86B8a4b`). No
  project-held owner, proxy admin or upgrader role remains.
- All project-owned user-facing revert and schema strings are bilingual and
  literal `require()` strings. No custom errors are used in project code.

## Rule-by-rule

| Rule | Result | Note |
|---|---|---|
| 001 vault rules | PASS | `VaultBaseV3` inherited; custom `onlyGuardian` resolves to `_getGuardian()`; no path replaces the Guardian |
| 002 factory rules | PASS | `VaultFactoryBaseV2` inherited; no commission fee is charged |
| 003 fairness | PASS | Split is a constant; both destinations immutable; `processRevenue()` is permissionless and can only move funds to those two addresses, so there is nothing to front-run |
| 004 UI-friendly | PASS | Literal bilingual `require()` strings throughout; no custom errors |
| 005 receive() gas | PASS | No loops, no external calls, no delegatecall in the `receive()` call tree. Measured well under 100,000 gas against a 1,000,000 cap |
| 006 integration tests | PASS | See below |
| 007 AI oracle | N/A | Not used |
| 008 trigger service | N/A | Not used |
| 009 emergency controls | N/A (proxy) | BeaconProxy vault; Guardian-only beacon upgrade is the emergency path. Guardian-only rescue functions are additionally provided |

## Verification completed

```text
forge build --sizes
BigCousinVaultUpgradeable   runtime: 14,979 bytes  (9,597-byte EIP-170 margin)
BigCousinVaultBeaconFactory runtime:  8,010 bytes  (16,566-byte margin)
FlappyCuzTreasury           runtime:  9,450 bytes  (15,126-byte margin)

28 unit tests passed; 0 failed
 2 BSC mainnet-fork integration tests passed; 0 failed
30 total; 0 failed
```

The live-fork test exercises the current VaultPortal factory path against the
live, enabled QQQB quote token: `...7777` creation, factory-created vault,
TaxProcessor transfer-plus-wake QQQB routing, balance-delta recognition,
bonding-curve tax dispatch, the 30/70 split landing in both treasuries, DEX
graduation, post-DEX sell and dispatch, and finally a signed payout of real
tax-derived QQQB to a player wallet.

Required coverage per Rule 006:

| # | Scenario | Test |
|---|---|---|
| 1 | Factory deploys a vault on `newTokenV6WithVault()` | `test_fullFlapPathAndGamePayout` |
| 2 | Vault wired: `taxProcessor.marketAddress() == vault` | `test_fullFlapPathAndGamePayout` |
| 3 | Curve buy → dispatch reaches the vault | `test_fullFlapPathAndGamePayout` |
| 4 | DEX graduation → sell → dispatch | `test_fullFlapPathAndGamePayout` |
| 5 | Core action succeeds (30/70 split pays out) | `test_fullFlapPathAndGamePayout`, `test_splitIsThirtySeventy` |
| 6 | Core action correctly gated | `test_processRevenueRevertsWithNothingToDo`, `test_factoryRejectsNonPortalCaller`, `test_factoryRejectsForeignQuoteAndData`, `test_guardianOnlyForEmergencyPaths` |

Plus `receive()` gas budget, `description()`, `vaultUISchema()`/`vaultDataSchema()`
well-formedness, rate limiting, and a value-conservation fuzz over the split.

## Manual review items

- **Audit `FlappyCuzTreasury` together with the vault.** It is the payout side of
  the same trust boundary: the vault funds it and it releases QQQB against
  signatures from an off-chain score signer.
- The treasury's security rests on caps, not on the signer being honest. A
  leaked signer key can drain at most `maxDailyPerWallet` per wallet per UTC day
  until the owner rotates it or pauses. Confirm those ceilings are sized against
  the treasury balance you intend to hold.
- Confirm the intended owner of `FlappyCuzTreasury` (it is `Ownable2Step`, and is
  NOT the Flap Guardian; it is a project-held key).
- Verify every deployment constructor argument and the deployed source on the
  explorer before registering the factory.
- The two treasury addresses are immutable. Confirm both before deployment;
  changing either requires deploying a new factory.
- The 70% remainder currently goes to a single `projectTreasury` address. If it
  is later meant to split further (buyback, lockers, insurance), that is a new
  contract behind that address, not a change to this vault.
- The Vault UI package binds a real Flap proof token for Workbench/E2E only.
  Replace the audit-stage binding with the audited factory deployment before
  publication; no fake production factory address is claimed.
