Forem: Sumana

Perpetual Engine Series Part 1: The Liquidation Logic

Sumana — Fri, 27 Mar 2026 16:57:00 +0000

When building a high-leverage trading engine, the most critical component isn't just speed—it’s the Risk Engine. If your liquidation logic fails, the exchange carries the debt, and the system becomes insolvent.

In this first post of my series, I’m diving deep into how I built the liquidation safety net for my Rust-based engine.

1. What is Liquidation?

Liquidation is the automatic closure of a position when a trader's collateral (Margin) is exhausted.

In perpetual trading, leverage is a double-edged sword. For example:

Margin: $100
Leverage: 10x
Position Size: $1,000

If the price moves against you, losses mount quickly. Once your $100 margin can no longer cover the loss, the engine must force-close the position to protect the exchange from losses exceeding your collateral.

2. The Liquidation Price (The Threshold)

The moment a position is opened, the engine calculates a Liquidation Price. This provides the trader with a predictable "point of no return."

The Formula

We use a 5% Maintenance Margin Rate ($0.05$). This means we trigger the close when you have 5% of your buffer remaining.

For Longs:
Liquidation Price = Entry Price × (1 - (0.95 / Leverage))

For Shorts:
Liquidation Price = Entry Price × (1 + (0.95 / Leverage))

Rust Implementation

Using rust_decimal ensures we avoid the dangerous rounding errors found in standard floating-point math.

let maintenance_buffer = dec!(1.0) - self.maintenance_margin_rate; // 0.95

let liquidation_price = match position_type {
    PositionType::Long => {
        entry_price * (dec!(1.0) - (maintenance_buffer / leverage))
    }
    PositionType::Short => {
        entry_price * (dec!(1.0) + (maintenance_buffer / leverage))
    }
};

3. Real-Time Maintenance Checks

While the Liquidation Price is set at the start, liquidations happen in real-time. On every price update, the engine performs a "Health Check":

Rule: Current Equity (Margin + PnL) <= Maintenance Threshold (Margin * 0.05)

The Logic in Action

fn should_liquidate(&self, position: &Position) -> bool {
    let current_equity = position.margin + position.pnl;
    let maintenance_threshold = position.margin * self.maintenance_margin_rate;
    current_equity <= maintenance_threshold
}

pub fn update_price(&mut self, new_price: Decimal) -> Result<UpdateResult, String> {
    // ... update PnL for all positions ...

    let to_liquidate: Vec<Uuid> = self
        .positions
        .values()
        .filter(|p| self.should_liquidate(p)) // Check every position
        .map(|p| p.id)
        .collect();

    for id in to_liquidate {
        self.close_position(id)?; // Force close
    }

    Ok(UpdateResult { ... })
}

4. Edge Cases: Beyond the Price

A robust engine must account for more than just price swings.

Edge Case 1: Funding Liquidation

In perpetuals, funding is applied periodically (every hour in my engine). If funding costs are large enough, they can erode a trader's margin and trigger liquidation even if the market price hasn't moved.

pub fn apply_funding(&mut self) -> Result<FundingResult, String> {
    // ... apply funding payments ...

    // Check for liquidations post-funding
    let to_liquidate: Vec<Uuid> = self
        .positions
        .values()
        .filter(|p| self.should_liquidate(p))
        .map(|p| p.id)
        .collect();

    for id in to_liquidate {
        self.close_position(id)?;
    }

    Ok(FundingResult { ... })
}

Edge Case 2: Double-Liquidation Prevention

Race conditions are real. If a price update and a funding payment hit simultaneously, you might try to close the same position twice. Using Result<T, E> and atomic-style state removal handles this gracefully.

pub fn close_position(&mut self, position_id: Uuid) -> Result<Decimal, String> {
    let position = self.positions.remove(&position_id)
        .ok_or_else(|| format!("Position not found"))?; 

    // If it's already closed, we return an Error rather than panicking.
    // This ensures our engine stays online and consistent.
}

5. Summary Table

Concept	What	When	Why
Liq Price	Pre-calculated threshold	Position Open	User transparency & risk awareness
Maintenance Check	Real-time equity check	Every price update	Catching volatility/flash moves
Close Position	Force-close the trade	When check triggers	Preventing negative equity/systemic loss
Error Handling	`Result<T, E>` logic	On liquidation	Preventing double-closes & race conditions

Conclusion

Proper liquidation logic ensures that losses are capped at the user's margin, the exchange stays solvent, and the system remains fair for all traders.

Building a Low-Latency Trading Engine in Rust

Sumana — Sun, 22 Mar 2026 18:39:57 +0000

When I started building a perpetual futures engine in Rust, the requirements looked straightforward:

Binance streams price updates
Users constantly check balances
Liquidations happen automatically

All of this needs to run at the same time, with low latency and zero mistakes.

Naturally, I started with a Mutex.
It felt like the safe, obvious choice.

But that assumption didn’t last long.

The First Problem: Reads Were Slower Than They Should Be

In this system, most operations are reads:

balance checks
position queries

Writes (like price updates) are much less frequent.

But with a Mutex, everything queues behind everything.

So even simple reads were waiting behind writes—and worse, sometimes behind network delays.

That’s when it became clear:

I was treating all operations equally, even though they aren’t.

Switching to RwLock

The first real improvement was replacing Mutex with RwLock.

let engine = Arc::new(RwLock::new(Engine::new(1000.0)));

Now:

Multiple readers can access the state at the same time
Writers still get exclusive access

// Read
let engine = engine.read().await;

// Write
let mut engine = engine.write().await;

This change alone removed the biggest bottleneck.

Reads stopped blocking each other, and latency dropped significantly.

The Next Issue: Blocking vs Yielding

Even with RwLock, there’s another subtle issue.

If you use blocking locks, the entire thread waits.

That means while one task is waiting:

no other tasks can run
the thread is effectively idle

With async:

let engine = engine.write().await;

The task yields instead of blocking.

That allows:

other API calls to run
other tasks to progress

This is what makes it possible to handle a large number of concurrent tasks efficiently.

Network I/O Was Still a Problem

Even after fixing locks, something still felt off.

