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 implements a coin-flipping game. The primary objects managed are `House`, which represents the game operator and holds funds, `Game`, which stores details of an ongoing game, `Partnership`, which allows for custom fee rates, and `AdminCap`, which grants administrative privileges. Public entry functions allow an `AdminCap` holder to create and manage `House` and `Partnership` objects, including topping up/withdrawing funds from the house pool/treasury, and updating fee rates and stake limits. Players can `start_game` (with or without a `Partnership` or `Kiosk` integration) by providing a guess, a seed, and a stake, which creates a `Game` object and stores it as a dynamic field on the `House` object. The `settle` function determines the game outcome based on a provided BLS signature and distributes rewards or returns the stake, moving funds between the house's pool and treasury. The `challenge` function allows players to reclaim their stake if a game is not settled within a specific
This package defines a single object type, `DROP`, which is a dummy struct. The `init` function is the only public/entry function. It creates a new currency `DROP` with specific metadata (name, symbol, description, icon URL) and a `PointCenter` for `DROP`. It then shares the `PointCenter` object publicly and transfers the `AdminCap<DROP>` and `CoinMetadata<DROP>` objects to the transaction sender. This module essentially sets up a new fungible token called "DROP" and its associated point system, making the `PointCenter` publicly accessible while granting administrative control and metadata ownership to the deployer.
This package, `de_voting_drop`, primarily manages a `DeVotingDrop` object, which appears to be a dummy struct used as a type parameter. The sole public function, `supply`, allows an authorized administrator (via `AdminCap`) to mint a specified quantity of a generic coin type (`Ty2`) and then supply these coins to a `RewardCenter`. This process involves using a `PointCenter` and a `Privilege` object, suggesting a system where points or privileges are tied to the ability to mint and supply rewards. The function mutates the `RewardCenter` by adding the newly minted coins and also interacts with the `PointCenter` to mint the coins.
This Sui package defines a generic Vault object that manages a balance of a specific coin type (Ty0) and a sheet of SIMPLE_VAULT objects. The create function initializes a new Vault, setting its balance to zero and creating an empty sheet, then shares the Vault object. The receive function allows a Vault to accept a Loan object, adding the loan's balance to the Vault's total balance and updating its internal sheet. The repay function enables a Vault to fulfill a repayment requirement from a Collector object by splitting a portion of its balance and passing it to the sheet's repay function. Finally, there are public getter functions to immutably access the Vault's balance and sheet.
This package, `snapshotter`, manages `Snapshotter` objects, which are used to simulate and execute point-based airdrop allocations. The `new` function creates a `Snapshotter` object, initializing it with total points, total allocation, a threshold, and a cursor to the first user in a `PointCenter`. The `create` function then transfers this new `Snapshotter` object to the transaction sender. The `destroy` function deletes a `Snapshotter` object. The `simulate` function iterates through users in a `PointCenter` (up to a specified limit), calculates their potential airdrop allocation based on their real-time points and the `Snapshotter`'s parameters, and emits a `Simulation` event for each eligible user. The `snapshot` function performs a similar iteration, but for eligible users, it levies points from the `PointCenter` (burning them if specified), allocates an `Eligibility` object from an `AirdropPool`, and transfers this `Eligibility` to the user. The `settle_all_
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.
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": "0xa7caa2a3e8d4dc1d35297ce32e46c4b05fa990968384cad74571c983ad6e598a",
"n_tx": 498,
"n_successful_tx": 481,
"n_distinct_epochs": 132,
"n_distinct_sponsors": 1,
"first_seen_cp": 11191369,
"last_seen_cp": 280395533,
"first_seen_ts_ms": 1692893477200,
"last_seen_ts_ms": 1779909257894,
"total_gas_spent_mist": 48310133000,
"n_self_sponsored_tx": 497,
"n_sponsored_tx": 1,
"gas_price_p50": 750,
"gas_price_p95": 753,
"active_hours_top24": [
11,
12,
13,
10,
9,
18,
17,
14,
5,
8,
7,
6,
19,
16,
3,
4,
15,
21,
22,
2,
20,
23,
1,
0
],
"primary_archetype": null,
"labels": [],
"label_confidence": [],
"bot_score": 0,
"bot_signals": [],
"cex_label": null
}Top active hours by UTC. Circadian peak → likely C. Europe / Africa / Middle East.
area + brightness = call volume; hover for detail