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 decentralized exchange (DEX) or trading platform, primarily managing ACL (Access Control List) objects, BaseConfig objects, and DCAConfig objects. Public/entry functions allow administrators (holding an AdminCap) to manage roles and permissions within the ACL, update package versions, and configure various parameters for DCA (Dollar-Cost Averaging) and limit orders. These functions mutate the ACL and configuration objects and emit corresponding events. Notable patterns include signature/allowlist gating through the AdminCap and ACL roles (operator, keeper, oracle), and the use of dynamic fields (Tables and Bags) for managing whitelists and protocol fee vaults.
This package defines a decentralized exchange (DEX) or swap protocol. The primary object type it manages is `Config`, which holds global settings like pause status, fee rate, and a `Bag` acting as a vault for collected fees. The `cetus` and `flowx` modules provide `start_swap` and `confirm_swap` entry points. `start_swap` initiates a swap, creating a `SwapRequest` and a `SwapContext` (cetus) or `Trade` (flowx) object. `confirm_swap` finalizes the swap, deducting fees into the `Config`'s vault, and emitting a `ConfirmSwapEvent`. The `config` module allows an `AdminCap` holder to set the pause status, fee rate, and migrate the package version, and to collect fees from the vault. The package uses an `AdminCap` for administrative functions and a vault (`Bag`) to store collected fees.
This Sui package facilitates token swaps, managing a primary `Config` object that holds global settings and an `AdminCap` for administrative control. The `config` module initializes the `Config` object, setting a fee rate, a fee receiver address, and a version, and transfers the `AdminCap` to the deployer. It also includes functions for pausing/unpausing swaps, setting fee rates and receivers, and migrating the package version, all gated by the `AdminCap`. The `bluefin`, `cetus`, and `flowx` modules provide `start_swap` and `confirm_swap` entry functions. `start_swap` creates a `SwapRequest` object and emits a `StartSwapEvent`, while `confirm_swap` processes the swap, deducts fees into a `Bag` within the `Config` object, and emits a `ConfirmSwapEvent`. Fees are collected by the `fee_receiver` via `collect_fee`. The package uses a `Bag` for dynamic storage of collected fees per coin type and includes version and pause checks on
The ferra_dlmm package primarily manages `LBPair` objects, which likely represent liquidity pools for token pairs. The single public function, `swap`, allows users to exchange two types of tokens (`Ty0` and `Ty1`) within a specified `LBPair`. This function mutates the `LBPair` object and requires a `GlobalConfig` object, a `Clock` object, and a `TxContext` object. The `swap` function does not exhibit any explicit signature/allowlist gating, time-gating, dynamic fields, admin caps, vault/escrow, or royalty patterns within this IR.
This package implements a bridge manager for token deposits and withdrawals. The primary objects managed are GlobalConfig (shared configuration for the bridge), AdminCap and OperatorCap (permission tokens), Treasury (a shared vault for coins of a specific type), and TxStatus (a shared object tracking used transaction hashes to prevent replay attacks). Public/entry functions allow users to deposit coins into the Treasury, emitting a DepositEvent, and operators (holding an OperatorCap) to withdraw coins from the Treasury to a specified recipient, recording the transaction hash in TxStatus and emitting a WithdrawEvent. The AdminCap is used to create OperatorCaps, set pause status, upgrade the bridge version, and configure deposit/withdraw limits in the GlobalConfig. The GlobalConfig enforces active status and deposit/withdrawal amount limits. The TxStatus object uses a dynamic field (Table) to store used bridge hashes, preventing double-spending or replay attacks for withdrawals.
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": "0xcb536a1e7824e308b0cab72b2d538de80391ff990b6ae2eb75d76ef7abef5b9b",
"n_tx": 3377,
"n_successful_tx": 1189,
"n_distinct_epochs": 77,
"n_distinct_sponsors": 2,
"first_seen_cp": 204072734,
"last_seen_cp": 263389379,
"first_seen_ts_ms": 1761209016391,
"last_seen_ts_ms": 1775811467513,
"total_gas_spent_mist": 6636815588,
"n_self_sponsored_tx": 3375,
"n_sponsored_tx": 2,
"gas_price_p50": 500,
"gas_price_p95": 507.23886,
"active_hours_top24": [
21,
18,
20,
15,
17,
16,
14,
4,
19,
8,
3,
13,
7,
2,
6,
1,
9,
22,
5,
12,
0,
23,
11,
10
],
"primary_archetype": null,
"labels": [],
"label_confidence": [],
"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