Skip to content

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

1 Commit
 
 
 
 

Repository files navigation

Open Exam Protocol

A decentralised integrity blueprint for national entrance exams. Born from the NEET 2026 leak.

STATUS: DRAFT v0.1 · RFC · seeking review, criticism, and collaborators


Why this exists

NEET-UG 2026 was written by 22.7 lakh students on May 3 and cancelled nine days later, after a "guess paper" circulating on WhatsApp matched ~120 questions of the real exam. The people arrested were not hackers. They were NTA's own translators and subject experts.

The same thing happened in 2024. Heads rolled, a committee wrote 101 recommendations, the chief was replaced — and the system leaked again, from inside, two years later.

The lesson is not "find better officials." The lesson is that any system whose security depends on the honesty of a single custodian will eventually be broken by exactly one corrupt insider. A resignation doesn't remove that vulnerability. It re-advertises the vacancy.

This document is a sketch of an exam pipeline where no single human — however senior, however corrupt — can leak a paper, open it early, or quietly change a result. Trust becomes a property of the system, not of whoever sits in the chair.

Provenance, honestly: the first draft of this blueprint took about 30 minutes and ~$5 of Claude credits, as the receipts behind a LinkedIn argument. It is a sketch by one chartered accountant who builds software — not a finished specification. That is precisely the point: if this much is possible in half an hour, a funded national mission has no technical excuse. Pull requests welcome.


Threat model

In scope — what this design defends against

# Threat Today's reality
T1 Insider with access leaks the question paper before the exam Happened in 2024 and 2026, via NTA's own staff
T2 Paper opened/copied during storage, printing, or transport Papers sit assembled for weeks in drawers, presses, lockers
T3 Single official's credentials are enough to exfiltrate the bank Custody is concentrated; one bribe suffices
T4 Answer key silently edited after the exam Key disputes and revisions happen with no public audit trail
T5 Marks/results tampered post-hoc ("mystery grace marks") Grace-mark decisions surface with no verifiable record
T6 Leak investigations take months and rely on raids No access log exists; forensics start from nothing

Out of scope — what this design does NOT solve

  • Exam-day conduct: impersonation, copying, invigilator collusion, device smuggling at centres. These are physical problems. Biometric authentication and centre-side controls (as recommended by the 2024 reform committee) remain necessary and complementary.
  • Endpoint compromise at CBT centres (malware on exam terminals). Mitigable with attested, locked-down images — but that is standard IT security, not this protocol.
  • Post-exam memorisation leaks (a candidate memorising questions and coaching centres reconstructing the paper afterwards). No cryptography prevents human memory; question-pool rotation and retirement (§4.5) reduce the value of doing this.

If someone tells you blockchain fixes everything about exams, they are selling something. It fixes T1–T6. That is the leak surface that cancelled two national exams.


Design principles

Four invariants. Every design decision below serves one of them.

  1. No single human ever holds the full question bank.
  2. The assembled paper does not exist until hours before the exam.
  3. No single human can decrypt anything alone — and every decryption is a public, timestamped record.
  4. Results must match commitments made before the exam. Any change is a visible event, not a quiet edit.

Corollary: corrupting this system requires a conspiracy across independent institutions, not a phone call to one person. That is the entire trick. We cannot make people honest; we can make dishonesty require impractical coordination.


Architecture overview

flowchart TD
    subgraph P1["1 · SUBMISSION (year-round)"]
        A[Registered contributors\nprofessors across India] -->|encrypt client-side| B[(Consortium chain\nsealed questions + open metadata)]
    end
    subgraph P2["2 · GENERATION (T-6h)"]
        B --> C[Public VRF draw\nseeded by public entropy]
        C --> D[Stratified paper selection\nverifiable by anyone]
    end
    subgraph P3["3 · UNLOCK (T-0)"]
        D --> E[Threshold decryption\nt-of-n institutions]
        E --> F[Centre terminals decrypt\nagainst valid admit cards]
        F --> G[(Every decryption logged\non chain)]
    end
    subgraph P4["4 · EVALUATION"]
        H[Answer-key hash\ncommitted BEFORE exam] --> I[Responses hashed\nat submission]
        I --> J[Results published\nwith Merkle proofs]
    end
    D -.->|hash| H
Loading

The chain is a permissioned consortium ledger — not a public token chain. Validators are independent institutions (see §2). All content is encrypted; all events are public. Anyone — a student, a journalist, a court — can verify the draw, the timing, the access log, and the result consistency from a public explorer.


