Sid
All ventures

Co-founder & CEO

Past ventureFounded 2020

DataNest Ventures

CoviFight, a contact-tracing system built in the first months of the pandemic. The data lived in public, the identities never did, and every phone worked out its own exposure risk.

Visit DataNest Ventures

The hard part of contact tracing was never the Bluetooth. It was asking millions of people to hand an operator the record of everyone they had met — so we built the version where you could check the maths yourself instead.

Product
CoviFight
Team
Three founders, twelve developers
Stack
Java · Python · Node.js · Gremlin Graph DB · Kubernetes on Azure
Benchmark
3× the exposure detection rate of DP-3T
Backing
A grant from The Meta Group, plus $6,500 AWS and $1,875 Wolfram credits

Early 2020

It began as research, not as a company

When COVID-19 struck in early 2020, VIT brought the summer break forward and the free months turned into an opportunity. I carried on earlier work on social network analysis — how people actually cross paths, and what the shape of those encounters says about what travels through them. The research gained momentum, became CoviFight, and CoviFight became the foundation of DataNest Ventures, founded by three of us.

The product was a hybrid mobile and web application in Java, Python, Node.js and Gremlin Graph DB, running on Kubernetes on Azure. The premise was narrow. A tracing app is only useful if enough people install it, and in 2020 the thing standing in the way of installing one was being asked to surrender an identity to whoever ran it.

I did not set out to start a company. I set out to find whether the interaction graphs I had been studying could tell someone something useful about their own risk.
On where CoviFight came from
The walkthrough we showed judges and health officials in 2020, from the team's own channel.

The core idea

The data is public. The identifiers are private.

Every user held a decentralised verifiable ID on a blockchain, with their public key as the sole identifier. No name, phone number, email address or device identity was ever written to chain. Nothing about a person was stored anywhere that could be used to identify them, which was a property of the design rather than a policy on top of it.

Capture was ordinary Bluetooth work. Devices ran continuous BLE scanning, and when two crossed paths each stored the other's ID locally. Those IDs resolved to public keys already on chain, so an encounter could be verified later without either party being named.

  1. Public key

    Sole identifier

    The only thing that names an identity, and nothing links it back to a person.

  2. BLE ID

    Rotated

    A Bluetooth Low Energy identifier provisioned onto the device at registration, rotated afterwards, and linked to the public key. It identifies a device session rather than a human.

  3. Status and history

    Public health signal

    Whether this identity is infected or was previously infected, with the date the infection was detected. A signal without a patient attached.

  4. Approximate geolocation

    Optional, coarse

    Captured only when a user chooses to update their status, and coarse by design.

  5. Probability score

    Updated hourly

    The likelihood of infection for this identity, and the output of the edge analytics below.

  6. Device type

    User or aggregator

    Lets the network tell a personal phone apart from a fixed scanner.

One identity's entire on-chain record. No name, phone number, email address or device identity appears anywhere in it.

Bluetooth encounter

Seven phones drift around a space, each advertising a short Bluetooth identifier that rotates over time. When two come within range a link is drawn between them and each device stores the other's identifier in its own local list — shown as a row of small dots beneath each phone. Hairlines drop to a rail along the bottom, the public ledger, where every identity holds one fixed public key. Encounters can therefore be verified later, and nothing recorded anywhere is a name, a number or a device identity.

Animation playing.

0x030C…A7PUBLIC LEDGERFA7217902A08
  • Accent marks an encounter in range: identifiers travelling in both directions.
  • The marks under a phone are the identifiers it has stored.
  • The rail is the public ledger — one fixed key per identity, while the identifier above it rotates.
Every dot is a phone. Two come within Bluetooth range, exchange rotating identifiers, and move on — neither learning anything about the person carrying the other.

Edge analytics

Every device did its own epidemiology

Because encounters resolved to public keys and BLE IDs that were already on chain, a device did not need a server to work out its own risk. It read what was public, computed locally, and published one number back. Federated analytics at the edge: every device computed its own risk locally and only anonymous scores were ever shared — never a contact history, and never model weights, because no shared model was being trained.

  1. Scan the chain

    The device runs a periodic quick scan against data already published on chain.

  2. Look for positives

    It checks whether any identity it has crossed paths with has since been detected positive.

  3. Recompute locally

    It updates its own probability score from the scores of every device it has been in contact with.

  4. Publish the score

    The updated probability goes back on chain. The contact history that produced it stays on the device.

  5. Everyone else updates

    On the next cycle, every device that has met yours recomputes against your new score.

Risk propagates through the contact graph iteratively, each round refining the last.

  1. 01

    You cross paths with A

    Two devices exchange IDs over Bluetooth and each stores the other's. Neither learns anything about the person carrying it.

    Day 0

  2. 02

    A is detected positive

    A's status and the detection date are recorded against A's public key. A's name is not, because the system never held it.

    Day 3

  3. 03

    Your device notices

    Your next local scan reads the chain, finds the ID it recorded on day zero, and raises your probability score.

    Next scan

  4. 04

    Nobody was told

    No central authority was involved, and no party learned that you and A had ever met.

    Throughout

The same mechanism, seen from one person's side.

The number in each mark, and the weight of its ring, are that identity’s published probability from 0 to 100. No server appears in this diagram: every mark is a device reading or writing data that is already public.

Propagation

Before the first cycle

  1. 1Scan the chain
  2. 2Recompute locally
  3. 3Publish the score

The contact graph

Nodes are anonymous identities — public keys. Edges are past Bluetooth encounters. Every identity carries a probability score, and every score starts at zero.

Latest records on chain

  • 0xb5c3identityregistered
  • 0x60dfidentityregistered
  • 0x8f8bidentityregistered

