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 package defines an NFT collection for "CryptoGoat" NFTs. The primary object types are `Manager` (likely an admin object for the collection) and `Nft` (the actual NFT object). Public/entry functions are largely unimplemented, aborting immediately, except for `create_nft_with_mutation_request` and `update_nft_with_mutation_request`. These two functions create or update `Nft` objects and associated `NftMutationRequest` objects, which are used for off-chain metadata updates. The `Manager` object holds a `TransferPolicyCap` and a `Balance<SUI>`, suggesting it manages collection-level transfer policies and collected funds. The `Nft` objects include fields for `group_id`, `type`, `name`, `description`, `media_url`, and `attributes` (a dynamic map). The package utilizes `kiosk` for NFT management and `transfer_policy` for defining transfer rules, and also integrates with a `launchpad` module, indicating a potential NFT launchpad or marketplace integration.
This package defines an `Nft` object type with fields for ID, name, description, media URL, and attributes (a VecMap of strings). The `init` function creates and shares a `TransferPolicy<Nft>` object, which includes a `kiosk_lock_rule` and a `royalty_rule` set at 300 basis points (3%). Public functions allow creating new NFTs and updating existing ones. `create_nft_with_mutation_request` creates an NFT and a corresponding `NftMutationRequest`, while `update_nft_with_mutation_request` updates an NFT within a Kiosk and generates a mutation request. The `create_nft_with_verification` and `update_nft_with_verification` functions are stubbed out and immediately abort.
This package defines an NFT collection for "Portrait Series" NFTs. The primary object types are `Manager`, which holds collection-level data like a display object, transfer policy capabilities, and a balance of SUI, and `Nft`, which represents individual NFTs with fields for group ID, type, name, index, description, media URL, and attributes. Public/entry functions are largely aborted, suggesting they are placeholders or not yet implemented, but `create_nft_with_mutation_request` creates a new `Nft` object and an associated `NftMutationRequest`, and `update_nft_with_mutation_request` modifies an existing `Nft`'s name, description, media URL, and attributes within a Kiosk. The package uses dynamic fields for NFT attributes and integrates with a `launchpad` module, likely for minting and managing NFT mutations. It also includes event definitions for minting, adding metadata, creating collections, and updating NFTs.
This package manages Nft objects, which represent non-fungible tokens with a name, description, media URL, and attributes. The init function immediately aborts, suggesting it's not intended for direct use or is a placeholder. Public functions like mint_order, mint_nft, mint_edition_nft, update_nft, create_nft_with_verification, and update_nft_with_verification also immediately abort, indicating they are either unimplemented or intended to be called through other modules. The create_nft_with_mutation_request function creates a new Nft object and an associated NftMutationRequest, allowing for deferred or controlled updates. The update_nft_with_mutation_request function modifies an existing Nft within a Kiosk and creates an NftMutationRequest. A notable pattern is the use of NftMutationRequest objects, suggesting a system for managing changes to Nfts, potentially involving an approval or verification process via the launchpad module.
This package defines a single object type, GRUNT, which is a dummy struct. The `init` function is the only public/entry function. It creates a new fungible token called "GruntCoin" with a fixed supply of 9 units, a description, and an image URL. It then freezes the `CoinMetadata` object, making it immutable, and transfers the `TreasuryCap` object to the sender of the transaction. This effectively gives the deployer of the module control over minting and burning of the GRUNT token. The package utilizes the standard Sui framework for creating fungible tokens and managing their metadata and treasury.
True specific-lot profit from 12 closed buy→sell round-trips of the same NFT (realized_roundtrip), wash-adjusted, valued at each leg's trade-hour USD. Excludes still-held inventory (that's unrealized).
marketplace NFT sales from analytics.sale. Net = proceeds − spend; realized trading flow, not true PnL (ignores still-held NFTs; wash trades inflate both sides).
nft_collectornft_traderRule-based labels, conservative precision.
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": "0x4591161fb33fc7eb3242e6a1cb89c545ac28f8ebaf260292ede9eecdea1f3cd9",
"n_tx": 2735,
"n_successful_tx": 2720,
"n_distinct_epochs": 214,
"n_distinct_sponsors": 3,
"first_seen_cp": 81264009,
"last_seen_cp": 281151437,
"first_seen_ts_ms": 1731959524279,
"last_seen_ts_ms": 1780146250687,
"total_gas_spent_mist": 37891890558,
"n_self_sponsored_tx": 2729,
"n_sponsored_tx": 6,
"gas_price_p50": 750,
"gas_price_p95": 750,
"active_hours_top24": [
13,
17,
18,
11,
19,
20,
23,
12,
0,
1,
2,
21,
14,
15,
8,
16,
22,
7,
10,
6,
4,
3,
9,
5
],
"primary_archetype": "nft_collector",
"labels": [
"nft_collector",
"nft_trader"
],
"label_confidence": [
0.95,
0.669
],
"bot_score": 0,
"bot_signals": [],
"cex_label": null
}Top active hours by UTC. Circadian peak → likely Atlantic / E. South America.
area + brightness = call volume; hover for detail