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 Enclave and EnclaveConfig objects, which represent secure enclaves and their configurations, respectively. Public entry functions allow users to create new EnclaveCaps (capabilities for managing enclaves), register new Enclaves by providing an EnclaveConfig and a NitroAttestationDocument, and destroy Enclaves based on either an outdated configuration version or possession of the correct EnclaveCap. It also provides functions to create and update EnclaveConfig objects, requiring an EnclaveCap for modification. A notable pattern is the use of EnclaveCap for administrative control over EnclaveConfig objects, and the verification of signatures against an Enclave's public key, where the message is an IntentMessage containing an intent, timestamp, and payload.
This package provides a zero-knowledge proof verification system and Merkle tree implementations. The `groth16_verifier` module defines a `VerifyingKey` object and functions to verify Groth16 proofs using BLS12-381 elliptic curve cryptography. The `merkle_tree` and `merkle_tree_v3` modules implement Merkle trees, managing `MerkleTree` and `MerkleTreeV3` objects respectively, which store tree height, next available index, root index, filled subtrees, and historical roots. Public functions allow initializing a tree, appending new leaves (mutating the tree's state and roots, using dynamic fields for storing intermediate nodes), retrieving the current root, and verifying if a given root is valid. The `merkle_tree_v3` module specifically uses Poseidon hashing for its Merkle tree operations.
This Sui package primarily manages `MerkleTree` and `MerkleTreeV3` objects, which are data structures used for cryptographic commitments. Public/entry functions allow users to `initialize` new Merkle trees with a specified height, `append` new leaves to existing trees (mutating the tree's `next_index`, `root_index`, `filled_subtrees`, and `roots`), and `get_root` or `is_valid_root` to query the current or historical roots. The package also provides `verify_proof` for Merkle proofs and `get_stats` for tree metadata. Notably, `merkle_tree_v3` uses `poseidon` hashing, while `merkle_tree` uses `keccak256`. Dynamic fields are used to store intermediate hashes within the Merkle tree structure. The `groth16_verifier` module provides functions to create `VerifyingKey` objects and `verify_proof` for Groth16 zero-knowledge proofs, which likely integrate with the Merkle tree
This Sui package manages a Q&A platform, primarily dealing with a shared `Platform` object and `Question` objects stored within it. Public/entry functions allow administrators (managed via an admin allowlist) to add/remove other admins, answer questions, update answers, and delete answers. Users can submit new questions, which increments a counter and stores the question in a table, and vote on existing questions, incrementing a vote count and preventing duplicate votes from the same address. The `Platform` object stores questions in two tables: one by ID and another by month, and all administrative actions and question submissions/votes emit events.
This Sui package manages dynamic NFTs and their associated traits. The primary object types are `SharedTraitController`, which stores and manages available traits, `AdminCap`, which grants administrative privileges, `DynamicNFT`, representing the NFTs themselves, and `TraitData`, which stores the actual trait information. Public/entry functions allow for creating a `SharedTraitController` and an `AdminCap`, adding/updating/removing traits from the `SharedTraitController` (only by the admin), minting `DynamicNFT`s, and modifying an NFT's traits (also only by the admin). The package uses an `AdminCap` for signature gating on administrative functions and `ObjectBag` for dynamic storage of traits within the `TraitStorage` object. NFTs can dynamically generate SVG images based on their assigned traits.
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": "0x0db8426f6207d23dc75352be968894e986d156d017ba1a217fcb521effcde94f",
"n_tx": 875,
"n_successful_tx": 774,
"n_distinct_epochs": 40,
"n_distinct_sponsors": 0,
"first_seen_cp": 157073617,
"last_seen_cp": 281006523,
"first_seen_ts_ms": 1750019970026,
"last_seen_ts_ms": 1780108085230,
"total_gas_spent_mist": 11221999948,
"n_self_sponsored_tx": 875,
"n_sponsored_tx": 0,
"gas_price_p50": 500,
"gas_price_p95": 741,
"active_hours_top24": [
0,
1,
6,
3,
23,
2,
16,
21,
20,
9,
17,
22,
19,
8,
12,
5,
4,
15,
14,
18,
7,
13,
11
],
"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. N. America (Pacific/Mountain).
area + brightness = call volume; hover for detail