1 · The consortium chain

  • Validators (illustrative n=9): NTA, NIC, two IITs (rotating), AIIMS, one Supreme Court-appointed observer body, CAG's audit office, and two state education boards (rotating annually). No single ministry controls a majority.
  • Consensus: standard BFT (e.g. Tendermint/HotStuff family). Throughput needs are trivial — this is hashes and access logs, not payments. A national exam cycle is small data.
  • Public read access: the full ledger (events, commitments, logs — never plaintext content) is publicly queryable. A block explorer is part of the deliverable, not an afterthought.
  • Public anchoring: the consortium chain's state root is anchored periodically (e.g. daily) to a public chain, so even a full-consortium collusion cannot rewrite history unnoticed.

Why a chain and not "a government database"? Because a database has an administrator, and an administrator is a chair, and a chair is the vulnerability this whole design exists to remove (threats T1, T3, T4, T5). Tamper-evidence, multi-party control, and public verifiability are the requirements; a consortium ledger is simply the boring, proven way to get all three at once.


2 · Question submission protocol

The guidelines below are the heart of invariant #1: no one ever holds the full bank.

2.1 Who may submit

  • Contributors are registered subject experts (university faculty, board-empanelled setters) with verified credentials issued as signed on-chain identities.
  • Contributor identity is pseudonymous on the public ledger (an ID, not a name) but escrowed with the consortium — accountability without a public target list for bribery.

2.2 How a question enters the system

  1. The contributor writes the question in an approved client app, offline.
  2. The client generates a random data key, encrypts the question content (stem, options, correct answer, solution), and wraps the data key to the exam epoch's threshold public key (§3.1). Plaintext never leaves the contributor's device.
  3. The client submits: the sealed content blob, open metadata — subject, syllabus topic code, stated difficulty, language(s), format — and a content hash, all signed by the contributor's credential.
  4. The chain records the submission event. The contributor can see only their own questions. No role exists — not at NTA, not anywhere — that can browse the pool in plaintext.

2.3 Pool rules (the "guidelines")

Rule Value (illustrative) Why
Minimum live pool per subject ≥ 50,000 sealed questions A leak of any one contributor's output is statistically worthless
Per-contributor cap ≤ 0.5% of any subject pool Bounds the damage of one corrupt contributor
Contributor count thousands, rotating No small clique to bribe
Metadata in cleartext subject, topic, difficulty, language The draw must balance the paper without opening content
Compensation flat fee per accepted question + royalty when drawn Aligns incentives with volume and quality
Retirement every drawn question is retired and published post-exam Public quality review; memorisation attacks lose value
Quality control post-exam statistical review (discrimination index, error reports) feeds contributor reputation Bad setters lose eligibility without anyone reading the live pool

2.4 The duplicate-question problem (honest note)

You cannot deduplicate ciphertext. Near-duplicate questions in the pool are handled statistically: oversampling at draw time, post-exam publication and review, and contributor reputation. This is a real trade-off of sealed submission — flagged here so nobody pretends otherwise. Research directions: privacy-preserving similarity (MPC/FHE) if it ever becomes cheap enough. It is not required for v1.


3 · Paper generation: the draw

3.1 Epoch setup

Before each exam cycle, the consortium runs a distributed key generation (DKG) ceremony producing one epoch public key; the private key exists only as n shares held by the validator institutions (threshold t-of-n, e.g. 5-of-9). No party ever holds the full key. All submissions in that cycle are wrapped to this epoch key.

3.2 The draw itself

  • At T-6 hours, a selection transaction executes on chain:
    • Entropy: a public randomness beacon value (e.g. drand) from a round after the submission freeze, combined with the chain's own committed state. Unpredictable by insiders, verifiable by everyone.
    • Algorithm: deterministic stratified sampling over the open metadata — so many questions per topic code per difficulty band, per the published exam blueprint.
    • Output: the ordered list of sealed question IDs for each paper variant.
  • Anyone can re-run the selection function against the public inputs and confirm the draw. You cannot bribe a dice roll the whole country can verify.
  • Until T-6h, "the NEET paper" does not exist anywhere — not in a drawer, a press, or an inbox. There is nothing to steal for the months when leaks happen today (threat T2).

3.3 Assembly

Selected questions are threshold-decrypted (§4) only inside the delivery path — rendered per-centre, per-variant, at or after T-0. For CBT (the announced direction for 2027+), assembly happens on attested exam servers. For any remaining pen-and-paper centres: just-in-time printing at the centre from a logged decryption, not weeks-early central printing.


4 · Unlock: opened by students, not officials

sequenceDiagram
    participant S as Student (admit card)
    participant C as Centre terminal
    participant V as Validator institutions (t-of-n)
    participant L as Chain (public log)
    Note over V: Before T-0: partial-decryption shares withheld
    S->>C: Present signed admit-card credential
    C->>L: Request paper unlock (centre ID + credential)
    L->>L: Verify: valid credential, T ≥ start time
    V-->>C: t partial decryptions (threshold met)
    C->>C: Combine → paper renders for this candidate
    C->>L: Log event: credential, centre, timestamp
    Note over L: Every view is now evidence
