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 Sui package defines a "zapper" module for interacting with a decentralized exchange (DEX) and a "u256" module for u256 arithmetic. The primary object types managed are `Coin<T>` (Sui's native coin type) and `Coin<LP<Ty0, Ty1>>` (liquidity provider tokens). The public/entry functions facilitate "zapping" in and out of liquidity pools: `zap_in` allows users to provide a single asset (Coin<Ty0>) to a liquidity pool and receive LP tokens, while `zap_out_to_x` and `zap_out_to_y` allow users to remove liquidity (burn LP tokens) and receive a single asset (Coin<Ty0> or Coin<Ty1> respectively). These functions mutate `PairMetadata` objects (representing liquidity pools) and `Treasury` objects (likely for fee collection). Notable patterns include the use of generic types (`Ty0`, `Ty1`) for different coin types, and the emission of `Zap
This package defines a decentralized exchange (DEX) for token swaps, focusing on concentrated liquidity pools. The primary object types are `Pool` (representing a liquidity pool for a token pair), `Position` (representing a user's liquidity position within a pool), and `FeeCollector` (for managing collected fees). Public/entry functions allow users to create liquidity pools, open and increase/decrease liquidity positions, and claim pending rewards. These functions mutate the state of `Pool` and `Position` objects, updating liquidity, reward debts, and fee reserves. Notable patterns include the use of `Custodian` objects as vaults for token balances within pools and fee collectors, and dynamic fields within registries (`PoolRegistry`, `FeeCollectorRegistry`, `PositionRegistry`) to store and retrieve associated objects. The package also includes an `AdminCap` for administrative actions (though its usage isn't fully detailed in the provided IR) and a `State` object that acts as a singleton holding references to the registries.
This package defines a launchpad for token sales, managing a primary object type called Launchpad<Ty0>. Public/entry functions allow users to initialize a launchpad with pre-sale and public-sale configurations, deposit funds into either sale, and withdraw funds from the public sale. These functions mutate the Launchpad object's internal balance tables and total deposit amounts. Notable patterns include time-gating for sale periods, a whitelist for pre-sale participation, and dynamic fields to manage balances of different token types (Ty0 and FLX). An AdminCap is used for access control during initialization.
This package, zapper, facilitates "zap-in" and "zap-out" operations for liquidity provision on a decentralized exchange. The primary objects it manages are Coins of various types (including LP tokens) and a `Container` object from the `factory` module. Public/entry functions allow users to add liquidity to a pair using only one type of coin (`zap_in`), or remove liquidity and receive only one type of coin (`zap_out_to_x`, `zap_out_to_y`). These functions mutate the `PairMetadata` object (likely representing a liquidity pool) and transfer coins to or from the caller. The package emits `ZapIn` and `ZapOut` events to record these operations, including the user's address, coin types, and amounts. It utilizes external modules for core DEX functionalities like `router` for swaps and `pair` for liquidity management.
This package facilitates "zapping" into and out of liquidity pools, abstracting multiple swap and liquidity provision steps into single transactions. The primary objects managed are `Coin<Ty0>`, `Coin<Ty1>`, and `Coin<LP<Ty0, Ty1>>` (liquidity provider tokens). The `zap_x_in_direct` and `zap_y_in_direct` functions allow users to provide single-sided liquidity by swapping a portion of their input coin for the other asset in the pair and then adding both to the liquidity pool, returning LP tokens. The `zap_in` entry function orchestrates this process, determining the correct `zap_x_in_direct` or `zap_y_in_direct` call based on the coin order and emitting a `ZapIn` event. The `zap_out_to_x` and `zap_out_to_y` entry functions allow users to remove liquidity and receive a single type of coin, by burning LP tokens, swapping one of the received coins for
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.
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": "0xde8159d463efd76a5c4e684672e795d4516d46e30ad2b9907fdc2ff929d4278a",
"n_tx": 699,
"n_successful_tx": 699,
"n_distinct_epochs": 169,
"n_distinct_sponsors": 0,
"first_seen_cp": 6361229,
"last_seen_cp": 259706242,
"first_seen_ts_ms": 1688034198545,
"last_seen_ts_ms": 1774869768434,
"total_gas_spent_mist": 69457192436,
"n_self_sponsored_tx": 699,
"n_sponsored_tx": 0,
"gas_price_p50": 750,
"gas_price_p95": 757,
"active_hours_top24": [
15,
9,
4,
14,
7,
8,
3,
6,
10,
11,
5,
12,
18,
17,
13,
19,
2,
1,
16,
20
],
"primary_archetype": null,
"labels": [],
"label_confidence": [],
"bot_score": 0,
"bot_signals": [],
"cex_label": null
}Tinted amber on the bubble map when they appear in the expanded graph.
Top active hours by UTC. Circadian peak → likely E. / SE Asia.
area + brightness = call volume; hover for detail