Software Engineer · Systems · Rust · Trading · Blockchain · Open Source
I like understanding what happens underneath the abstraction.
I'm a software engineer interested in systems programming, backend infrastructure, Rust, distributed systems, trading systems and blockchain infrastructure.
I started by building web applications and backend services.
Then I started asking questions like:
What happens when this gets concurrent? Where is the bottleneck? What actually happens in memory? How does the data move through the system? What happens when something fails?
That curiosity gradually pulled me toward Rust, C++, Linux, low-latency systems, financial infrastructure and blockchain protocols.
I'm interested in building software close to the critical path:
Rust · C++ · Linux · Networking · Concurrency · Distributed Systems · Performance
I enjoy working on systems where memory, synchronization, data structures and latency aren't implementation details — they're part of the design.
A growing part of my work is around the engineering behind financial markets.
I'm interested in:
Market Data
↓
Order Book
↓
Strategy
↓
Risk
↓
Execution
↓
Portfolio
Especially:
market microstructure · matching engines · order books · low-latency systems · execution · risk · systematic trading · quantitative research
I'm less interested in treating trading as a black box and more interested in understanding the infrastructure that makes a trading system work.
I've also spent significant time building around blockchains.
My interests include:
Solana · Move · Sui · smart contracts · blockchain indexing · on-chain execution · protocol infrastructure
What interests me most isn't simply writing contracts.
It's everything around them:
Smart Contract
↓
Execution
↓
Events / State Changes
↓
Indexer
↓
Database
↓
Market Data / Application
I've worked with both Solana/Rust and Move-based ecosystems, which has given me a different perspective on smart-contract execution, resource/state models, indexing and protocol design.
I don't try to list everything here.
These are a few projects that represent the direction I'm heading.
A CLOB-based trading system built around Solana and Rust.
The project explores the complete path from an on-chain matching engine to off-chain indexing, market data and a trading interface.
Solana · Rust · CLOB · Indexing · Trading Infrastructure
A C++20 implementation exploring the mechanics behind high-performance order-book systems.
Things I've experimented with include:
SPSC queues · object pools · intrusive data structures · cache behaviour · integer arithmetic · latency measurement
I use Rust for projects where I want to understand the system rather than hide it behind abstractions.
That includes:
event-driven architectures · accounting/ledger systems · blockchain infrastructure · execution systems · concurrency
I've also worked with Move-based blockchain systems, particularly around protocol logic, mathematical correctness and execution.
One area I've explored deeply is how seemingly simple numerical algorithms behave when implemented with integer arithmetic and blockchain constraints.
That intersection of:
Mathematics + Programming Languages + Protocol Design
is something I find particularly interesting.
I enjoy contributing to systems that already have users, architecture and constraints.
I've been working around projects in:
CNCF · Kubernetes · KubeEdge · HAMi · cloud-native infrastructure · sandboxing · Rust · blockchain infrastructure
The part I enjoy most is not just writing the patch.
It's:
Read the architecture
↓
Understand the existing assumptions
↓
Reproduce the problem
↓
Find the actual failure mode
↓
Make the smallest correct change
↓
Test it
↓
Send it upstream
That's a very different kind of engineering from building a project from scratch — and I enjoy it.
I'm particularly interested in the layers people normally don't see.
Application
│
Backend / APIs
│
Distributed Systems
│
Networking / IPC
│
Processes / Threads
│
Memory / Cache
│
CPU
And in trading / blockchain:
Protocol
│
Execution
│
State
│
Events
│
Indexing
│
Market Data
│
Application
Understanding those boundaries is what makes engineering interesting to me.
Competitive programming has been another way I've developed that mindset.
1000+ DSA problems ICPC 2023 Amritapuri Regionalist Team Loopy_bois Regional Rank: 108 / 228
I still enjoy problems where the first solution works — but the interesting question is:
Can we make it better?
Blockchain: Solana · Move · Sui · Aptos · Smart Contracts · Indexers
Systems: Rust · C++ · Linux · Networking · Concurrency
Backend: Node.js · NestJS · PostgreSQL · MySQL · MongoDB · Redis
Infrastructure: Docker · Kubernetes · Cloud Native
Rust
├── Systems Programming
├── Concurrency
├── Networking
└── Performance Engineering
Trading
├── Market Microstructure
├── Order Books
├── Execution
├── Risk
└── Quantitative Research
Blockchain
├── Solana
├── Move
├── Sui
├── Smart Contracts
├── Indexing
└── Protocol Infrastructure
Open Source
├── Kubernetes
├── Cloud Native
├── Sandboxing
└── Developer Infrastructure
I enjoy competitive programming, reading about systems and digging into how things work below the API.
Lately, that usually means going down one of these rabbit holes:
"How fast can this be?"
"What happens if this fails?"
"Why was it designed this way?"
"Can I understand the implementation instead of just using it?"
Systems · Rust · Trading · Blockchain · Open Source
Build it. Measure it. Understand it.