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 manages Vault objects, which represent leveraged yield farming positions. Public functions allow administrators (holding a VaultCap) to initialize new Vaults, add swap routes, and manage withdrawal fees. Users can deposit assets (Coin<Ty0>) into a Vault via `deposit_a` or `deposit_b` to receive LP shares (Coin<Ty2>). The `harvest` module enables authorized entities (VaultAcl, RouterAcl) to claim rewards from incentive pools and issue a permissioned receipt. The package uses an admin cap (VaultCap) for privileged operations, dynamic fields for swap routes, and emits events for Vault creation, deposits, and reward harvesting.
This package defines an on-chain oracle for price feeds, primarily managing the KriyaOracle object. The KriyaOracle stores prices and their sources in dynamic tables. AdminCap holders can set and remove primary/secondary price sources for different asset types. Price updates are submitted via PriceReceipts, which can contain prices from primary and secondary sources; the update logic includes a check to ensure the difference between primary and secondary prices is "reasonable" before updating the KriyaOracle's stored price. Users can query prices for specific assets, but the oracle enforces a staleness threshold, aborting if the price is too old. The oracle_utils module provides helper functions to convert between USD values and asset amounts using the oracle's price data and a separate CoinDecimalsRegistry.
This Sui package defines a vault system for managing liquidity and trading on DeepBook, a decentralized exchange. The primary object types are `Vault<Ty0, Ty1>` (the main vault holding assets and managing requests), `AdminCap` (for administrative control), `VaultCap` (a capability for interacting with a specific vault), `DepositRequest` and `WithdrawRequest` (for user deposits/withdrawals), and `Counter` (for rebalancing). Public/entry functions allow for creating vaults, adding deposit/withdrawal requests, processing these requests, and placing/canceling DeepBook limit orders. These functions mutate the `Vault` object's balances, request tables, and strategy state, and interact with DeepBook's `clob_v2` and `custodian_v2` modules. Notable patterns include: an `AdminCap` for initial setup, a `VaultCap` for authorized vault interactions, an address allowlist for trading operations, and a state machine (`strategy_state`) within the `Vault` to control the flow of deposits, withdrawals
This Sui package primarily manages `Vault` objects, which are liquidity pools for two distinct token types (`Ty0`, `Ty1`). The `app` module initializes an `AdminCap`, which is a capability object that grants administrative privileges. Public/entry functions allow administrators to create new `Vault` objects and `VaultCap` objects (which grant control over a specific vault), and to create trading accounts on DeepBook. Users can add liquidity to a `Vault`, receiving `VaultLpToken`s, and submit withdrawal requests for their `VaultLpToken`s. Administrators can process these withdrawal requests, distributing the underlying assets and burning the `VaultLpToken`s. The package utilizes signature/allowlist gating through the `AdminCap` for administrative actions and manages dynamic fields implicitly through the `Vault`'s `withdraw_requests` vector.
This Sui package defines a vault system for managing and trading assets on DeepBook, a decentralized exchange. The primary object types are `Vault` (which holds assets and manages trading permissions) and `VaultCap` (a capability token to control a specific vault). Public/entry functions allow creating new vaults, whitelisting/revoking addresses for trading, placing/canceling DeepBook orders, and managing deposit/withdrawal requests. The package utilizes an `AdminCap` for privileged operations like vault creation, and `VaultCap` for controlling individual vaults, enforcing an allowlist pattern for trading. It also incorporates a versioning system to ensure compatibility and includes a state machine for the vault's operational status (active, paused for deposits, paused for withdrawals).
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": "0x54ddafa58454c82c36bf39bb3a14568f09cc04a4fb069cc7f73b47c92bd8ff74",
"n_tx": 5594,
"n_successful_tx": 4638,
"n_distinct_epochs": 106,
"n_distinct_sponsors": 0,
"first_seen_cp": 36610938,
"last_seen_cp": 181917893,
"first_seen_ts_ms": 1718275008296,
"last_seen_ts_ms": 1755931726612,
"total_gas_spent_mist": 37381510876,
"n_self_sponsored_tx": 5594,
"n_sponsored_tx": 0,
"gas_price_p50": 758,
"gas_price_p95": 762,
"active_hours_top24": [
11,
12,
10,
9,
8,
13,
20,
16,
15,
19,
21,
14,
6,
17,
7,
22,
18,
5,
23,
0,
1,
3,
4,
2
],
"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 W/Central Asia / India.
area + brightness = call volume; hover for detail