Permissioned Blockchain Ledger for Vehicle Ownership Transfer and Hypothecation at RTO Offices

When a vehicle changes hands in India, the paperwork is fragile. The buyer and seller sign the transfer forms, the financier releases or records a hypothecation, an NOC travels between RTOs — and the RC's true history exists as scattered entries that a forger can misrepresent: a vehicle sold with an unpaid loan, a car hypothecated to two banks, an edited certified copy.

RC-Chain is a lab-scale permissioned blockchain modelling exactly this workflow for a fictional Karnataka transport-office network. Four peer nodes — RTO-East, RTO-West, a Transport Department auditor and a financier (Sahakara Bank) — run the same Node.js service sharing one append-only log. Every lifecycle event — registration, transfer of ownership, hypothecation added, hypothecation terminated, NOC issued, scrapped — is signed with Ed25519 by the party that owns the action (seller and buyer sign transfers; the bank signs loan events; the clerk countersigns), validated by the leader against a vehicle state machine (no transfer while a hypothecation is active without the bank's consent; no second loan on a financed vehicle), replicated under a Raft-style leader with a 3-of-4 quorum, and committed as a hash-chained block whose batch Merkle root is anchored at the auditor.

The consensus layer is genuinely exercised, not decorative: the project measures throughput and latency across 1-, 3- and 5-node lab configurations, kills followers and leaders mid-run, and proves a tampered store is caught by cross-node comparison — an advanced VTU MCA project where hash chains, signatures, Merkle trees and quorum consensus all do visible work.

Vehicle lifecycle events in India are created by parties who do not share a system: buyers and sellers sign transfers, financiers record hypothecation, and RTOs register, issue NOCs and scrap entries. Because each office keeps its own reconcilable-or-not copy, the record can be misrepresented: a vehicle is sold while its loan is still open, hypothecated to two financiers at once, or a certified copy is edited after issuance. There is a need for a shared, append-only ledger in which every lifecycle event is signed by the party responsible, ordered through quorum consensus among mutually independent offices, anchored so that any later alteration of any single copy is detectable, and guarded by a state machine that refuses the illegal transitions the paperwork currently allows. The project delivers exactly this as a four-node permissioned network with a measurable consensus layer, not a mock-up.

Abstract

This project builds RC-Chain, a permissioned blockchain application for vehicle registration-office workflow. Four peer nodes (two RTOs, a department auditor, a financier) replicate an append-only, hash-chained log of signed lifecycle events — registration, transfer, hypothecation, its termination, NOC and scrap — using a Raft-style leader election and a three-of-four commit quorum. A per-vehicle state machine enforces the Act's workflow (no transfer under an active loan without bank consent; no double hypothecation), Merkle roots are anchored at the auditor, and a cross-node verifier detects tampering. Experiments measure throughput and latency across cluster sizes and under leader failure.

Introduction

The registration certificate (RC) is the legal identity of a vehicle. Its events — transfer, hypothecation and its termination, NOC — are created by different offices and banks, precisely the situation where shared, tamper-evident records matter. A permissioned network models this honestly: known nodes, signed actions, quorum agreement, no tokens or mining.

Existing System and Its Limitations

• Centralised registries hold the record, but office-level copies — registers, certified extracts, bank files — are mutable and unreconciled.
• A sale against an outstanding loan surfaces only when a clerk notices the missing bank termination.
• The same vehicle has been hypothecated twice by submitting paperwork to different offices; detection is manual, after the fact.
• Limitations: no shared append-only history, no party-signed actions, no automatic cross-check, no proof that a record copy is unaltered.

Proposed System

• Signed events: every action carries Ed25519 signatures — seller plus buyer for transfers, financier for loan events, clerk countersigning — verified before acceptance.
• State machine: per-vehicle status with legal-transition rules; illegal proposals are rejected before consensus.
• Quorum replication: a Raft-style leader orders events into hash-chained blocks; a block commits when three of four nodes acknowledge; heartbeats and timeouts drive leader re-election.
• Anchoring and audit: each block's Merkle root is anchored at the auditor with the leader's signature; inclusion proofs show single events against it.
• Tamper evidence: the verifier compares all nodes' chains and reports the first divergent block; a modified store cannot survive.
• Experiments: throughput and latency for 1-, 3- and 5-node configurations, follower-kill and leader-kill scenarios, plotted with Python.

Feasibility Study

• Technical: all pieces are standard — node:crypto for SHA-256 and Ed25519, SQLite (WAL) per node, Docker Compose boots the four-node lab on a 16 GB laptop, matplotlib plots the runs.
• Economic: zero licence cost; everything is open-source.
• Operational: the console mirrors clerk and auditor desks; seed data covers 40 vehicles across all states, including a double-hypothecation attempt rejected live.
• Legal fit: the workflow mirrors Forms 29/30 and 34/35 practice under the Motor Vehicles Act, 1988; the project is a teaching replica, not a national-registry replacement, and stores no Aadhaar or PAN data.

In scope

• One fictional Karnataka transport-department network: two RTO nodes, one auditor node, one financier node; three human roles (clerk, bank officer, auditor) on a React console.
• Full event lifecycle with party signatures, quorum replication, leader election, Merkle anchoring, cross-node verification, fault-injection experiments and CSV/JSON exports of the audit trail.

Out of scope (v1)

• Integration with the national Vahan registry or real RTO software — the project is a teaching-scale replica with fictional offices and vehicles.
• Public-chain deployment, tokens or proof-of-work; membership is fixed and permissioned.
• Biometric or Aadhaar-based identity of owners — parties are referenced by licence-style internal codes only; no government ID numbers are stored.
• Mobile apps; the console is responsive web. Smart-contract platforms (Fabric/Ethereum private networks) are future work — the consensus layer is purpose-built so the class can measure it.

The project spans 16 weeks across the VTU MCA Phase-2 semester and follows an incremental SDLC with risk-first ordering — the quorum replication and election logic are the hardest parts, so they are built and fault-tested before any console polish. The three-member split: Member A owns the node core (log, quorum, election), Member B owns signing, intake validation and the console, Member C owns the state machine, anchoring, verifier and experiments; all three write tests for their own modules.

Testing approach: unit tests for hash chaining, signature verification and every state-machine transition including all illegal ones; Supertest integration tests for the commit path (quorum reached, quorum blocked with a node down); fault-injection scripts that stop containers mid-run and assert recovery without committed-data loss; golden-vector tests with pre-computed signatures; and a tamper drill that edits one node's store and asserts the verifier names the divergent block.

RC-Chain is a replicated service with a thin console. Each peer node is an Express application holding an append-only SQLite store of blocks; nodes know each other from a membership file with Ed25519 public keys. A client request never writes directly — it goes to the current leader, which validates signatures and state rules, appends the event as a new block (hash-chained to the previous), replicates it to followers, and commits on three acknowledgements out of four. Followers acknowledge by verifying the block's hash and the embedded signatures; a node never accepts a block whose entries it cannot verify. Heartbeats maintain leadership; on timeout, term numbers increase and an election picks a new leader with the longest committed chain.

flowchart TD
  K(["Clerk / bank officer"]) -->|"event proposal (signed)"| LDR["Leader node"]
  LDR --> V["Verify party signatures + state rules"]
  V -->|"valid"| AP["Append block: events + prevHash + term + Merkle root"]
  AP --> R1["Replicate to followers"]
  AP --> F2["RTO-West node"]
  AP --> F3["Auditor node (anchors roots)"]
  AP --> F4["Financier node"]
  F2 -->|"ack after verification"| CM["Commit when quorum = 3 of 4"]
  F3 -->|"ack after verification"| CM
  F4 -->|"ack after verification"| CM
  R1 --> CM
  CM --> ACK["Commit receipt to proposer"]
  ST[("Per-node SQLite: append-only blocks")] --> VF["Cross-node verifier: compare hashes, report first divergence"]
  ST --> MK["Inclusion proof: event → Merkle root → anchor"]
  HB["Heartbeat timeout → election with term numbers"] --> LDR

Event and vehicle state model

erDiagram
  NODE ||--o{ BLOCK : appends
  BLOCK ||--o{ EVENT : contains
  EVENT }o--|| VEHICLE : about
  EVENT }o--o| PARTY_SIGNATURE : "carries"
  BLOCK ||--|| MERKLE_ROOT : "anchors"

  NODE {
    string node_id PK
    string role
    string public_key
    int term
  }
  BLOCK {
    int height PK
    string prev_hash
    string root_hash
    int term
    datetime committed_at
  }
  EVENT {
    string event_id PK
    int height FK
    string vehicle_id FK
    string type
    string payload_json
    datetime proposed_at
  }
  PARTY_SIGNATURE {
    string event_id FK
    string signer_role
    string signature
  }
  VEHICLE {
    string vehicle_id PK
    string reg_no UK
    string owner_code
    string state
    boolean financed
  }

Vehicle state machine

flowchart TD
  R["REGISTERED"] -->|"transfer signed by seller + buyer, no active loan"| T["TRANSFERRED"]
  T -->|"hypothecation signed by financier"| H["HYPOTHECATED"]
  R -->|"hypothecation signed by financier"| H
  H -->|"termination signed by financier"| LC["LOAN CLOSED"]
  LC -->|"transfer"| T
  H -->|"transfer attempt"| X1["REJECTED: bank consent required"]
  H -->|"second hypothecation attempt"| X2["REJECTED: already financed"]
  T -->|"NOC issued; entry at other RTO"| NOC["NOC ISSUED"]
  NOC -->|"scrap certified"| S["SCRAPPED"]
  LC -->|"scrap certified"| S
  S -->|"any further event"| X3["REJECTED: vehicle scrapped"]

DFD level 1

flowchart TD
  K(["Clerk / bank officer"]) --> P1["1.0 Validate proposal and signatures"]
  P1 <--> D1[("D1 Membership keys")]
  P1 --> P2["2.0 Order via leader and commit on quorum"]
  P2 <--> D2[("D2 Block log per node")]
  D2 --> P3["3.0 Derive vehicle state and enforce rules"]
  P3 <--> D3[("D3 Vehicle registry view")]
  D2 --> P4["4.0 Anchor Merkle roots at auditor"]
  P4 <--> D4[("D4 Anchor log")]
  A(["Auditor"]) --> P5["5.0 Verify chain across nodes"]
  D2 --> P5
  D4 --> P5
  P5 --> A
  K --> P6["6.0 Issue inclusion proofs"]
  D4 --> P6

The design deliberately separates integrity (hash chain and Merkle roots), authenticity (party signatures) and agreement (quorum commit) — three words examiners often blur, each mapped here to a distinct, testable mechanism.

• BFT consensus option: swap the crash-fault-tolerant quorum for a PBFT-style protocol and compare message complexity and latency — a natural extension for the advanced experiment chapter.
• Smart-contract port: re-implement the state machine as chaincode on a private Hyperledger Fabric channel and compare developer effort and throughput.
• Financier-to-RTO direct events: bank systems push termination events without a clerk intermediary, with webhook acknowledgement and the same signature guarantees.
• RC QR verification: a citizen-facing page that verifies an anchored extract against the Merkle root with a signed offline snapshot.
• Inter-state NOC federation: a second network peering across 'state' boundaries, exchanging anchored roots — the realistic shape of inter-RTO workflows.
• Anomaly analytics: owner-velocity and churn features over the event log to flag suspicious transfer patterns for the auditor.