A contact graph of 9 anonymous identities linked by 16 past Bluetooth encounters. One identity is detected positive and its status is written on chain against its public key. On each cycle every device independently reads the chain, recomputes its own probability from the published scores of identities it has met, and publishes only that number back. Contact histories never leave the devices and no server takes part. After 5 cycles the scores converge to: 0xb5c3 9 per cent, 0x60df 11 per cent, 0x8f8b 17 per cent, 0xac22 11 per cent, 0xd6d7 19 per cent, 0x5822 37 per cent, 0x0ee9 9 per cent, 0xf12a 34 per cent, 0xb81e 100 per cent.

One identity is detected positive and risk spreads outward through the contact graph, a cycle at a time, with every device doing its own arithmetic.

The result

Three times the detection rate of DP-3T

Exposure detection rate

DP-3T
Baseline
CoviFight
Measured against DP-3T, the prevailing decentralised proximity-tracing standard and the thing the architecture had to beat to be worth building.

The multiple is the headline. The property underneath it is the part I would defend first, and it is the answer to the obvious question — why a blockchain rather than a database. Because the data was on chain, every edge node could perform the analytics independently and verify the result independently. A light client could check the epidemiology for itself instead of trusting an operator's output.

Neither a central server nor a conventional distributed database gives every participant that. Without it, the anonymity guarantee is a promise rather than a property, and a promise is a poor thing to ask a country to install.

Consent as configuration

Edge, central, or hybrid — decided by jurisdiction

Nothing was ever compulsorily uploaded. A device could optionally send its connected-device list to a central server sitting outside the blockchain, and whether that happened at all depended on a country's regulations and on how deep its government wanted the analytics to go. Where a jurisdiction opted in, the data collected was still fully anonymous, and it fed time-series analytics alongside graph and social-network analytics — linking encounters between anonymous identities and estimating infection probability against continuously updating variables.

  • Edge-only

    Every device computes and verifies its own risk from on-chain data. No server, no upload, no central authority.

  • Central

    A government opts in, anonymous data is aggregated, and the full time-series and graph analytics run centrally.

  • Hybrid

    Both, in whatever mix local law allows.

Consent and data residency were configuration rather than a rewrite. That is what made the system deployable across European jurisdictions with very different privacy regimes, and it is what made the conversations with them possible at all: a government could evaluate the mode that fitted its own law rather than the one we happened to prefer.

Observed share of the encounter graph

One population, one set of movements, two observation regimes. Dashed hairlines are encounters as they happen; solid accent lines are the ones the network gets to record.

Two side-by-side simulations of the same eighteen moving phones in one space. On the left, an encounter is recorded only when two phones come close enough for a direct Bluetooth handshake. On the right, three fixed aggregator devices also observe any phone inside their zone, so encounters in those areas are recorded whether or not two phone carriers happened to meet. Both panels run the same population from the same seed. Current figures: 0 simulated encounters so far. Phones alone recorded 0, 0 percent. Phones with aggregator devices recorded 0, 0 percent.

Phones only

Recorded only when two carriers come close enough to shake hands over Bluetooth.

0 of 0 recorded

0%

Phones and aggregators

Three fixed scanners also observe every phone that passes inside their zone.

0 of 0 recorded

0%

  • Phone
  • Aggregator
  • Recorded
  • Missed

Illustrative. Every figure here is generated by this simulation, not measured from a deployment. It shows what aggregator devices do to observed coverage; which part of the architecture accounted for the detection results is a separate, open question.

Aggregator devices are fixed scanners rather than phones. Toggle them to see what they do to how much of the encounter graph the network actually observes.

Running it

Co-founder and CEO, and the person writing the schema

Developers led

12

Developers led

Scrum Master across cross-functional teams

EU vs Virus, of 2,000+ teams

2nd

EU vs Virus, of 2,000+ teams

Real-time Communication and Prevention challenge

Officials, institutions and partners met across Europe

50+

Officials, institutions and partners met across Europe

Student Innovators in India

Top 15

Student Innovators in India

SAMADHAN, Ministry of Human Resource Development

I ran the company and I led the engineering, and at around twenty-one those were one job rather than two. Twelve developers, a compressed 2020 timeline under lockdown conditions, and Scrum Master duty across cross-functional teams — while contributing the machine learning models and the database schema myself. I set the technical direction: Gremlin Graph DB and time-series analytics to find the interaction patterns, an integrated blockchain layer for privacy and verifiability, and a Kubernetes deployment on Azure sized to collect and analyse terabytes of human interaction data.

The outward half was mine too. We secured a grant from The Meta Group, a European investment group, along with $6,500 in AWS credits and $1,875 in Wolfram credits. I met more than fifty people across Europe about how CoviFight could raise COVID-19 detection — public officials, academic institutions, corporate partners and venture capitalists. The opt-in architecture was what made those meetings go anywhere.

Recognition

Five international awards in four months, and what stayed with me

The two that mattered: CoviFight placed 2nd in the Real-time Communication and Prevention challenge at EU vs Virus, the European Commission's pan-European hackathon led by the European Innovation Council, out of 9,000+ participants and 2,000+ teams, winning €1,000. In April, India's Ministry of Human Resource Development named the team among the Top 15 Student Innovators in the country in the SAMADHAN challenge.

Three more followed in the same stretch: The Wolfram Award from Wolfram Research for open-source work using AI or blockchain against COVID-19, 2nd position in Boston University's Resiliency Challenge, and a top-six finish in the Crisis Response track of The Global Hack. All five are credited to DataNest Ventures.

What I took from it was not the awards. It was the habit of asking what a system proves rather than what it claims — and finding out how much of building a company is conversations with people who will never read the architecture, and who have to be given a reason to trust it anyway.

It taught me the difference between designing something private and designing something whose privacy anyone can check. I have wanted that property in everything I have built since.
On what CoviFight was for