DandelionTech

From consensus protocol to a working product suite.

FLASH was not treated as a protocol in isolation. The work covered consensus design, user products, merchant tools, network infrastructure, and day-to-day technical direction.

Product
FLASH Cryptocurrency
Role
Technology Head
Period
2017–2020
Scope
Protocol · products · operations

The starting point

A blockchain does not become useful because its consensus mechanism works on paper. It must confirm transactions at a practical speed, expose understandable products, and run on infrastructure that can be monitored and maintained.

Deepak Kumar Yadav led the technology work for FLASH Cryptocurrency from September 2017 to September 2020. His responsibility crossed the usual boundaries between protocol engineering, application delivery, and operations. That breadth shaped the central decision: build the network and the products around it as one system.

Three decisions shaped the system.

Each decision answered a different part of the same problem: how to turn a protocol into software that people could use and a team could operate.

  1. Constraint
    The network needed short settlement times without relying on traditional proof-of-work or proof-of-stake overhead.
    Decision
    Design a delegate-based protocol in which elected delegates select 25 miners and assign ordered time slots.
    Result
    FLASH Consensus achieved settlement in about five seconds.
  2. Constraint
    A protocol is not a usable product. People and merchants still need practical ways to hold, send, receive, and inspect transactions.
    Decision
    Build the web wallet, mobile applications, merchant services, and blockchain explorer as one product suite.
    Result
    The work moved beyond protocol design into a complete set of user and merchant-facing products.
  3. Constraint
    The product suite depended on a network that had to be deployed, monitored, and supported as it changed.
    Decision
    Own the cloud and DevOps layer alongside protocol and application delivery.
    Result
    Architecture, products, and network operations stayed under one technical direction through delivery.

One network. Four practical surfaces.

The consensus layer set the rules. The product suite made those rules usable.

What the work produced

A delegate-based protocol with about five-second settlement, delivered with the products and operational layer required to make the network usable.

What this case demonstrates

The useful part of the work was not a single technical novelty. It was the ability to carry one architecture from protocol rules into interfaces, merchant tooling, infrastructure, and ongoing operation without losing ownership between teams.

No adoption, revenue, or transaction-volume claim is made here. Those figures are not needed to explain the engineering decisions or the scope delivered.

Bring us the rough version.

In 30 minutes, we'll test the scope, name the first risk, and tell you honestly whether we're the right team.

Booking project conversations

Book a 30-minute call

You speak with an engineer. No sales hand-off.