AZEEM // SRC.INDX

HYDERABAD, IN // --:-- GMT+5:30

RUST // GO // DISTRIBUTED_SYSTEMS

I'm Azeem —
Engineering
resilient, low-
latency systems
for Web3.

Scaling cross-chain infrastructure and distributed solver systems — from design to production.

Illustration of Azeem Shaik

Current Direction

Currently at Garden Finance — building the solver infrastructure behind cross-chain atomic swaps across Bitcoin, EVM, and beyond.

Since Oct 2024 — Atomic swaps, Rust, and a lot of edge cases

Built an RFQ solver engine in Rust — covering pricing, hedging, and settlement

Extended the atomic swap protocol to Tron — swap settles under 30 secs

Selected Work

Projects Archive

Distributed systems, cryptographic tooling and product software built to hold up under real use.

LIVE_ARCHIVE / 04 ENTRIES

Munger

Production RFQ solver for cross-chain swaps — covering quote generation, execution, hedging, inventory rebalancing, and settlement, backed by a double-entry ledger and fixed-point arithmetic for deterministic P&L under concurrent flows.

Rust · HTLCs · Hexagonal Architecture · Market Making

Solver
Cross-chain
DeFi

Markdown Utils

Privacy-first markdown toolkit for developers working with specs, docs, and AI-generated output. Export to PDF, DOCX, and HTML, diff revisions, normalize messy markdown, and inspect document structure without sending files to a server.

Next.js · TypeScript · Markdown Parsing · Client-side Export

Web App
Developer Tool
Client-side

HSM Simulator

Software-based HSM simulator for Bitcoin and EVM signing. Validates custody and recovery flows with Taproot PSBT signing, EVM hash signing, and an m-of-n admin recovery path under the same address.

Bitcoin · Taproot · BIP341 · Next.js

Bitcoin
Cryptography
Simulator

API Client Macro

Published Rust macro that generates type-safe HTTP clients from declarative endpoint definitions — expanding one API spec into async traits, concrete clients, and request handling code.

Rust · Procedural Macros · Async · Type System

Rust
Open Source
Dev Tooling

Working Principles

Make the critical path reliable first.

The most interesting problems are the ones that have to be correct, fast, and ready to hold up in production.

01

Prove The Hard Path

Get the hardest path working end to end first. Everything around it gets easier once that holds.

02

Make Failure Modes Obvious

A system is easier to trust when its weak spots are clear. I want to know how it fails before I depend on it.

03

Measure Real Behavior

I trust traces, latency data, and real failures over instinct — the system tells you what matters.