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 fungible token named "BLUE" (Bluefin). The `init` function creates the `CoinMetadata<BLUE>` and `TreasuryCap<BLUE>` objects, freezing the metadata and transferring the `TreasuryCap` to the sender. The `mint` entry function allows the holder of the `TreasuryCap` to mint new `BLUE` coins and transfer them to a specified address, but only if the total supply does not exceed 1,000,000,000,000,000,000. The `burn` entry function allows the `TreasuryCap` holder to burn `BLUE` coins. The package primarily manages `CoinMetadata<BLUE>` and `TreasuryCap<BLUE>` objects, with the `TreasuryCap` acting as an admin capability for minting and burning.
This package defines a vault system for managing deposits and withdrawals of a generic coin type. The primary object types are `Vault` and `Queue<Ty0>`. `Vault` stores information about a specific perpetual, its operator, pause states for deposits/withdrawals, and a table of depositors' balances. `Queue<Ty0>` manages a queue of deposit and withdrawal requests, holds claimable funds, and maintains a balance of the generic coin type. Public/entry functions allow an `AdminCap` to create new vaults and queues, update a vault's operator, and pause/unpause vault operations. Users can `request_deposit_to_vault` and `request_withdraw_from_vault`, which add `Request` objects to the `Queue` and update the depositor's balance within the `Vault`. The `process_queue` function, callable by a `QueueProcessorCap`, iterates through pending requests, updates internal balances, and moves funds to a claimable state for withdrawals. Finally, `claim_withdrawn_funds` allows users to claim
This Sui package defines a GRUU coin and a locking mechanism for it. The `gruu` module creates the GRUU coin with a fixed supply and transfers the TreasuryCap to address 0x0. The `lock_coin` module manages `Lock` objects, which hold GRUU coins and can have associated `TGE` (initial unlock percentage), `Vesting` (linear unlock schedule), and `Demand` (specific unlock amounts at specific times) dynamic object fields. The `init_tokenomic` entry function initializes multiple `Lock` objects with varying GRUU amounts and vesting/TGE schedules, transferring them to specific addresses, and sets an `initialize` flag on a `TokenomicCap` to prevent re-initialization. The `claim` entry function allows users to claim unlocked GRUU from a `Lock` object based on the current timestamp and the lock's vesting/TGE/demand schedules, emitting a `ClaimTokenomicEvent`. The `DemandCap` object is used to gate the `add_demand` function, ensuring only the owner of
This package defines capabilities for managing vaults. It introduces three primary object types: AdminCap, VaultOwnerCap, and CreateVaultCap. The 'init' function creates and transfers an AdminCap to the deployer. The 'create_vault_cap' public entry function, callable only by an AdminCap holder, creates a new custom coin type (TreasuryCap and CoinMetadata) and then mints and transfers a CreateVaultCap for that coin type to the caller. This module uses an admin cap for permissioning and creates new coin types.
This Sui package defines a collection of "Nikka" NFTs and a custom "MEO" coin. The primary object types managed are Nikka (the NFT) and MintData, which holds information about the NFT collection's minting phases. Public functions allow an AdminCap holder to add minting phases with specific start/end times, prices, and per-user limits, and users to mint Nikka NFTs by paying with a specified coin type. The MintData object is mutated to track minted NFTs and store the collected coins, while the Phase object's joiners table tracks user mint counts. Notable patterns include the use of dynamic object fields to store minting phases and collected coins within the MintData object, time-gating for minting phases, and an AdminCap for administrative actions like adding phases and withdrawing funds. Royalties are also configured for the Nikka collection.
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": "0xb30f32a0fb2c016d8f6905e8a4d776bd13159567c849cb01ce48d567116b1982",
"n_tx": 328,
"n_successful_tx": 325,
"n_distinct_epochs": 57,
"n_distinct_sponsors": 0,
"first_seen_cp": 55710340,
"last_seen_cp": 213931439,
"first_seen_ts_ms": 1725706299653,
"last_seen_ts_ms": 1763572412329,
"total_gas_spent_mist": -1993757860,
"n_self_sponsored_tx": 328,
"n_sponsored_tx": 0,
"gas_price_p50": 750,
"gas_price_p95": 750,
"active_hours_top24": [
13,
14,
19,
11,
12,
22,
18,
16,
23,
0,
9,
10,
1,
8,
17,
21,
15,
6,
20,
7
],
"primary_archetype": null,
"labels": [],
"label_confidence": [],
"bot_score": 0,
"bot_signals": [],
"cex_label": null
}Top active hours by UTC. Circadian peak → likely UK / W. Europe / W. Africa.
area + brightness = call volume; hover for detail