The engine was directly tied to the WebSocket feed.

And network behavior is unpredictable:

sometimes fast
sometimes slow
sometimes delayed

That means your core engine inherits that unpredictability.

Decoupling with MPSC

The fix here was to separate concerns using a channel.

Instead of processing prices directly:

WebSocket → Channel → Engine

let (tx, mut rx) = tokio::sync::mpsc::channel(100);

The WebSocket task just sends updates
The engine processes them independently

This removes network jitter from the critical path.

The engine becomes more predictable, even if the network isn’t.

Sharing State Across Tasks

At this point, multiple parts of the system needed access:

WebSocket task
API handlers
liquidation logic

Rust doesn’t allow multiple owners by default, so this needs to be explicit.

That’s where Arc comes in:

let engine = Arc::new(RwLock::new(Engine::new(1000.0)));

Each task gets a clone:

let engine_clone = engine.clone();

Now everything shares the same state safely.

Financial Accuracy: Why f64 Doesn’t Work

This is one of those things that seems small but isn’t.

Using f64:

1000.0 - 0.1 - 0.1 - 0.1
= 999.7000000000001

That error might look tiny, but in a trading system:

it accumulates
it affects PnL
it can break liquidation logic

So instead:

use rust_decimal::Decimal;

Now calculations are exact.

No rounding surprises.

Handling Errors Without Crashing

One last thing: reliability.

In a system like this, a panic isn’t just a bug—it’s downtime.

So instead of:

.unwrap()

Everything returns a Result<T, E>:

let position = self.positions.get(&id)
    .ok_or("Position not found")?;

Errors are handled and propagated, not ignored.

Putting It Together

At a high level, the system looks like this:

WebSocket → MPSC Channel → Engine Processor
                                ↓
                         Arc<RwLock<Engine>>
                                ↓
                  API + Reads + Writes + Liquidations

Each part solves a specific problem:

RwLock → efficient reads
async/await → no thread blocking
MPSC → isolates network behavior
Arc → shared ownership
Decimal → exact calculations
Result<T, E> → reliability

Final Thought

None of these choices are “fancy.”

They’re just responses to real constraints:

high read volume
unpredictable I/O
strict correctness requirements

Once those constraints are clear, the architecture almost designs itself.

Escrow as a Design Choice

Sumana — Sat, 24 Jan 2026 16:40:00 +0000

Most freelance platforms are broken in one very specific way: they custody money. Either the client pays the platform and hopes it behaves, or the freelancer works first and prays they’ll get paid. Both models rely on trust, and trust is exactly what software is supposed to remove.

This is where escrow actually matters — not as a buzzword, but as a design choice.

A proper escrow doesn’t ask who do you trust?
It asks what is allowed to happen, and when?

On Solana, an escrow can be designed so that no human, not even the platform admin, can touch the funds. Every job creates its own on-chain agreement. The client locks money, the freelancer is named upfront, and the platform steps out of the money flow entirely. No “support tickets”, no “we’ll look into it”, no delayed releases.

The most interesting part is this: the contract doesn’t hold money — it holds rules. The money lives in a vault controlled by a Program Derived Address. That vault has no private key. No one can “log in” and move funds. The only way money moves is if the contract’s conditions are met.

This flips the power dynamic. The platform stops being a judge. The client can’t rug. The freelancer can’t fake a claim. And the code doesn’t negotiate.

What makes this powerful isn’t complexity — it’s restraint. One job, one escrow, one vault. Funds never mix. There’s no global balance to mismanage, no admin override to abuse. You don’t need to trust the platform because it literally cannot steal from you.

Most freelance platforms fail quietly — not because of features, but because of how money is handled. An escrow forces clarity upfront: who is paying, who gets paid, which token is used, and when funds can move. Once these rules are encoded, there’s very little room for ambiguity or misuse.

A platform doesn’t need the ability to move user funds freely to function. In fact, removing that power often leads to a simpler and safer system. The contract becomes the source of truth. The platform becomes just an interface.

Appendix: Reference Escrow Implementation

Rust Macros: Declarative vs Procedural

Sumana — Sat, 27 Dec 2025 17:25:00 +0000

Rust macros often feel intimidating at first, especially if you’re coming from traditional object-oriented or scripting languages. But macros in Rust exist for one simple reason: to eliminate boilerplate and enable powerful compile-time code generation.

Once you understand why macros exist and the two types Rust provides, they become an essential tool rather than a scary one.

Why Rust Has Macros

Functions in Rust are used to reuse behavior.
Macros, on the other hand, are used to reuse syntax and structure.

Macros:

Run at compile time
Generate Rust code
Have zero runtime cost

This makes them ideal for patterns that functions simply cannot express.

Declarative Macros (`macro_rules!`)

Declarative macros are the first type of macros most Rust developers encounter.

macro_rules! create_function {
    ($name:ident) => {
        fn $name() {
            println!("Hello from {}", stringify!($name));
        }
    };
}

Using the macro:

create_function!(hello);

At compile time, this expands to:

fn hello() {
    println!("Hello from hello");
}

Key Characteristics

Pattern-based (ident, expr, etc.)
Simple and predictable
Excellent for reducing repetitive code

Generating Multiple Functions with Macros

Declarative macros become more powerful with repetition.

macro_rules! generate_functions {
    ($($name:ident),*) => {
        $(
            fn $name() {
                println!("Hello from {}", stringify!($name));
            }
        )*
    };
}

Usage:

generate_functions!(foo, bar, baz);

This single macro call generates multiple functions automatically.

This kind of code generation is impossible with normal functions, which is exactly why macros exist.

When to Use Declarative Macros

Use macro_rules! when:

You’re repeating similar code patterns
You need compile-time code generation
Functions are not expressive enough

Rule of thumb:

If a function can solve the problem, use a function.
Use macros only when you need syntax generation.

Procedural Macros (Macros You Use Every Day)

Even if you’ve never written a macro, you’ve already used procedural macros.

A common example is Serde:

#[derive(Serialize, Deserialize)]
struct User {
    username: String,
    age: u32,
}

This #[derive] is a procedural macro.

What it does:

Reads your struct at compile time
Generates serialization and deserialization logic
Eliminates massive amounts of boilerplate

Unlike declarative macros, procedural macros:

Work on Rust’s syntax tree (AST)
Are more powerful
Are commonly used by frameworks and libraries

Attribute Macros in Practice

#[serde(rename = "user_name")]
username: String,

This tells Serde how fields should appear in JSON without changing your Rust code.

The behavior is injected at compile time through macros, not runtime logic.

Serialization and Deserialization: Why Macros Matter

Serialization converts Rust data into a transferable format like JSON.
Deserialization converts it back into Rust types.

Rust struct → JSON → Client / DB / File
JSON → Rust struct → Business logic

Rust structs cannot be sent directly across systems. Serialization is how Rust communicates with the outside world.

A Real-World Edge Case

JSON does not support NaN.

score: f64::NAN

This will fail during serialization, even though Rust itself allows it.
Sometimes the limitation isn’t Rust or macros—it’s the data format.

Why Rust’s Macro Design Works

Rust macros:

Reduce boilerplate
Enforce consistency
Move complexity to compile time
Keep runtime code clean and fast

Declarative macros help you write less code.
Procedural macros help libraries write code for you.

Final Takeaway

macro_rules! → write your own compile-time patterns
Procedural macros (derive, attributes) → use powerful library-generated code
Macros exist to solve problems functions cannot
Serialization is how Rust crosses system boundaries

Data vs Behavior in Rust

Sumana — Wed, 17 Dec 2025 16:40:00 +0000

Rust takes a unique approach to software design by separating data from behavior. Instead of relying on classes and inheritance, Rust uses structs to store data and traits to define behavior. This design leads to safer, more scalable, and easier-to-maintain systems.

If you’re coming from object-oriented languages, Rust’s approach might feel unfamiliar at first. But once you understand how struct, impl, and trait work together, the design becomes intuitive and powerful.

Structs in Rust: Modeling Data

In Rust, a struct is used purely to represent data.

struct Rect {
    width: f32,
    height: f32,
}

A struct does not define behavior on its own. This keeps data representation explicit and simple.

Adding Behavior with `impl`

Rust attaches behavior to data using an impl block.

impl Rect {
    fn area(&self) -> f32 {
        self.width * self.height
    }
}

This approach is ideal when behavior belongs to a single concrete type. The method borrows the struct using &self, ensuring safe access without transferring ownership.

Traits in Rust: Defining Behavior Contracts

Traits define shared behavior across types.

trait Shape {
    fn area(&self) -> f32;
}

A trait specifies what a type can do, not how it does it.

impl Shape for Rect {
    fn area(&self) -> f32 {
        self.width * self.height
    }
}

This allows multiple types to implement the same behavior while keeping their internal logic separate.

Trait Bounds and Scalable Design

Traits become especially powerful when used with generic functions.

fn get_area(shape: impl Shape) -> f32 {
    shape.area()
}

This function works with any type that implements the Shape trait. Adding new shapes does not require modifying existing code, which is why traits are considered a core tool for scalability in Rust.

Clone vs Copy: Ownership-Aware Duplication

Rust uses traits to control how values are duplicated.

#[derive(Clone)]
struct Person {
    name: String,
    age: u32,
}

Because String owns heap memory, cloning must be explicit.

let p2 = p1.clone();

For stack-only data, Rust allows implicit copying:

#[derive(Copy, Clone)]
struct Point {
    x: i32,
    y: i32,
}

This explicit distinction prevents accidental memory bugs.

Debug vs Display: Formatting Output in Rust

Rust separates developer-focused output from user-facing output.

Debug formatting

#[derive(Debug)]
struct Rect {
    width: u32,
    height: u32,
}

println!("{:?}", rect);

Display formatting

use std::fmt;

impl fmt::Display for Rect {
    fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
        write!(f, "({}, {})", self.width, self.height)
    }
}

println!("{}", rect);

This separation encourages clean logging and better user experience.

Why This Design Works

By separating data (struct) and behavior (trait), Rust avoids inheritance-related issues and promotes composition. This results in code that is easier to extend, refactor, and reason about.

Ownership in Rust

Sumana — Tue, 09 Dec 2025 18:42:00 +0000

Ownership is Rust’s memory management system based on three rules:
each value has a single owner, only one owner can exist at a time, and a value is dropped when its owner goes out of scope.
Values are either moved (ownership is transferred) or copied (for simple Copy types like integers).

This system allows Rust to guarantee memory safety at compile time, without a garbage collector.

Value is dropped when its owner goes out of scope

fn main() {
    let name = String::from("Pixy");
    take_ownership(name);
}

fn take_ownership(s: String) {
    println!("{}", s);
} // s goes out of scope here → dropped

Here, ownership of name is moved into take_ownership.
When the function ends, s goes out of scope and Rust automatically frees the memory.

Ownership is transferred (moved)

fn main() {
    let username = String::from("Pixy");
    print_user(username);
}

fn print_user(name: String) {
    println!("User: {}", name);
}

Passing username into print_user moves ownership.
After the move, main can no longer access username. Only one owner exists at a time.

Function takes ownership

fn take(s: String) {
    println!("{}", s);
}

fn main() {
    let name = String::from("Pixy");
    take(name);
}

The function parameter s becomes the new owner.
Once take finishes, the value is dropped.

Borrowing with immutable references

fn borrow(s: &String) {
    println!("{}", s);
}

fn main() {
    let name = String::from("Pixy");
    borrow(&name);
    println!("{}", name);
}

Here, the function borrows name using &String.
Ownership stays in main, so name is still usable afterward.

Multiple immutable references at the same time

Rust allows multiple immutable references to the same value at the same time, as long as no one is mutating it.

fn main() {
    let name = String::from("Pixy");

    let ref1 = &name;
    let ref2 = &name;

    println!("{} {}", ref1, ref2);
}

This works because:

Both ref1 and ref2 are read-only
Ownership still stays with name
No data race is possible when only reading

Borrowing rule summary

✅ Multiple immutable references are allowed
✅ One mutable reference is allowed
❌ Mutable and immutable references cannot coexist

This rule is what lets Rust be strict and flexible at the same time.

