all collections · daily · marketplace overlay
weekly · real (teal) vs wash (rose)
counterparties · funders · clusters
The 0x554d…c505 wallet is a package PUBLISHER, likely a developer or project team member, who mostly fiddles with admin settings and blobbing things. It bought two NFTs on Tradeport, which is either a very slow rug or a very patient collector.
Move packages this wallet published on-chain — what it shipped, not what it used.
This package defines a system for managing "graveyards" for players, along with an authority structure. The primary object types are `AdminCap`, `OperatorCap`, `OperatorCapsBag`, `GraveyardCap`, `Version`, and `GraveyardReg`. The `init` functions set up initial `AdminCap`, `GraveyardCap`, `OperatorCapsBag`, `Version`, and `GraveyardReg` objects, transferring the `AdminCap` and `GraveyardCap` to the deployer and sharing `OperatorCapsBag`, `Version`, and `GraveyardReg`. Public/entry functions include `issue_operator_cap` and `revoke_operator_cap` (gated by `AdminCap`) to manage `OperatorCap`s within an `OperatorCapsBag`, `migrate` and `admin_freeze` (gated by `AdminCap`) to update or freeze the `Version` object, and `add_to_graveyard` (gated by `GraveyardCap`) to record player "deaths" in a `GraveyardReg`. Notable patterns
This package facilitates an auction system for digital assets, primarily managing Auction and AuctionRegistry objects. The public/entry functions allow authorized operators to create, update, and invalidate auctions, as well as set winners and clean up old auctions. Users can bid on auctions using SUI coins, and claim rewards or settle bonds. Notable patterns include the use of AuctionOperatorCap for administrative actions, time-gating for auction phases (start/end), and dynamic fields within AuctionRegistry to store active/inactive auctions. The system also uses a Version object for upgradeability and an InvoiceRegistry for managing penalties.
This Sui package defines a system for managing and approving various "owner" objects, primarily MagazineOwner, BulletStoreOwner, and AuctionOwner. The seal_authority module manages AdminCap, SealAuthorityCap, and OperatorCapsBag objects, which are used for access control. AdminCap holders can issue SealAuthorityCaps and SealViewerCaps, and revoke SealAuthorityCaps. SealAuthorityCaps are stored in an OperatorCapsBag, which acts as an allowlist for authorized operators. The seal_policy module allows SealAuthorityCap holders to issue MagazineOwner, BulletStoreOwner, and AuctionOwner objects, and update their data. These owner objects contain allowlists (for IDs or addresses) or store data. The seal_version module manages a Version object, which is used to validate operations across the package, and can be migrated to a newer version or frozen by an AdminCap.
This Sui package primarily manages Player objects, which hold various game-related data like accolades, claimed rewards, and resources. Public/entry functions allow for claiming accolade rewards, which can grant gangsters, perks, or game resources to the player, and mutate the Player object, TurfInformation, and emit events. The admin_controller module provides entry points for game operators (gated by GameOperatorCap and OperatorCapsBag) to configure game parameters like player registry settings, experience bonuses, level curves, and to mint perks or create bounty sessions. A notable pattern is the use of dynamic fields to store reward values within AccoladeReward objects and player-specific data. Many functions are gated by an authority check, ensuring only authorized operators can perform certain actions, and version validation is consistently applied.
This Sui package defines a reward system for a game, managing `RewardRegistry`, `Reward`, and `SpinReward` objects. The `dvd_authority` module establishes a GovernorCap for administrative control and OperatorCaps for specific operational permissions, stored in an `OperatorCapsBag`. Public entry functions in `dvd_rewards` allow authorized operators (validated via `is_valid_operator` and requiring a `Version` object) to create and modify different reward types (tier rewards, spin rewards) within the `RewardRegistry` using dynamic object fields. Rewards include various game elements like gangsters, resources, perks, physical items, HQ aesthetics, and spin tickets, which are stored in `VecMap`s within the `Reward` and `SpinReward` objects.
marketplace NFT sales from analytics.sale. Net = proceeds − spend; realized trading flow, not true PnL (ignores still-held NFTs; wash trades inflate both sides).
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": "0x554d6b4efe3cbe6c7255cc49d715d42653121f79813f081a6f8efb313872c505",
"n_tx": 612,
"n_successful_tx": 609,
"n_distinct_epochs": 95,
"n_distinct_sponsors": 1,
"first_seen_cp": 132439614,
"last_seen_cp": 255947917,
"first_seen_ts_ms": 1744312064605,
"last_seen_ts_ms": 1773909943020,
"total_gas_spent_mist": 22357165118,
"n_self_sponsored_tx": 611,
"n_sponsored_tx": 1,
"gas_price_p50": 557.0834,
"gas_price_p95": 750,
"active_hours_top24": [
13,
8,
16,
5,
14,
15,
11,
12,
4,
17,
7,
6,
3,
19,
10,
9,
21,
18,
23,
20,
22,
2,
0,
1
],
"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