Loading
  • Time-lock: validator institutions release partial decryptions only at the scheduled start. Before T-0, early decryption is not "against the rules" — it is mathematically unavailable to any single party, including every validator (invariant #3, threat T1/T3).
  • Admit-card binding: unlock requests must carry a valid, signed candidate credential (deliverable via DigiLocker-class infrastructure). Papers decrypt for candidates at centres, not for officials in offices.
  • The access log is the headline feature: every decryption writes which credential, which centre, what second to the public ledger. If a paper surfaces on WhatsApp, the investigation is a query, not a year of raids (threat T6). A leak becomes evidence against the leaker.

5 · Evaluation: commit first, reveal later

  • Before the exam: the hash of the answer key (produced by the same draw, since sealed submissions include the key) is committed on chain. Nobody can retro-fit a key (threat T4).
  • At submission: every response sheet (OMR scan or CBT response log) is hashed and anchored on chain, with a receipt to the candidate.
  • At results: scores are published with Merkle proofs tying each result to the committed key and the committed responses. Any candidate can verify their own chain of custody.
  • Corrections are events, not edits: a key challenge upheld, a grace-mark policy, a re-evaluation — each is a new, signed, public on-chain decision with its rationale. Policy can still be humane; it can no longer be silent (threat T5).

6 · What breaking this would take

Attack Cost under today's system Cost under this design
Leak the full bank One insider Impossible: no full-bank plaintext exists anywhere
Leak the assembled paper pre-exam One insider, weeks of window Collusion of ≥ t independent institutions inside a 6-hour window, permanently logged
Open a paper early A key and a photocopier ≥ t validator institutions defecting simultaneously, publicly
Rig the selection Whoever assembles the paper Predicting a public randomness beacon (i.e., no)
Change the answer key quietly An office PC Breaking a hash commitment the whole country holds
Erase the evidence Shredder Rewriting a BFT ledger anchored to a public chain

One corrupt person stops being enough. That is the entire objective.


7 · Objections, answered

"Why not just a well-run government database?" A database has an admin. An admin is a chair. See 2024, 2026. The requirement is not storage — it is the absence of any single point of trust, plus public verifiability. That is what a consortium ledger with threshold custody buys, and a database cannot.

"Blockchain doesn't stop humans at exam centres." Correct, and this document says so explicitly (threat model, out of scope). This fixes the paper-setting and evaluation legs — the two that cancelled national exams twice in three years.

"Scale?" 23 lakh candidates is trivially small for this design. The chain stores hashes, events, and sealed blobs — not videos of anyone's exam. This is kilobytes per candidate.

"Cost?" A retest for 22.7 lakh students, plus a year of CBI investigation, plus the option value of 2.7 lakh students who didn't come back — every cycle. Against that: a consortium of nine nodes and a DKG ceremony. This is a rounding error on one cancelled exam.

"CBT from 2027 already fixes this." CBT changes the vault, not the trust model. A centralised CBT server with an administrator is the same chair with a better lock. The 2026 leak came from people entitled to access.

"Isn't the VRF gameable by whoever picks the entropy?" No party picks it. The beacon value is public, produced after the freeze, and combined with committed chain state. Anyone can recompute the draw.


8 · Pilot proposal

Do not start with NEET. Start with one small NTA exam cycle:

  1. Stand up the consortium chain with five founding validators.
  2. Run one subject's question pool through sealed submission (§2).
  3. Execute the public draw, threshold unlock, and commit-reveal evaluation.
  4. Publish the explorer. Invite hostile audit — academics, journalists, the losing coaching industry. Pay a bug bounty.
  5. Report everything, including what broke.

Then scale.


Contributing

This is a v0.1 sketch and it has holes — find them. Issues and PRs are welcome, especially from: cryptographers (DKG/threshold choices, VRF construction), psychometricians (stratified draw vs. paper equivalence), exam administrators (operational reality checks), and lawyers (governance, evidence admissibility of on-chain logs).

Ground rule: attack the design, not people. We have enough scapegoat politics already.

Provenance & license

Drafted July 2026 by CA who Codes — a chartered accountant who builds software — with Claude. First pass in ~30 minutes for ~$5 of credits, then published here as the receipts behind an argument: demand systems, not scapegoats. Contact: ca.who.codes@proton.me.

Licensed under MIT. Fork it, improve it, hand it to a committee — no permission needed.

About

Decentralised integrity blueprint for national entrance exams — sealed question submission, verifiable random paper generation, threshold unlock, commit-reveal evaluation. Born from the NEET 2026 leak. RFC v0.1

Topics

Resources

Stars

Watchers

Forks

Releases

Packages

Contributors