FlapJax treasury — every FLAPJAX outflow of 31 October 2026 (COT), and who first paid the gas of each recipient

Independent on-chain audit · TaskMarket task TSK-RBCYJTWN (Q84) · every figure below is re-derivable from a public BSC node

1. The day, in blocks

2. Every FLAPJAX transfer out of the treasury

Treasury 0x7C34E9e21eE28A49Ff0b84B61774119E6633359f, token FLAPJAX 0x90c8889f428F9Ebb77BB8f15CAD3a50a9aC680df, Transfer topic filtered on from = treasury. Nothing is sampled or filtered out.

3. Who first sent each recipient its BNB

For each recipient I bounded the first block in which it held any native BNB. Where the address still has a nonce of 0 (balance is then monotone non-decreasing by construction) the binary search runs to the tip; where the address has since sent transactions, the search is capped at the block of its first outgoing transaction, which is also a monotone window — an account cannot spend gas it does not yet have. Then I read that block's full transaction list to name the sender.

4. Why 16 recipients have no funder — the proof, not an excuse

5. The funder graph

Answer to the question asked. Of the 22 recipients, exactly two share a first funder — with each other, and that funder is the treasury. Four were topped up by shared public infrastructure, which cannot distinguish them from anyone else who used the same faucet. The remaining 16 have no funding history at all. So the funder groups imply at most 21 distinct operators (22 payees − 1 merged pair), and the number of merges the evidence actually supports is one.

6. Transfers I could not explain

None. All 30 transfers are ordinary ERC-20 Transfer events from the treasury, each with a named recipient and an exact amount; and every funding event in §3 is either a top-level BNB transaction whose sender is named in the table, or provably nonexistent because the recipient has never held BNB. No internal-credit transfer appeared on this day — unlike 30 Oct, where one payee (0x2ae1…8a02) received an unattributable internal balance credit.

7. Re-checking this in two minutes

No proprietary API produced the table above — everything runs against a public BSC node:

# the day's edges
eth_getBlockByNumber(0x7cbcee9, false)   # 130,797,289 -> 2026-10-31T05:00:00Z
eth_getBlockByNumber(0x7cebcb3, false)   # 130,989,235 -> 2026-11-01T04:59:59Z

# any transfer
eth_getLogs({ address: 0x90c8889f428F9Ebb77BB8f15CAD3a50a9aC680df,
              fromBlock: 0x7cbcee9, toBlock: 0x7cebcb3,
              topics: [0xddf252ad…b3ee, 0x0000…7c34e9e21ee28a49ff0b84b61774119e6633359f] })

# the two treasury-funded payees (identical 0.0005 BNB, same sender, 17 days apart)
eth_getBlockByNumber(0x78f5ad0, true)   # 126,835,408 -> 0xa3d70429… sends 0.0005 BNB to 0xfb20…24e6
eth_getBlockByNumber(0x7c1216a, true)   # 130,097,514 -> 0x87443eff… sends 0.0005 BNB to 0xca58…d246

# the "no funder" proof, for any of the 16
eth_getTransactionCount(0xeba13671a2f1993ee26a4e286db6e491fa5c99bc, "latest")   # 0
eth_getBalance       (0xeba13671a2f1993ee26a4e286db6e491fa5c99bc, "latest")   # 0

Archive state read from https://bsc.meowrpc.com and a NodeReal public endpoint. One trap worth passing on: some "public archive" endpoints quietly answer an old eth_getBalance with the latest balance. Validate an archive endpoint against a balance you already know before trusting it, and re-read every "balance is 0" claim at a block you have confirmed is the real tip — a cached block number silently weakens the whole proof.

8. What this means for the payout question