DEV Community: Usang Emmanuel

Why Your Ubuntu Laptop Lags, and How to Fix It for Free

Usang Emmanuel — Tue, 23 Jun 2026 00:46:17 +0000

My main work laptop is a Dell from 2017 with 8 GB of RAM. For weeks it had been crawling, freezing for whole seconds while I worked, and every so often it would simply switch itself off in the middle of a task. If you have ever lost unsaved work to a laptop that powers down on its own, you know exactly how frustrating that is.

So I sat down and fixed it properly. The first thing I learned is worth saying up front: a slow, crashing laptop is usually two different problems wearing the same costume. Treat them as one and you will chase your tail. Separate them, and both become fixable.

Everything below is free and copy-paste ready. It was tested on Ubuntu 24.04 LTS, and it applies to almost any older Linux machine.

The honest disclaimer: Nobody can promise an old laptop will never lag. Software cannot add cores or memory that are not physically there. But you can absolutely stop the freezes and shutdowns completely and make everyday work feel smooth. That is the realistic, achievable goal.

0. Diagnose first, do not guess

The biggest mistake is blindly applying "speed up Ubuntu" tweaks before knowing what is actually wrong. Spend five minutes measuring. Your lag has one of four common causes: heat, memory, disk, or a dying battery.

Check temperature (the usual cause of random shutdowns):

sudo apt install lm-sensors -y
sudo sensors-detect --auto
sensors

Watch the Core temperatures while you work. If they spike past 90 to 100 °C right before a crash, you have a thermal problem, not a software one.

Check memory (the usual cause of freezing):

free -h
sudo apt install htop -y
htop

In htop, watch the Mem and Swp bars during normal use. If memory pins near your limit and swap fills up, that thrashing is your freeze.

Check disk space (a quiet killer):

df -h /

A root partition above 90% full makes Linux lag and turn unstable. Small SSDs fill up fast.

Read the crash logs and battery health:

# What went wrong during the previous (crashed) session
journalctl -b -1 -p err --no-pager
journalctl -k -b -1 | grep -i -E 'thermal|temperature|critical'

# Battery wear: compare 'energy-full' to 'energy-full-design'
upower -i $(upower -e | grep BAT)

If energy-full has dropped well below the design figure, a worn battery plus a weak charger can cause instant power loss that looks just like a crash.

1. Fix the random shutdowns (heat)

Start with the software layer:

# Intel's active thermal manager: throttles smartly instead of crashing
sudo apt install thermald -y
sudo systemctl enable --now thermald

The permanent fix: On a laptop more than a few years old, the fan is clogged with dust and the CPU's thermal paste has dried out. Blow out the fan vents with compressed air and repaste the CPU. It is a 30 minute job, or a cheap one at a repair shop, and it cures heat-related shutdowns for good. No software substitutes for this.

2. Fix the freezing (memory pressure)

Enable zram, compressed swap that lives in RAM. This is the biggest single software win on a low-memory machine:

sudo apt install zram-tools -y
echo -e "ALGO=zstd\nPERCENT=50" | sudo tee /etc/default/zramswap
sudo systemctl restart zramswap

Tune swappiness so the kernel prefers fast zram:

echo 'vm.swappiness=100' | sudo tee /etc/sysctl.d/99-swappiness.conf
sudo sysctl --system

Install earlyoom, the anti-freeze safety net. When RAM is fully used up, Linux can hang for minutes. earlyoom steps in early, kills the single heaviest process, and keeps your desktop responsive:

sudo apt install earlyoom -y
sudo systemctl enable --now earlyoom

3. Reclaim disk space

Safe cleanup first:

sudo apt autoremove --purge -y        # old packages + unused kernels
sudo apt clean                         # cached .deb files
sudo journalctl --vacuum-size=200M     # trim system logs

If you use Docker, it is almost always the biggest disk hog:

docker system df                       # see what Docker is using

⚠️ Careful, this deletes data: docker system prune -a --volumes removes unused images, containers and volumes. Volumes can hold databases. Run it deliberately. Drop --volumes if you only want to clear images and stopped containers.

4. Lighten the desktop

# Turn off window animations
gsettings set org.gnome.desktop.interface enable-animations false

# See if the file indexer is eating CPU in the background
tracker3 status

