Necter · DePIN · L2 Infrastructure • 2024–25
A new kind of chain with no existing tools to read it.
Necter is an OP-Stack L2 built for DePIN, AI compute, IoT, and data sovereignty, with primitives no existing explorer knows how to show. Working directly with Necter's founding team as sole designer, I built two products from scratch: the chain explorer that gives investors and developers their first window into what the protocol actually does, and the mining app store that turns a raw compute network into something people can participate in.
Necter Explorer · Live Blocks
OP-Stack · Kailua ZKBlock Height
4,821,047
TPS
124
Active Miners
2,847
ZK Proofs Today
18,421
The Problem
DePIN is a $19B sector with 41 million deployed devices and almost no tooling to make it legible. Necter runs DePIN devices, AI jobs, IoT gateways, and zk-proof verification on one chain. None of it visible in any existing explorer. First problem: build one that understood what it was showing.
The second problem was distribution. Necter's economy runs on miners: developers who publish tasks, operators who run hardware, community members who stake and earn. Getting them in required a layer that felt like an app store, not a protocol spec.
Block Explorer
The core explorer surfaces Necter's native primitives alongside standard blockchain data: zk-proof anchors on every block, job lifecycle events, device attestations. The information architecture had to feel familiar to anyone who's used BaseScan, while exposing data that has never existed in an explorer before.
Necter Explorer · Blocks
Live · 2s block time↑ Click any block to expand. Expanded view shows ZK proof hash, gas usage, and job type breakdown.
AI Job Lifecycle
AI compute jobs on Necter move through five stages, from posting to payout, and each stage lives on-chain. No existing explorer shows this. The job view makes the full lifecycle readable at a glance so operators can see where a job is, who's running it, and whether the proof has landed.
Explorer · AI Compute Jobs
247 active jobs↑ Click a job to see lifecycle. Post → Bid → Assignment → Proof → Payout. ZK verification status, proof hash, and dispute window shown at every stage.
DePIN Devices
DePIN device data is the hardest module in the explorer: device fingerprints, attestation history, stake, uptime, slashing events. None of this exists in standard block explorer patterns. The operators managing these devices think like sysadmins, not traders, so the view had to meet them where they already are.
Explorer · DePIN Device Registry
8,421 registered devices↑ Click any device. Fingerprint hash, attestation type (TEE/TPM/SGX), stake, uptime score, slashing history, and task completion rate. All verifiable on-chain.
App Store
Miners discover and subscribe to compute tasks the same way a developer finds an API: browse by category, check requirements, read reputation, one-click subscribe. The design reference was the App Store, not a DeFi protocol. Ease of entry drives network growth.
Necter Mining App Store · Discover
142 live apps↑ Click Subscribe on any app. Hardware requirements, reward model, stake required, and reputation score visible before any commitment.
Developer Publish
The developer side is a four-step publish flow: define the mining profile via JSON config, upload the miner binary, set reward parameters, submit to governance. Developers with no mining infrastructure background ship a live mining network in under 30 minutes.
Developer Portal · Create Mining App
Step 1 of 4App Name
Domain
Description
↑ Interactive — publish an app. JSON config defines consensus, hardware requirements, rewards, and verification. MSaaS compiles the miner runtime.
Governance
Every app requires DAO approval before listing. The governance view shows pending submissions, vote tallies, and attestation status, giving governance members the signal they need to approve or reject without reading raw contract data.
Governance · App Listing Queue
6 pending review↑ Click Approve or Reject. Each submission shows developer attestation status, category, stake requirement, and hardware type.
Design Decisions
Familiar structure, novel data
The core challenge was that Necter's data (AI jobs, DePIN devices, ZK proofs) had no established visual language. The decision was to borrow the structural patterns of BaseScan (column headers, row expansion, hash display) and extend them rather than invent from scratch. Developers who've used any block explorer can orient immediately. The novel modules layer on top of a familiar skeleton.
App Store reference, not protocol reference
The first version of the mining app store was designed like a DeFi protocol: stake, configure, submit. Drop-off was immediate. The reframe: miners aren't interacting with a protocol, they're choosing a job. The App Store reference (browse by category, read reviews, one-tap subscribe) is what drove 30-minute time-to-first-app. Ease of entry directly drives network growth.
Hardware monitoring patterns for DePIN devices
DePIN device data (fingerprints, attestation history, slashing events, uptime scores) had no blockchain explorer precedent. The pattern that worked came from hardware monitoring dashboards: Datadog, Grafana. Device operators think like sysadmins, not DeFi traders. Designing for how they already think about infrastructure reduced the learning curve to near zero.
Outcomes
Both products shipped to Necter's live network. The metrics below reflect the first 3 months post-launch.
Mining apps published through the developer portal. Target was 50 in first quarter.
Average developer time from first login to live mining app. Previous flow required custom infra setup.
Miner onboarding completion rate. Industry benchmark for DePIN protocols is ~40%.
Novel explorer modules shipped: DePIN devices, AI jobs, IoT, zk-proofs, governance, staking.
“The explorer is the first thing I show investors. It makes the protocol legible in a way raw contract data never could.”
— Necter Founder
Reflection
Two weeks after launch, we had to redesign the reward display in the app store. We'd assumed miners cared about projected APY. They didn't. They wanted to know how many tasks ran yesterday and what each one paid. The data was there, just surfaced wrong. That redesign took three days but it exposed a blind spot I should have caught earlier: I'd talked to the protocol team extensively but only got access to real miners late in the process. The explorer held up because BaseScan gave us a proven skeleton to extend. The app store needed a second pass because we were designing for miners we hadn't actually watched use the product. Next time, I'd insist on user access before the first wireframe, not after the first deploy.