MotiveLayer's AI model analyzed half a day of Sui mainnet — 1.23 million user transactions — and produced a full behavioral census of the chain: what every transaction means, who is behind the activity, and what the long tail is hiding, down to the smallest bots.
Everyone assumes 10M+ transactions a day is too much to understand. Measured, the chain collapses to a much smaller set of recurring behaviors.
The half-day window (checkpoints 301,020,000–301,219,999) holds 2,755,113 transactions; 1,229,800 are user transactions (the rest is system/consensus traffic). Structurally, those collapse to 28,507 distinct transaction patterns — with an extremely head-heavy distribution:
Structurally distinct transaction patterns, log scale. Marked points are measured.
About 60% of the distinct patterns occur exactly once, yet together they carry only ~1.4% of volume. The economically meaningful head of the chain is a few hundred behaviors; uniqueness accumulates in a long tail that barely moves volume — which is where the most interesting actors hide.
Every one of the 1.23M transactions was interpreted by our AI model — no manual labeling, no per-protocol integrations.
“New to the model” = activity the model had not yet learned at the time of the run.
97.0% of all activity received an interpretation — and 99.5% of anything the model had encountered before. The remainder is not a blind spot: everything the model cannot yet explain is studied by our AI automatically and becomes permanent knowledge. Coverage only goes up — new protocols are typically understood within hours of appearing on-chain, and understanding acquired once applies to every past and future transaction.
Each behavior type carries an actor attribution judged from evidence — sender concentration, cadence, failure tolerance, and the nature of the action.
Evidence-based attribution per behavior type; “mixed” = types demonstrably used by both bots and people.
At least 63% of identified activity is automated trading and strategy bots, another 19% is protocol-operated keepers and admin, and identifiable human-initiated activity is under 2% — a rounding error on the chain it lives on. The interesting life is in the tail: individual market-making operations, obfuscated arbitrage adapters, gamblers, collectors, and one-wallet infrastructure — all itemized below.
The 5th-largest behavior on the chain (34.6k tx) is an obfuscated DeepBook strategy: a guard call (owner check + Clock deadline + monotonic nonce, all hash-named) followed by hashed modules that cancel/re-place orders via a TradeProof. Disassembly also decoded “stonker” (28.8k tx), an obfuscated bot working the SUI/USDC and DEEP/USDC pools.
Package 0x520c is an instruction-identical redeployment of arb adapter 0xa505 under a fresh address — same bytecode, new identity. One of its clusters ran 8 successes to 120 failures: the operator eats gas on failed attempts to be first when the spread appears.
A single-sender Cetus/Bluefin flash-swap arb bot grinds at a 95.7% failure rate; a multi-DEX settlement route fails 84% of the time; one DLMM treasury cycle went 1-for-15. All 140,582 failed transactions (11.4% of the window) are preserved and interpreted as attempted behavior — failed arbitrage is some of the highest-signal data on the chain.
Real people show up as Magma swaps (seven distinct wallets, 17.5% slippage-abort rate — real traders, not one bot), wheel/plinko/coinflip bets on sponsored gas, Tradeport NFT bids, card-pack openings on Rip Station, missions in an on-chain mafia game (Vendetta), and article publishing on Inkray.
A single keeper wallet accounts for 100% of one price-feed package's traffic (creating and setting a fresh feed object every cycle); Supra proof pushes, Bluefin Pro's sequencer settlement, and a derivatives venue's “regime push” (14.3k tx) are each one operator doing all the work.
A single campaign package logged user activity 85,970 times and mass-added 15,388 addresses to whitelists in 12 hours — mass-registration patterns consistent with points farming. Quest check-ins and referral creation ride alongside. Exactly what incentive-auditing exists for.
“Lotus” (~28k tx) is a vault-managed DeepBook market-making system — depositors' funds quoted via delegated TradeCaps, bytecode-verified. Meanwhile Ferra's DLMM liquidity is effectively one LP bot (378 of 380 transactions from a single operator).
An entrypoint named claim_liquidity_minging_rewards — the typo shipped to mainnet and bots call it anyway. An oracle-settled soccer-wager book. And “Character Hub” issuing AI-agent capabilities on-chain — agents getting on-chain identities, two transactions at a time.
All 269 behavior types identified in the 1.23M-transaction window, grouped by category with per-category volume. Together they cover 90.6% of user transactions with a fully identified purpose; a further 6.4% is recognized at component or activity level. Actor attributions are evidence-based; protocol names are stated only where our analysis confirmed them, otherwise hedged.
| Behavior | Transactions |
|---|---|
| Orderbook trading & market-making | |
| botDeepBook v3 — cancel limit order (maker quote refresh) An owner BalanceManager proof followed by pool::cancel_order on a DeepBook v3 deployment (0xcaf6...) — the canonical market-maker quote pull. This is the single largest activity pattern on the chain (~16% of all user transactions by itself; DeepBook order flow overall is ~45%), driven by MM bots that cancel and re-place quotes continuously. | 199,870 16.25% |
| botDeepBook v3 — place limit order (maker quote) Owner proof then a single pool::place_limit_order on the same DeepBook v3 deployment as the cancels — the placement half of continuous quote refresh by market-maker bots. Together with its cancel twin it accounts for roughly a quarter of the 1.23M transactions we analyzed. | 138,857 11.29% |
| botDeepBook v3 (older package version) — place limit order Identical owner-proof + place_limit_order shape but targeting a different DeepBook v3 package deployment (0xf482...). Multiple MM operations call older upgrade versions of the DeepBook package ID rather than the current one, so the same economic action shows up on-chain across several distinct deployments. | 53,482 4.35% |
| botDeepBook v3 — bulk cancel live orders Owner proof followed by pool::cancel_live_orders on the 0xf482 DeepBook deployment — a maker wiping its entire resting book on a market in one shot, typically before re-quoting or on shutdown/risk events. We also observed a two-market variant that cancels across two pools from one proof, with 100% success. | 41,854 3.40% |
| botObfuscated DeepBook market-making strategy — order refresh (variant A) A hash-named guard call (0xc721::h86261::h8b64d — bytecode-verified to check owner address, a deadline against the Clock, and a monotonically increasing nonce) followed by 0xe748::h0d1a7::h011fb, whose disassembly shows it cancelling and re-placing DeepBook limit orders through a BalanceManager TradeProof. At 34.6k transactions this deliberately obfuscated strategy is one of the biggest single bots on the chain — a professional MM hiding its logic behind hashed identifiers. | 34,649 2.82% |
| botDeepBook v3 — cancel order via delegated trader key Same cancel shape but authorized by generate_proof_as_trader — a delegated TradeCap key rather than the BalanceManager owner — on the 0xb29d DeepBook deployment. The owner/trader split reflects MM operational hygiene: hot trading keys operate on a BalanceManager whose owner key stays cold. | 17,120 1.39% |
| botDeepBook v3 — place limit order via delegated trader key Trader-proof authorized limit-order placement on the 0xb29d deployment, the placement half of the delegated-key MM flow. Together the trader-key variants add ~34k transactions to the DeepBook quote-refresh volume. | 16,759 1.36% |
| botDeepBook v3 — place two limit orders (two-sided quote) One owner proof feeding exactly two place_limit_order calls with identical pool type arguments — a maker posting both sides (or two price levels) of a market atomically in one PTB. Standard two-sided quoting from the same MM population as the single-order flow. | 14,619 1.19% |
| botLotus DeepBook vault (v10 package) — batch order placement A single place_batch_limit_orders_pure_seq call on the older of two Lotus packages, always with exactly the LP_TOKEN/SUI/USDC type arguments. Lotus is a vault protocol (LotusDBVault holds an LP token and a DeepBook TradeCap) that runs market-making on DeepBook on behalf of depositors; disassembly confirms the batch call cancels existing orders then places the supplied order ladder. 14.6k transactions — the vault's quote-refresh loop. | 14,569 1.18% |
| botObfuscated DeepBook market-making strategy — order refresh (variant B) Same guarded pattern as variant A (owner/deadline/nonce guard then the obfuscated 0xe748 strategy package) but calling the sibling entrypoint he605f, a second order-refresh routine in the same bytecode that also drives DeepBook cancel/place calls through a TradeProof. Another 9.9k transactions from the same obfuscated MM operation. | 9,851 0.80% |
| botDeepBook v3 — atomic cancel-and-replace order One trader proof feeding pool::cancel_order then pool::place_limit_order with identical pool/type arguments — an atomic quote replacement. We observed 505 of 521 attempts succeed, with the rare failures aborting inside DeepBook's big_vector::leaf_remove when the order to cancel is already gone (filled or cancelled) — a classic MM race. | 8,023 0.65% |
| botDeepBook v3 — batch place 3+ limit orders (ladder quoting) One owner proof feeding three to ten place_limit_order calls, all on the same pool with identical type arguments — a maker laying out an entire price ladder atomically. We observed batches of 3, 4, 5, 6, 7, 8 and 10 orders; failures (e.g. 51 of 153 among the 8-order batches) abort mid-batch on balance withdrawal, i.e. the bot occasionally over-quotes its collateral. | 6,558 0.53% |
| botLotus DeepBook vault (v11 package) — batch order placement The canonical Lotus package's place_batch_limit_orders_pure_seq — the same cancel-and-replace-ladder vault operation as on the older package, on Lotus's newer deployment. Disassembly verifies the vault checks its cap and pool binding, generates a trader proof from its stored TradeCap, and drives DeepBook order placement on behalf of vault depositors. | 6,076 0.49% |
| botLotus DeepBook vault — place single limit order A single lotus_db_vault::place_limit_order on the canonical Lotus package — the vault posting one DeepBook order through its stored TradeCap rather than refreshing a whole ladder. Part of the same automated MM-vault operation as the batch order placements. | 4,107 0.33% |
| botLotus vault — cancel all DeepBook orders (market-maker refresh) Lotus is a vaulted DeepBook market-making protocol: its lotus_db_vault module holds pooled capital and places and cancels DeepBook v3 limit orders on the vault's behalf. This is the bulk-cancel leg of its quote-refresh loop — one observed cancel-all removed 18 resting orders at once, while sibling single-order cancels fail frequently (in one group, 10 of 12 aborted inside DeepBook's order-book internals, racing to cancel already-gone orders). | 3,270 0.27% |
| botDeepBook v3 — owner-proof limit order placement (market maker) A BalanceManager generate_proof_as_owner call whose proof result is threaded into pool::place_limit_order, all against one specific DeepBook v3 deployment (0xb29d...). The proof-then-order pattern is characteristic of an automated market-making operation quoting on DeepBook; our analysis grouped roughly 967 transactions of owner place/cancel/replace cycles from this package alone. | 2,969 0.24% |
| botDeepBook v3 — owner-proof order cancel (market-maker refresh) The cancel side of the same DeepBook v3 (0xb29d...) market-making loop: an owner proof from BalanceManager consumed by pool::cancel_order. Cancel volume closely mirrors the corresponding order placements (2,948 vs 2,969), consistent with a bot continuously replacing stale quotes. | 2,948 0.24% |
| botDeepBook v3 — cancel live orders across two markets from one proof One BalanceManager owner proof consumed by two consecutive pool::cancel_live_orders calls with different market type-argument pairs — a market maker pulling all its resting quotes on two DeepBook books in a single transaction. All 143 transactions we analyzed succeeded, emitting batches of OrderCanceled events. | 1,945 0.16% |
| botExecution vault — capital withdrawal backing a DeepBook limit order A private execution-funding vault (vault::withdraw, then one or two deposits back) supplying capital for a place_limit_order, with explicit check_min_amount/check_deadline validation calls in the same PTB. The vault bytecode shows withdraw/deposit/withdraw-and-receive custody operations only — it is the working-capital pocket of a DeepBook trading operation, with slippage and deadline guards typical of automated execution. | 1,674 0.14% |
| botDeepBook v3 — cancel orders with owner trade proof (market-maker refresh) balance_manager::generate_proof_as_owner creates a TradeProof whose result is wired into one or more pool::cancel_order calls, emitting OrderCanceled. This proof-threaded shape is the programmatic order-management path used by market makers pulling quotes. | 327 0.03% |
| botDeepBook v3 — place limit orders with owner trade proof The owner TradeProof result wired into one or more pool::place_limit_order calls (disassembly shows the entrypoints take &TradeProof), emitting OrderPlaced/OrderInfo on success. The quote-posting half of programmatic market making on DeepBook v3. | 284 0.02% |
| botDeepBook v3 — cancel-all, withdraw, and replace (market-maker cycle) The full quote-refresh cycle on canonical DeepBook v3 (0x2c8d): generate_proof_as_owner → pool::cancel_all_orders → pool::withdraw_settled_amounts → optional replacement place_limit_order, with the proof result consumed by every pool call. Textbook market-maker maintenance — pull all quotes, sweep settled balances, repost. | 232 0.02% |
| botDeepBook v3 — withdraw settled maker balances On the DeepBook v3 deployment (0x0e73...), a generate_proof_as_owner result is consumed by withdraw_settled_amounts (optionally followed by two withdraw_all sweeps) — a market-maker routine sweeping settled trade proceeds out of a BalanceManager. Every instance we observed succeeded. | 215 0.02% |
| botDeepBook v3 — cancel all orders (market-maker refresh) generate_proof_as_owner's TradeProof result is wired into pool::cancel_all_orders on the canonical DeepBook v3 package — a classic market-maker quote teardown. All 36 cancellations we observed succeeded and emit order::OrderCanceled; the same package family also carries vault-backed order placements with heavy slippage-abort rates. | 167 0.01% |
| botDeepBook v3 — clear referral + sweep balances An exact sequence of unset_balance_manager_referral then two withdraw_all calls on the DeepBook v3 deployment — a trader tearing down its BalanceManager referral configuration and sweeping both order-pair assets out in one shot. | 115 <0.01% |
| botLotus DeepBook vault — cancel order (market-maker refresh) cancel_order<T0,T1,T2> takes &mut LotusDBVault, the vault cap, and a DeepBook Pool; bytecode analysis shows it checks the vault/pool relationship and cap access, generates a trader proof from the vault's stored TradeCap, and calls DeepBook pool::cancel_order. Lotus is a vault-managed DeepBook market-making system whose cancellation traffic alone accounted for roughly 300 transactions in the window we analyzed. | 90 <0.01% |
| botDeepBook v3 — BalanceManager withdrawal Traders pulling funds out of their DeepBook v3 BalanceManager via balance_manager::withdraw<T> on the 0x0e735... DeepBook deployment. This package's traffic is dominated by flash-loan and market-making bots — our analysis found 173 flash-loan attempts against it with a 68% failure rate — so these withdrawals are mostly automated trading-account fund management; all withdrawals succeeded. | 71 <0.01% |
| botLotus vault — cancel all DeepBook orders (alternate deployment) A market-making vault ('lotus_db_vault') that manages DeepBook limit orders behind a vault capability; cancel_all_orders<T0,T1,T2> takes the vault, its cap and the DeepBook pool and emits OrderCanceled per order. This 'alternate' package (0x5ea2c9..., v10) shares its module set with the canonical Lotus package but is a distinct deployment; roughly 303 Lotus cancellation transactions we analyzed were concentrated in just two sender addresses — quote-refresh churn from a market-making bot. | 48 <0.01% |
| humanStandalone limit-order protocol — place order A dedicated limit-order package (0x37d628...): place_limit_order validates and consumes a coin split in the same transaction, emits OrderPlacedEvent, indexes the order and shares the order object so keepers can later fill it; the owner can cancel via cancel_order_by_owner. An unbranded on-chain limit-order book, distinct from DeepBook. | 26 <0.01% |
| humanOn-chain limit-order book — owner cancels order The owner of a shared limit-order object on an unbranded limit-order protocol cancels it via `cancel_order_by_owner`, which verifies sender ownership and emits `OrderCanceledEvent`. Placement in the same package funds and shares the order object from a split coin, so cancels return that escrowed balance; all observed cancels succeeded. | 12 <0.01% |
| Oracles, keepers & price feeds | |
| infraPyth — accumulator price-feed update (via Wormhole VAA) The full Pyth pull-oracle update pipeline: wormhole vaa::parse_and_verify, create_authenticated_price_infos_using_accumulator, N repeated update_single_price_feed calls, hot_potato_vector::destroy, plus a SplitCoins fee payment. 62.7k transactions of keeper/crank traffic keeping Pyth feeds fresh for downstream DeFi — pure oracle infrastructure load. | 62,701 5.10% |
| infraUnbranded oracle-priced SUI/USDC pool — keeper price push with expiry Repeated price_oracle::update_price_with_expiry calls (typically two per PTB) on package 0xf6a6..., which also hosts an oracle-priced SUI/USDC pool (pool::swap_buy/swap_sell) used inside vault-rebalance bot routes. 54k transactions of a keeper feeding its own pool's price oracle; our analysis could not tie the venue to any known protocol brand — the pool trades exclusively SUI/USDC. | 54,185 4.41% |
| infraSaturation-curve AMM — keeper price update A single update_prices call on a one-module 'saturation_curve' package that is itself an oracle-priced AMM (the same module exposes swap_x_2_y/swap_y_2_x, which appear as swap legs inside bot routes). 20.4k transactions of the operator's keeper marking the curve's prices; the protocol brand could not be identified. | 20,428 1.66% |
| infraSupra oracle — verify proof and push price A single price_data_pull_v2::verify_oracle_proof_push call on Supra's Sui package (module names SupraSValueFeed / price_data_pull confirm the identity). 8.8k transactions of Supra's pull-oracle keepers verifying signed price proofs and writing them on-chain. | 8,829 0.72% |
| infraMark-price keeper — repeated update_mark_price pushes One or more repeated mark_price::update_mark_price calls on a single package per transaction — the batched-repeat shape of a derivatives-protocol keeper refreshing mark prices for multiple markets in one PTB. We have not attributed a protocol brand, so this is best read as a perp/derivatives mark-price feed maintained by protocol infrastructure. | 2,098 0.17% |
| infraPrivate price feed — keeper create-and-set push A create_price -> set_price pair on a private price_feed package, and notably never a standalone set: across 209 transactions we analyzed, the setter always follows a fresh create in the same PTB. A single privileged keeper wallet sent 100% of the traffic, with a 36.8% failure rate — an app-specific oracle pushing (and often losing races on) its own feed objects. | 1,997 0.16% |
| infraNautilus (TEE enclave) oracle — attested price update A single update_prices call whose 13-input shape (three shared objects plus ten Pure values) is consistent with Sui's Nautilus framework for AWS Nitro Enclave verifiable computation — a signed enclave attestation being verified on-chain to update a price-feed object. One keeper address produced all observed traffic with 100% success, exactly what a TEE-oracle relay looks like. | 1,988 0.16% |
| botDeepBook v3 — DEEP price-point cranking Repeated pool::add_deep_price_point calls (2, 3, 4, or 8 per PTB, four type arguments, shared Clock and reference pool) on a later-generation DeepBook package, each emitting a deep_price::PriceAdded event. This maintains the DEEP-denominated price points DeepBook uses for fee conversion — keeper/cranking activity, typically run by market-making operations. | 714 0.06% |
| infra'Oracle Pro' — batched multi-provider price updates Batches of update_single_price_v2 calls (34 per transaction in what we observed) on a package whose bytecode validates provider/configuration data before oracle::update_price emits PriceUpdated and mutates value/timestamp. A protocol-operated price keeper; the consuming protocol's brand was not established. | 337 0.03% |
| infraAlpha Lending — standalone oracle price refresh Transactions whose only Alpha Lending calls are update_price, each consuming an oracle get_price_info result — price maintenance for the lending market with no accompanying user action, i.e., keeper-style refreshes rather than borrower activity. | 131 0.01% |
| infraCustom price-feed keeper — Arbitrum-extended price push A single privileged keeper wallet (0xe01da37c..., accounting for all 209 transactions we analyzed from this package) pushing prices to a bespoke price_feed package; this variant runs create_price -> create_arbitrum_price_ext -> set_price_for_arbitrum, i.e. it creates a fresh price object with an Arbitrum extension on every push rather than updating in place. The Arbitrum variant went 5-for-5 in our observations while the base create-and-set variant failed 36.8% of the time. | 31 <0.01% |
| Campaigns, points & attestation | |
| mixedCampaign points program — activity log A single call into an unbranded single-module 'campaign' package that logs user activity (bytecode shows LoginEvent/ReferralEvent, whitelist and referral state). At 86k transactions (~8% of all user transactions, down from ~10.5% in an earlier observation window) it is the third-largest workload on the chain; the uniform single-call shape plus the paired whitelist administration from the same package suggests an operator-run quest/points attestation program, though it is not proven whether the logs are user-signed or backend-batched. | 85,970 6.99% |
| infraCampaign points program — whitelist administration Single add_whitelist calls on the same unbranded campaign package as the activity logs — the operator adding addresses to the campaign's allowlist. We observed this flow to be extremely bursty (e.g. 874 calls in one time window vs 8 in the next), consistent with batch enrollment jobs rather than organic activity. | 15,388 1.25% |
| humanQuest — paid daily check-in quest_v2::checkin on a quest package: bytecode shows it validates ownership and the configured fee, records the check-in, deposits the fee, and emits EventCheckin, with the fee coin split off in the same transaction. Classic daily-engagement points farming — per-wallet actions, though such campaigns are routinely multi-wallet farmed. | 1,354 0.11% |
| humanCampaign app — referral registration Exactly two calls on campaign package 0x9f6d: log_user_activity validates the active campaign and emits LoginEvent, then create_referral mutates referral state and emits ReferralEvent with referrer, referee, and creation time. A quest/points application recording a referral relationship; the brand behind the package could not be established from bytecode. | 156 0.01% |
| humanQuest campaign — claim signed bonus points A quest/check-in campaign package (quest_v2): claim_bonus_point verifies an off-chain signature over the claim, charges the configured fee from a coin split in the same transaction, credits bonus points and emits ClaimBonusEvent. A companion flow handles the daily check-in; both are fee-paying user engagement actions on an unbranded points program. | 28 <0.01% |
| Flash loans, arbitrage & strategy bots | |
| bot'Stonker' obfuscated cross-venue SUI/USDC strategy bot One hash-named entrypoint (entrypoint::aaf6cc9d45ba0185f) whose bytecode delegates to a module literally named 'stonker' in a second package; its 22-argument signature takes a DeepBook v3 BalanceManager, SUI/USDC and DEEP/USDC DeepBook pools, plus SUI/USDC pools from several other venues (Cetus GlobalConfig/RewarderGlobalVault, a FEE500BPS Turbos-style pool) in a single call. 28.8k transactions of one operator's cross-venue inventory/market-making strategy compressed into a single obfuscated call. | 28,826 2.34% |
| botVault-funded Cetus flash-swap arbitrage bot A rigid route: Cetus pool::flash_swap_with_partner -> swap_pay_amount -> withdraw repayment funds from a proprietary vault package -> repay_flash_swap_with_partner -> min-amount + deadline validation -> redeposit to the vault. Of 570 attempts we analyzed, 404 failed (71%), aborting at the min-amount check — an arb bot whose profitability guard usually rejects the route, spamming attempts regardless. | 8,247 0.67% |
| botFlash-loan arbitrage via universal router + Cetus leg Flash-borrows from a dedicated flash-loan package (flashloan_quote returns a coin plus a hot-potato receipt), runs a full universal-router build/start/finish/settle session including a Cetus adapter leg, and repays in the same PTB. Only about 15% of the attempts we observed succeeded (26 of 179) — an arb searcher whose routes mostly abort unprofitable, costing only gas. | 6,917 0.56% |
| botVault-funded Bluefin Spot pool-swap bot vault::withdraw -> Bluefin Spot pool::swap -> min-amount + deadline validation -> two vault::deposit calls, all through the same proprietary vault/validation packages as the Cetus flash-swap route. We observed 246 of 302 attempts fail (81%), aborting inside pool::swap (code 1009) — the same vault-rebalancing/arb operation probing Bluefin instead of Cetus. | 6,611 0.54% |
| botNonce-deduplicated single-DEX swap bot A nonce_manager::commit call (idempotency/replay guard) followed by exactly one direction-coded venue call — turbos_a2b, cetus_b2a, momentum_a2b, bluefin_a2b, magma_b2a, etc. — from a paired route package. The commit-first pattern and a 41% observed failure rate mark this as an automated execution system (likely an off-chain strategy engine deduplicating its own orders), not user flow. | 6,316 0.51% |
| botFlash-loan arbitrage via universal router + Bluefin leg Same flash-loan + universal-router envelope as the Cetus variant but with a Bluefin swap leg. This is one of the most failure-dominated large flows on the chain: only 5 of 262 observed attempts succeeded (~2%) — a searcher continuously probing a route that almost never clears its profitability check. | 6,129 0.50% |
| botFlash-backed multi-venue arb route ('Haedal aggregator' adapter) A receipt-backed flash open/close pair enclosing swap legs through a multi-venue adapter package whose bytecode wraps Cetus, FlowX CLMM and Kriya AMM swaps — it appears to be a 'Haedal aggregator' adapter; the borrowed balance demonstrably threads through every adapter leg of the route. 5.3k transactions of flash-funded atomic arbitrage; we separately track the attempts that abort before the route completes. | 5,289 0.43% |
| botCustom arbitrage router — circular multi-DEX route with profit check A proprietary opener call (arb_swap or its Cetus-limit variants) whose swap context is threaded through every intervening venue leg (Turbos, DeepBook, Cetus observed), terminated by router::confirm_swap. Most routes are explicitly circular — USDC->USDC or SUI->SUI — and failed attempts abort inside confirm_swap with code 2, i.e. the route completed but did not beat the minimum-profit threshold. | 4,647 0.38% |
| botObfuscated multi-venue arbitrage executor (bytecode-decoded) A single-module executor with ~40 two-letter function names that our disassembly fully decoded: four flash-swap venue families (opener/closer pairs like fla/flra), a dozen direct-swap adapters, and a terminal gz<T> that enforces a minimum profit and converts the residual balance to a coin. Only 11 of 285 observed attempts succeeded (96% failure) — an MEV searcher running high-frequency, mostly-unprofitable probes behind deliberate obfuscation. | 4,401 0.36% |
| botFlash-loan arbitrage via universal router + Turbos leg The same flash-loan + universal-router arb envelope with a Turbos pool-factory swap_router::*_with_return_ leg inside it (the returned coins feed later route legs or repayment). About 37% of the attempts we observed succeeded (89 of 239) — the best hit rate among the flash-route variants, same searcher pattern. | 3,966 0.32% |
| botObfuscated flash-loan arbitrage adapter ('para' module) A four-call route on an obfuscated package our AI decoded from bytecode: para::flash_loan_base/quote (borrow, constructing a SwapReceipt), move_balance_a_from_receipt, side-matched repay_loan_base/quote, then me/tr — disassembly-proven to merge residual profit into a coin or transfer it to the sender. We observed only 29 of 261 attempts succeed (~89% failure) — another obfuscated searcher grinding mostly-unprofitable flash cycles. | 3,285 0.27% |
| botObfuscated atomic router — flash-backed multi-hop arb route (bytecode-decoded) A private, fully obfuscated router package (0x1db0..., module jk with names like xa/cbx/bfay/rtb) whose bytecode our AI disassembled: xa/xb borrow DeepBook flash loans, ca/cb and bfa/bfb execute Cetus and Bluefin swaps, cax/bfax open flash-swap receipts with corresponding closers, d3a/d3b place DeepBook market orders, and the mandatory terminal rtb enforces a minimum output and sweeps the residual balance. In short: an atomic cross-venue arbitrage bot with no public brand. | 2,512 0.20% |
| botObfuscated multi-DEX router (jk) — flash-swap route, near-total failure The notorious jk package (0xa9a5...): 13 one-to-three-letter function names that resisted identification until our AI decoded the bytecode, showing cax/cbx open Cetus flash swaps (cay/cby repay), bfax/bfbx do the same on Bluefin, and the terminal xz enforces a minimum output. Behaviorally it is a single arbitrage bot — one sender produced ~95% of the 235 transactions we analyzed, with a 95.7% failure rate, i.e. it spams atomic arb attempts that usually abort when the edge has vanished. | 2,436 0.20% |
| botObfuscated flash-swap arb adapter (clone deployment) Package 0x520c... is instruction-identical bytecode to another obfuscated arb adapter (0xa505...) apart from its self-address — the operator redeployed the same code. Its para module opens Cetus flash swaps or DeepBook-style flash loans, moves balances through receipts, and repays; observed routes ran at roughly 90% failure (e.g. 6 of 86 Cetus flash-swap routes succeeded), classic spray-and-pray atomic arbitrage. | 2,239 0.18% |
| botDLMM wrapper — flash-swap route leg A thin wrapper (0x42e8...) over an unbranded DLMM (bin-liquidity) pool implementation: every transaction pairs a pool::flash_swap(_with_partner) opener with its repay closer, identical type arguments, and receipt consumption. Nearly all observed traffic is the partner-fee flash-swap pair, i.e. this DLMM being tapped as a priced liquidity leg inside atomic routing rather than by direct LPs. | 2,142 0.17% |
| botThreshold vault — withdraw/swap/redeposit cycle (vault arb keeper) A vault-custody arbitrage cycle: the threshold vault (0xf0b2...) withdraws a balance, routes it through a two-asset CLMM adapter's swap_a2b/swap_b2a legs (0x3e34...), and redeposits via deposit_with_threshold_and_event, which enforces a minimum-output threshold before accepting the funds back. We observed 83 successes against 74 failures — a profit-gated bot that frequently aborts when the threshold is missed. | 2,106 0.17% |
| botCustom Cetus CLMM wrapper — flash-swap route A custom adapter package (0x45d4...) exposing cetus_clmm_flashswap_a2b/b2a openers and corresponding repay closers; each transaction runs the exact open-first/repay-last bracket with receipt consumption. Successful transactions emit canonical Cetus pool SwapEvents, proving the venue; the wrapper itself is one operator's private routing shim used to source Cetus liquidity flash-style inside atomic strategies. | 2,101 0.17% |
| botObfuscated jk router — pure flash-swap multi-hop route The single-package variant of the obfuscated jk (0xa9a5...) router: an opener from cax/cbx/bfax/bfbx (bytecode-proven Cetus/Bluefin flash-swap openers), a chain of swap hops, the corresponding closer, and a terminal xz minimum-output settlement — with no other package involved in the transaction. This is the same essentially single-sender arbitrage bot whose broader activity ran at ~95% failure; these are its self-contained atomic route attempts. | 1,963 0.16% |
| botDeepBook v3 flash-loan arb wrapper (bytecode-decoded d3 module) An obfuscated wrapper (0x68cc..., module d3) whose disassembly maps ba/bb to DeepBook borrow_flashloan_base/quote, a/b to pool::swap_exact_quantity, and ra/rb to validated flash-loan repayment; every route runs a borrow-first, repay-last bracket with the FlashLoan receipt threaded through. It is a purpose-built atomic arbitrage vehicle funded entirely by DeepBook flash loans, and observed failures are unprofitable attempts that abort before repayment. | 1,798 0.15% |
| botMulti-DEX settlement router — nonce-bumped arb route (84% failure) A private router (0x167d...) with per-venue modules (deepbook_router, cetus_router, bluefin_router, momentum_router) whose every transaction ends in settlement::settle -> nonce::bump — a replay-protected settlement discipline typical of a competitive searcher. In the period we analyzed, only 31 of 198 transactions succeeded; the 84% failure rate is an arb bot burning gas on missed opportunities across four venues. | 1,578 0.13% |
| botBluefin CLMM — flash-swap route leg (0x760d adapter) A flash-swap route through an unbranded adapter package (0x760d) whose bluefin_clmm_flashswap/repay_flashswap pairs demonstrably hit Bluefin's canonical pools, confirmed by the emitted LiquidityRemoved/UserFeeCollected-family events. The flash receipt is repaid within the same transaction; this adapter shape is characteristic of programmatic routing and arbitrage rather than wallet UIs. | 1,001 0.08% |
| botGuarded CLMM inventory-rebalance keeper (unbranded venue) An owner-gated keeper: a guard call that verifies the sender, a clock deadline, and a monotonic nonce (all confirmed in bytecode), followed by an obfuscated strategy call our AI decoded from disassembly — it compares target vs current BalanceManager holdings and repeatedly executes paired CLMM flash swaps until the requested inventory shift is met. Market-making inventory management on a CLMM venue we leave unnamed here. | 789 0.06% |
| botDeepBook v3 — flash-loan-funded route Paired borrow_flashloan_base/quote → return_flashloan_base/quote on the 0x337f DeepBook deployment, with the receipt consumed by the matching return and intervening swap legs funded by the borrowed coin. Zero-capital arbitrage routing using DeepBook as the flash-liquidity source. | 685 0.06% |
| botDeepBook flash loan → Cetus arbitrage bot (mostly failed probes) A dedicated arb pipeline: DeepBook v3 borrow_flashloan_base/quote, one to four Cetus adapter legs (jk::cetuswap_0/1) each consuming the prior result, then receipt-backed repayment. We observed 103 successes against 542 failures — a bot continuously probing for profitable cycles and aborting (e.g. at the balance split) when the route is unprofitable. | 611 0.05% |
| botUniversal router — flash-loan-enclosed route (unbranded aggregator) A complete build → start_routing → next → finish_routing → settle session on an unbranded universal-router aggregator (package 0xc263, with partner/commission support), enclosed by a paired flashloan_quote/return from a separate flash-loan package. We observed 65 successes against 605 failures — overwhelmingly failed arbitrage attempts. | 597 0.05% |
| botObfuscated flash-arb helper (bytecode-decoded, ~97% failed attempts) A private obfuscated helper whose single-letter functions our AI decoded from disassembly: dbb/dbq open DeepBook flash loans, drb/drq repay them, ea/eb are DeepBook swaps, and am/ga/gb/lb/ta wrap AMM, CLMM flash-swap, DLMM flash-swap, and lending-token/CPMM conversions. Only 5 of 160 executions we observed succeeded — a single operator's arb bot spamming mostly unprofitable probes. | 458 0.04% |
| botFlash-funded order-book arbitrage inside a Magma router context Orderbook::swap legs from a dedicated adapter (0xe1d9) threaded through a Magma router new_swap_context/confirm_swap session, with a flash-liquidity lifecycle enclosing the route. A flash-funded order-book arbitrage pattern; the venue brand behind the adapter was not established. | 443 0.04% |
| botFlash-loan universal route with dedicated pool-wrapper leg The same unbranded universal-router + flash-loan bracket as the other universal flash routes, distinguished by a dedicated pool-wrapper swap leg inside the route. Zero-capital routing/arbitrage executed programmatically; each transaction records the flash loan, router session, and wrapper swap. | 411 0.03% |
| botObfuscated multi-venue balance-route executor (Ferra/STEAMM/Momentum) An obfuscated route executor our AI decoded from bytecode: fda/fdb call Ferra lb_pair::swap, spa runs a STEAMM/Suilend bToken mint → CPMM swap → burn route, mma/mmb wrap Momentum flash swaps, and cdb/fb wrap further unbranded flash-swap venues, all threaded as a balance chain. A private multi-venue arbitrage bot. | 322 0.03% |
| botVault-funded flash-swap arbitrage strategy (Bluefin/Turbos/Cetus executors) Package-internal strategy modules (bfx/tfx/cfx) that fund flash swaps from their own vaults, verify repayment, and emit either a BSE result-summary event or an EE no-execution event — i.e. the strategy can deliberately no-op when conditions aren't met. A self-contained vault-capitalized arb/rebalance bot spanning three CLMM venues. | 308 0.03% |
| botTurbos — flash-swap route via arb wrapper Wrapper 0xcabe opens a receipt-returning turbos_clmm_flashswap_b2a, routes the borrowed coin, and repays with the opening receipt. Both instances we observed were failed attempts, consistent with an opportunistic arbitrage bot probing Turbos pools and aborting when the route is unprofitable. | 201 0.02% |
| botObfuscated multi-pool flash-swap arb bot (0x5f95) Bytecode-decoded entrypoints c1::c0p_ls, cm::cm0p_ls, and cf2::cf2p_ls in one obfuscated package each borrow venue balances plus a flash receipt and later consume the receipt in repayment — three ABI variants of a package-internal multi-pool flash-swap strategy. All five transactions we examined were failed attempts, so a large share of this volume is unprofitable probes. | 188 0.02% |
| botThreshold-guarded treasury conversion cycle withdraw_coin_with_event releases treasury assets, exactly one conversion call consumes that result, and deposit_coin_with_threshold_and_event redeposits only if the returned amount clears a minimum. An automated operator loop cycling a treasury asset through one swap; 7 of 12 runs we observed aborted on the threshold check, i.e., the bot frequently fails to clear its min-out. | 187 0.02% |
| botProprietary vault-strategy swap bot (0xcfba) Package-internal ffx/hd1 modules withdraw coins from the strategy's own vaults, execute a pool swap (hd1 consumes supplied oracle objects first), redeposit balances, and emit a BSE result-summary or EE no-execution event. Sibling modules bfx/tfx/cfx in the same package run flash-swap arbitrage, marking this as one proprietary strategy operator's non-flash swap leg. | 177 0.01% |
| botObfuscated arb adapter 0x520c — DeepBook+Cetus flash route An intentionally obfuscated flash-arbitrage adapter (0x520c61..., instruction-identical to a sibling adapter at 0xa505...) whose function names (d3b conversion, r_c_f_s_* closers, move/take_balance receipt plumbing) our AI decoded from the obfuscated bytecode; the route encloses a DeepBook conversion and a Cetus leg inside the package's own flash borrowing and settlement. Classic spray-and-pray MEV: of 128 transactions we analyzed from this package, only 8 succeeded (~94% failure), each failure aborting in the repayment/profit check. | 38 <0.01% |
| botDeepBook gate strategy — flash-backed swap route A private strategy package whose gate::swap_b2a wraps DeepBook swap_exact_quantity, disposes of remainders and returns the output coin, enclosed by a vault loan/repay pair (or DeepBook's own borrow/return receipt), with every coin passing through the gate both fed from and consumed by other commands. A receipt-verified flash-loan arbitrage bot routing through DeepBook. | 36 <0.01% |
| botFerra DLMM arb bot — vault-loan flash route An arbitrage strategy that borrows from a private vault (vault::loan returns a coin plus a Receipt), routes the coin through a Ferra DLMM swap, runs an explicit profit check, and repays the exact receipt. The enclosing loan/route/check/repay wiring is visible in the transaction structure; this is a self-funded (vault-capitalized) arb bot rather than user swap traffic. | 16 <0.01% |
| botCetus — flash-loan borrow/repay route Transactions whose only calls into this Cetus CLMM package are exactly balanced `pool::flash_loan` / `pool::repay_flash_loan` pairs — uncollateralized pool borrowing wrapped around external route legs. This is flash-loan arbitrage plumbing: the loan finances whatever venue hops sit between open and repay, executed atomically by strategy bots. | 13 <0.01% |
| botDLMM partner flash swap with treasury settlement A strategy bot withdraws from its own treasury vault, opens a partner flash swap on a DLMM pool, repays with the withdrawal, and redeposits proceeds through a threshold-checked deposit (successful runs emit `WithdrawEvent`, `SwapEvent`, `ReceiveRefFeeEvent`, `DepositEventWithThreshold`). We observed this cycle failing 14 of 15 times — near-continuous attempted arbitrage that rarely clears its own profit threshold. | 12 <0.01% |
| botScallop flash-loan-backed arbitrage route A thin wrapper contract borrows a balance from Scallop's `borrow_flash_loan`, threads it through result-wired external venue legs, and repays the receipt via `repay_flash_loan` — classic flash-loan arbitrage with the loan receipt provably consumed by the repayment. Half of the observed transactions failed, i.e. attempted routes that aborted before profit. | 11 <0.01% |
| Swaps & aggregator routing | |
| humanCommission-taking swap router (front-end/bot interface) Every PTB starts with router::split_with_percentage_for_commission + split_with_percentage carving a fee off the input coin, routes through venue hops (Aftermath, Cetus, DeepBook, FlowX, Turbos, external Magma observed), and ends in finalize — emitting CommissionRecord/OrderRecord/HopRecord events. This is the on-chain footprint of a fee-charging trading interface (Telegram-bot / front-end style) executing user swaps; ~34% of the attempts we observed failed, consistent with retail slippage settings. | 6,464 0.53% |
| mixedUniversal router (unbranded aggregator) — completed swap route A complete build -> start_routing -> [next...] -> finish_routing -> settle session on the universal-router package (0xc263..., modules include treasury, partner_manager and commission — a fee-charging DEX aggregator whose brand we have not been able to confirm). It serves both retail-style aggregated swaps and as the routing backbone that the flash-loan arbitrage routes wrap; the figures here cover the standalone, non-flash-funded routes. | 5,962 0.48% |
| mixedCetus CLMM — swap via official pool_script periphery A single pool_script_v2::swap_a2b/swap_b2a call on a package with the full Cetus integrate-script module set (pool_script, router_with_partner, stable_farming) depending directly on the Cetus CLMM core (0x1eabed72). Ordinary routed swaps — observed pairs included USDC/SUI, DEEP/SUI and memecoins like JACKSON and ZAMA — with ~99.8% success, i.e. real trade flow rather than arb probing. | 4,647 0.38% |
| mixedBluefin Spot (CLMM) — direct swap (gateway swap_assets) A single gateway::swap_assets call on the Bluefin Spot gateway where one side of the trade is a freshly created coin::zero — the SDK's exact-input swap shape. We observed 226 such swaps with only 2 failures, emitting Bluefin's original-package AssetSwap event; plain spot trading routed through Bluefin's own periphery. | 4,488 0.36% |
| humanMagma Finance (CLMM) — router-mediated swap The full Magma swap lifecycle: router::new_swap_context -> magma::swap -> router::confirm_swap (+ optional coin cleanup) across Magma's two packages; Magma Finance is a verified, audited CLMM on Sui. We observed a 17.5% failure rate spread across 7 distinct trader wallets — not one bot — trading a single USDC<->MAGMA pair, with failures consistent with confirm_swap slippage guards. | 4,377 0.36% |
| mixedUnbranded orderbook venue — swap leg inside Cetus Aggregator V3 session An orderbook::swap adapter call (venue package 0xbf7915..., no public brand identified) executed inside a Cetus Aggregator V3 routing session, bracketed by the aggregator's new_swap_context ... confirm_swap lifecycle. Effectively this is aggregator order flow being filled against a small on-chain orderbook rather than an AMM pool. | 2,314 0.19% |
| botOracle-priced SUI/USDC pool — swap_buy/swap_sell A pool that prices SUI/USDC trades off an oracle rather than an internal curve (pool::swap_buy / swap_sell, emitting SwapExecutedV2); the protocol brand remains unidentified. In observed traffic its swaps appear predominantly as legs inside vault withdraw/redeposit cycles (e.g. vault::withdraw -> swap_buy -> adapter swaps -> threshold deposit), so the flow is largely programmatic strategy execution rather than retail swapping. | 2,005 0.16% |
| mixedCetus Aggregator V3 — settled route via Cetus adapter A fully-verified Cetus Aggregator V3 session (router package 0xde5d..., docs-confirmed): new_swap_context opens a balance-carrying context, only the official Cetus adapter executes legs inside it (including fixed-output flash-swap receipt pairs), and confirm_swap enforces slippage and emits ConfirmSwapEvent. This is mainstream aggregator order flow; we measured substantial failure shares on these aggregator routes (roughly 40% attempted-but-aborted), reflecting slippage reverts and bot usage mixed with retail. | 1,618 0.13% |
| mixedCetus Aggregator V3 — settled route via Bluefin adapter The same rigorously-verified Cetus Aggregator V3 context/confirm lifecycle, but with all in-context legs executed by the official Bluefin adapter (0x4e7c...) — Cetus's aggregator routing user order flow into Bluefin Spot pools, with successful transactions emitting Bluefin AssetSwap plus the aggregator's ConfirmSwapEvent. Notable as cross-protocol composition: Cetus's router monetizing Bluefin's liquidity. | 1,472 0.12% |
| mixedFee-tiered CLMM (Turbos-style pool_factory) — A-to-B swap swap_router::swap_a_b on a CLMM whose three type arguments are the two coins plus an explicit fee tier (e.g. FEE500BPS/FEE10000BPS), the pool_factory/position_manager/swap_router layout used by Turbos-style CLMMs; the exact brand is unconfirmed. Observed swaps include long-tail meme pairs (e.g. MIU/SUI), consistent with ordinary user swap flow on a mid-tail DEX. | 1,433 0.12% |
| mixedCetus — router swap with threshold/settlement consumption A single router::swap on Cetus's pool-script router package (0xae9c...), whose bytecode internally opens and repays a pool flash_swap and returns two coins, with the results consumed by check_coin_threshold or transfer_coin_to_sender settlement. This is the standard Cetus SDK swap path — every transaction we examined succeeded, i.e. well-quoted retail/integrator swaps rather than racing bots. | 1,425 0.12% |
| mixedCetus — direct wrapper swap (single-call integrator shim) A minimal third-party wrapper (0xfa55...) exposing only cetus::swap_a2b/swap_b2a; each transaction makes exactly one such call, with the output handled by MergeCoins/TransferObjects. Observed transactions emit genuine Cetus SwapEvents on pairs like ZAMA/SUI with ~95% success — some integrator's or trader's own thin swap entrypoint over Cetus pools. | 1,229 0.10% |
| mixedCetus Aggregator V3 — multi-venue route (Cetus + Bluefin adapters) A Cetus Aggregator V3 session that splits or chains one order across both official adapters — Cetus pools and Bluefin Spot pools inside the same slippage-checked context lifecycle, with every leg tied back to its opening context and final confirmation. The multi-venue split is the aggregator doing genuine best-execution routing rather than a single-pool passthrough. | 1,083 0.09% |
| mixedFee-tiered CLMM (Turbos-style pool_factory) — B-to-A swap The reverse-direction twin of the A-to-B flow: swap_router::swap_b_a on the same fee-tiered CLMM whose third type argument encodes the pool's fee tier (FEExxxBPS). Ordinary directional user swap flow on this mid-tail DEX, emitting the pool's native SwapEvent in observed successes. | 1,016 0.08% |
| mixedCetus DLMM — flash-swap execution Swaps on Cetus's DLMM (bin-liquidity) pools, which execute as a flash_swap → optional pay_amount → repay_flash_swap bracket with the receipt wired into repayment; the events trace to the underlying 0x5664 DLMM pool. Used both for direct swaps and as legs inside routed and arbitrage flows, with a meaningful failure share — we observed 143 successes against 40 failed attempts. | 1,007 0.08% |
| mixedMagma Finance — full router-mediated swap route The complete Magma Finance router lifecycle — new_swap_context → one or more venue swap legs (Magma AMM, plus Turbos/Bluefin/Ferra adapters) → confirm_swap → transfer_or_destroy_coin cleanup. Magma is an audited CLMM AMM on Sui; our analysis found 7 distinct traders and a 17.5% failure rate consistent with slippage-guard aborts at confirm_swap. | 655 0.05% |
| mixedCetus CLMM — swap via 0x45d4 adapter One or more cetus_clmm_swap_a2b/b2a calls through the unbranded 0x45d4 wrapper, each output consumed by the next leg or a terminal transfer; the venue is confirmed by canonical Cetus SwapEvent emissions. The adapter's dual use for swaps and flash arbitrage suggests largely programmatic senders. | 471 0.04% |
| mixedBluefin CLMM — swap via 0x760d adapter One or more bluefin_clmm_swap_a2b/b2a calls through the unbranded Bluefin adapter, each result consumed downstream — standalone swaps not enclosed in any flash or router lifecycle. The venue is confirmed by canonical Bluefin events; senders are largely programmatic. | 394 0.03% |
| mixedUniversal router — multi-branch settled swap route A complete session on the unbranded universal-router aggregator with multiple routing branches (repeated start_routing/next/finish_routing under one build) ending in settle, with optional percentage-commission/partner-fee wiring. This is the aggregator's normal split-route swap settlement rather than a flash-funded arb, so it plausibly includes user-facing aggregator traffic. | 386 0.03% |
| mixedUnbranded swap interface — split-funded swap An interface::swap call on a specific package, fed by a split input coin; bytecode analysis shows it performs swap_out and emits a SwappedEvent. The action is a completed direct swap, but the venue's commercial brand was not established by our analysis; every instance we observed succeeded. | 235 0.02% |
| infraPeriphery pool — deferred swap settlement A dedicated two-type-argument periphery_pool::settle_swap entrypoint on package 0x08d1 that settles a previously initiated swap and emits SwapSettledEvent — the completion leg of an asynchronous, two-phase swap flow, which points at protocol-operated settlement rather than direct user trading. The venue's brand remains unidentified. | 138 0.01% |
| mixedTurbos Finance — direct pool swap A direct swap through Turbos' pool_script_v2 entrypoint, with the preceding coin result wired straight into the pool script; every such swap we observed emitted the pool SwapEvent and succeeded. Plain user swaps on the Turbos CLMM with no aggregator involved. | 67 <0.01% |
| botDeepBook v3 — direct pool swap A bare `pool::swap_exact_base_for_quote` against a specific DeepBook v3 package version, with the output consumed later in the transaction — no router, no balance manager. We observed this shape running 1 success to 7 failures, the signature of bots firing direct taker swaps at the book and frequently missing, rather than retail flow. | 13 <0.01% |
| mixedCetus Aggregator — context-bracketed single-venue Cetus swap An exact three-call shape — a context package's `cetus::start_swap`, a swap through the package Cetus documents as the CetusRouter adapter of Aggregator V3, and `cetus::confirm_swap` — i.e. an aggregator session that resolved to a single Cetus leg. The start/confirm bracket carries the slippage-checked swap context, so this is routed swap execution rather than a direct pool call. | 2 <0.01% |
| Liquidity provision & vaults | |
| mixedBluefin Spot (CLMM) — open position + initial liquidity pool::open_position followed by gateway::provide_liquidity_with_fixed_amount on Bluefin's CLMM gateway package (0xd075..., confirmed as Bluefin Spot: it emits events under Bluefin's original 0x3492 package ID). 15.9k opens against 11.9k reward-collect-and-close transactions over the same period indicates heavy automated position cycling (rebalancing LPs) on top of ordinary users, across pairs like DEEP/SUI, WAL/USDC, XBTC/USDC. | 15,913 1.29% |
| mixedBluefin Spot (CLMM) — collect rewards + close position gateway::collect_reward followed by gateway::close_position on the Bluefin Spot gateway — the exit half of the position-cycling pattern (11.9k closes vs 15.9k opens over the same period). Success emits PositionClosed under Bluefin's original package; the volume symmetry with opens points to automated LP rotation strategies harvesting incentives. | 11,897 0.97% |
| mixedCetus CLMM — open position with fixed-coin liquidity pool_script_v2::open_position_with_liquidity_by_fix_coin on the Cetus script periphery — opening a new concentrated-liquidity position and funding it from a fixed coin amount in one call. We observed 190 of 193 attempts succeed across pairs like USDC/SUI and DEEP/USDC; ordinary LP provisioning on Cetus. | 3,462 0.28% |
| mixedCetus CLMM — collect fees/rewards and close position The Cetus position-teardown chain: pool_script_v2 collect_fee / collect_reward (rewards repeated per incentive token), optional remove_liquidity, then pool_script::close_position, executed as one composite transaction. The standard exit path for Cetus LPs, mirror image of the open-position flow. | 3,416 0.28% |
| mixedBluefin CLMM — one-call smart close helper A third-party helper package whose single closer::close_smart call (7 type arguments, 6 inputs) atomically removes liquidity, collects fees and rewards, and closes a Bluefin CLMM position — we observed 146 of 146 succeed, emitting LiquidityRemoved, UserFeeCollected, UserRewardCollected, and PositionClosed from the Bluefin core package. The convenience-wrapper design suggests position-management tooling used both programmatically and by fronted users. | 2,433 0.20% |
| botObfuscated CLMM LP strategy — guarded position rebalance An obfuscated strategy wrapper (0x94a9..., functions h9af1d/h75c48) always preceded by a separate guard package whose disassembly shows owner, deadline, and monotonic-nonce checks — an operator-keyed keeper pattern. Event evidence proves the economics: the two h9af1d calls close/remove an existing CLMM position and the final h75c48 opens and funds a replacement (USDC/SUI pairs), i.e. an automated LP range rebalancer; all 163 transactions we analyzed succeeded. | 2,133 0.17% |
| mixedBluefin CLMM gateway — close liquidity position gateway::close_position on the package our analysis identified as Bluefin's current CLMM gateway deployment (0xd075..., emitting events typed against the original 0x3492... Bluefin package and corroborated by public docs). A plain LP lifecycle action — closing a Bluefin Spot concentrated-liquidity position — reached by both end users and position-management tooling. | 1,617 0.13% |
| botBluefin CLMM strategy vault — guarded rebalance with reward harvest An obfuscated Bluefin CLMM strategy package (0x5132...) behind the shared owner/deadline/nonce guard: disassembly proves h468a5 collects position rewards into the strategy's BalanceManager and hca0b6 conditionally unwinds the old position then opens and funds a new range (observed transactions emit LiquidityRemoved, PositionClosed, PositionOpened, LiquidityProvided in one transaction). A keeper-driven automated LP vault on Bluefin Spot. | 1,364 0.11% |
| mixedBluefin CLMM gateway — remove liquidity (with optional fee/reward collect) gateway::remove_liquidity on Bluefin's CLMM gateway (0xd075...), optionally followed by collect_fee and collect_reward in the same PTB. Ordinary Bluefin Spot LP withdrawal across a broad pair set (DEEP/SUI, WAL/USDC, XBTC/USDC and others in observed traffic), from both direct users and LP tooling. | 1,234 0.10% |
| botFerra DLMM — open bin position and seed liquidity (single LP bot) lb_pair::open_position immediately funded by add_liquidity whose position argument is the open call's own result — opening and seeding a bin-liquidity (DLMM) position on a package our analysis identified as Ferra's DLMM. Activity is dominated by a single LP-management bot — 378 of 380 observed transactions came from one sender with zero failures, cycling open/add/claim/close across bins. | 1,152 0.09% |
| botCustom Bluefin CLMM wrapper — remove liquidity and close position The position-close flow of a custom Bluefin adapter package (0x760d..., functions bluefin_clmm_remove_liquidity / collect_reward / close_position): removal first, close last, with the wrapper's uniform two-type-argument convention. This is the same private wrapper family (paired with a Cetus twin at 0x45d4...) used programmatically for LP management, not Bluefin's public entrypoints. | 1,055 0.09% |
| mixedCetus — close LP position (official router package) Position closes through Cetus's official pool_script entrypoints (package 0xae9c): bytecode analysis shows close_position conditionally removes all remaining liquidity and consumes the Position object, optionally preceded by fee/reward collectors that pay proceeds to the sender. Every instance we observed succeeded; this is the standard Cetus LP-exit flow used by both app users and automation. | 806 0.07% |
| mixedCetus — open LP position with liquidity (official router package) A single Cetus entrypoint (pool_script_v2, package 0xae9c) that creates a Position, adds fixed-coin liquidity, repays the add-liquidity receipt, and transfers the new position NFT to the sender — a complete position-creation lifecycle inside one Move call. The standard Cetus zap-in used from the app and by LP automation. | 805 0.07% |
| mixedBluefin CLMM gateway — open position and provide liquidity The 'gateway' package (0xd075) is Bluefin's current CLMM gateway deployment: its transactions emit event types from the original Bluefin package (0x3492 PositionOpened/LiquidityProvided), corroborated by public docs. This is the pool::open_position → gateway::provide_liquidity flow, i.e. new Bluefin LP positions opened through the gateway. | 765 0.06% |
| botBluefin CLMM — atomic smart-close helper A helper package (0x478f) whose closer::close_smart entrypoint internally removes all liquidity, collects up to five reward types, and closes the position in one call; these transactions emit Bluefin's canonical LiquidityRemoved, UserRewardCollected, and PositionClosed events. The single-entrypoint, all-success pattern points to an automated position manager rather than manual UI closes. | 754 0.06% |
| mixedCetus CLMM — close position via 0x45d4 adapter Position close (remove_liquidity, optional collect_reward, close_position) through an unbranded wrapper package whose calls demonstrably hit real Cetus pools, confirmed by canonical 0x1eabed... SwapEvent emissions. The same adapter also serves swap and flash-arb traffic, suggesting a programmatic LP-management stack rather than the official Cetus front end. | 656 0.05% |
| mixedBluefin CLMM — open position funded by an atomic Cetus swap A single PTB that swaps on Cetus and wires the swap output directly into opening and funding a Bluefin CLMM position — an atomic cross-venue zap-in. All 40 instances we observed succeeded; constructing this flow requires programmatic PTB assembly, pointing to zap tooling or LP-management automation. | 623 0.05% |
| mixedCetus CLMM — open position funded by an atomic Bluefin swap Mirror of the Bluefin variant: a Bluefin swap's output is wired in the same PTB into opening and funding a Cetus CLMM position. An atomic cross-venue zap-in that requires programmatic PTB construction; every instance we observed succeeded. | 499 0.04% |
| mixedBluefin CLMM — open position and add liquidity via 0x760d adapter bluefin_clmm_open_position followed by bluefin_clmm_add_liquidity through the same unbranded adapter used for Bluefin swap and flash legs, with the opened position feeding the add-liquidity call. The venue is confirmed by canonical Bluefin events; likely an LP-management stack operating alongside its Cetus twin (0x45d4). | 431 0.04% |
| botBluefin CLMM managed strategy — conditional position unwind An owner-gated strategy keeper: a guard call that verifies the sender, a deadline, and a monotonic nonce (confirmed in bytecode), followed by obfuscated strategy calls on package 0x5132, where disassembly shows h468a5 collects position rewards and hf55bd removes liquidity, collects fees, and closes the position. The unwind arm of an automated Bluefin LP vault that also has rebalance and open variants. | 430 0.03% |
| mixedUnbranded 'pool_factory' AMM — increase LP position liquidity position_manager::increase_liquidity (three type arguments) on a package our analysis identified as a self-contained pool_factory AMM and position manager with mint/increase/decrease/burn/swap and protocol-fee families; its commercial brand was not established. Routine liquidity top-ups on that venue. | 388 0.03% |
| botGuarded obfuscated LP strategy — position unwind The owner/deadline/nonce guard followed by an obfuscated strategy call (package 0x94a9, hd7d93) that our analysis identifies as the unwind arm of a guarded LP strategy wrapper with sibling rebalance and open operations. An automated LP vault keeper whose business branding is intentionally opaque; the mechanics are proven, the brand is not. | 362 0.03% |
| mixedUnbranded 'pool_factory' AMM — decrease liquidity and collect proceeds The exact decrease_liquidity → collect → collect_reward sequence on the unbranded pool_factory AMM's position manager — a partial LP withdrawal that also harvests fees and rewards. Counterpart of the liquidity top-up flow on the same venue. | 350 0.03% |
| infraBluefin managed-LP vault — harvest rewards + collect fees The managed-LP vault package (0xdd33) borrows the Bluefin position, collects its reward balance and both fee balances, and realizes them as vault income, emitting RewardHarvested and FeesCollected. Both calls share the same vault and pool inputs, so this is the vault operator's proceeds-collection keeper, not a retail LP. | 210 0.02% |
| mixedCetus CLMM — open position (bare pool call) A lone pool::open_position on Cetus's current mainnet CLMM package v14 (0x25eb..., confirmed against Cetus docs; events still emit under the original 0x1eabed package). Creates the empty position NFT before liquidity is added — a direct-integration path rather than Cetus's usual router scripts. | 207 0.02% |
| botBluefin CLMM strategy vault — open LP position (keeper) An exact two-call shape: an owner/deadline/monotonic-nonce guard (0xc721::h8b64d, decoded from bytecode) followed by obfuscated 0x5132::h39356::hca0b6, which disassembly shows conditionally removes or closes an existing Bluefin position then opens and funds a new one (the package imports Bluefin's CLMM). This is the open-only variant of a single operator's automated managed-LP rebalancer. | 203 0.02% |
| mixedCetus CLMM — full position exit via pool_script helper Removes liquidity and collects fees and rewards directly on Cetus CLMM v14, then closes the position through helper package 0xfbb3's pool_script::close_position — a complete LP exit split across Cetus's core and script packages. | 184 0.01% |
| humanBluefin Spot CLMM gateway — add liquidity gateway::provide_liquidity_with_fixed_amount on 0xd075..., confirmed as Bluefin's current CLMM (Bluefin Spot) gateway deployment — its transactions emit events typed under the original package 0x3492, and public Bluefin docs corroborate the upgrade lineage. The standard front-end path for topping up an existing position. | 176 0.01% |
| mixedCetus CLMM — open + fund position (adapter package) Position opening and initial funding through adapter package 0x45d4, whose transactions emit canonical Cetus 0x1eabed::pool events — proving it fronts Cetus pools rather than being an independent venue. | 155 0.01% |
| botObfuscated guarded LP strategy — open position (0x94a9) An exact shape: guard 0xc721::h8b64d (a bytecode-decoded owner check, deadline, and monotonic nonce) followed by 0x94a9::h147c2::h75c48, which emits CLMM OpenPositionEvent/AddLiquidityEvent. The open-only leg of a single operator's automated LP suite, whose three-call sibling (163 of 163 observed runs succeeded) collects rewards, closes, and reopens positions in USDC/SUI-family pools. | 141 0.01% |
| infraBluefin managed-LP vault — oracle-driven recenter The transaction parses a Wormhole VAA, threads it into authenticated Pyth updates for two feeds, then calls bluefin_lp::recenter, which takes the managed position from the capital vault, redeploys liquidity around the fresh price, and emits Recentered. A vault keeper rebalancing its Bluefin range; one run we observed was a failed attempt. | 132 0.01% |
| humanBluefin Spot CLMM gateway — exit position (+ residual swap) pool::remove_liquidity, fee and reward collection, then pool::close_position_v2 on Bluefin's CLMM gateway (0xd075), optionally ending with a pool::swap that converts one residual leg — the front-end 'exit and consolidate into one asset' flow. | 127 0.01% |
| mixedUnbranded CLMM (0x7028 lineage) — full position close Removes liquidity (RemoveLiquidityEvent), collects rewards and fees, then consumes the position in liquidity::close_position, emitting ClosePositionEvent. A well-formed CLMM whose commercial brand remains unidentified; the same package's flash-swap modules are separately used by opaque strategy vaults. | 121 <0.01% |
| mixedCetus CLMM — close position remove_liquidity plus close_position directly on Cetus's mainnet CLMM package v14 — the direct-integration counterpart to the bare open-position flow on the same package. | 116 <0.01% |
| mixedTurbos — close position via wrapper Through third-party wrapper 0xcabe: remove liquidity, collect both reward types against the same position, consume all returned coins, and finally close that position — a full Turbos LP exit packaged behind one helper. | 110 <0.01% |
| humanBluefin Spot CLMM gateway — open + fund position (pool entrypoint) pool::open_position whose result is wired into pool::add_liquidity_with_fixed_amount on Bluefin's CLMM gateway package — the pool-module variant of opening and funding a Bluefin Spot position; a gateway-module variant of the same flow also circulates. | 109 <0.01% |
| mixedTurbos — open position via wrapper The wrapper's turbos_clmm_open_position consumes prepared coins, returns the position NFT plus both remainder coins, and the transaction consumes all of them via later merge/transfer commands — position creation on Turbos routed through the same third-party helper package as the close and flash routes. | 99 <0.01% |
| mixedUnbranded CLMM ('pool_factory' stack) — mint LP position A single position_manager::mint with three type arguments on package 0xa5a0, a complete CLMM stack (pool_factory, swap_router, position_manager, flash swaps) that ranks among the highest-volume unbranded DEX packages we observed; its commercial brand could not be established from on-chain evidence, so we describe it structurally. | 93 <0.01% |
| mixedCetus DLMM — close bin-liquidity position update_position_fee_and_rewards first, then close_position and destroy_close_position_cert on the Cetus DLMM package (0x0489, whose swaps emit the underlying 0x5664 pool SwapEvent) — a full exit from Cetus's bin-based DLMM pools including final fee/reward settlement. | 92 <0.01% |
| mixedBin-liquidity wrapper (0x7fc4) — open + fund position with slippage check The wrapper's open_position internally opens the position, computes required token amounts, splits both input coins, repays the open-position certificate, and transfers the resulting Position to the sender; a follow-up utils call validates active-bin slippage. Records emit RewardSettleEvent, OpenPositionEvent, and AddLiquidityEvent; the underlying bin-based venue is unbranded. All seven instances we observed succeeded. | 87 <0.01% |
| mixedpool_factory AMM — harvest position fees and rewards Fee plus reward collection on the unbranded 'pool_factory' CLMM package (0xa5a0c2..., an AMM with position_manager/swap_router modules whose brand we could not establish even from full bytecode disassembly). These transactions run pure collect/collect_reward sequences with no liquidity change and no other protocols involved; the same package's swap legs are heavily used by arbitrage routes, but position collection is ordinary LP harvesting. | 67 <0.01% |
| humanCetus CLMM — collect position fees/rewards (canonical package) LP fee/reward collection against the canonical Cetus CLMM mainnet package 0x25ebb9... (version 14, the upgrade lineage of the original 0x1eabed7... package, whose event types the transactions still emit). Ordinary position holders harvesting accrued proceeds without touching liquidity. | 64 <0.01% |
| humanBluefin spot CLMM (gateway) — collect fees/rewards Fee and/or reward collection through the 'gateway' module of Bluefin's current spot CLMM deployment (0xd07533...): transactions call the new package but still emit event types from the original 0x3492c8... deployment, which is how our analysis identified the package as Bluefin. Collection is the only economic action in these transactions — plain LP harvesting. | 62 <0.01% |
| infraBluefin managed-LP vault — collect rewards and fees The bluefin_rewards management package calling collect_reward_and_fees_b_is_sui, which collects both pool rewards and fees for a managed position and emits ProfitConvertedToSuiV2 — i.e. vault profits realized and converted to SUI. This is the harvesting half of a managed Bluefin LP strategy (a companion operation recenters and redeploys the position), run by the vault operator rather than end users. | 51 <0.01% |
| humanCetus CLMM — add liquidity (canonical package) Liquidity additions to existing positions on the canonical Cetus CLMM package 0x25ebb9... (mainnet v14). Standard LP deposit flow, distinct from the open, close and collect operations on the same package. | 50 <0.01% |
| humanCetus periphery — collect fees and rewards Fee/reward harvesting through Cetus' pool_script periphery package (0xae9c20...): the v2/v3 collector entrypoints call the underlying pool, convert collected balances to coins and send them to the sender. These are pure collections with no accompanying position close; every one we observed succeeded. | 41 <0.01% |
| humanpool_factory AMM — burn position (terminal exit) Full position exit on the unbranded pool_factory CLMM, running the exact terminal sequence decrease_liquidity -> collect -> collect_reward (x2) -> burn: drain liquidity, harvest fees and both reward streams, then destroy the position NFT. Ordinary LP wind-down on a package whose brand we could not establish. | 25 <0.01% |
| humanUnbranded CLMM 0x702855 — collect position earnings Fee/reward collection on an unidentified CLMM at 0x702855...: collect::fee returns two coins and emits FeeCollectedEvent, collect::reward emits CollectPoolRewardEvent, and every returned coin is consumed by a later command in the transaction. The pool mechanics are fully established by bytecode analysis but the protocol brand is not; the same package also hosts an opaque flash-execution flow used by strategy bots. | 19 <0.01% |
| infraCommunity USDC pool — record opened hedge A community-pool USDC vault whose operator records hedges executed off-pool: opening mutates the active-hedge vector and aggregate totals, transfers the hedge coin, and emits UsdcHedgeOpened; the same package carries matching hedge-close and admin external-NAV attestation operations. On-chain bookkeeping of an externally executed hedging strategy, not a DEX trade. | 16 <0.01% |
| humanTurbos Finance — harvest and re-add liquidity A composite Turbos position operation: collect fee/reward proceeds and, in the same transaction, add fixed-coin liquidity to (or open) a position — effectively harvest-and-compound or harvest-and-adjust in one transaction. The harvested coins are consumed by the final add-liquidity call or transferred out; every such transaction we observed succeeded. | 14 <0.01% |
| humanLiquidity-bin AMM — add liquidity to existing position A direct `lb_pair::add_liquidity` call into an unbranded liquidity-bin (Joe LB / DLMM-style) pool package, topping up an existing bin position. Our analysis confirmed the mechanics and events of this venue but could not recover its commercial brand, so it is described generically as a liquidity-bin AMM. | 10 <0.01% |
| botBluefin CLMM — automated harvest, recenter, redeploy A position-management automation package atop Bluefin CLMM: one entrypoint collects rewards and fees, closes the drifted position, opens a replacement centered on the current price, re-adds liquidity, and emits `PortfolioCapitalRecentered` (a sibling flow converts profit to SUI via `ProfitConvertedToSuiV2`). This is programmatic LP rebalancing — vault/keeper behavior, not manual position management. | 6 <0.01% |
| humanTurbos — close liquidity or staked-liquidity position An LP tears down a Turbos CLMM position — including the staked-position variant closed through `staked_position_script_v2` — removing liquidity and emitting `ClosePositionEvent`/`RemoveLiquidityEvent`. These are direct pool-script calls from position owners rather than routed or vault-managed flows. | 6 <0.01% |
| humanUnbranded pool-script CLMM — collect position fees Fee harvesting on an unbranded CLMM DEX that clones the Turbos/Cetus-style `pool_script_v2` wrapper convention. Our analysis enumerated its full swap/open/add/collect/close function family across pairs like USDC/SUI and DEEP/SUI but could not attribute a commercial brand to the venue. | 4 <0.01% |
| humanLiquidity-bin AMM — claim fees, withdraw, close position Full position teardown on the unbranded liquidity-bin AMM: the exact sequence `collect_position_fees` then `remove_liquidity` then `close_position` in one transaction. The three-step exit (versus the rewards-inclusive four-step variant) implies the position had no active reward incentives to claim. | 3 <0.01% |
| humanLiquidity-bin AMM — claim rewards and fees, withdraw, close The complete exit for an incentivized bin position on the unbranded liquidity-bin AMM: collect position rewards, collect fees, remove all liquidity, and close the position in a single four-call sequence. The extra `collect_position_rewards` leg distinguishes farmed positions from the plain fee-only closes. | 3 <0.01% |
| humanLiquidity-bin AMM — claim fees and withdraw, keep position Partial de-risking on the unbranded liquidity-bin AMM: the exact `collect_position_fees` then `remove_liquidity` sequence pulls fees and liquidity out while leaving the bin position object open for later redeployment. | 2 <0.01% |
| humanTurbos — collect position fees and rewards An LP harvests a Turbos CLMM position without touching liquidity: the `pool_script_v3` collectors mutate supplied coin objects from the returned fee/reward balances, which the transaction then transfers to the owner. Distinct from the manage-liquidity composites that immediately re-add the proceeds. | 2 <0.01% |
| humanUnbranded pool-script CLMM — add liquidity to position A `pool_script_v2::add_liquidity_by_fix_coin` call on the unbranded pool-script CLMM DEX, adding fixed-coin liquidity to an existing position. Our analysis enumerated the package's readable Turbos-style wrapper API in full, but the venue behind it was never brand-attributed. | 1 <0.01% |
| humanDLMM pool wrapper — collect position fees and rewards Harvesting on an unbranded DLMM venue accessed through a wrapper package: the exact `update_position_fee_and_rewards` then `collect_position_fee` then repeated `collect_position_reward` sequence settles and pulls a bin position's accrued earnings. The wrapper fronts an implementation package with `dlmm_math`, `bin`, `pool`, and `position` modules whose commercial brand was not recoverable. | 1 <0.01% |
| humanCetus DLMM — collect position fees and rewards Fee and reward collection on a position in Cetus's DLMM (discretized bin-liquidity) product — the proceeds-only action, distinct from its close-with-rewards and flash-swap flows. We observed only a single occurrence, reflecting how new the Cetus DLMM product surface is relative to its CLMM. | 1 <0.01% |
| Lending & collateral | |
| mixedScallop — lending market operation (deposit/withdraw/borrow/repay/rewards) A single-verb transaction against the Scallop lending market wrapper (0xfe1d...): each transaction performs one operation among deposit, withdraw, enter_market_return, borrow, repay, or claim_reward_as_coin. Identity is confirmed by on-chain events (Scallop receipt-coin types, DepositEvent/WithdrawEvent/BorrowEvent/RepayEvent/ObligationCreatedEvent) — everyday money-market usage by depositors and borrowers. | 1,183 0.10% |
| humanSuilend — supply collateral The standard Suilend deposit flow in one PTB: supply liquidity to a reserve, mint cTokens, and deposit them into the sender's obligation as collateral. Ordinary user lending activity through the Suilend app. | 362 0.03% |
| humanNAVI — deposit and mint sCoin (liquid deposit token) A two-stage NAVI deposit confirmed by bytecode analysis: mint::mint accepts underlying liquidity and returns a market coin, which s_coin_converter::mint_s_coin consumes to lock the balance and mint the transferable sCoin (NAVI's liquid deposit receipt). Standard user lending flow that makes the deposit position composable. | 339 0.03% |
| humanAlphaLend (Alpha Lending) — add collateral add_collateral on the alpha_lending package — which appears to be AlphaFi's AlphaLend money market — accompanied only by the protocol's own update_price / fulfill_promise oracle-helper calls. Routine user collateral deposits; sibling flows cover borrow, repay, remove_collateral, and reward claims. | 233 0.02% |
| humanSuilend — withdraw collateral Withdraws cTokens from an obligation, redeems them, and fulfills the resulting typed LiquidityRequest hot potato — Suilend's canonical collateral-unwind path returning underlying liquidity to the user, with the request objects making the lifecycle wiring unambiguous. | 169 0.01% |
| humanAlpha Lending (AlphaLend) — remove collateral remove_collateral<T> on the Alpha Lending package returns a promise that must be consumed by fulfill_promise (or fulfill_promise_SUI), with oracle update_price calls appearing as helpers in the same transaction. Our analysis identified the package as Alpha Lending; all 102 transactions we observed on it succeeded. | 152 0.01% |
| humanSuilend — borrow borrow_request emits BorrowEvent and returns a typed LiquidityRequest that fulfill_liquidity_request consumes to release the borrowed liquidity — Suilend's hot-potato borrow lifecycle, which makes the flow unambiguous on chain. | 104 <0.01% |
| humanAlpha Lending — repay loan Users repaying debt on Alpha Lending, a lending market with market, position, rewards and SUI-staker modules. Repays typically ship in the same transaction as the protocol's own oracle price refresh (update_price, fulfill_promise), and every Alpha Lending action we observed succeeded. | 73 <0.01% |
| humanAlpha Lending — borrow Users drawing debt from Alpha Lending, with only the protocol's own oracle helper calls alongside the borrow in the same transaction. Part of the full lending lifecycle on this package (add/remove collateral, borrow, repay, claim rewards), all of which succeeded across everything we observed. | 63 <0.01% |
| humanAlpha Lending — claim incentive rewards Users claiming lending-incentive rewards from Alpha Lending's rewards module, accompanied only by the protocol's own oracle helper calls, just like the rest of the Alpha Lending lifecycle. Routine reward harvesting that succeeded in every case we observed. | 60 <0.01% |
| mixedNAVI — redeem sCoin for underlying Exit from NAVI's tokenized-deposit wrapper: burn_s_coin decreases sCoin supply and returns the locked NAVI market coin, which the same transaction feeds into redeem::redeem to get the underlying liquidity back (RedeemEvent). The burn output flows directly into the redeem call, making this the complete two-step unwrap — the mirror of the sCoin mint flow. | 31 <0.01% |
| mixedScallop — refresh veSCA-boosted incentive stake A balanced unstake/restake cycle on Scallop's incentive package ending in stake_with_ve_sca_v2, optionally enclosing reward redemption: the transactions emit ObligationUnlocked, an optional RepayEvent, ObligationLocked and the IncentiveAccountUnstake/StakeEvent pair. This is how positions re-lock to refresh their veSCA boost — a periodic maintenance pattern often performed automatically on the user's behalf. | 19 <0.01% |
| humanSuilend — claim obligation rewards Users claiming liquidity-mining rewards on their Suilend obligations: the claim entrypoints return reward coins and emit ClaimRewardEvent, with each reward coin merged or transferred within the same transaction. Straightforward reward harvesting on Sui's largest lending market. | 17 <0.01% |
| humanScallop — redeem lending incentive rewards Users redeem accrued Scallop lending-incentive rewards via the incentive package's `redeem_rewards`, which emits `IncentiveAccountRedeemRewardsEvent`, with every returned reward coin consumed by later commands in the same transaction. This is the standalone claim, as opposed to the veSCA-boosted unstake/restake refresh cycle that encloses redemption. | 13 <0.01% |
| mixedNAVI leverage vault — claim liquidity-mining rewards via delegate Claims accrued liquidity-mining rewards for NAVI leverage-farming positions through an owner-cap delegate module that validates the cap, emits `LeverageDelegationOperationPerformed` with a `ClaimLiquidityMiningReward` variant, then calls the underlying claim. A memorable bytecode detail: the on-chain entrypoint is literally named `claim_liquidity_minging_rewards` — the typo shipped to mainnet. | 6 <0.01% |
| humanNAVI — deposit collateral into lending obligation A single `deposit_collateral` call moving a coin into a NAVI lending obligation, emitting `CollateralDepositEvent`. It is the bare collateral-posting action, distinct from NAVI's sCoin mint/redeem wrappers. | 4 <0.01% |
| Perpetuals, options & derivatives | |
| infraBluefin Pro (perp DEX) — trade settlement with oracle refresh price_feed::update_price_feed immediately followed by exchange::trade_v3 on a perp-exchange package whose module layout corresponds to Bluefin Pro's off-chain-orderbook / on-chain-settlement architecture (attribution corroborated against Bluefin Pro docs). We observed ~5 sequencer addresses sending near-equal shares at ~99.8% success — this is the protocol's own settlement keeper writing the fresh mark price and settling the matched trade in one PTB. | 5,161 0.42% |
| infraBluefin Pro — operator batch trade settlement The Bluefin Pro perpetuals exchange settling batches of off-chain-matched trades on-chain: one or more identical 32-argument batch_trade_with_provided_gas_fee calls against the exchange's own package. This is the exchange operator's matching-engine settlement pipeline, not end-user transactions. | 911 0.07% |
| infraTypus — DeFi options vault round transition (keeper crank) Typus's DOV lifecycle advanced in one PTB: deliver the expiring round, settle, recoup, activate, and open the next auction, emitting DeliveryEvent, SettleEvent, RecoupEvent, ActivateEvent, and NewAuctionEvent (some variants wrap Scallop withdraw/deposit for the vault's idle capital). Protocol-operated round-cranking, matching Typus's documented vault lifecycle. | 242 0.02% |
| infraTypus Perps — funding-rate keeper (Pyth refresh) Keeper batches run one Pyth accumulator update per market and immediately feed the refreshed price into Typus trading::update_funding_rate, which mutates funding state and emits UpdateFundingRateEvent. Pure protocol maintenance of Typus's perpetual funding, with the oracle update result wired directly into each funding call. | 216 0.02% |
| humanWaterX prediction market — place order place_order validates the caller's account-permission object and creates a collateral-backed order via internal balance-backed order creation, emitting OrderPlaced in every record we observed, with the account-request result flowing directly into the lifecycle call. WaterX publicly describes itself as a prediction-markets product on Sui. | 119 <0.01% |
| mixedWaterX prediction market — fill order The explicit public fill_order lifecycle function matches against a resting order and updates positions, emitting OrderFilled in every record we observed — the taker/matching side of WaterX's collateralized prediction order flow. | 107 <0.01% |
| infraBluefin Pro perps — set funding rates (operator) One or more identical set_funding_rate calls (5 arguments, zero type arguments) on the Bluefin Pro exchange package — the exchange operator posting signed funding rates per perpetual market. | 96 <0.01% |
| infraBluefin Pro perps — apply funding to accounts Repeated apply_funding_rate calls settling accumulated funding against Bluefin Pro margin accounts. Runs as the operator keeper counterpart to set_funding_rate — we observed exactly 96 transactions of each in this window, consistent with paired batches. | 96 <0.01% |
| humanWaterX Predict — request position close First step of WaterX's two-phase position exit on its Sui prediction markets: request_close checks the account permission and updates the position via request_close_internal, emitting CloseRequested. Closes are request-then-confirm (with a cancel path), so a request only queues the exit; every request we observed succeeded. | 61 <0.01% |
| mixedWaterX Predict — confirm position close Second step of WaterX's two-phase exit: confirm_close (a single 7-argument call) finalizes a previously requested close and emits CloseConfirmed. The request/confirm split means settlement is decoupled from the user's request; confirm volume closely mirrors request volume in this period (57 vs 61). | 57 <0.01% |
| humanBluefin Pro — deposit to exchange bank Deposits into Bluefin Pro's internal asset bank (the exchange package that settles its off-chain orderbook on-chain): deposit_to_internal_bank mutates the bank and emits a Deposit event. Traders funding their perp accounts; the surrounding activity on the package (batch trades, funding-rate application) is operator-driven, but deposits and withdrawals are the user-facing edge. | 15 <0.01% |
| mixedBluefin Pro — withdraw from internal bank Withdrawal of collateral from Bluefin Pro's on-chain asset bank via `exchange::withdraw_from_bank`, emitting `Withdraw` — the exit path of its off-chain-orderbook, on-chain-settlement perp exchange. Withdrawals are user-initiated but flow through the same exchange settlement package whose trading is driven by a handful of sequencer/keeper senders. | 14 <0.01% |
| humanWaterX prediction market — cancel position-close request A trader on WaterX (a Sui prediction/position-trading product) cancels a previously requested position close; the account-permission request result flows into `cancel_close`, and the record emits `CloseCancelled`. WaterX runs a full request/confirm/cancel close lifecycle on its prediction positions, and every lifecycle action we observed succeeded. | 6 <0.01% |
| humanBluefin Pro — update account trading delegates An account holder on the Bluefin Pro perp exchange updates which addresses are authorized to act on their account; bytecode analysis shows the call capturing old and new authorized-account vectors and emitting `AuthorizedAccountsUpdated`. This is the delegation step that lets the exchange's operator/sequencer infrastructure trade and settle on behalf of the user. | 5 <0.01% |
| Games & gambling | |
| humanWheel — on-chain randomness wager (sponsored gas) A casino wheel game: SplitCoins carves the bet, wheel::play<SUI> consumes it against shared objects consistent with Sui's native Random plus Clock/config, and the payout is transferred back in the same transaction — bet, resolution, and payout are fully atomic with no claim step (a losing spin is still a 'successful' transaction). We observed sponsored transactions (sender is not the gas payer), so the operator subsidizes gas and the real player population is larger than naive sender counts suggest; one of a whole catalog of same-shaped games (coinflip, plinko, limbo, range) on sibling packages. | 1,281 0.10% |
| humanSweeTHouse — coinflip bet The SweeTHouse casino's coinflip: exactly SplitCoins → coinflip::play<T> (ten arguments) → TransferObjects of the settlement coin, emitting BetResultEvent plus rakeback, VIP, contest, and daily-streak events. Every bet we observed executed successfully (a losing flip is still a successful transaction); bet, resolution, and payout settle atomically in one PTB. | 568 0.05% |
| humanSweeTHouse — soccer wager The soccer game in the SweeTHouse casino catalog (sibling of coinflip/wheel/plinko/limbo, each on its own package with an identical play-shape): a split coin funds soccer::play, whose returned settlement coin is transferred back, emitting BetResultEvent<Soccer> plus wager-balance and pool-funding events. Bet and payout settle atomically. | 245 0.02% |
| humanSweetHouse casino — Plinko bet play_internal validates configuration, derives random slot outcomes from on-chain randomness, records the wager in a stake ticket, settles through the house, and returns the winnings coin, which the transaction must consume. All 23 wagers we observed succeeded. | 139 0.01% |
| humanPvP coinflip — create game (escrow stake) Player-versus-player coinflip: create_game converts the creator's stake coin into the shared Game object's balance and emits GameCreatedEvent, waiting for an opponent to join and resolve. Notably, cancellations (44) nearly match creations (51) in this period while join-and-resolve is rare, so most posted games never find a taker and the creator reclaims the escrow. | 51 <0.01% |
| humanLimbo — casino multiplier bet A Limbo-style casino game: play<T> consumes a stake coin, draws an outcome from Sui on-chain randomness, and returns a result coin, with the transaction wired SplitCoins -> play -> TransferObjects. Bytecode analysis confirms the entry ABI on the 0x89db6a... package; the operator brand is not established from on-chain data. | 50 <0.01% |
| humanPvP coinflip — cancel unjoined game Creators reclaiming their escrow from coinflip games nobody joined: cancel_game removes the Game object, withdraws the pot, emits GameCancelledEvent and returns the coin to the creator. Its volume (44) nearly matching game creation (51) shows most games expire unmatched. | 44 <0.01% |
| humanSweetHouse Range — casino range bet SweetHouse's 'Range' game: play_internal consumes the wager, creates a stake ticket, computes a randomized outcome, settles the ticket and returns the resulting coin, with every transaction wired SplitCoins -> play -> TransferObjects and emitting a core::BetResultEvent<range::Range>. Same casino suite as SweetHouse's Plinko and coinflip games. | 41 <0.01% |
| humanVendetta — start mission (on-chain mafia game) A fully on-chain mafia/turf-war strategy game: players hire scouts, train recruits, move gangsters, attack free or owned turf, and here start missions. Bytecode analysis confirms start_mission as a 15-argument entrypoint that validates the player and mutates mission and player state objects; these transactions touch only the game's own package. | 22 <0.01% |
| humanVendetta — move gangster between turfs A player action in Vendetta, a mafia-themed on-chain strategy game: `game::move_gangster` validates the player and mutates the turf state objects, calling nothing outside the game package. The game's whole action set (attack, missions, training, scouts) runs as small zero-type-argument entry calls, and every observed action executed successfully. | 11 <0.01% |
| humanVendetta — attack player-owned turf The PvP battle transition of the Vendetta mafia game: `game::attack_owned_turf` validates the attacking player then mutates the player, turf, and battle state objects in place through a 31-argument entrypoint — genuine battle executions against the game package itself. | 9 <0.01% |
| humanPvP coinflip — join and resolve wager A second player joins a peer-to-peer coinflip game whose creator's stake is escrowed in a shared `Game` object; `join_game` puts up an equal stake, resolves the flip, emits `GameResolvedEvent`, destroys the emptied escrow, and transfers the whole pot to the winner. This is player-vs-player escrow gambling, distinct from the house-banked SweeTHouse casino games we also observed on Sui. | 7 <0.01% |
| humanVendetta — attack unclaimed turf The PvE counterpart to Vendetta's turf battles: `game::attack_free_turf` (a 29-argument entrypoint) validates the player and executes the battle state transition against an unowned turf, expanding the player's territory. Like all Vendetta actions, it is a self-contained game-package call with no coins or type arguments involved. | 5 <0.01% |
| humanVendetta — hire scouts A Vendetta game-economy action: `game::hire_scouts` (an 8-argument entrypoint) validates the player and mutates player state to add scout units used for reconnaissance in the mafia strategy game, with the game package the only one called in the transaction. | 2 <0.01% |
| humanVendetta — train recruits One or more `game::train_recruits` calls (a 10-argument entrypoint) that validate the player and run the recruit-training state transition — Vendetta's unit-progression action, batchable within one transaction. Every Vendetta game action we observed executed successfully. | 1 <0.01% |
| NFT markets & collectibles | |
| mixedTradePort — place funded NFT bid(s) Creates one or more funded single- or multi-collection bids on TradePort (Sui's NFT trading aggregator), emitting CreateSingleBidEvent/CreateMultiBidEvent; every bid coin comes from a prior result in the same transaction, and multi-bid IDs are consumed later in it. Collection-wide offers of this shape are placed both by collectors and by automated bidding. | 112 <0.01% |
| humanTradePort — relist kiosk item at new price TradePort's relist entrypoint emits RelistSimpleListingEvent alongside the underlying orderbook Add/RemoveListingEvent pair — a seller repricing an existing orderbook-backed kiosk listing, with the kiosk borrow and return wired around the call. | 81 <0.01% |
| mixedTradePort — cancel NFT bid(s) Cancelling escrowed bids on the TradePort NFT marketplace: the bytecode reads the stored SingleBid/MultiBid, verifies buyer or admin authority, emits CancelSingleBidEvent and returns the escrowed balance to the bidder. Bid churn (create/cancel cycles as prices move) is typical of semi-automated NFT bidding, and cancels roughly track creates in volume. | 59 <0.01% |
| humanTradePort — create kiosk listing(s) Sellers listing NFTs through TradePort's orderbook-backed kiosk listings: the entrypoints emit CreateSimpleListingEvent plus the underlying orderbook AddListingEvent, and borrow/return kiosk variants preserve the borrowed-value wiring around the listing call. Every listing we observed succeeded. | 49 <0.01% |
| humanTradePort — accept NFT bid (sale) A seller hitting an open TradePort bid: acceptance consumes the bid and the NFT, emits MatchSingleBidEvent, and where the collection enforces a Sui TransferPolicy the returned TransferRequest is settled later in the same transaction (royalty/policy compliance). This is the actual sale leg of TradePort's bid book. | 44 <0.01% |
| humanTradePort — cancel kiosk listing Delisting on TradePort: the entrypoint emits CancelSimpleListingEvent plus the underlying orderbook RemoveListingEvent, removing the orderbook-backed kiosk listing. Routine seller-side listing management. | 29 <0.01% |
| humanRip Station — reveal card from pack The pack-opening moment of Rip Station, an NFT trading-card pack product: `reveal_and_return` pulls the deposited card out of reveal storage, mutates its metadata to the revealed state, re-locks it into the buyer's kiosk, and emits `CardRevealedEvent`. Bytecode analysis shows a full mint/buy/deposit/reveal/sell/burn card lifecycle with dedicated events for each step. | 10 <0.01% |
| humanRip Station — buy card packs Collectors buy one or more sealed card packs from Rip Station's vault, via either the plain recipient entrypoint or a personal-kiosk variant that also deposits the purchased cards straight into reveal storage; both paths emit `PackBoughtEvent`. Bytecode analysis shows the purchase records the purchased card IDs and optionally feeds them directly into the reveal flow. | 7 <0.01% |
| humanRip Station — sell card back to protocol A collector sells a card back: `sell_card` splits the sale fees, removes the card from the seller's personal kiosk, burns it, records the order, and emits `CardSoldEvent`. The burn-on-sale design means the protocol acts as a buyback sink rather than a resale marketplace. | 7 <0.01% |
| infraRip Station — operator mints card inventory The Rip Station operator mints new cards directly into a configured pack vault (`mint_cards` emitting `CardMintedEvent` per card) — inventory restocking that feeds later pack purchases, not a collector action. The same package exposes operator-only vault toggles and burn functions for inventory management. | 7 <0.01% |
| humanTradePort NFT auctions — place top bid A bidder on TradePort's NFT auction house redeems funds from their Sui address balance (`coin::redeem_funds` as the first command), then the bid entrypoint consumes that coin and emits `PlaceTopBidEvent`. The same package runs the full lot lifecycle — kiosk-borrowed lot submission, top-bid tracking, and settlement emitting sold/return events. | 1 <0.01% |
| Walrus storage | |
| infraWalrus — certify blob (publisher availability confirmation) The final step of a Walrus upload: system::certify_blob on the verified Walrus core package (0x98da...) submits the storage-node availability certificate that marks a registered blob as durably stored. Activity is publisher infrastructure, not end users: in the period we analyzed, the top 10 senders accounted for ~87% of these transactions with zero failures. | 2,883 0.23% |
| infraWalrus — register blob paid from address balance, with metadata A distinct Walrus upload path: WAL is redeemed from the sender's native address balance (coin::redeem_funds / send_funds scaffolding) rather than an owned Coin, then space is reserved, the blob registered, and metadata always attached — all 224 transactions we examined bundled the metadata pair. The consistent shape points to one uploader service's integration rather than ad-hoc users. | 2,476 0.20% |
| infraWalrus — reserve space and register blob (upload first half) The first on-chain half of a Walrus upload on the core package: system::reserve_space returns a Storage resource that is threaded directly into system::register_blob (optionally with metadata attachment), after which off-chain slivers are distributed and a later certify_blob completes availability. Like certification, this traffic is dominated by publisher/uploader services rather than end-user wallets. | 1,150 0.09% |
| infraWalrus archival wrapper — batch-extend shared blobs with WAL Two or more archival_blob::extend_shared_blob_using_token calls on a third-party archival wrapper (0xabd7..., distinct from Walrus core) that wraps blobs as shared 'archival' objects anyone can fund; each call pays WAL to push a shared blob's storage expiry further out. The repeated-call batching is a maintenance service keeping an archive alive epoch over epoch. | 1,139 0.09% |
| botWalrus — certify blob and attach metadata Walrus core storage writes: system::certify_blob (finalizing an already-registered blob once storage nodes have attested) immediately followed by blob::insert_or_update_metadata_pair. Our analysis of the Walrus core package shows heavy publisher-pipeline concentration — roughly five bot-like addresses account for the bulk of activity (top-10 senders around 87%), all successful. | 703 0.06% |
| botWalrus — wrap blob into shared archival object A third-party archival package (0xabd7...) takes an already-registered Walrus Blob and wraps it in a newly created SharedArchivalBlob that is immediately shared, making the blob a public shared object (e.g. so anyone can fund extensions). Bytecode analysis shows the exact create-UID/wrap/share_object sequence with no events; the two-owned-object input shape suggests an automated archival client rather than ad-hoc users. | 72 <0.01% |
| mixedWalrus — certify blob and wrap as shared blob Certifies a Walrus blob (`system::certify_blob`) and immediately wraps it in a `shared_blob::new` object — a publicly shared wrapper anyone can fund to extend the blob's storage lifetime, effectively a tip-jar for keeping data alive. We verified the function signatures against the public MystenLabs Walrus source, and the broader Walrus certify activity is heavily bot-driven (the top-10 senders account for around 87 percent of volume). | 9 <0.01% |
| Bridges & cross-chain | |
| infraChainlink CCIP — OffRamp OCR report commit (DON keeper) A single offramp::commit on the Chainlink CCIP OffRamp package — the DON's OCR3-signed commit of a cross-chain message batch (Merkle roots plus fee-quoter price updates) onto Sui, emitting CommitReportAccepted and Transmitted. No user assets move in this transaction; it is pure oracle-network infrastructure, and every commit we observed succeeded. | 1,125 0.09% |
| infraCircle CCTP — inbound USDC receive-and-mint receive_message returns a Receipt; the token-messenger handler consumes it, mints the native token, and emits MintAndWithdraw; then stamp_receipt and complete_receive_message finish the lifecycle with every call consuming the preceding result. Destination-side completion of a Circle CCTP transfer into Sui, typically executed by automated relayers on users' behalf. | 118 <0.01% |
| infraLiquidity bridge (unbranded) — verified withdrawal payout verify_request returns a VerifiedMessage that withdraw consumes, emitting WithdrewEvent and RequestedEvent — the destination-side payout of a cross-chain liquidity-pool bridge. The v2 package (0xccbe) has the same application logic as v1 with upgraded dependencies; executed by the bridge operator against users' verified deposit messages. The bridge's brand remains unidentified. | 115 <0.01% |
| infraLiquidity bridge (unbranded) — fulfill bridge-and-swap request init_fulfill_swap_request consumes the verified bridge message and returns a coin plus a SwapHotPotato; the coin is routed through a DEX leg and complete_fulfill_swap_request consumes both the hot potato and the routed output, emitting SwappedEvent — the bridge operator filling a user's bridge-in-with-swap order on the destination side. | 94 <0.01% |
| mixedWormhole — outbound bridge message publication Outbound cross-chain transfers that terminate in Wormhole core publish_message: token-bridge, NTT, fast-refund or MCTP routes where the message created by the earlier bridge/transceiver call is consumed by the publication. In every case publish_message follows a token transfer/burn or transceiver release, so this is genuine bridge-out traffic (users and bridge frontends), not free-standing keeper pings. | 66 <0.01% |
| infraLiquidity bridge — fulfill cross-chain swap request (relayer) The operator side of a swap-enabled liquidity bridge: init_fulfill_swap_request consumes a verified bridge message and returns a coin plus a SwapHotPotato, the coin is routed through a venue, and complete_fulfill_swap_request consumes the hot potato and routed output, emitting SwappedEvent — hot-potato-enforced swap-and-deliver of an inbound transfer. Bytecode analysis confirms the open/route/close chain; the v1 and v2 packages carry identical application logic. | 26 <0.01% |
| infraLiquidity bridge — verified withdrawal release Inbound release on the same liquidity bridge: verify_request returns a VerifiedMessage which withdraw consumes, emitting WithdrewEvent and RequestedEvent — delivery of bridged funds against a verified cross-chain message. Executed by the bridge's relayer flow rather than initiated as a fresh user action on Sui. | 24 <0.01% |
| humanxBridge asset manager — escrow and send cross-chain transfer Outbound leg of a small cross-chain asset manager: the send path serializes a TransferMsg, escrows or joins the user's coin, and calls connectionv3::send_message, emitting the connection Message event. User-originated bridge-outs; the matching inbound path (message verification, rate-limiting, escrow release) is relayer-operated. | 16 <0.01% |
| Publishing, social & AI agents | |
| humanInkray — publish free-access article Content publishing on Inkray (a decentralized publishing platform): vault::access_free returns an Access value that articles::post_with_cap consumes to create an Article and emit article-posted, with the returned article object transferred to the sender. Creator activity, part of a publication lifecycle whose create-publication sibling shares the package. | 302 0.02% |
| humanInkray publishing — create publication publication::create creates and shares the publication object, emits its publication-created event, and returns an owner capability that the transaction transfers to the creator. Inkray is an on-chain publishing platform; we also observe posting of free-access articles under publications as a companion flow. | 99 <0.01% |
| humanCharacter Hub — issue AI-agent capability AI-agent infrastructure: the owner of a Character Hub calls `issue_agent_cap_via_hub`, which validates hub ownership, creates an `AgentCap`, emits `AgentCapIssued`, and transfers the capability — an on-chain permission token letting an agent act for a character. This package manages `LivingCharacter` objects with hubs, pass-books, and manager whitelists; it is one of the few agent-identity systems we observed on mainnet, at only a couple of transactions. | 2 <0.01% |
| humanCharacter Hub — mint AI character from direct prompt Creation of an on-chain AI agent identity: `mint_direct_prompt` takes seven pure inputs (the prompt/attribute payload), creates a `LivingCharacter` object, registers its hub, and transfers it to the creator. With a single observed transaction, this captures the genesis of one character in a nascent AI-agent identity protocol. | 1 <0.01% |
| humanCharacter Hub — create access-management objects Sets up the permission layer for a character: `create_access_management` creates and shares a `PassBook` and a `ManagerWhitelist`, emitting `AccessManagementCreated`. These shared objects gate who may manage or access the AI character, complementing the transferable agent capabilities issued by the hub owner. | 1 <0.01% |
| humanCharacter Hub — rotate character and hub owner Ownership handover of an AI character: `reassign_owner_with_rotation_synced` updates the character object and its hub's owner in one synchronized call and emits `CharacterHubUpdated`. The 'rotation synced' design keeps the character and its controlling hub from ever pointing at different owners. | 1 <0.01% |
| Transfers & coin management | |
| mixedNative SUI transfer — split coins and send Pure PTB plumbing with no Move calls: SplitCoins off gas or an owned coin, then TransferObjects of the split results to a literal address. This is the canonical payment/withdrawal shape used by wallets, exchange hot wallets and bots alike; in every case the transferred objects are exactly the split results and the recipient is a literal 32-byte address. | 9,164 0.75% |
| mixedSui native — bare TransferObjects send A pure framework-level transfer: a single TransferObjects command sending gas or input objects to a 32-byte address supplied as a Pure input, with no MoveCall at all. This is the plainest possible Sui payment/asset send, used by wallets, exchanges, and scripts alike. | 3,111 0.25% |
| mixedStreaming payments — create and share a funded stream An unbranded streaming-payment protocol: the entrypoint consumes a funding coin, constructs a PaymentStream<T>, emits StreamCreated, and shares the object. In every instance we observed, the funding coin is wired from a preceding coin::redeem_funds address-balance withdrawal, indicating programmatic payment/vesting tooling; all observed creations succeeded. | 242 0.02% |
| mixedAdrenaline — rule-verified asset transfer An Adrenaline asset is optionally split, a transfer request is created, verified against the token's pass_rule policy, and confirmed, emitting AdrenalineSplitEvent/AdrenalineTransferEvent, with the split output feeding the transfer and the request flowing into verify and confirm. A closed-loop, policy-gated token transfer flow; the mechanics are clear from chain data, but the commercial brand behind Adrenaline remains unidentified. | 188 0.02% |
| humanYY Finance — internal-ledger payout withdraw_yyV1 verifies the sender's recorded balance, decrements it, increments a withdrawal counter, splits the backing balance into a coin, and transfers it to the sender — users cashing out of a permissioned internal ledger whose credits are posted separately by an operator via set_add_yy_balance. All 29 transactions we observed succeeded; the brand behind YY remains unidentified. | 98 <0.01% |
| Protocol operations & infra | |
| infraUnidentified derivatives venue — admin 'push regime' keeper call A single admin::push_regime call on a package whose modules (admin, oracle, pool, trader, liquidity_provider, settlement, version) and Wormhole/Pyth dependencies indicate an unbranded oracle-priced trading/derivatives venue. 14.3k transactions of what appears to be a protocol keeper continuously pushing a pricing/risk 'regime' parameter; we could not establish the protocol's identity. | 14,257 1.16% |
| infraUnbranded AMM — keeper multiplier update (SUI/USDC) Exactly two v2::update_mults calls per PTB, always with the SUI/USDC type pair, on a package that also exposes swap functions seen inside arb routes. A single keeper address sends 100% of this traffic with zero failures — most plausibly per-pool fee/liquidity-weight multiplier maintenance for a proprietary AMM, though the exact multiplier semantics remain unconfirmed. | 7,331 0.60% |
| infraTurbos Finance (CLMM) — protocol fee withdrawal pool_factory::collect_protocol_fee_with_return_v2 on the Turbos CLMM package (identified by its distinctive fee-tier type modules — FEE500BPS etc. — plus pool_factory/position_manager/swap_router layout), with the returned coins transferred out. 4.1k transactions of the protocol team sweeping accrued protocol fees pool by pool — surprisingly high-cadence treasury operations, not user activity. | 4,147 0.34% |
| infraUnbranded 'pool_factory' AMM — protocol fee collection with swap-out Bytecode analysis shows collect_protocol_fee_with_return_v2 checks a manager role before returning both protocol-fee coins; the PTB then routes one returned coin through Magma router swap contexts and transfers both routed and untouched coins. Protocol treasury operations: the team sweeping accrued fees and converting one side. | 283 0.02% |
| infraFaith — buyback: 90% burn / 10% staking deposit Faith's (faithgg_staking_v2 module) protocol buyback: the transaction runs a Magma router swap (new_swap_context -> Cetus leg -> confirm_swap) and wires the completed router result straight into burn90_and_deposit10, which splits the coin, burns 90% and deposits 10% as staking rewards, emitting BuybackApplied and RewardsDeposited. A protocol-operated keeper converting fees into token burn plus staker yield; every one we observed succeeded. | 67 <0.01% |
| infraFaith/Radiance — round-keeper crank Single-call keeper operations on Faith/Radiance's round_manager: crank_auto_entries_v2, settle_entry_v2, open_round_entry_v2 or snapshot_radiance_entry_v2, each standing alone with no other Move calls. All 159 such calls we observed succeeded, splitting roughly crank 68 / settle 43 / open 42 / snapshot 6 — a protocol bot advancing rounds, not player activity. | 64 <0.01% |
| infraCommunity USDC pool — close recorded hedge An operator of a community USDC pool closes a previously recorded hedge: the call removes the entry from the active-hedge vector, settles aggregate accounting, and emits `UsdcHedgeClosed`. The hedge itself is executed off-chain or elsewhere — the pool only books it on-chain, and the same package carries an admin-only external-NAV attestation call, so this is fund bookkeeping, not trading. | 12 <0.01% |
| Other | |
| botShared counter — bare increment (purpose unknown) A single counter::increment call on one package mutating one shared object — no type arguments, no events, no coin movement, and 100% success across every transaction we examined. The purpose is not provable from chain data; the cadence and triviality are consistent with a heartbeat, load-test, or on-chain activity ticker driven by a script. | 2,178 0.18% |
| mixedAdrenaline — asset join/mint/verified transfer The Adrenaline digital-asset protocol (0x3ebb...): observed activity falls into pure join batches (merging asset objects, emitting AdrenalineJoinEvent with one source object deleted), pure mint batches, or a split -> transfer -> pass_rule::verify -> confirm_request flow where a compliance-style rule check gates a confirmed transfer. The rule-verified transfer path suggests a permissioned/RWA-flavored asset system; the commercial identity beyond the module names is unconfirmed. | 1,977 0.16% |
| humanSunset — claim vested release into protocol balance history::claim_release on the Sunset package, whose bytecode shows an investment/vesting scheme: invest, stake, repurchase-with-points, dividend/reward/release exchange, and per-user released-amount accounting. This call updates the user's and the global released totals and credits the vested amount to the user's in-contract balance — users harvesting their vesting schedule; observed claims were uniformly successful. | 1,595 0.13% |
| humanSunset — claim accrued dividends/rewards into protocol assets The unbranded 'Sunset' staking/investment protocol (package 0xfe68): bytecode analysis shows the exchange_dividend_asset / exchange_reward_asset / exchange_release_asset entrypoints update a user's accrued accounting fields and transfer project assets out — effectively users converting accrued dividends, rewards, or vesting releases into tokens. Part of a full invest/stake/repurchase/claim lifecycle our analysis mapped from disassembly; the protocol's public identity remains unknown. | 748 0.06% |
| humanSunset — repurchase order from accrued points Sunset is an investment/staking protocol with on-chain order books of stake, investment, dividend and release accounting; repurchase mutates the user's points and power and appends a repurchase order. Notably fragile: repurchase attempts we observed frequently aborted, so a meaningful share of this period's 29 transactions are likely failed attempts rather than completed repurchases. | 29 <0.01% |
| humanCreek — stake XAUm tokenized gold Users stake XAUm (tokenized gold) in Creek's staking manager and receive the protocol's paired reserve (GR) and yield (GY) coins back in one transaction, each stake emitting `StakeEvent`. All observed stakes and unstakes succeeded, consistent with direct wallet users of a small gold-yield product. | 13 <0.01% |
| humanCreek — unstake XAUm tokenized gold The reverse of Creek staking: users burn both the reserve and yield receipt coins and get XAUm (tokenized gold) transferred back, with `UnstakeEvent` emitted in every observed case. Bytecode analysis shows `unstake` consuming both receipt coins in the staking manager before releasing the underlying. | 12 <0.01% |
| humanSunset — create investment order A user deposits assets into the Sunset protocol's `investment_v1`, which consumes the coins, routes or transfers the assets, updates the user's recorded power and accounting, and appends an investment order. Sunset is an unbranded staking/investment-scheme protocol with orders, accrued dividends, repurchase points, and vested releases tracked in package state; its economic product is not externally identified. | 5 <0.01% |
| humanSunset — stake into protocol balance A user stakes into the unbranded Sunset protocol: the input coin is converted to a stored balance and a `StakeOrder` is appended to the user's order history. Part of Sunset's order-ledger design in which invests, stakes, repurchases, and claims all append typed orders to package state. | 1 <0.01% |