all collections · daily · marketplace overlay
weekly · real (teal) vs wash (rose)
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 are leveraged yield farming vaults. Public/entry functions allow for initializing a new Vault, adding swap routes, updating withdrawal/performance fees, collecting fees, enabling/disabling deposits, setting deposit limits, and adjusting slippage parameters. These functions primarily mutate the state of the Vault object. A notable pattern is the use of a VaultCap for administrative functions, acting as an admin gating mechanism. The package also utilizes permissioned receipts for deposits, which include various data points related to the deposit transaction. It interacts with external modules for incentive management, oracle pricing, and obligation handling, suggesting integration with a broader DeFi ecosystem.
This Sui package defines a leveraged yield farming protocol. The primary object type it manages is the `Vault`, which holds deposited assets (`Ty0`), borrowed assets (`Ty1`), and issues vault tokens (`Ty2`). Public/entry functions allow users to initialize vaults, deposit assets into vaults (minting `Ty2` tokens), and administrators (holding a `VaultCap`) to configure vault parameters like fees, deposit limits, and slippage, and to collect fees. Notable patterns include admin gating via `VaultCap` for configuration and fee collection, and the use of `PermissionedReceipt` for managing deposit flows, which suggests a multi-step or permissioned process. The package also integrates with external oracles (`KriyaOracle`, `PriceOracle`) and pools for asset management and pricing.
This package manages an AggregatorAcl object, which contains an Access object. The init function creates and shares a new AggregatorAcl object. The acl module provides functions to retrieve the Access object or its ID from an AggregatorAcl. The cetus_adapter and kriya_adapter modules implement flash swap functionalities for different decentralized exchanges (Cetus and Kriya, respectively). Both adapters have public flash_swap and repay_flash_swap functions that interact with external pool objects, using a PermissionedReceipt to store and retrieve swap parameters like amount, input type, fixed input, slippage, and pool ID. These functions also utilize the AggregatorAcl for access control, ensuring only authorized entities can perform these operations. The error module defines custom error codes for invalid pool IDs, input types, and repay types.
This package defines a vault system for managing liquidity in a decentralized exchange (DEX) context, likely interacting with a concentrated liquidity AMM. It primarily manages Vault objects, which hold liquidity (Coins) and configuration settings. Public and entry functions allow users to deposit liquidity into vaults, collect fees and rewards, and for administrators to adjust vault parameters. Key patterns include admin caps for privileged operations, version checks for compatibility, and the use of dynamic fields for configuration. The system calculates and distributes fees, and handles the minting and burning of vault-specific tokens representing deposited liquidity.
This package facilitates token swaps between two token types (Ty0 and Ty1) using a liquidity pool. The primary object type it manages is the `Pool<Ty0, Ty1>`, which represents a liquidity pool for a specific pair of tokens. The public entry functions, `check_and_swap_a_2_b` and `check_and_swap_b_2_a`, allow users to swap tokens in either direction (Ty0 to Ty1 or Ty1 to Ty0). These functions mutate the `Pool` object by performing a flash swap, which involves temporarily borrowing tokens from the pool, executing the swap logic, and then repaying the borrowed amount. The package interacts with a `GlobalConfig` object and uses the `Clock` for potential time-related operations within the underlying `pool` module. There are no explicit signature/allowlist gating, time-gating, dynamic fields, admin caps, vault/escrow, or royalties visible at this level of IR.
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.
area + brightness = call volume; hover for detail
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": "0xd67d48e4297af17ad12cd49e55a99d87f9326fab3cc049d722a7e20364007db1",
"n_tx": 92,
"n_successful_tx": 72,
"n_distinct_epochs": 23,
"n_distinct_sponsors": 0,
"first_seen_cp": 6064312,
"last_seen_cp": 80027259,
"first_seen_ts_ms": 1687730617556,
"last_seen_ts_ms": 1731659884856,
"total_gas_spent_mist": 5588602176,
"n_self_sponsored_tx": 92,
"n_sponsored_tx": 0,
"gas_price_p50": 751,
"gas_price_p95": 757,
"active_hours_top24": [
11,
13,
12,
7,
10,
8,
16,
17,
15,
22,
21,
9,
18,
14
],
"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.