Then trim startup apps (search "Startup Applications"), keep browser tabs under control, and disable GNOME extensions you do not use. Your browser is usually a bigger memory hog than everything else combined, so turn on its built-in memory saver or tab discarding.

For a real step-change on very old hardware, install a lighter session and pick it at the login screen:

sudo apt install xubuntu-desktop -y    # XFCE: light and fast (optional)

5. Check the SSD and update firmware

# Find your disk's device name first
lsblk

# Health check (use nvme0n1 OR sda, whichever lsblk shows)
sudo apt install smartmontools -y
sudo smartctl -H /dev/nvme0n1

# Update BIOS / firmware (many laptops are supported)
sudo fwupdmgr refresh && sudo fwupdmgr update

6. What NOT to waste time on

Popular advice that will not move the needle on a modern Ubuntu release. Skip these:

preload: largely obsolete with SSDs
"RAM cleaner" apps and scripts: placebo, Linux manages memory well already
Reinstalling Ubuntu: rarely the real fix, and it costs you a day
Aggressive CPU-governor hacks: modern defaults are already sensible

7. The real ceiling (the honest part)

Everything above will stop the crashes and smooth out daily use. But two hardware truths set the actual ceiling:

Clean and repaste the cooling: the permanent cure for heat-driven shutdowns.
Add RAM: if you run containers, dev servers, or many browser tabs, more memory does more than every software tweak combined. Check your model's maximum capacity and slot count before buying.

Do the software fixes today, do the two hardware steps when you can, and you have solved the problem at the root instead of papering over it.

The 60-second version

Symptom	Most likely cause	Do this
Random shutdown	Overheating or weak battery	thermald, then clean + repaste
Long freezes	Out of RAM	zram + earlyoom + swappiness
General lag	Full disk or heavy desktop	cleanup + disable animations
Still slow	Not enough RAM	Upgrade memory

After all of this, my laptop went from freezing every few minutes to running smoothly through a full work day. It still slows down when I push it really hard, because 8 GB is 8 GB, but the freezes and the random shutdowns are gone.

If this helped you rescue an old machine, drop a comment with what worked for you, and share it with someone still fighting a laggy laptop. Follow me for more practical Linux and developer workflow tips.

LUMINA 3D LOGO GENERATOR WEB APP

Usang Emmanuel — Thu, 23 Apr 2026 14:56:47 +0000

This post is my submission for DEV Education Track: Build Apps with Google AI Studio.

What I Built

I Built a 3D logo generator app using Google studio which builds based on the user's decription for their logo in realtime

the prompt: i want you to build a web app that generates 3D LOGOs for business ideas and established businesses, ultra realistic logos with different templates for users to select from as well as decription panels for them to type the logo description, incorporate image generation with the Imagen API and using google API too for accurate logo details, a very user friendly and professional UI.

Demo

My Experience

I Learnt how to use google studio in less than 2hrs and i must say, i'm impressed by the high attention rate of this app to details.

Proof server and Indexer: how Midnight processes transactions

Usang Emmanuel — Tue, 21 Apr 2026 11:01:27 +0000

A hands-on walkthrough of Midnight's two core infrastructure components: the proof server that generates zero-knowledge proofs locally, and the Indexer that makes on-chain data queryable via GraphQL.

Introduction

This tutorial is aimed at developers who are new to Midnight and want to understand how transactions are processed behind the scenes.

When you build a DApp on Midnight, two pieces of infrastructure do most of the heavy work behind the scenes: the proof server and the Indexer. One handles the privacy side, the other handles the data side. You need both or nothing works. Understanding both is the difference between a DApp that works and a DApp that fails suddenly.

The proof server is the reason your private data stays private on Midnight. It runs locally on your machine, takes the ZK circuits produced by your Compact contract, combines them with your private inputs, and gives out a zero-knowledge proof. That proof is what gets submitted on-chain, not your data.

The Indexer handles the other direction. It watches the blockchain, parses every block and transaction, and exposes that data through a GraphQL API. Anything your DApp needs to read from on-chain (contract state, transaction history, epoch info) flows through the Indexer.

In this tutorial we will walk through what each component does, set them both up with Docker, talk about the version pinning that trips up most newcomers, and send real queries to the Indexer's GraphQL endpoint. By the end you will have a working local stack and a mental model for how a Midnight transaction actually moves from your wallet to the chain and back.