Borrowing with mutable references

fn change(s: &mut String) {
    s.push_str("!");
}

fn main() {
    let mut name = String::from("Pixy");
    change(&mut name);
}

Mutable borrowing allows modifying a value without taking ownership.
Rust ensures only one mutable reference exists at a time, preventing data races.

Final thought

Ownership, moves, and borrowing work together to prevent memory leaks, use-after-free errors, and data races — all without runtime overhead.

Dinner Plans & Distributed Systems : A Fun Guide to Consensus

Sumana — Sat, 04 Oct 2025 16:25:00 +0000

Picture this: a group of friends is starving and trying to decide where to eat. What seems like a simple dinner plan is actually a perfect way to explain how computers in a distributed system agree on things. Let’s turn these friends into servers and see how three big consensus algorithms—Paxos, Raft, and BFT—play out in real life.

Paxos: The Democracy (But a Messy One)

Friend A says, “Let’s get pizza!” They’re the proposer. The rest of the group listens and becomes acceptors—they raise hands if they like the idea. If most agree, boom—pizza it is! The learners are the ones who didn’t vote but need to know the final plan so they don’t show up at the wrong place. Paxos works even if some friends leave the chat, but if too many people propose at once (“No, tacos!” … “Burgers!”), chaos happens. That’s why sometimes one friend is chosen to always suggest options—smoother but still a bit complicated.

Raft: The Leader Everyone Follows

This time, the group elects a leader—let’s say Friend B. Friend B declares, “We’re having sushi tonight.” Everyone nods and follows along. If Friend B suddenly drops out (maybe their phone dies), the group quickly votes for a new leader and continues. Raft makes the process simple: one person decides, everyone else follows. No endless debates, just clear direction.

Byzantine Fault Tolerance (BFT): Handling the Trickster

Now imagine Friend C is a prankster. They whisper to some, “We’re going for burgers”, while telling others, “It’s definitely pizza.” Uh oh—chaos! To deal with this, the group double-checks plans with multiple friends before trusting anything. It takes more talking and time, but ensures that no one gets fooled. That’s BFT: built for situations where not everyone is trustworthy—perfect for blockchains, where some participants might try to cheat.

The Takeaway

Paxos = messy democracy, but reliable.
Raft = one clear leader, simple and practical.
BFT = built for tricksters, slower but super secure.

So next time your friends argue about dinner, just smile—you’re all secretly running consensus algorithms!

☕ Cache Eviction — Lessons from a Small Café

Sumana — Fri, 26 Sep 2025 15:15:00 +0000

Imagine running a cozy café with a tiny pastry shelf. You can only keep a few items at a time, and when the shelf is full, something has to go. The real question: which pastry gets kicked off to make room for the new one?

That’s exactly what caches do in software. The shelf is your RAM, pastries are data, and the “kick-off” rules are called cache eviction policies. Let’s see how each works — café style.

FIFO — First In, First Out

Kick out the oldest item first.

Everyday café analogy: The cinnamon bun that’s been sitting on the shelf longest gets tossed to make space for fresh pastries.

Why it works: What if that cinnamon bun is still a customer favorite? FIFO doesn’t care — it’s gone.

Where it's used: Simple and predictable, FIFO works in queues, streaming buffers, and systems where order matters more than popularity.

LFU — Least Frequently Used

Kick out the least popular item.

Everyday café analogy: The chocolate cake nobody ever orders gets removed, while cheesecake that flies off the shelf stays.

Why it works: A pastry that was trendy last month might still hog space today, even though no one buys it anymore.

Where it's used: LFU is great for CDNs, recommendation engines, and image caches — places where popularity beats freshness.
👉 Try it here: LeetCode LFU Cache

LRU — Least Recently Used

Kick out the item that hasn’t been touched in the longest time.

Everyday café analogy: That croissant sitting untouched for days gets tossed, while the one someone grabbed just yesterday stays.

Why it works: Sometimes recency isn’t everything — a customer-favorite pastry could still get removed if it hasn’t sold lately.

Where it's used: LRU is the most common default. It powers browser caches, Redis eviction, OS page replacement, and session storage.
👉 Try it here: LeetCode LRU Cache

MRU — Most Recently Used

Kick out the newest item you just used.

Everyday café analogy: You whip up a fresh green matcha latte, take one sip, and toss it. Strange rule, but sometimes it works.

Why it works: You risk losing the freshest, most relevant data.

Where it's used: Rarely used, but handy in niches like database cursors or workloads where older data is more valuable.

The Café Lesson

Your café shelf — like a cache — can only hold so much. Different rules give you different trade-offs:

FIFO → Oldest cinnamon bun goes.
LFU → Least-loved chocolate cake goes.
LRU → Stale croissant goes.
MRU → Fresh green matcha latte goes.

The Next Chapter for Solana

Sumana — Fri, 20 Jun 2025 11:36:58 +0000

Solana is getting ready to drop its most ambitious protocol change to date — Alpenglow. If you’ve followed Solana since launch, you know it’s already one of the fastest blockchains out there. But Alpenglow isn’t about being fast — it’s about going real-time, resilient, and ready for Web2-scale use cases.

Built by Anza (Solana Labs’ core dev team) in collaboration with Prof. Roger Wattenhofer from ETH Zurich, this upgrade completely reimagines how consensus works on Solana.

Let’s break down what’s changing, why it matters, and what it unlocks for builders and validators alike.

From 12 Seconds to 150 Milliseconds — Finality Gets a Turbo Boost

Right now, Solana reaches finality in ~12.8 seconds — fast by blockchain standards, but not real-time. Alpenglow brings this down to a blazing 100–150 milliseconds.

You read that right.

This makes use cases like real-time games, live streaming, high-frequency trading, and instant payments finally viable on-chain. It’s not a marginal speed-up — it’s a fundamental shift. This puts Solana’s performance in the same league as centralized platforms like AWS or Stripe, but with decentralization baked in.

Under the Hood: Votor and Rotor

Alpenglow ditches Solana’s old consensus stack — including Proof of History (PoH) and Tower BFT — in favor of two new core components:

Votor — Smarter Consensus

