Flash Transaction

A nonce-less transaction layer built for parallel execution, multi-device ownership and quantum-resistant finality.

Overview

Traditional account-model blockchains enforce a sequential nonce for every transaction. Each transaction must reference the exact counter of the previous one, forcing transactions from the same account to be processed strictly in order. This introduces bottlenecks, stuck transactions and race conditions in multi-device wallets.

Sahyadri removes this dependency entirely. Every Flash Transaction carries its own unique identifier, an expiry window and a cryptographically random salt — allowing multiple transactions from the same account to be processed in parallel, in the same block, without any ordering constraint.

Core Idea

No nonce. No sequence. Just signed intent with expiry and uniqueness, validated independently inside a bounded, self-pruning replay window.

Why It Matters

Ethereum's sequential nonce model was designed for a simpler era. As decentralized finance scaled, the nonce bottleneck became a systemic limitation: batch transactions stall, retries collide, and multi-device wallets inevitably race. Every rejected nonce is a failed user experience and a delayed settlement.

Sahyadri's Flash Transaction layer eliminates the problem at the protocol level. A single account can broadcast multiple independent transactions concurrently — all valid, all ordered by consensus, all final.

Parallelism

∞

Independent transactions per account, no sequential dependency.

Expiry Window

100

Blocks after which the transaction is invalid. Replay-safe by construction.

Prune Threshold

150

Blocks after which replay IDs are automatically dropped from state.

Signature

ML-DSA-65

Post-quantum FIPS 204 signatures on every transaction.

Design Comparison

Modern Layer-1 networks have explored several approaches to the nonce problem. Flash Transaction combines the best of each design into a unified model.

Model	Replay Protection	Parallel Txs	Multi-Device	Offline Signing
Ethereum (Sequential Nonce)	Account counter	No	Races	Chain query
Solana (Durable Nonce)	Recent blockhash	Partial	Yes	Yes
Aptos (Orderless Nonce)	Per-tx replay nonce	Yes	Yes	Chain query
Sahyadri (Flash Transaction)	Expiry + flash_id	Yes	Yes	Yes

Architecture

Every Flash Transaction flows through a bounded, deterministic pipeline — designed to be verifiable in isolation, parallel across accounts, and reorg-safe under the DAG consensus.

1 — Signed Intent

Sender constructs a Flash Transaction with amount, recipient, fee, expiry, and a cryptographically random 16-byte salt.

2 — Unique Identifier

A deterministic flash_id is derived from sender, recipient, amount, fee, expiry and salt. It serves as the replay-detection key.

3 — Consensus Batch

Multiple Flash Transactions from different senders land in the same block and are validated in parallel. Same-sender transactions are aggregated for cumulative balance checks.

4 — Bounded Replay Window

Accepted flash_ids are stored in an account-local vector, each tagged with its source block. After the pruning threshold the entry is automatically dropped.

Transaction Structure

A Flash Transaction is a compact, self-contained data structure. Every field is fixed-width or length-prefixed to allow zero-copy decoding in Rust.

// FlashTransaction — 32 bytes minimum, ML-DSA-65 signed { version : u16 // protocol version pubkey : Vec<u8> // 1952 bytes (ML-DSA-65) recipient : Vec<u8> // 20-byte address hash amount : u64 // kana (10^8 = 1 CSM) fee : u64 // kana (min 1000) expiry_daa_score : u64 // current + 90 buffer salt : [u8; 16] // CSPRNG random signature : Vec<u8> // 3309 bytes (ML-DSA-65) }

Encoded On-Chain

Flash Transactions are wrapped inside a standard transaction envelope using the magic prefix FLASH_V1. This allows the protocol to distinguish them from classical account transactions without introducing a new transaction type at the networking layer.

Validation Order

Each Flash Transaction is validated in a strict, cheapest-first order to minimize wasted computation on invalid inputs. Signature verification is the most expensive operation and is deliberately placed after all cheap checks.

