all collections · daily · marketplace overlay
weekly · real (teal) vs wash (rose)
counterparties · funders · clusters
The 0x4dee…961d wallet is trying to be an NFT market maker, placing and cancelling bids on Tradeport while occasionally panic-selling into Cetus. The bot score of 0.8 and the "floor_arb_bot" signal suggest it's about as successful as a screen door on a submarine, and the "wash_trader" signal suggests it knows it.
Move packages this wallet published on-chain — what it shipped, not what it used.
This package defines an `Nft` object type with fields for ID, name, description, media URL, and attributes (a `VecMap<String, String>`). The `init` function and most public/entry functions (`mint_order`, `mint_nft`, `mint_edition_nft`, `update_nft`, `create_nft_with_verification`, `update_nft_with_verification`) immediately abort, indicating they are either placeholders or intended for future implementation. The `create_nft_with_mutation_request` function creates a new `Nft` object and an associated `NftMutationRequest` using a `launchpad` module. The `update_nft_with_mutation_request` function mutates an existing `Nft` object within a `Kiosk` by updating its name, description, media URL, and attributes, then creates an `NftMutationRequest` for these changes. The package heavily relies on the `launchpad` module for NFT mutation requests and interacts with `Kiosk` objects for managing NFTs.
The `bitcoin_era` package primarily manages `Nft` objects, which represent non-fungible tokens with attributes like `group_id`, `type`, `name`, `description`, `media_url`, and a `VecMap` of string attributes. It also manages a `Manager` object, which holds a `Display<Nft>`, a `TransferPolicyCap<Nft>`, a `Balance<SUI>`, and a vector of reserved NFT IDs. Most entry functions, including `withdraw_balance`, `withdraw_reserved_nfts`, `withdraw_royalties`, `add_nft_metadata`, `mint_nft`, and `update_nft`, immediately abort, suggesting they are either placeholders or intended to be called through other mechanisms not directly exposed as entry points. The `create_nft_with_verification` function creates a new `Nft` and sets its ID within a `Verification` object, while `update_nft_with_verification` allows modifying an existing `Nft`'s metadata (name, description, media_url, attributes) if the provided
This package manages "Nft" objects, which represent non-fungible tokens with attributes like group_id, type, name, description, media_url, and a map of custom attributes. The "Manager" object acts as an admin cap, holding a display object for NFTs, a transfer policy cap, a balance of SUI, and a vector of reserved NFT IDs. Public functions allow the package publisher (admin) to withdraw SUI from the manager's balance, withdraw reserved NFTs from the manager's dynamic fields into a Kiosk, and withdraw royalties from the NFT transfer policy. Users can mint new NFTs, which are then locked into a Kiosk, and update existing NFTs' metadata (description, media_url, attributes) if they are in a Kiosk. The package utilizes dynamic object fields to store reserved NFTs within the Manager object and implements a versioning mechanism for the Manager.
This package defines a single module, 'age', which primarily manages a custom coin type also named 'AGE'. The 'init' function is an entry point that creates a new currency, 'AGE', with a fixed decimal precision of 6, a name "Ape Genesis", a symbol "AGE", and a description "Ape Era". It also sets a URL for the coin metadata. This function then transfers both the TreasuryCap<AGE> and CoinMetadata<AGE> objects to the sender of the transaction, effectively granting administrative control and metadata ownership to the deployer. There are no other public or entry functions, meaning no further operations on the AGE coin are defined within this module. The module does not exhibit patterns like signature/allowlist gating, time-gating, dynamic fields, or vault/escrow functionality.
This package defines a single object type, GOE, which is a dummy struct used to represent a custom coin. The `init` function is called once upon package deployment
True specific-lot profit from 14 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).
6 self-dealing round-trips excluded from the headline (gross incl. wash: -$2).
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.
nft_collectorRule-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": "0x4deedf8e61a233acc87d97d64c8236727a06c1297a8ef905e48199952ab2961d",
"n_tx": 622,
"n_successful_tx": 611,
"n_distinct_epochs": 102,
"n_distinct_sponsors": 1,
"first_seen_cp": 67781436,
"last_seen_cp": 270864573,
"first_seen_ts_ms": 1728646754383,
"last_seen_ts_ms": 1777614200273,
"total_gas_spent_mist": 3063509276,
"n_self_sponsored_tx": 621,
"n_sponsored_tx": 1,
"gas_price_p50": 740,
"gas_price_p95": 750,
"active_hours_top24": [
15,
18,
14,
8,
12,
9,
17,
11,
16,
7,
13,
4,
20,
6,
19,
10,
5,
21,
23,
22,
1
],
"primary_archetype": "nft_collector",
"labels": [
"nft_collector"
],
"label_confidence": [
0.65
],
"bot_score": 0.8,
"bot_signals": [
"floor_arb_bot",
"wash_trader"
],
"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