Prerequisites

Before you begin, make sure you have:

A machine running Ubuntu (or another Linux distribution)
Docker installed and running
Basic familiarity with the command line
curl installed (for testing GraphQL queries)

What the proof server actually does

Midnight transactions are different from what you are used to on Ethereum or Solana. There is no signature in the usual sense. Instead, a transaction carries a zero-knowledge proof, a compact proof that basically says "the computation described by this contract was executed correctly using valid private inputs" without revealing what those inputs actually were.

That proof does not just appear out of nowhere though. It requires the ZK circuits generated when your Compact contract is compiled, the verification keys that describe the circuit shape, and your actual witness data (balances, secrets, whatever the contract needs). The proof server is the process that takes all of that and produces the final zk-SNARK.

The important design choice here: it runs locally. Your private inputs never leave your machine. The server is a Docker container you run yourself, and the Midnight.js SDK talks to it over HTTP.

First-run behavior

The first time you start the proof server, it has to fetch some artifacts. You will see logs like this:

INFO midnight_base_crypto::data_provider: Missing zero-knowledge verifying key
for Zswap inputs. Attempting to download from the host
https://midnight-s3-fileshare-dev-eu-west-1.s3.eu-west-1.amazonaws.com/

That is the server pulling down the ZK verification keys and ZKIR (Zero-Knowledge Intermediate Representation) source files from Midnight's S3 bucket. Integrity is checked before anything is used. If a file's hash does not match, the server refuses to start.

Once the download is done and caching is complete, you will see:

INFO actix_server::builder: starting 4 workers
INFO actix_server::server: starting service: "actix-web-service-0.0.0.0:6300",
workers: 4, listening on: 0.0.0.0:6300

That is an Actix web server (Rust-based, very fast) spinning up with four worker threads on port 6300. This is the endpoint the SDK will hit when it needs a proof generated.

Confirming it is working and active

A quick server check for our local host:

curl http://localhost:6300

Returns:

{"status":"ok","timestamp":"2026-04-21 10:13:12.154677419 +00:00:00"}

If you get that response, the server is ready to accept proof requests.

Wiring it to your DApp

In your Midnight.js code, the SDK wrapper that talks to the proof server is httpClientProofProvider:

import { httpClientProofProvider } from
  '@midnight-ntwrk/midnight-js-http-client-proof-provider';

// Points to your local proof server
const proofProvider = httpClientProofProvider('http://localhost:6300');

From there, every time your DApp submits a transaction, the SDK bundles up the circuit and witness, sends it to localhost:6300, waits for the proof, and attaches it to the unsigned transaction before submission.

Docker setup for local development

Both the proof server and the Indexer ship as Docker images. If you do not already have Docker on your machine, get that sorted first.

For production, you can run your own Indexer and proof server on dedicated infrastructure, or use Midnight's hosted endpoints for Preview, Preprod, and Mainnet.

On Ubuntu (I am on 24.04):

sudo apt install -y docker.io
sudo usermod -aG docker $USER
# log out and back in, or:
newgrp docker

Verify with docker --version and docker run hello-world before going further. If docker run hello-world gives you a "permission denied" error, the group change has not taken effect yet. The newgrp docker above usually fixes it without a full logout.

Running the proof server

docker run -p 6300:6300 midnightntwrk/proof-server:8.0.3 midnight-proof-server -v

A few things worth calling out:

The -v flag on midnight-proof-server enables verbose logging. Keep it on while you are learning. When something goes wrong, the extra output tells you exactly where.
This command occupies your terminal. Open a new tab for everything else.
First run pulls the image and downloads the ZK artifacts, so it takes several minutes. Subsequent runs are fast because Docker caches the image and the artifacts persist inside the container.

Running the Indexer

For a fully local setup, run the standalone Indexer image. The correct tag depends on your target network:

# For Preview network
docker run -p 8088:8088 \
  -e APP__INFRA__SECRET=$(openssl rand -hex 32) \
  midnightntwrk/indexer-standalone:4.3.2

# For Preprod / Mainnet
docker run -p 8088:8088 \
  -e APP__INFRA__SECRET=$(openssl rand -hex 32) \
  midnightntwrk/indexer-standalone:4.0.1

