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 three primary object types: `ColorObject`, `SimpleWarrior`, and `Object` (within `trusted_swap`). The `color_object` module allows creating, transferring, updating, and deleting `ColorObject`s, which store RGB color values. The `simple_warrior` module enables creating `Sword`, `Shield`, and `SimpleWarrior` objects, where warriors can equip or unequip swords and shields, transferring previously equipped items back to the sender. The `trusted_swap` module facilitates a trusted swap mechanism for `Object`s, where users create `ObjectWrapper`s containing the `Object` to swap and a SUI fee (minimum 1000 SUI), and then two `ObjectWrapper`s can be swapped if their wrapped `Object`s have matching `scarcity` and differing `style`, with the combined SUI fees transferred to the transaction sender.
This package defines a single object type, CTX, which is a dummy struct. The `init` function is the only public/entry function and it initializes a new fungible token (Coin<CTX>) and its associated metadata (CoinMetadata<CTX>) and TreasuryCap<CTX>. It mints an initial supply of 10,000,000,000 CTX tokens and transfers both the TreasuryCap and the initial minted tokens to the transaction sender. The CoinMetadata object is frozen, preventing further modification. This module implements a standard fungible token creation pattern.
This package defines a system for managing NFT collections and their minting processes. It primarily manages Minter objects, which represent an NFT collection and its associated minting phases, and Nft objects, which are the individual NFTs. Public functions allow the Minter's owner to add, remove, and update SalePhase objects within a Minter. These SalePhase objects define parameters like price, max sales, mints per user, start time, and an optional Merkle root for allowlist gating. The mint function allows users to mint NFTs, checking against the current active sale phase, enforcing price, supply limits, per-user limits, and optionally verifying a Merkle proof for allowlisting. Notable patterns include owner-gating for administrative functions, time-gating for sale phases, and optional Merkle root verification for allowlist functionality. The Minter object uses Sui's Table for tracking user and sale phase specific mint counts.
This package defines a single object type, LOL, which is a dummy struct. The init function is the only public/entry function. It creates a new currency of type LOL, mints an initial supply of 100 * 10^9 coins, and transfers both the TreasuryCap for LOL and the minted coins to the transaction sender. It also freezes the CoinMetadata object. The package uses standard Sui coin and transfer functionalities. There are no notable patterns like signature/allowlist gating, time-gating, dynamic fields, vault/escrow, or royalties.
This Sui package defines a vault system for managing deposits and withdrawals of fungible tokens. The primary object types are `Vault`, which stores information about a specific vault (operator, pause states, depositors' balances), and `Queue<Ty0>`, which holds pending deposit/withdrawal requests and claimable funds. Public/entry functions allow an `AdminCap` holder to create vaults and queues, update vault operators, and pause/unpause deposits and withdrawals. Users can request deposits to a vault (transferring coins to the queue's balance) or withdrawals from a vault (reducing their recorded balance in the vault). A `QueueProcessorCap` holder can process requests from the queue, updating internal balances and making funds claimable. Notable patterns include admin/role-based gating for critical operations, the use of dynamic fields (`Table`) for managing depositors and requests, and an escrow-like mechanism where funds are held in the `Queue` object until processed and claimed. Version checks are performed on `Vault` and `Queue` objects before most operations.
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.
flipperRule-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": "0xac3a46147b0801a6f8d3468a9d1c06ef28addd9616685c74837016507e99a6c8",
"n_tx": 1223,
"n_successful_tx": 1223,
"n_distinct_epochs": 40,
"n_distinct_sponsors": 0,
"first_seen_cp": 19848494,
"last_seen_cp": 120571139,
"first_seen_ts_ms": 1701557125779,
"last_seen_ts_ms": 1741480802079,
"total_gas_spent_mist": -4452286436,
"n_self_sponsored_tx": 1223,
"n_sponsored_tx": 0,
"gas_price_p50": 750,
"gas_price_p95": 750,
"active_hours_top24": [
15,
14,
16,
23,
0,
21,
1,
18,
19,
17,
2,
20,
22,
12,
13
],
"primary_archetype": "flipper",
"labels": [
"flipper"
],
"label_confidence": [
0.565
],
"bot_score": 0.4,
"bot_signals": [
"timing_automation"
],
"cex_label": null
}Top active hours by UTC. Circadian peak → likely Atlantic / E. South America.
area + brightness = call volume; hover for detail