all collections · daily · marketplace overlay
weekly · real (teal) vs wash (rose)
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 Sui package appears to implement a game's reward and progression system. (1) The primary object types managed are `AccoladeRewardRegistry` (which stores reward packs), `AccoladeThresholdMapRegistry` (which maps thresholds to reward packs), and `Player` (which tracks player progress and claimed rewards). `AccoladeReward` objects are dynamically created and stored within the `AccoladeRewardRegistry`. (2) Public/entry functions include: `create_reward_pack` which creates new `AccoladeReward` objects and adds them to an `AccoladeRewardRegistry`; `delete_reward_pack` which removes `AccoladeReward` objects from the registry; `map_threshold_to_reward` which associates a threshold with a reward pack ID within the `AccoladeThresholdMapRegistry`; and `claim_accolade_rewards` which allows players to claim rewards based on their progress, mutating the `Player` object by adding claimed rewards and potentially updating game resources like gangsters, perks, and other in-
This package defines a swap mechanism, primarily managing SwapPoints, SwapPointsConfig, FeeConfig, and GameRewardPool objects. The public/entry functions allow for administrative control over swap parameters and fees, as well as the core swap functionality. AdminCap objects are used for signature gating on administrative functions, ensuring only authorized users can modify configurations. The swap_flowx function facilitates token swaps, calculates fees, distributes them to developers and a committee, and adds a portion to a game reward pool, while also awarding swap points to the user. The system also includes a versioning mechanism via the SwapVersion object to ensure compatibility and controlled upgrades.
This package defines a "Crimes" game where players can engage in "blackmail" and "crack safe" activities. The primary objects are `BlackmailType`, `BlackmailRegistry`, `PlayerBlackmailInfo`, `Safe`, and `SafeRegistry`. Public/entry functions allow players to `record_blackmail`, which calculates success chance, loot, cooldowns, and level points based on player levels, blackmail type, and registry configurations, updating `PlayerBlackmailInfo`. The `validate_guess` function handles safe-cracking attempts, determining if a guess is correct, higher, or lower, and updates the `Safe` object's bounds or resets it. An admin `set_safe_config_value` function allows modifying `SafeRegistry` parameters. Notable patterns include version validation (`crimes_version::validate_version`), random number generation for success chances and loot (`random::new_generator`, `random::generate_u64_in_range`, `random::generate_bool`), and time-gating for safe cooldowns (`clock::
This Sui package manages various reward types for a "Vendetta" game, primarily through the RewardRegistry object. The dvd_authority module establishes a GovernorCap for administrative control and OperatorCaps for specific operational permissions, stored in an OperatorCapsBag. Public functions allow the GovernorCap to issue and revoke OperatorCaps, and to issue DVDCaps. The dvd_rewards module, guarded by OperatorCaps and a versioning system (dvd_version), enables the creation and modification of different reward structures: tiered rewards (Reward object) and spin rewards (SpinReward object). These rewards can include gangsters, game resources, perks, physical items, HQ aesthetics, spin tickets, and NFTs, all managed as dynamic fields within the RewardRegistry.
This package primarily manages a single object type, EventCap, which serves as an administrative capability. The init function creates an EventCap and transfers it to the deployer. All public/entry functions are event emitters; they take an EventCap as the first argument, indicating that only holders of this capability can trigger these events. These functions do not mutate any on-chain state directly but rather emit various game-related events such as raids, captures, rewards, upgrades, and player actions. A notable pattern is the use of an administrative capability (EventCap) to gate access to event emission, ensuring that only authorized entities can log these game events. There are no other notable patterns like time-gating, dynamic fields, vault/escrow, or royalties.
Wallets that share a funder, were co-funded by the same personal-scale source, or land in the same behavioral cluster. A heuristic, not proof of common control.
Tinted amber on the bubble map when they appear in the expanded graph.
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": "0xc368782d3601e826ce3f9a74742806e71acbbdef02214ed314b7923b0216c3c7",
"n_tx": 75,
"n_successful_tx": 75,
"n_distinct_epochs": 7,
"n_distinct_sponsors": 0,
"first_seen_cp": 164837452,
"last_seen_cp": 179434687,
"first_seen_ts_ms": 1751853069784,
"last_seen_ts_ms": 1755325030505,
"total_gas_spent_mist": 5806155452,
"n_self_sponsored_tx": 75,
"n_sponsored_tx": 0,
"gas_price_p50": 740,
"gas_price_p95": 741,
"active_hours_top24": [
23,
2,
10,
1,
22,
6,
7,
4,
5,
17,
12,
16,
15,
3,
9
],
"primary_archetype": null,
"labels": [],
"label_confidence": [],
"bot_score": 0,
"bot_signals": [],
"cex_label": null
}Top active hours by UTC. Circadian peak → likely W. N. America (Pacific/Mountain).
area + brightness = call volume; hover for detail