The APP__INFRA__SECRET is required. It is used to encrypt sensitive data the Indexer stores internally. Generating it with openssl rand -hex 32 gives you a clean 256-bit hex string.

By default the standalone Indexer connects to a local Midnight node at ws://localhost:9944, so if you want a fully self-contained stack you will also need a node running. For most DApp development that is overkill.

Use the hosted Indexer instead

For development work, the simplest approach is to skip the standalone Indexer entirely and hit Midnight's hosted endpoints:

Preview: https://indexer.preview.midnight.network/api/v4/graphql
Preprod: https://indexer.preprod.midnight.network/api/v4/graphql
Mainnet: https://indexer.mainnet.midnight.network/api/v4/graphql

These are the same Indexer code, just running against Midnight's test and production networks. You get a fully-synced indexer for free, which is great when you are prototyping.

Errors you will actually hit

A few I have run into:

permission denied while trying to connect to the Docker daemon socket: your user is not in the docker group yet. Run the usermod and newgrp commands above.
bind: address already in use on port 6300: something else is already bound to that port, or a previous container is still running. docker ps to find it, docker stop <container-id> to kill it.
Cannot connect to the Docker daemon: the daemon is not running. sudo systemctl start docker.

Those are some quick fixes to the issues I encountered while setting up.

Docker tags and version pinning

This is the single most important thing to get right, and also the easiest to get wrong.

The proof server version must be compatible with the ledger version your target network runs. Always check the support matrix for the exact pairing before pulling images.

Here is the current compatibility matrix at the time of writing:

Component	Version	Notes
Node (Midnight)	1.0.0	Preview
Node (Midnight)	0.22.5	Preprod / Mainnet
Compact devtools (`compact`)	0.5.1	Installs compilers, manages versions
Compact compiler (`compact compile`)	0.31.0	Contract compiler
Compact runtime	0.16.0	Runtime library
On-chain runtime	3.0.0	v3
Ledger	8.1.0	Preview
Ledger	8.0.3	Preprod / Mainnet
Midnight.js	4.1.1	DApp framework
Midnight Indexer	4.3.2	Preview
Midnight Indexer	4.0.1	Preprod / Mainnet
Proof server	8.0.3	ZKP generation

Version matrix verified against the live support matrix on June 5, 2026. Always check https://docs.midnight.network/relnotes/support-matrix before pulling images, as versions change between network upgrades.

Why alignment matters

The proof server generates proofs against a specific circuit format. The Ledger (the on-chain state machine) defines how those proofs are verified. Both sides have to agree on the exact format, verification keys, and field layout. If they do not, one of two things might happen:

The proof is rejected outright when your transaction hits the chain.
Worse, the transaction silently fails in a way that is very hard to debug, because the proof itself looked structurally fine but encoded assumptions the ledger no longer holds.

You do not want to be debugging that at 2 AM. Just pin the versions.

How to check

Before pulling any image, check the official support matrix:

https://docs.midnight.network/relnotes/support-matrix

Then pin explicitly:

# Proof server 8.0.3 is compatible with Ledger 8.0.3 (Preprod/Mainnet)
docker pull midnightntwrk/proof-server:8.0.3   # Correct
docker pull midnightntwrk/proof-server:7.0.0   # Version mismatch
docker pull midnightntwrk/proof-server:latest  # Never do this

Best practices

Never use :latest. Your setup might work today and break tomorrow for no obvious reason and you will ship bugs that only appear on some machines.
Keep a note of your working combination in your repo's README. When a teammate clones the project six months from now, that one line saves them an afternoon of confusion.
Pin every component together. When you upgrade the Ledger, also upgrade the proof server, the Node, and update your Compact compiler.

Querying the Indexer with GraphQL

Now for the fun part. The Indexer's GraphQL API is where your DApp or a debugger reads on-chain data. Let's send some real queries to the Preview network endpoint and walk through what comes back.

Query 1: get the latest block

curl -s -X POST https://indexer.preview.midnight.network/api/v4/graphql \
  -H "Content-Type: application/json" \
  -d '{"query": "{ block { hash height timestamp protocolVersion author } }"}' \
  | python3 -m json.tool

Response:

{
  "data": {
    "block": {
      "hash": "2a4d888a...",
      "height": 293425,
      "timestamp": 1776161520001,
      "protocolVersion": 22000,
      "author": "3a8a798e..."
    }
  }
}

