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 primarily manages `AppRecord` objects, which store information about applications, and `AppCap` objects, which are capabilities to manage `AppRecord`s. Public/entry functions allow users to register new applications, assign package information to an application, and manage network-specific details for an application. The `assign_package` function makes an `AppCap` immutable, preventing further changes to its package information. The package utilizes a `Table` to store `AppRecord`s, keyed by `Name` objects, and enforces a maximum of 25 networks per `AppRecord`. It also integrates with a SUINS registration system, requiring valid and non-expired SUINS domains for registration and removal of applications.
This package manages two primary object types: `Hero` and `HeroV2`, both containing a unique ID and a name. The `new` and `new_v2` public entry functions create new `Hero` and `HeroV2` objects respectively, initializing them with a provided name. The `set_name` and `set_name_v2` public functions allow modification of the `name` field for existing `Hero` and `HeroV2` objects. There are no notable patterns like signature/allowlist gating, time-gating, dynamic fields, admin caps, vault/escrow, or royalties present in this module. The module essentially provides basic CRUD operations for two distinct but structurally identical "Hero" object types.
This package manages `AppRecord` objects, which store information about applications, and `AppCap` objects, which act as capabilities for managing these records. Public/entry functions allow users to register new applications, remove existing ones, assign package information to an application, and manage network-specific details. The `AppCap` can be made immutable after package assignment, preventing further changes to the core application information. The package uses a `Table` to store `AppRecord` objects, keyed by a `Name` object, and `VecMap`s within `AppRecord` to store metadata and network-specific `AppInfo`. The `app_cap_display` module generates SVG text for displaying application information, and the `move_registry` module integrates with a SUINS registration system, requiring valid and unexpired SUINS registrations for app registration.
This Sui package manages `AppRecord` and `AppCap` objects, which represent applications and their administrative capabilities, respectively. Public functions allow for registering new applications (creating an `AppRecord` and an `AppCap`), assigning package information to an application, and managing network-specific details for an application. Notably, an `AppCap` can be made immutable after package assignment, preventing further changes to the core package information. The `MoveRegistry` module acts as a central registry, storing `AppRecord` objects in a `Table` indexed by a `Name` object derived from SUINS registrations. The package utilizes dynamic fields for `AppRecord` metadata and employs an admin cap (`AppCap`) to gate access to modification functions.
This package defines a QuestPass object, representing a referral, and a QuestHouse object, which manages these referrals. The QuestHouse contains a table of addresses that have already claimed a referral and a boolean indicating if claims are enabled. The `init` function creates a shared QuestHouse object, initialized with claims enabled, and a QuestCap object, which is transferred to the deployer. The `mint` function allows a user to mint a QuestPass for a referee if claims are enabled, the sender hasn't claimed yet, and the sender is not the referee, updating the QuestHouse's claims table. The `enable_claims` and `disable_claims` functions, gated by the QuestCap, toggle the `enabled` status of the QuestHouse. This module uses an admin cap (QuestCap) for gating administrative functions and a dynamic field (Table) within QuestHouse to track claims.
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.
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": "0xfe09cf0b3d77678b99250572624bf74fe3b12af915c5db95f0ed5d755612eb68",
"n_tx": 237,
"n_successful_tx": 233,
"n_distinct_epochs": 54,
"n_distinct_sponsors": 1,
"first_seen_cp": 5925315,
"last_seen_cp": 278427532,
"first_seen_ts_ms": 1687587006272,
"last_seen_ts_ms": 1779463385403,
"total_gas_spent_mist": 35596026132,
"n_self_sponsored_tx": 236,
"n_sponsored_tx": 1,
"gas_price_p50": 750,
"gas_price_p95": 751,
"active_hours_top24": [
12,
14,
8,
17,
13,
16,
19,
6,
18,
0,
9,
20,
4,
11,
10,
23,
15,
21,
5,
22,
7
],
"primary_archetype": null,
"labels": [],
"label_confidence": [],
"bot_score": 0,
"bot_signals": [],
"cex_label": null
}Tinted amber on the bubble map when they appear in the expanded graph.
Top active hours by UTC. Circadian peak → likely C. Europe / Africa / Middle East.
area + brightness = call volume; hover for detail