Votor is the new finality engine, using a dual-path model:

Fast Finalization: Finality in ~100ms if 80% of stake is participating.
Slow Finalization: Finality in ~150ms even with only 60% stake online.

Both paths run simultaneously, allowing the network to adapt to validator participation in real time without dropping performance.

Rotor — Better Data Propagation

Rotor replaces Turbine’s tree-like propagation with a single-hop relay model. It reduces latency and simplifies communication between nodes. While Turbine was optimized for bandwidth, Rotor keeps that benefit but adds major speed improvements.

Together, Votor + Rotor = smoother, more reliable consensus at scale.

Stronger in the Face of Chaos

Solana’s past network outages have been a sore point. Alpenglow addresses this with a new “20+20” resilience model:

Network remains safe even if 20% of stake is actively malicious.
Network stays live even if another 20% of validators are offline or sluggish.

That’s a major robustness boost. While Solana sacrifices the classic 33% Byzantine tolerance, the tradeoff massively improves liveness during partial outages or attacks.

Validators Rejoice: Voting Fees Are Gone

Under the current system, validators pay roughly 1 SOL per day just to submit vote transactions. That’s a big chunk of their cost.

Alpenglow eliminates this entirely.

Votes move off-chain using BLS signature aggregation.
Result: No vote tx spam, no gas fees, no constant key management headaches.
Profitable validation becomes possible at just 450 SOL (down from ~4850 SOL).

This is a massive win for decentralization, opening up validator roles to more people and reducing reliance on high-cap validators.

A Cleaner, Simpler Protocol

One underrated benefit of Alpenglow: it simplifies everything.

No more Proof of History.
No Tower BFT.
No gossip vote propagation.

Instead, it uses local timeout-based finality and direct vote messages — much easier to reason about and more developer-friendly. Plus, everything’s grounded in formal proofs this time, moving away from trial-and-error toward provable correctness.

This makes it easier for new clients to implement, audit, and extend Solana.

What Comes After Alpenglow?

Alpenglow isn’t the end — it’s the new starting point.

This upgrade paves the way for:

Multiple Concurrent Leaders (MCL): Boosts throughput by allowing multiple block producers at once.
Asynchronous Execution: Smart contracts that don’t rely on strict ordering.
Improved MEV resistance (TBD): The new architecture makes it easier to experiment with better MEV protection models.

Alpenglow is expected to land on Solana mainnet in 2025. Migration will take time, but it’s already in motion.

Final Thoughts

With Alpenglow, Solana’s not just faster — it’s more robust, simpler to run, and ready for serious applications.

This isn’t just an optimization — it’s Solana stepping into its next era. One where a decentralized chain doesn’t just scale, but also responds like the fastest Web2 systems.

For devs, it unlocks a new class of real-time dapps.
For validators, it lowers the barrier to entry and cuts major costs.
For the ecosystem, it’s a signal: Solana’s playing for keeps.

Actix Web vs Poem Framework

Sumana — Fri, 13 Jun 2025 16:21:44 +0000

Modern web frameworks have a common challenge: sharing resources efficiently when handling multiple requests at the same time. Both Actix Web and Poem use Rust’s Arc (a smart pointer for thread-safe sharing), but they go about it in very different ways. Here’s a quick dive into how each one uses Arc and multithreading to manage concurrent request handling.

Understanding Arc in Web Server Context

Web servers spin up multiple worker threads to handle requests at the same time. These threads often need access to shared stuff—like DB connections, app state, or configs. That’s where Arc comes in. It allows safe shared ownership across threads using atomic reference counting, it’s a core piece of how Rust handles concurrency in web apps.

// Arc enables this pattern:
let shared_data = Arc::new(expensive_resource);
let clone1 = Arc::clone(&shared_data); // Thread 1 gets this
let clone2 = Arc::clone(&shared_data); // Thread 2 gets this  
let clone3 = Arc::clone(&shared_data); // Thread 3 gets this
// All threads share the same underlying data

Actix Web: Hidden Arc with Connection Pooling

Actix Web abstracts Arc usage behind its web::Data wrapper, implementing a connection pooling strategy for maximum concurrency.


#[actix_web::main]
async fn main() -> std::io::Result<()> {
    let pool = create_pool().await?;

    HttpServer::new(move || {
        App::new()
            .app_data(web::Data::new(pool.clone())) // Arc created internally
            .route("/todos", web::get().to(list_todos_handler))
    })
    .bind("127.0.0.1:8080")?
    .run()
    .await
}

async fn list_todos_handler(pool: web::Data<PgPool>) -> Json<Vec<Todo>> {
    let todos = sqlx::query_as!(Todo, "SELECT * FROM todos")
        .fetch_all(pool.get_ref()) // Extract from Arc
        .await?;
    Json(todos)
}

Actix Web Thread Distribution

┌──────────────────┐    ┌──────────────────┐    ┌──────────────────┐
│   WORKER THREAD 1│    │   WORKER THREAD 2│    │   WORKER THREAD 3│
├──────────────────┤    ├──────────────────┤    ├──────────────────┤
│                  │    │                  │    │                  │
│ ┌──────────────┐ │    │ ┌──────────────┐ │    │ ┌──────────────┐ │
│ │web::Data<T>  │ │    │ │web::Data<T>  │ │    │ │web::Data<T>  │ │
│ │(Arc wrapper) │ │    │ │(Arc wrapper) │ │    │ │(Arc wrapper) │ │
│ └──────┬───────┘ │    │ └──────┬───────┘ │    │ └──────┬───────┘ │
│        │         │    │        │         │    │        │         │
└────────┼─────────┘    └────────┼─────────┘    └────────┼─────────┘
         │                       │                       │
         └───────────────────────┼───────────────────────┘
                                 │
                                 ▼
                    ┌─────────────────────────┐
                    │    SHARED HEAP DATA     │
                    ├─────────────────────────┤
                    │     Arc<PgPool>         │
                    │  ┌─────────────────┐    │
                    │  │ ref_count: 3    │    │
                    │  └─────────────────┘    │
                    │  ┌─────────────────┐    │
                    │  │     PgPool      │    │
                    │  │ ┌─────────────┐ │    │
                    │  │ │Connection   │ │    │
                    │  │ │Pool (thread │ │    │
                    │  │ │safe already)│ │    │
                    │  │ └─────────────┘ │    │
                    │  └─────────────────┘    │
                    └─────────────────────────┘