Fun fact: my first query used blocks instead of block and the API corrected me. The error messages are actually helpful.

Breaking down what you get back:

hash: the unique identifier for this block.
height: block number, basically a counter that keeps going up.
timestamp: Unix time in milliseconds.
protocolVersion: which version of the Midnight protocol this block was produced under. Useful for detecting upgrades.
author: the validator (stake pool operator) who produced the block.

Query 2: fetch a specific block by height

Pass an offset argument to target a specific block. Here is the genesis block:

curl -s -X POST https://indexer.preview.midnight.network/api/v4/graphql \
  -H "Content-Type: application/json" \
  -d '{"query": "{ block(offset: { height: 1 }) { hash height timestamp transactions { hash id protocolVersion contractActions { address } } } }"}'

This also pulls in the transactions in that block, and for each transaction the contract actions it triggered. Running it against Preview returned the genesis block with its initial bootstrapping transaction.

Query 3: current epoch information

curl -s -X POST https://indexer.preview.midnight.network/api/v4/graphql \
  -H "Content-Type: application/json" \
  -d '{"query": "{ currentEpochInfo { epochNo durationSeconds elapsedSeconds } }"}'

Result showed epochNo: 986757, durationSeconds: 1800 (a 30-minute epoch), and whatever elapsedSeconds had accumulated by the time of the call. Handy when you are building anything that cares about staking cycles or time-based contract logic.

Query 4: read contract state by address

This is the query a real DApp actually needs. Once you have a deployed contract address, you can fetch its current on-chain state:

curl -s -X POST http://localhost:8088/api/v4/graphql \
  -H "Content-Type: application/json" \
  -d '{"query": "{ contractAction(address: \"99d36f1c860ee0cf83b23b1b90ca61e9bd2b32597ae2c09dd3fae3ecc7ed0bd5\") { address state transaction { hash } } }"}' \
  | python3 -m json.tool

Response:

{
  "data": {
    "contractAction": {
      "address": "99d36f1c860ee0cf83b23b1b90ca61e9bd2b32597ae2c09dd3fae3ecc7ed0bd5",
      "state": "6d69646e696768743a636f6e74726163742d73746174655b76365d...",
      "transaction": {
        "hash": "b5f984348ba73e0f747df7f1da886159d48d3a6cc5514abf18656f9030cc8ee7"
      }
    }
  }
}

Breaking down what comes back:

address: the contract's unique identifier on the network.
state: the hex-encoded on-chain state of the contract. This is the serialized WASM state blob. Your DApp deserializes it using the contract's TypeScript bindings.
transaction: the transaction that produced this state update, identified by its hash.

The ContractAction type also exposes zswapState, unshieldedBalances, and a reference back to the full transaction object if you need deeper context.

I deployed a Hello World contract using create-mn-app to get a real contract address to demonstrate this query:

Pro tip: schema introspection

Do not memorize the schema. Ask for it:

curl -s -X POST https://indexer.preview.midnight.network/api/v4/graphql \
  -H "Content-Type: application/json" \
  -d '{"query": "{ __schema { queryType { fields { name description } } } }"}'

That returns every available top-level query along with its description. I do this every time I am exploring a new version of the Indexer.

What is available

Top-level queries include:

block: get a block by hash or height (latest if no offset).
transactions: look up transactions by hash or identifier.
contractAction: fetch contract actions by contract address.
currentEpochInfo: current epoch number and timing.
spoCount: number of stake pool operators.
stakeDistribution: stake distribution across validators.
Plus dustGenerationStatus, dParameterHistory, and others.

Useful block fields: hash, height, protocolVersion, timestamp, author, ledgerParameters, parent, transactions, systemParameters.

Useful transaction fields: id, hash, protocolVersion, raw, block, contractActions, unshieldedCreatedOutputs, unshieldedSpentOutputs, zswapLedgerEvents, dustLedgerEvents.

WebSocket subscriptions for real-time updates

Polling the Indexer for new data works but burns bandwidth and adds latency. For anything live (a wallet UI that updates when funds arrive, a dashboard that streams blocks, a DApp that reacts to contract state changes) you want subscriptions.

The Indexer's GraphQL endpoint also accepts WebSocket connections, and the schema exposes a set of subscriptions you can tap into.

