For the frozen Sui window, 0xf297beb5b35cc39932217e5b4384708fa20b42313bf80488b0c531963702c1b1 did one thing: it submitted 1,972 campaign-whitelist authorizations. Every transaction committed successfully, used the same one-call composition, and was sponsored by the same separate gas owner, 0xe98aaadcdf0dfdbaf182b91269566adc413401c423229bfc4b690e884e25e3ee.
That repetition is consistent with scripted or batch dispatch. It does not establish a bot, a person, or a shared operator.
A narrow repertoire at machine cadence
These whole-history figures cover 1,972 eligible transactions between 13:01:55 and 23:29:17 UTC on July 19, 2026. All matched add-campaign-whitelist through sui/add-campaign-whitelist/direct/v1, calling campaign::add_whitelist in package revision 0x9f6de0f9c1333cecfafed4fd51ecf445d237a6295bd6ae88754821c8f8189789.
The median gap was 226 milliseconds and the 90th-percentile gap was 2.474 seconds. The longest idle period was 2,982,693 milliseconds, about 49 minutes and 43 seconds. Activity arrived in bursts: 458 transactions during the 17:00 hour, 302 during 19:00, and 295 during 21:00. The busiest minute was 19:54 UTC, with 109 transactions.
The separate latest-500 transaction sample covers 20:33:55–23:29:17 UTC. Its median gap was effectively zero because many calls shared timestamps or arrived within the same millisecond, reinforcing the appearance of batched dispatch.
What the authorization means
The stored contract interpretation describes add_whitelist as an administrator-gated operation that authorizes a supplied address for a campaign and creates a corresponding permission record without referral history. The package analysis says the call requires the campaign administrator to match the transaction sender, initializes the record with zero referrals, and performs no fungible-asset operation.
The evidence is deliberately narrower than the label. It proves the authorization call and its input, not the identity or consent of the supplied address, nor any later participation or benefit. In the first recorded transaction, RkpLg3aQ, the detail names 0x9b1de70d117ea02830b015c75193afc916ff1f13bda90b519595695acd0c71b3 as the submitted input. Near the end, FgbJWerW submits 0xbd2329518cd88287334243c7323f65331be914beebfed2bc0825f7768bc3d011; another recent example, 9bWLxoFs, submits 0xcfbda5f891a5a668c2a2a57720390cf73db5a7498809c9f03254adae31a244c8.
Those values show changing call inputs, not independently observed whitelist state.
The bounded money story
Across the complete history, MotiveLayer recorded no sender movement entries. That is a statement about the available movement evidence, not proof that no underlying asset changed elsewhere.
The recorded net gas total was 3,513,867,360 MIST. Because every transaction was sponsored, the separate gas owner—not the sender address—paid the recorded gas. In the latest-500 sample, every row carried 1,781,880 MIST of net gas, totaling 890,940,000 MIST for that sample. There are no prices or cross-asset flows here, so the record cannot establish profit, loss, or economic benefit.
The strongest description is therefore modest but clear: within this frozen window, this on-chain address repeatedly submitted administrator-gated campaign whitelist authorizations at batch-like cadence, while another address consistently supplied the gas. The chain evidence does not identify who controlled either address or what happened to the authorized recipients afterward.