Expiry check. Reject if current_daa > expiry_daa_score. A single integer comparison — the cheapest possible fail-fast.
Fee minimum. Reject if fee < 1000 kana. Prevent spam without competing with legitimate traffic.
Replay detection. Check the derived flash_idagainst the sender's bounded recent_flashes set. O(n) lookup where n is bounded by the pruning window.
Signature verification. Verify the ML-DSA-65 signature against the computed sighash. This is the most CPU-intensive step and is run on a dedicated parallel thread pool.
Balance check. Ensure the sender has sufficient balance to cover amount + fee. In a batch, balances are aggregated per-sender before this check to prevent double-spend within a block.

Batch Processing

A single block can contain Flash Transactions from many different senders, processed in parallel. The critical property is that same-sender transactions within a block are aggregated before balance validation to prevent double-spending the same funds twice.

// Validate entire batch atomically match validator.validate_flash_batch(&txs, current_daa) { Ok(()) => { // Aggregate sender debits, validate once per sender // Then apply every transaction in the batch } Err(e) => { // Whole batch rejected — all-or-nothing log::warn("flash batch rejected: {:?}", e); } }

Reorg Safety

The Sahyadri consensus is a DAG — blocks can be reordered, disconnected, or re-merged as the blue set evolves. Every recent_flashes entry therefore stores the hash of the block that produced it. When a reorg disconnects a block, only entries originating from that specific block are unwound. Parallel transactions from other blocks remain untouched and continue to be replay-protected.

Per-Block Unwind

Blind removal of flash entries would silently make previously-applied transactions replay-eligible. Sahyadri avoids this by never removing an entry unless the block that produced it is being disconnected.

State Pruning

Replay-tracking state does not grow unbounded. Each flash_idcarries the expiry value under which it was accepted. On every block commit, the protocol prunes entries whose expiry has fallen below the current DAA score minus a safety buffer.

With a 100-block expiry and a 50-block safety buffer, the maximum replay window is 150 blocks. After 100 blocks the transaction is invalid anyway, and after 150 blocks its replay record is discarded. Storage per account therefore remains bounded by recent activity only.

Design Principles

Parallel by Default

Transactions from different accounts do not share state. Transactions from the same account are aggregated only at the batch boundary. The result is a system where parallelism is the natural default, not an exception.

Bounded State

Replay protection is local, temporary, and self-pruning. There is no global monotonically growing counter, no chain-wide replay set, and no unbounded per-account index. The cost of accepting a transaction is bounded and predictable.

Reorg-Correct

Every applied transaction is tagged with its source block. Reorgs unwind only the affected entries. Cross-block parallelism is preserved through reorgs without any replay or state corruption.

Quantum-Resistant

Every Flash Transaction is signed with ML-DSA-65 (CRYSTALS-Dilithium3), a NIST-standardized post-quantum signature scheme. The security of the transaction layer does not depend on the eventual hardness of elliptic-curve problems.

Developer-Transparent

Wallets, SDKs and applications interact with Flash Transactions through the same RPC and JSON interfaces as classical transactions. The nonce-less model is exposed as a natural API surface — not a separate protocol to learn.

SDK Usage

The Sahyadri Web3 SDK exposes a small, focused API for constructing and submitting Flash Transactions. Expiry is computed automatically from the current DAA score returned by the node.

import { buildFlashTransactionHex, SahyadriClient } from '@sahyadrinet/web3.js'; const client = new SahyadriClient(); await client.connect(); // Current DAA score from node — no caching const daa = await client.getDaaScore(); // Build a signed, ready-to-broadcast Flash Transaction const txHex = buildFlashTransactionHex({ secretKey: wallet.secretKey, publicKey: wallet.publicKey, recipient: recipientHash20, amount: BigInt(50000000), // 0.5 CSM fee: BigInt(1000), currentDaaScore: daa, });

Summary

Flash Transaction is not a patch on top of a sequential system. It is a rethinking of what a transaction is in a post-nonce world: a signed intent, valid within a bounded time window, uniquely identifiable, parallel by default and safe under reorg.

Combined with Sahyadri's DAG consensus, post-quantum signature scheme and native identity layer, it forms the transaction substrate on which Web5 applications can be built without inherited bottlenecks from the previous generation of blockchains.