all collections · daily · marketplace overlay
weekly · real (teal) vs wash (rose)
counterparties · funders · clusters
Move packages this wallet published on-chain — what it shipped, not what it used.
This package defines a bot defense system with two primary objects: `BotDefender` and `BotTrap`. A `BotDefender` object, owned by a single address, tracks bot neutralization statistics, maintains a list of authorized defenders, and a list of known malicious addresses using dynamic tables. `BotTrap` objects are created by users to lure and neutralize bots, tracking their type, gas cost, and trigger count. Public functions allow the `BotDefender` owner to add authorized defenders and malicious addresses, and upgrade the defense level. The `neutralize_bot` function increments statistics on the `BotDefender` and emits a `BotNeutralized` event, while `validate_transaction` checks for suspicious activity based on defense level and known malicious addresses, emitting a `ThreatBlocked` event if detected. The system employs various "destruction methods" (`execute_gas_drain`, `execute_logic_bomb`, etc.) which involve computationally intensive loops, potentially as a form of resource-draining bot deterrent.
This package defines a bot defense system using two primary object types: `BotDefender` and `BotTrap`. A `BotDefender` object, owned by its creator, tracks defense statistics, stores authorized defenders, and maintains a list of known malicious addresses using dynamic fields (tables). `BotTrap` objects represent individual traps with a type, gas cost, and trigger count, also owned by their creator. Public functions allow creating these objects, adding authorized defenders and malicious addresses to a `BotDefender` (owner-gated), and arming/disarming `BotTrap`s (creator-gated). The `neutralize_bot` and `validate_transaction` functions simulate bot interaction, updating defender statistics and emitting events, with `validate_transaction` performing checks against the malicious address list and defense level. The system also includes functions that simulate various "destruction methods" (e.g., gas drain, logic bomb) which are called when a bot is neutralized.
This package defines a HoneypotToken object, which represents a token with specific properties like name, symbol, total supply, and a "honeypot" mechanism. The create_honeypot_token public entry function initializes a new HoneypotToken object, sets its initial state (including `is_armed` to true), and transfers ownership to the creator. It also emits a TokenCreated event. The trigger_payload public entry function is the core of the honeypot logic; it can only be called by the token's creator and increments a `trigger_count`. If the caller is not a "known attacker" (checked against a hardcoded list of addresses), the SUI coin passed to the function is transferred to the token's `recovery_address`; otherwise, it's returned to the caller. This function emits an AttackerInfected event. The get_token_info public function simply returns various fields of a HoneypotToken object. The notable pattern is the hardcoded list of "known attacker" addresses used for conditional asset transfer, acting
This package defines an AnomalyGenerator object that monitors transactions for anomalous behavior. It manages AnomalyProfile objects for individual addresses, storing their anomaly scores, types, and fees paid. Public functions allow creating an AnomalyGenerator, generating anomalies, and handling transactions, which can be normal, anomalous, or bait-consuming. The system applies fees to transactions, with a portion potentially returned to the sender and the rest sent to a recovery address. Notable patterns include dynamic fields (Table for anomaly_profiles), a blacklist (VecSet), and event emissions for critical anomalies, system compromises, and fee collection. The system also features a "bait" mechanism where a portion of the transaction value is held and potentially released based on system status.
This package manages a primary object type called CounterController, which tracks a target address, a defender address, an active status, and a count of "trapped" attempts. The public/entry functions allow a defender to create a CounterController, increment the trapped_count when a "drain attempt" occurs, and block or unblock the target controller. All these actions emit a CounterEvent. Notably, the trap_drain_attempt, block_target, and unblock_target functions are gated by the defender's signature, ensuring only the designated defender can modify the CounterController's state. The CounterController object is shared, making its state publicly accessible.
Where this wallet's SUI first came from, and what it seeded downstream. Observational: a CEX funder suggests a real/retail origin; a high-fanout non-CEX funder is a signal worth noting — not proof of anything.
{
"wallet": "0x832d99f9686b9c6efe5eb5a700f83045baa8594cc823bdd9e52d335bc9679fb4",
"n_tx": 478,
"n_successful_tx": 428,
"n_distinct_epochs": 113,
"n_distinct_sponsors": 0,
"first_seen_cp": 33518414,
"last_seen_cp": 209945263,
"first_seen_ts_ms": 1715183630559,
"last_seen_ts_ms": 1762621192883,
"total_gas_spent_mist": -1421094476,
"n_self_sponsored_tx": 478,
"n_sponsored_tx": 0,
"gas_price_p50": 750,
"gas_price_p95": 759,
"active_hours_top24": [
23,
22,
14,
13,
9,
8,
12,
10,
11,
1,
3,
21,
4,
15,
7,
0,
5,
6,
2,
16,
18,
20,
17
],
"primary_archetype": null,
"labels": [],
"label_confidence": [],
"bot_score": 0,
"bot_signals": [],
"cex_label": null
}Top active hours by UTC. Circadian peak → likely W/Central Asia / India.
area + brightness = call volume; hover for detail