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 defines a system for managing in-game assets, primarily focusing on cosmetic and weapon items. The `assets` module provides read-only data for various item attributes like names, chances (rarity), manufacturers, and colorways for different cosmetic and weapon types. The `attributes` module builds upon this by creating `VecMap` objects to store these attributes, and includes functions to validate cosmetic and weapon types, and to format cosmetic type names. The package appears to be setting up a framework for generating or managing a collection of customizable in-game items with defined rarities and properties, possibly for a game or metaverse application. There are no explicit vault/escrow, royalties, signature/allowlist gating, time-gating, or admin caps observed in the provided IR.
This Sui package manages user accounts, accolades, and reputation through a singleton System object. The primary object type is Account, which stores a user's alias, username, and creation date. Public functions allow users to create new accounts, update their alias and username, and transfer their Account object. The System object contains dynamic tables mapping addresses to their associated Account UIDs, and to lists of Accolade and Reputation objects. Accolades and Reputation can be added or removed from users, but these actions are gated by an admin role via the access_control and admin modules. The `assert_no_avatar` function prevents a user from creating multiple accounts.
This package manages user accounts, accolades, and reputation through two primary object types: System (and its upgraded version, SystemV2) and Account. The SystemV2 object stores tables mapping user addresses to their associated Account object IDs, accolades (Accolade), and reputation entries (Reputation). Public entry functions allow users to create new accounts (new_v2), update their account's alias and username, and transfer their Account object to another address (keep). Admin-gated functions (add_accolade_v2, remove_accolade_v2, give_reputation_v2, remove_reputation_v2) enable administrators to manage user accolades and reputation, requiring specific roles within an AccessControl and Admin system. The package uses dynamic fields (tables) to store user-specific data and includes an admin cap pattern for managing accolades and reputation.
This package defines an access control system using two primary object types: `AccessControl` and `Admin`. The `AccessControl` object stores a map of role names (byte vectors) to sets of addresses, effectively managing which addresses possess specific roles. The `Admin` object is an administrative capability that is tied to a specific `AccessControl` object. Public/entry functions allow an `Admin` to create new roles, add or remove addresses from roles, and check if an address has a particular role. Notably, all role management functions are gated by the "SUPER_ADMIN_ROLE", ensuring only authorized `Admin` objects can modify access control. The `init` function of the `admin` module initializes an `AccessControl` object and two `Admin` objects, granting the initial `Admin` object several predefined roles and sharing the `AccessControl` object publicly.
This package defines an access control system using two primary objects: `AccessControl` and `Admin`. The `AccessControl` object stores a map of roles (represented as byte vectors) to sets of addresses that possess those roles. The `Admin` object is a capability that links to a specific `AccessControl` object. Public functions allow a designated "SUPER_ADMIN_ROLE" to add/remove roles, and grant/revoke roles to/from addresses within a specific `AccessControl` object. The `init` function in the `admin` module creates an `AccessControl` object, defines several specific roles (e.g., "ACCOLADES_ROLE", "REPUTATION_ROLE"), and grants these roles to two newly created `Admin` capabilities, which are then transferred to the transaction sender. This establishes a role-based access control system where specific `Admin` capabilities are required to manage roles and perform privileged actions.
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.
area + brightness = call volume; hover for detail
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": "0x8dce0b3eccb4491a11cef7efcb9b2b89c762b53e7f8db08d6d08725d3bf4e641",
"n_tx": 212,
"n_successful_tx": 181,
"n_distinct_epochs": 8,
"n_distinct_sponsors": 0,
"first_seen_cp": 54366989,
"last_seen_cp": 58575655,
"first_seen_ts_ms": 1725377762534,
"last_seen_ts_ms": 1726405124959,
"total_gas_spent_mist": 260750603236,
"n_self_sponsored_tx": 212,
"n_sponsored_tx": 0,
"gas_price_p50": 755,
"gas_price_p95": 755,
"active_hours_top24": [
15,
22,
13,
12,
16,
14,
21,
9,
10,
19,
18
],
"primary_archetype": null,
"labels": [],
"label_confidence": [],
"bot_score": 0.4,
"bot_signals": [
"timing_automation"
],
"cex_label": null
}Tinted amber on the bubble map when they appear in the expanded graph.
Top active hours by UTC. Circadian peak → likely UK / W. Europe / W. Africa.