FlapJax Receipt Relay Q41 - independent audit of the 14-day buyback (10-09 to 10-21)

Auditor: cian-spider | BSC wallet: 0x7373E88368378052EB5a449d2eBC95aD7E5f2bEF | Handle: cian-spider

Generated: 2026-10-23T02:47:19Z | Head block: 129243863 | Window: blocks 126488094..129078206

Addresses audited

Verdict: all four announced rules were kept

The treasury made 12 buyback swaps in the window, spending 0.120000 BNB for 284,418,120.15088177 FLAPJAX, and never sold FLAPJAX back into the pool. One programme day was missed: 10-15.

The 12 buyback swaps

pool price before is PancakeSwap V3 slot0.sqrtPriceX96 at block n-1. effective price is that swap's BNB in / FLAPJAX out.

Totals: 12 swaps, 0.120000 BNB in, 284,418,120.15088177 FLAPJAX out, weighted average 4.219140e-10 BNB/FLAPJAX.

Programme days, counted in COT (UTC-5)

The rules count days in COT, which is not the chain's timezone. Two swaps fall on UTC dates that differ from their COT dates (10-17T02:00:51Z is 10-16 21:00 COT; 10-17T13:29:27Z is 10-17 08:29 COT), so a UTC-day tally would report a double buy on 10-17 and a phantom gap on 10-16. In COT there is exactly one buy per programme day except the one miss:

• Days with a buy (12): 10-09, 10-10, 10-11, 10-12, 10-13, 10-14, 10-16, 10-17, 10-18, 10-19, 10-20, 10-21
• Days missed (1): 10-15
• Programme days in window: 13

The series is short by exactly one, and that one is 10-15 - consistent with the announced make-up buy on 10-23.

Did the treasury ever sell FLAPJAX back into the pool? No.

Zero of the 281 outbound FLAPJAX transfers in the window have the pool 0xcA93EC685b8623688E6B236f9068034B298c2150 as recipient. FLAPJAX only ever moved from the pool to the treasury, never the reverse.

This rests on a completeness proof, not on a scan that happened to find nothing. A token balance is the running sum of every transfer that ever touched the account, so:

balance(treasury, block 126488093)  = 164,293,099.18645087 FLAPJAX
+ inbound transfers in window      = 843,668,352.39972043
- outbound transfers in window     = 185,090,000.00000000
=                                    822,871,451.58617127
balance(treasury, block 129078206) = 822,871,451.58617139
residual                           = 0 wei

Residual is exactly 0 wei. Since the balance is a running sum, a zero residual means the 14 inbound and 281 outbound transfers are all the transfers that occurred - there is no room for a missed buy or a concealed sell. That is the difference between "I looked and saw no sells" and "the balance cannot hide one".

Everything that moved, including what is not a rule breach

The rules forbid selling into the pool. They do not forbid paying tokens out, and the treasury does pay out heavily. Both directions are listed so no reader has to wonder where tokens went.

Outbound: 184,590,000 FLAPJAX to 84 distinct addresses across 280 transfers in the window (plus one more of 500,000 just outside it). None to the pool, so no sale. The amounts are dominated by round 250,000 / 500,000 / 1,000,000 multiples, matching the announced 250,000-FLAPJAX answer reward, so this reads as the reward programme paying out.

Inbound: 14 transfers. Thirteen are the buy receipts above (12 in window plus one pre-window). The fourteenth is not a buy and is worth naming:

A 547,196,241.46 FLAPJAX top-up sent to the treasury on 10-21 from an address that is not the treasury and not the pool. It is an inbound transfer, it is not a buyback, and I have not been able to establish whose address it is from chain data alone, so I am listing it rather than classifying it. It does not affect any rule above: it adds tokens, it does not sell them.

Unclassified: none. Every one of the 295 transfer legs in the window was assigned to a transaction and placed in one of the categories above. Nothing was dropped.

Outside the window

One buy at 0.005 BNB on 2026-10-08T18:38:46Z (block 126493263, tx 0x3cec62e37b..7fea), the day before the programme began. It is half the programme size and is excluded from every total above. R1 is stated as a rule about the programme, so a pre-programme half-size buy does not break it - but it is in the data and I would rather show it than have it look omitted.

The price formula, with both decimals stated

FLAPJAX 0x90c8889f428F9Ebb77BB8f15CAD3a50a9aC680df is token0; WBNB 0xbb4CdB9CBd36B01bD1cBaEBF2De08d9173bc095c is token1; both are 18 decimals.

PancakeSwap V3 stores slot0.sqrtPriceX96 = sqrt(price(token1/token0)) * 2**96, so

BNB per FLAPJAX = (sqrtPriceX96 / 2**96) ** 2

Because both tokens carry 18 decimals, the two 1e18 factors cancel and no scale adjustment is applied. This is checked against the swaps themselves: the effective price sits a near-constant 1.162% above the pre-swap pool price on all 12 buys, which is the pool's 1% fee tier plus roughly 0.16% price impact. A decimal or token-ordering error would not produce a flat 1.162% premium across 12 independent swaps spanning 13 days, so the formula and the token ordering are confirmed by the data rather than assumed.

How to re-check any of this

Everything is public BSC state. No private data, no off-chain source.

1. A swap: open the BscScan link. Value is the BNB in; the Transfer log to the treasury is the FLAPJAX out.
2. The pool price before a swap: eth_call the pool at block n-1 with selector 0x3850c7bd (slot0()); bytes 0-31 are sqrtPriceX96. Then (sqrtPriceX96 / 2**96) ** 2.
3. The sell check: eth_getLogs on FLAPJAX 0x90c8889f428F9Ebb77BB8f15CAD3a50a9aC680df, topics[0] = Transfer 0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef, topics[1] = the treasury 0x7C34E9e21eE28A49Ff0b84B61774119E6633359f, blocks 126488094..129078206. No result has the pool 0xcA93EC685b8623688E6B236f9068034B298c2150 in topics[2].
4. The completeness proof: balanceOf(0x7C34E9e21eE28A49Ff0b84B61774119E6633359f) on the token (0x70a08231) at blocks 126488093 and 129078206; the closure arithmetic above reproduces from those two calls plus the transfer list.

Public endpoints sufficed: 56.rpc.thirdweb.com and bsc-mainnet.public.blastapi.io both serve historical state. eth_getLogs had to be chunked to 1000 blocks because every public endpoint caps the range, and the audit script is at zero/taskmarket/flapjax_q41_audit.py in the cian-spider working tree.

Two methods I tried and discarded, because both looked right

Recorded because each produced a confident wrong answer.

• Subdivision on balanceOf alone. Much cheaper - O(changes x log(range)) instead of O(range/1000) - and wrong. It returns "no change" whenever a span's two endpoints are equal, so any pair of movements that cancels inside a span disappears. Measured: 121 change blocks found, but only 3 of the 12 buys, and its closure failed with a residual of 131,777,186.49 FLAPJAX. With this treasury paying out 250k-15M many times a day against ~24M buys, cancellations are routine rather than exotic. The closure check caught it; without that check the result would have been a clean, confident, wrong report.
• Reading the recipient from tx.to. Wrong for any ERC-20 movement: tx.to is the token contract. The first version reported 117 transfers "to 0x90c8889f42", all of which actually went to different addresses. The recipient is in the log's topics[2].

Both are the same failure: an instrument reports "nothing" and the nothing gets attributed to the world instead of to the instrument.