Poem: Explicit Arc with Shared State

Poem takes an explicit approach, requiring developers to manually wrap shared state in Arc<<Mutex<T>> for thread-safe access to a centralized store.

#[tokio::main(flavor = "multi_thread")]
async fn main() -> Result<(), std::io::Error> {
    let s = Arc::new(Mutex::new(Store::new().unwrap()));

    let app = Route::new()
        .at("/website/:website_id", get(get_website))
        .at("/website", post(create_website))
        .data(s);

    Server::new(TcpListener::bind("0.0.0.0:8080"))
        .run(app)
        .await
}

pub fn get_website(
    Path(id): Path<String>,
    Data(s): Data<&Arc<Mutex<Store>>>,
) -> Json<GetWebsiteOutput> {
    let mut locked_s = s.lock().unwrap_or_else(|poisoned| poisoned.into_inner());
    let website = locked_s.get_website(id).unwrap();
    Json(GetWebsiteOutput { url: website.url })
}

Poem Arc Wrapping Pattern

┌─────────────────────────────────────────┐
│              Arc Wrapper                │ ← Sharing across threads
│ ┌─────────────────────────────────────┐ │
│ │ ref_count: 3 (cloned to 3 threads)  │ │
│ └─────────────────────────────────────┘ │
│ ┌─────────────────────────────────────┐ │
│ │           Mutex Wrapper             │ │ ← Thread-safe mutation
│ │ ┌─────────────────────────────────┐ │ │
│ │ │ lock_state: locked/unlocked     │ │ │
│ │ └─────────────────────────────────┘ │ │
│ │ ┌─────────────────────────────────┐ │ │
│ │ │          Store Data             │ │ │ ← Your actual mutable data
│ │ │        (websites, etc.)         │ │ │
│ │ └─────────────────────────────────┘ │ │
│ └─────────────────────────────────────┘ │
└─────────────────────────────────────────┘

Framework Philosophy: Actix vs Poem

Actix Web leans into a stateless, connection-pooled setup. It hides Arc under abstractions like web::Data::new(), so you don’t have to worry about it. Each handler can independently borrow a DB connection, enabling real parallelism with zero fuss.

On the other hand, Poem gives you full control. You’ll often use patterns like Arc<Mutex<T>>, making shared state super visible. It keeps app state in memory, which is great for fast access to cached data—but, you’ll need to manage those concurrency primitives yourself.

Both tackle shared resource access across threads, but they come from different mindsets: abstraction vs control, parallelism vs consistency, and external vs internal state. Knowing how they handle Arc helps a lot when scaling web apps in Rust.

🚀 Want to see this in action? Check out the complete implementations:

Actix Web Example

Poem Example (forked and adapted from 100xdevs - thanks for the great foundation!)

How to Build a Cross-Chain Token Bridge

Sumana — Fri, 11 Apr 2025 18:01:03 +0000

🧭 BNB Smart Chain Testnet ↔ Polygon Amoy

Introduction

Cross-chain bridges are essential infrastructure in the evolving blockchain ecosystem. They enable tokens and data to move across independent networks — allowing true interoperability in the Web3 world.

In this blog, I’ll break down how to build a cross-chain token bridge between the BNB Smart Chain Testnet and Polygon Amoy Testnet. The project uses Solidity smart contracts, a WebSocket-based event listener, a transaction queue with nonce tracking, and a frontend for users to interact with the bridge.

⚙️ Smart Contracts: Token Locking & Releasing

The bridge uses two smart contracts — one on each chain — to manage token custody and emit events during transfers.

Key Features

Token Locking: Locks tokens on the source chain when a transfer is initiated.
Token Releasing: Releases tokens on the destination chain after verification.
Nonce Verification: Prevents replay attacks by tracking unique nonces per transaction.
Token Whitelisting: Only pre-approved tokens can be bridged.
Amount Limits: Defines minimum and maximum bridge amounts.
Access Control: Only the bridge owner can execute the release function.

🔍 Code Snippet


function bridge(IERC20 _tokenAddress, uint256 _amount) public {
        // Validate token and amount
        if (!whitelistedTokens[_tokenAddress]) revert BridgeContract__Token_Not_Whitelisted();
        if (_amount > maxAmounts[_tokenAddress] && maxAmounts[_tokenAddress] > 0) 
            revert BridgeContract__Amount_Too_Large();
        if (_amount < minAmounts[_tokenAddress] && minAmounts[_tokenAddress] > 0) 
            revert BridgeContract__Amount_Too_Small();

        // Check allowance
        if (_tokenAddress.allowance(_msgSender(), address(this)) < _amount) 
            revert BridgeContract__Insufficient_Allowance();

        // Transfer tokens from sender to bridge
        bool success = _tokenAddress.transferFrom(_msgSender(), address(this), _amount);
        if (!success) revert BridgeContract__Transaction_Failed();

        // Emit bridge event
        emit Bridge(_tokenAddress, _amount, _msgSender());
    }