Available subscriptions

Discovered via schema introspection:

blocks: subscribe to new blocks as they arrive, with an optional starting offset.
contractActions: stream contract actions filtered by contract address.
shieldedTransactions: shielded transaction events for a given session ID.
unshieldedTransactions: unshielded transaction events for a given address.
zswapLedgerEvents: ZSwap ledger events.
dustLedgerEvents: DUST ledger events.

Why this matters

The difference between polling and subscriptions looks small until you are running it at scale:

Polling: "anything new?" no. "anything new?" no. "anything new?" yes, here. Every poll is a request, whether or not there is data.
Subscription: you ask once, the Indexer pushes data to you whenever there is something to say.

For a block explorer or a live wallet view, this is the difference between a smooth UI and one that either lags or hammers the Indexer.

Connecting with WebSocket

The correct endpoint for WebSocket subscriptions adds a /ws suffix:

wss://indexer.preview.midnight.network/api/v4/graphql/ws

The protocol is graphql-transport-ws, not the legacy start message type. The correct handshake is connection_init then connection_ack then subscribe then next.

Here is a working Node.js subscription client:

const WebSocket = require('ws');

const ws = new WebSocket(
  'wss://indexer.preview.midnight.network/api/v4/graphql/ws',
  'graphql-transport-ws'
);

ws.on('open', () => {
  console.log('Connection opened, sending connection_init...');
  ws.send(JSON.stringify({ type: 'connection_init', payload: {} }));
});

ws.on('message', (data) => {
  const msg = JSON.parse(data.toString());
  console.log('Received:', JSON.stringify(msg));

  if (msg.type === 'connection_ack') {
    console.log('Acknowledged. Subscribing to blocks...');
    ws.send(JSON.stringify({
      id: '1',
      type: 'subscribe',
      payload: {
        query: 'subscription { blocks { hash height timestamp } }'
      }
    }));
  }

  if (msg.type === 'next') {
    console.log('>>> NEW BLOCK:', JSON.stringify(msg.payload.data.blocks, null, 2));
  }
});

ws.on('error', (err) => console.error('Error:', err.message));

Running this against the Preview network produces a live stream of blocks as they are produced:

Connection opened, sending connection_init...
Received: {"type":"connection_ack"}
Acknowledged. Subscribing to blocks...
>>> NEW BLOCK: {
  "hash": "0a1332ee9e9df5c0d189fecf0abe5295622a87b14b79fdf79e90dab3b13f0725",
  "height": 1044844,
  "timestamp": 1780671888000
}
>>> NEW BLOCK: {
  "hash": "15fcfcab66b95f7c38acbe6f16e62479347cc20161f10c49c40487da972f0cee",
  "height": 1044845,
  "timestamp": 1780671894001
}
>>> NEW BLOCK: {
  "hash": "1ea601c792222aceaa66ad305592cef3ddeef98d66de0fcab76e9936f900f9ca",
  "height": 1044846,
  "timestamp": 1780671900000
}

Each next message carries the new block data as it arrives. No polling required.

`indexerPublicDataProvider` vs. direct GraphQL

You now have two ways to read Indexer data: through the Midnight.js SDK, or by hitting the GraphQL endpoint directly. Both are valid and useful in different situations.

To be honest, if you are just starting out, the direct GraphQL approach is easier to understand because you can see exactly what is happening.

The SDK approach

import { indexerPublicDataProvider } from
  '@midnight-ntwrk/midnight-js-indexer-public-data-provider';

const provider = indexerPublicDataProvider(
  'https://indexer.preview.midnight.network/api/v4/graphql',
  'wss://indexer.preview.midnight.network/api/v4/graphql/ws'
);

The main thing this provider exists to do is contractStateObservable, which subscribes to a deployed contract's live state:

const CONTRACT_ADDRESS = '99d36f1c860ee0cf83b23b1b90ca61e9bd2b32597ae2c09dd3fae3ecc7ed0bd5';

const subscription = provider.contractStateObservable(
  CONTRACT_ADDRESS,
  { type: 'latest' }
).subscribe({
  next: (state) => {
    console.log('Contract state received:', JSON.stringify(state, null, 2));
  },
  error: (err) => console.error('Error:', err),
});

Running this against a locally deployed Hello World contract returns the live contract state object:

Subscribing to contract state via indexerPublicDataProvider...
Contract state received:
{
  "__wbg_ptr": 1188192
}

The __wbg_ptr value is a WebAssembly memory pointer. The SDK has deserialized the raw hex state blob from the Indexer into a live WASM object your contract's TypeScript bindings can work with directly. This is the abstraction indexerPublicDataProvider provides over raw GraphQL.

What this gets you:

A type-safe TypeScript interface: autocomplete, compile-time checks, the works.
Clean integration with the rest of Midnight.js. deployContract() and findDeployedContract() both use this provider internally.
Automatic serialization and deserialization: on-chain byte blobs become usable objects.
Managed WebSocket subscription lifecycle: no manual reconnect logic.

The direct approach

curl -s -X POST https://indexer.preview.midnight.network/api/v4/graphql \
  -H "Content-Type: application/json" \
  -d '{"query": "{ block { hash height timestamp } }"}'

What this gets you:

Full control over the exact query shape.
Zero dependency on TypeScript or Node.js. You can hit the endpoint from Python, Go, Rust, a shell script, or Postman.
A fast debugging loop: no rebuild, no bundler, just a curl.
Freedom to build tools that do not fit the SDK's assumptions (custom analytics, block explorers, monitoring).

Picking between them

Use case	Recommendation
Building a DApp with Midnight.js	`indexerPublicDataProvider`
Debugging contract state	Direct GraphQL
Building a block explorer	Direct GraphQL
Custom analytics or monitoring	Direct GraphQL
Standard contract deployment	`indexerPublicDataProvider`

How they relate

The important thing to note: indexerPublicDataProvider is a wrapper around the same GraphQL API. Under the hood, the SDK is sending the same queries you would send by hand. It just wraps them in a typed, cleaner interface that plays well with the rest of the Midnight.js ecosystem.

So everything you learn from running raw GraphQL queries still helps you when you use the SDK later. Time spent exploring the GraphQL endpoint with curl makes you a better SDK user, because you develop intuition for what the SDK is actually doing. And if you ever need to step outside the SDK to build tooling, to debug a weird state, or to automate something, you already know the shape of the API.

Wrapping up

The proof server and the Indexer are the two halves of how a Midnight DApp interacts with the network:

proof server: privacy side. Generates ZK proofs locally so your private data never leaves your machine.
Indexer: data access side. Makes on-chain state queryable via GraphQL, with WebSocket subscriptions for real-time updates.

Before you go, remember: pin your Docker tags and check the support matrix religiously, use indexerPublicDataProvider for building DApps and direct GraphQL for debugging, and use schema introspection whenever you want to explore what the Indexer can do.

Resources

Midnight docs: https://docs.midnight.network/getting-started
Support / compatibility matrix: https://docs.midnight.network/relnotes/support-matrix
Midnight Discord: https://discord.com/invite/midnightnetwork

From here, check out the official tutorials for building your first contract on Midnight.

DEV Community: Usang Emmanuel

Why Your Ubuntu Laptop Lags, and How to Fix It for Free

0. Diagnose first, do not guess

1. Fix the random shutdowns (heat)

2. Fix the freezing (memory pressure)

3. Reclaim disk space

4. Lighten the desktop

5. Check the SSD and update firmware

6. What NOT to waste time on

7. The real ceiling (the honest part)

The 60-second version

LUMINA 3D LOGO GENERATOR WEB APP

What I Built

Demo

My Experience

Proof server and Indexer: how Midnight processes transactions

Introduction

Prerequisites

What the proof server actually does

First-run behavior

Confirming it is working and active

Wiring it to your DApp

Docker setup for local development

Running the proof server

Running the Indexer

Use the hosted Indexer instead

Errors you will actually hit

Docker tags and version pinning

Why alignment matters

How to check

Best practices

Querying the Indexer with GraphQL

Query 1: get the latest block

Query 2: fetch a specific block by height

Query 3: current epoch information

Query 4: read contract state by address

Pro tip: schema introspection

What is available

WebSocket subscriptions for real-time updates

Available subscriptions

Why this matters

Connecting with WebSocket

indexerPublicDataProvider vs. direct GraphQL

The SDK approach

The direct approach

Picking between them

How they relate

Wrapping up

Resources

`indexerPublicDataProvider` vs. direct GraphQL