open clearing engine
what happens after a trade? a rust implementation of novation, netting, and settlement, with an event log that can be replayed.
hello, i'm dharun ashokkumar · india
i build systems to understand how they work.
from linux infrastructure to a clearing engine in rust. i like getting close to the machinery: how a container stays isolated, how a virtual machine starts, how a trade becomes a settlement.
i'm studying computer science at lovely professional university, and sharing the code and the lessons along the way.
open to internships, freelance work, and open-source collaboration.
follow the work: clearing-engine source · lpu labs in screenshots · merged contributions
three things i've built
different problems. the same need to see what's happening underneath.
lpu labs
a development environment should be a browser tab away. this platform brings together docker orchestration, per-user networks, and persistent storage.
vmmanager
virtual machines and containers in one native desktop app. written in c to work directly with the libraries and sockets underneath.
on my workbench
a working reading list · updated
- building
- clearing infrastructure — following a trade all the way to a replayable settlement result.
- learning
- linux isolation — where a container's network, storage, and resource boundaries meet.
- debugging notes
- vm connection handling — memory ownership and sockets that stop talking.
these threads come from my project notes. read the longer versions →
inside the homelab
a learning map, not a live inventory or status dashboard.
an architecture sketch of the systems i work with, based on lpu labs and vmmanager. open a layer to explore its job and the engineering question behind it.
linux hostcompute, networking, and storage underneath it all
01browser labs
runs: development environments managed through fastapi and docker, with browser access through kasmvnc or code-server.
why: make a prepared environment accessible without local installation.
the question: how do you reclaim idle compute without removing a user's work?
02virtual machines
runs: qemu/kvm virtual machines managed through libvirt; incus containers through a separate api.
why: keep both management paths in one native desktop interface.
the lesson: a quiet dashboard hides memory ownership and connections that can fail.
03networks & volumes
runs: per-user docker networks and persistent volumes in the lab platform.
why: separate users' traffic and keep files beyond a container's lifetime.
the question: which resources belong to a session, and which belong to the user?
04observability
runs: prometheus metrics, structured logs, and container health checks in the documented lab architecture.
why: make resource usage and lifecycle events inspectable.
the question: can the logs explain a failed launch without reproducing it?
notes from the work
- why i built a clearing engine i'll probably never run in productionwhat replayability taught me about correctness.
- a backtest that ignores costs is fictionthe assumptions that disappear when transaction costs arrive.
about me
i started with arduino projects. somewhere along the way, the questions grew into whole systems. more about me →
around the site
say hello
have something interesting to build? say hello, or read my resume.