(https://github.com/sumana10/Bridge-Contract/blob/main/contract/src/BridgeContract.sol)

📡 WebSocket Listener: Real-Time Blockchain Monitoring

Instead of polling blocks, the system uses WebSocket connections to listen for TokenLocked events in real time from both chains.

Key Features

Dual Network Monitoring: Monitors both BNB and Polygon chains concurrently.
Event-Based Architecture: Processes transactions as soon as they're emitted.
Block Tracking: Records the last processed block to prevent missing events after reconnection.
Historical Event Replay: On restart, reprocesses missed events from the last saved block.

🔍 Code Snippet


  const bridgeListener = (tokenAddress, amount, sender, event) => {
      console.log(`Bridge event detected on ${network}: Token ${tokenAddress} Amount ${amount}`);

      const txhash = event.log.transactionHash.toLowerCase();

      console.log(`Adding job to queue for new event: ${txhash}`);

      bridgeQueue.add({
        txhash,
        tokenAddress: tokenAddress.toString(),
        amount: amount.toString(),
        sender: sender.toString(),
        network,
      }).catch(error => {
        console.error(`Error adding job to queue:`, error);
      });

      prisma.networkStatus.update({
        where: { network },
        data: { lastProcessedBlock: event.log.blockNumber },
      }).catch(error => {
        console.error(`Error updating last processed block:`, error);
      });
    };

(https://github.com/sumana10/Bridge-Contract/blob/main/indexer/src/index.ts)

🧵 Bridge Queue: Ordered Transaction Processing

The queue service ensures that events are processed sequentially, securely, and only once.

Key Features

Nonce Management: Prevents duplicate or replayed transactions.
Sequential Execution: Guarantees events are processed in order.
Transaction Validation: Verifies if a transaction has already been handled.
Gas Optimization: Dynamically adjusts gas based on current network conditions.

🔍 Code Snippet


bridgeQueue.process(async (job) => {
  const { txhash, tokenAddress, amount, sender, network } = job.data;
  console.log(`Processing job for txhash ${txhash} on ${network}`);

  try {
    console.log(`Checking if transaction ${txhash} exists in database`);
    let transaction = await prisma.transactionData.findUnique({
      where: { txHash: txhash },
    });

    if (!transaction) {
      console.log(`Transaction ${txhash} not found, creating new record`);

      console.log(`Getting nonce for ${network}`);
      const nonceRecord = await prisma.nonce.upsert({
        where: { network },
        update: { nonce: { increment: 1 } },
        create: { network, nonce: 1 },
      });

      console.log(`Using nonce ${nonceRecord.nonce} for ${network}`);

      transaction = await prisma.transactionData.create({
        data: {
          txHash: txhash,
          tokenAddress,
          amount,
          sender,
          network,
          isDone: false,
          nonce: nonceRecord.nonce,
        },
      });

      console.log(`Created transaction record for ${txhash}`);
    } else {
      console.log(`Transaction ${txhash} already exists in database`);
    }

    if (transaction.isDone) {
      console.log(`Transaction ${txhash} already processed, skipping`);
      return { success: true, message: "Transaction already processed" };
    }

    console.log(`Executing transfer for transaction ${txhash}`);
    await transferToken(network === "BNB", amount, sender, transaction.nonce);

    console.log(`Transfer completed, updating transaction status for ${txhash}`);
    await prisma.transactionData.update({
      where: { txHash: txhash },
      data: { isDone: true },
    });

    console.log(`Transaction ${txhash} marked as done`);
    return { success: true };
  } catch (error) {
    console.error(`Error processing job for txhash ${txhash}:`, error);
    throw error;
  }
});

🗃️ PostgreSQL Database: State Persistence

The bridge uses PostgreSQL to store event history, transaction data, and the current state of each chain.

Key Tables

TransactionData: Stores hash, amount, token, sender, chain, and nonce.
NetworkStatus: Tracks the last processed block per chain.
Nonce: Ensures nonce uniqueness per network.

🖼️ Frontend: Bridge UI for Users

The frontend allows users to connect their wallets, select a token, approve it, and initiate cross-chain transfers.

Key Features

Network Detection: Auto-detects the connected chain.
Token Approval Flow: Prompts users to approve tokens if allowance is insufficient.
Transaction Submission: Initiates the lock transaction on the source chain.
Real-Time Feedback: Shows transaction progress and final status.

🔒 Security Features

Security is baked into every part of the system:

Replay Protection via nonce verification
Whitelisted Tokens Only to prevent malicious tokens
Minimum/Maximum Amount Limits
Owner-Only Release Logic
Reliable Event Tracking across node restarts
Gas Adjustment based on network conditions

📽️ Demo and Repository

🧠 Explore the Code: [https://github.com/sumana10/Bridge-Contract/]
🎬 Watch the Demo: [https://www.youtube.com/watch?v=5SE1Bx1tve8]

You’ll find setup instructions, deployment scripts, and detailed documentation in the repo.

🧠 Conclusion

This cross-chain bridge project demonstrates a clean, modular approach to transferring tokens between EVM-compatible blockchains. By combining smart contracts, event-driven services, a transaction queue, and a PostgreSQL database, the system achieves reliable, end-to-end cross-chain communication.

You can extend this project to support additional chains, add NFT bridging, or even decentralize the bridge using a validator network or oracle integration.

Building an NFT Marketplace Smart Contract with Solidity and OpenZeppelin

Sumana — Mon, 30 Sep 2024 17:52:13 +0000

Building a Decentralized NFT Marketplace with Solidity

In this blog, we'll walk through the creation of a simple NFT marketplace using Solidity. This contract will allow users to list NFTs for sale, purchase NFTs, and manage ownership—all while ensuring security with the ReentrancyGuard feature to prevent certain types of attacks. Let’s break down the functionality and code.

Key Features:

Listing NFTs for sale by paying a small listing fee to the contract owner.
Buying NFTs with ether through the marketplace.
Security against reentrancy attacks to safeguard transactions.
Fetching NFTs you own or have created.

Contract Breakdown

1. Contract Setup and State Variables

The contract imports the OpenZeppelin libraries for ERC721 (NFT standard), counters for unique token IDs, and reentrancy protection.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.6;

import "@openzeppelin/contracts/token/ERC721/ERC721.sol";
import "@openzeppelin/contracts/utils/Counters.sol";
import "@openzeppelin/contracts/security/ReentrancyGuard.sol";

contract NFTMarket is ReentrancyGuard {
    using Counters for Counters.Counter;

    // Counters to track total items and items sold
    Counters.Counter private _itemIds;
    Counters.Counter private _itemsSold;

    // Contract owner gets a listing fee for every NFT listed
    address payable owner;
    uint256 listingPrice = 0.001 ether;

    constructor() {
        owner = payable(msg.sender);
    }

Counters are used to track the total number of NFTs listed and those sold.
The owner of the marketplace earns a listing fee on every NFT sale.

2. Struct and Mapping

A MarketItem struct stores the details of each listed NFT, including the item ID, contract address, seller, owner, price, and sale status. A mapping is used to access each MarketItem by its ID.

    struct Marketitem {
        uint itemId;
        address nftContract;
        uint256 tokenId;
        address payable seller;
        address payable owner;
        uint256 price;
        bool sold;
    }

    mapping(uint256 => Marketitem) private idToMarketItem;

3. Listing NFTs for Sale

This function allows users to list their NFTs on the marketplace by specifying the contract address, token ID, and price. They must pay a small listing fee.

    function createMarketItem(
        address nftContract,
        uint256 tokenId,
        uint256 price
    ) public payable nonReentrant {
        require(price > 0, "Price must be at least 1 wei");
        require(msg.value == listingPrice, "Must pay listing price");

        _itemIds.increment();
        uint256 itemId = _itemIds.current();

        idToMarketItem[itemId] = Marketitem(
            itemId,
            nftContract,
            tokenId,
            payable(msg.sender),
            payable(address(0)),
            price,
            false
        );

        IERC721(nftContract).transferFrom(msg.sender, address(this), tokenId);
        emit MarketItemCreated(itemId, nftContract, tokenId, msg.sender, address(0), price, false);
    }

NFTs are transferred to the marketplace contract (address(this)).
The marketplace owner collects a small fee, and the NFT is listed for sale.

4. Buying NFTs

This function allows users to purchase an NFT by sending the required ether. It transfers both the NFT ownership and the ether between buyer and seller.

    function createMarketSale(
        address nftContract,
        uint256 itemId
    ) public payable nonReentrant {
        uint price = idToMarketItem[itemId].price;
        uint tokenId = idToMarketItem[itemId].tokenId;
        require(msg.value == price, "Please submit the asking price");

        idToMarketItem[itemId].seller.transfer(msg.value);
        IERC721(nftContract).transferFrom(address(this), msg.sender, tokenId);

        idToMarketItem[itemId].owner = payable(msg.sender);
        idToMarketItem[itemId].sold = true;
        _itemsSold.increment();
        payable(owner).transfer(listingPrice);
    }

Buyers must send the correct price to complete the sale.
Ownership of the NFT and ether is securely transferred.

5. Fetching NFTs

Several functions allow users to fetch NFTs that are available for sale, those they own, or ones they have created.

    function fetchMarketItems() public view returns (Marketitem[] memory) {
        uint itemCount = _itemIds.current();
        uint unsoldItemCount = _itemIds.current() - _itemsSold.current();
        uint currentIndex = 0;

        Marketitem[] memory items = new Marketitem[](unsoldItemCount);
        for (uint i = 0; i < itemCount; i++) {
            if (idToMarketItem[i + 1].owner == address(0)) {
                uint currentId = idToMarketItem[i + 1].itemId;
                Marketitem storage currentItem = idToMarketItem[currentId];
                items[currentIndex] = currentItem;
                currentIndex += 1;
            }
        }
        return items;
    }

This function returns all unsold NFTs, which can be displayed in the marketplace UI.

Conclusion

This Solidity contract lays the foundation for a decentralized NFT marketplace. Users can securely list, buy, and manage NFTs while paying small listing fees. By leveraging OpenZeppelin libraries and reentrancy protection, we ensure security and ease of use for our marketplace.

Forem: Sumana

Perpetual Engine Series Part 1: The Liquidation Logic

1. What is Liquidation?

2. The Liquidation Price (The Threshold)

The Formula

Rust Implementation

3. Real-Time Maintenance Checks

The Logic in Action

4. Edge Cases: Beyond the Price

Edge Case 1: Funding Liquidation

Edge Case 2: Double-Liquidation Prevention

5. Summary Table

Conclusion

Building a Low-Latency Trading Engine in Rust

The First Problem: Reads Were Slower Than They Should Be

Switching to RwLock

The Next Issue: Blocking vs Yielding

Network I/O Was Still a Problem

Decoupling with MPSC

Sharing State Across Tasks

Financial Accuracy: Why f64 Doesn’t Work

Handling Errors Without Crashing

Putting It Together

Final Thought

Escrow as a Design Choice

Rust Macros: Declarative vs Procedural

Why Rust Has Macros

Declarative Macros (macro_rules!)

Key Characteristics

Generating Multiple Functions with Macros

When to Use Declarative Macros

Procedural Macros (Macros You Use Every Day)

Attribute Macros in Practice

Serialization and Deserialization: Why Macros Matter

A Real-World Edge Case

Why Rust’s Macro Design Works

Final Takeaway

Data vs Behavior in Rust

Structs in Rust: Modeling Data

Adding Behavior with impl

Traits in Rust: Defining Behavior Contracts

Trait Bounds and Scalable Design

Clone vs Copy: Ownership-Aware Duplication

Debug vs Display: Formatting Output in Rust

Why This Design Works

Ownership in Rust

Value is dropped when its owner goes out of scope

Ownership is transferred (moved)

Function takes ownership

Borrowing with immutable references

Multiple immutable references at the same time

Borrowing rule summary

Borrowing with mutable references

Final thought

Dinner Plans & Distributed Systems : A Fun Guide to Consensus

Paxos: The Democracy (But a Messy One)

Raft: The Leader Everyone Follows

Byzantine Fault Tolerance (BFT): Handling the Trickster

The Takeaway

☕ Cache Eviction — Lessons from a Small Café

FIFO — First In, First Out

LFU — Least Frequently Used

LRU — Least Recently Used

MRU — Most Recently Used

The Café Lesson

The Next Chapter for Solana

From 12 Seconds to 150 Milliseconds — Finality Gets a Turbo Boost

Under the Hood: Votor and Rotor

Votor — Smarter Consensus

Rotor — Better Data Propagation

Stronger in the Face of Chaos

Validators Rejoice: Voting Fees Are Gone

A Cleaner, Simpler Protocol

What Comes After Alpenglow?

Final Thoughts

Actix Web vs Poem Framework

Understanding Arc in Web Server Context

Actix Web: Hidden Arc with Connection Pooling

Actix Web Thread Distribution

Poem: Explicit Arc with Shared State

Declarative Macros (`macro_rules!`)

Adding Behavior with `impl`