Proof, not promises.

Abstract and introduction

Background

India has shown that shared digital public infrastructure can reach national scale. Identity, payments and document exchange systems now serve hundreds of millions of people and have become models studied worldwide. These systems share a pattern: open, interoperable foundations on which public and private services are built.

One foundational layer remains largely missing: shared, verifiable trust in records. Every department, vendor and platform keeps its own logs and databases. When a salary record, a procurement decision, a certificate or an access event is disputed, the evidence usually sits inside the system of the party whose actions are in question. Investigations rely on the assumption that no one with administrator access changed anything.

At the same time, the infrastructure those systems run on is fragmented and frequently foreign-owned. Small IT teams stitch together hosting, databases, authentication, storage, delivery, email, monitoring and security from different providers, each with its own contract, pricing model and failure modes.

The problem

1. Dependency. Core compute, storage and delivery infrastructure is largely supplied by foreign providers, priced in foreign currency, with ultimate control outside Indian jurisdiction.
2. Fragmentation. A typical application depends on a dozen separate vendors. Each adds cost, contracts and integration work that small teams cannot sustain.
3. Unverifiable records. Audit logs are files or tables controlled by the same administrators whose actions they record. There is often no independent way to prove a record has not been changed.
4. Unsuitable blockchains. Public blockchains offer independent verification but bring digital currencies, anonymous validators and fee volatility, which conflict with public procurement rules, data-protection law and regulatory expectations.

Our approach

We separate the work of serving from the work of recording. The Platform serves applications at the speed users expect. The Ledger records compact cryptographic evidence of what the Platform did, maintained by a consortium that no single operator controls. Neither requires a digital currency, and neither places personal data on a ledger.

Contributions of this paper

• An architecture that combines a complete application platform with an independent consortium ledger, while keeping each independently operable.
• A currency-free ledger design using authorised accounts, measured resource weights and rate limits in place of transaction fees.
• Record formats for anchors, deployment manifests, usage receipts and access grants that carry no personal data.
• A hybrid post-quantum signature scheme for long-lived public records, with a path to cryptographic migration.
• A governance model in which automated analysis informs decisions but never changes consensus rules on its own.
• A GPU billing unit based on work performed rather than time rented, with a verification method for untrusted operators.

Design goals and assumptions

Non-goals

• Not a store of application data. The Ledger holds proofs, not documents, rows or files.
• Not a payment network or token economy. Value moves through regulated banking channels.
• Not permissionless. Participation requires verification, because accountability matters more than anonymity for public records.
• Not autonomous. No model changes validator sets, vote weights or finality rules.
• Not a general smart-contract marketplace. Ledger functions are purpose-built and governed.

Assumptions

Existing approaches

Several approaches already address parts of the problem. Each leaves a gap that matters for public institutions.

Our design combines what institutions need from each: the completeness of a cloud platform, the independence of a multi-party ledger, the privacy of off-ledger data, and the accountability of verified participants.

System overview

Participants

The two systems are independent. The Ledger can serve any system that needs tamper-evident records. The Platform continues serving applications if the Ledger is temporarily unreachable, queuing evidence until it is available again.

Ledger architecture

Consortium membership

The Ledger is operated by a consortium of member organisations: government bodies, public sector undertakings, academic institutions and verified enterprises. Each member completes organisational verification before admission. Membership, roles and verification attestations are recorded on the Ledger, so the composition of the consortium is always publicly auditable.

Node types

Validators do not accept direct public connections. Query traffic reaches full and access nodes, which protects validators from overload and attack.

Network layer

• Every node has a cryptographic network identity. Only identities on the governance-approved allowlist can join the validator network.
• All peer connections are mutually authenticated and encrypted.
• Blocks, votes and transactions spread through gossip among authorised peers, so no single connection is critical.
• Members are encouraged to run validators in different cities and on different network providers to reduce correlated failures.

State and blocks

The Ledger's state is a key-value store organised as a Merkle trie. Every block header commits to the root of the state after that block, the root of the block's transactions, and the parent block's hash. This gives three kinds of proof:

• Inclusion proofs that a transaction is part of a block.
• State proofs that a stored value, such as an anchored root, existed at a given block.
• Chain proofs that a block is an ancestor of a finalised block.

Light clients and the verification tool use these proofs to check records without downloading the whole Ledger.

Transaction lifecycle

Consensus and finality

The Ledger separates block production from finality. This keeps the chain responsive while giving every record a precise, irreversible point of confirmation.

• Block production. Admitted validators take turns producing blocks in fixed time slots of a few seconds, in an order known to all validators. There is no mining and no stake-based lottery.
• Finality. Validators run a Byzantine fault tolerant finality protocol, voting on chains rather than individual blocks. Once more than two-thirds of validators have voted for a block, that block and all of its ancestors are final. One round can finalise many blocks at once.

Safety and liveness

Safety is always preferred over liveness. A final record is never reversed. Applications that need certainty wait for finality; applications that need speed use the Platform directly and receive evidence shortly after.

Misbehaviour evidence

Two forms of misbehaviour are cryptographically provable: a validator producing two different blocks in the same slot, and a validator casting conflicting finality votes in the same round. Any node that observes such conflicting signed messages can submit them as evidence. Evidence is recorded on the Ledger and triggers a governance process to pause or remove the validator. Because there is no stake to confiscate, consequences are institutional: suspension, removal and the contractual terms of consortium membership.

Validator lifecycle

Why not proof of stake or proof of work

Proof of work spends energy to decide who writes blocks, and proof of stake requires a valuable token that validators lock as collateral. Both solve a problem the consortium does not have: choosing honest writers among anonymous participants. Our validators are known institutions admitted by governance and bound by agreements. Authority-based production with Byzantine fault tolerant finality gives fast, deterministic confirmation without a currency.

Runtime, transactions and upgrades

Deterministic runtime

All ledger logic runs in a deterministic WebAssembly runtime, so every node computes identical results regardless of hardware or operating system. The runtime is itself stored in the Ledger's state. Nodes always execute the runtime version recorded on-chain, which prevents disagreements about which rules apply.

Transactions without a currency

The Ledger has no native token and charges no transaction fees. Fees on public chains exist mainly to prevent spam and allocate scarce block space. The Ledger achieves the same with accountability and measurement:

Runtime modules

Module terms are deliberately generic, so systems other than the Platform can use the Ledger for their own records.

Upgrades without forks

Data retention

Archive nodes keep every block and every historical state, so any record can be proven decades later. Other nodes may prune old state to save space while still verifying new blocks. Because the Ledger stores only compact proofs, long-term storage requirements stay modest compared with storing documents themselves.

Records and proofs

The Ledger stores four kinds of evidence. Each is designed to be small, free of personal data, and verifiable by third parties.

Anchors

Writing every event to a ledger would be slow and would put data where it cannot be erased. A service instead collects a batch of events, computes a Merkle tree of their hashes, signs the root and anchors only that root. Each event keeps a short proof linking it to the anchored root.

Verifying a record

1. Hash the record with the algorithm named in its anchor.
2. Combine the hash with the sibling hashes in its Merkle proof to compute a root.
3. Fetch the anchor from a finalised Ledger block using a state proof.
4. Check that the computed root equals the anchored root.
5. Check both signatures on the anchor against the service's registered keys.
6. Check that the anchor's sequence and previous-anchor links are unbroken.

If every check passes, the record existed in exactly this form no later than the block's finality time. The open verification tool performs these steps without any access to the Platform.

Anchoring windows

Each stream anchors on a fixed window, chosen per stream. Shorter windows give fresher evidence; longer windows use less block space. A payroll stream may anchor every few minutes, while a high-volume access log may anchor less often. Streams also anchor immediately when a batch reaches its size limit. Very recent events that have not yet been anchored are marked as pending in every interface.

Deployment manifests

Each time an application is deployed, a manifest records the digest of the exact software artifact, its version, and a hash describing where it runs. An auditor can later prove which software version was serving at a given time, which matters when a system's behaviour is questioned.

Usage receipts

Metering services aggregate usage per customer per day, build a Merkle tree of the daily totals, and anchor its root as a receipt batch. Each invoice line links to its receipt proof, so customers can confirm that billed usage was not altered after the fact. Infrastructure contributors receive the same proofs for their earnings.

Access grants

When a person or system is granted access to a protected resource, a grant record stores a salted hash of the subject, a hash of the resource, the scope and the expiry. Revocations are recorded the same way. This proves who had permission at any moment without revealing identities to anyone who lacks the salt.

Corrections

Final records are never edited. A correction is a new record that references the one it supersedes. The complete history, including the fact that a correction was made, remains verifiable.

Cryptography

The Ledger uses only standardised, publicly analysed algorithms from well-reviewed implementations. We do not design our own ciphers or hash functions; custom cryptography is one of the most common causes of security failures.

Algorithm roles

Why hybrid signatures

ML-DSA and ML-KEM are standardised by NIST as FIPS 204 and FIPS 203. They resist known quantum attacks, but they are newer than classical schemes. Combining them with well-established elliptic-curve algorithms means a record stays secure if either family is weakened. The cost is larger signatures, roughly 3.3 kilobytes instead of 64 bytes. That is acceptable because the Ledger signs compact batch roots rather than individual events.

Hybrid signature format

A hybrid signature is valid only if both component signatures verify. Messages include a domain separation label that names the record type and network, so a signature for one purpose or network cannot be replayed for another.

Key hierarchy

• Storage. Root keys stay offline in hardware security modules. Operational keys live in hardware-backed secret stores.
• Rotation. Keys rotate on a schedule and immediately after any suspected exposure. New keys are registered on-chain before old ones retire.
• Revocation. Revoked keys are recorded on the Ledger with the block at which revocation took effect. Records signed before revocation remain valid; records signed after are rejected.
• Randomness. Keys and nonces are generated only from operating-system cryptographic random sources.

Harvest now, forge later

Records created today may be challenged decades from now, when large quantum computers may exist. Hybrid signatures ensure that evidence anchored today remains unforgeable over the long retention periods typical of government records. Hybrid key establishment protects confidential traffic that an adversary might record today and try to decrypt later.

Cryptographic agility

Every signature and hash on the Ledger carries an algorithm identifier, and accounts rotate keys through the post-quantum keys module. Validator consensus keys will migrate to post-quantum schemes once implementations suitable for consensus are mature and independently audited. Because the runtime is upgradeable through governance, such migrations do not require a new chain. Previously anchored records can be re-attested under new algorithms if an existing algorithm is ever weakened.

Governance

Governance is explicit, recorded and member-driven. Every change to who participates or how the Ledger behaves passes through a proposal and a vote.

Proposal lifecycle

Consortium charter

Governance on the Ledger is backed by a legal consortium charter covering membership obligations, validator operating standards, confidentiality, dispute resolution and exit terms. The charter's hash is anchored on the Ledger, and amendments follow the same proposal process.

AI-assisted, human-decided

Operating a national ledger produces large volumes of telemetry: validator health, network latency, usage patterns and security events. An AI-native security suite analyses this data to detect anomalies such as a failing validator, a node inflating usage reports or coordinated misbehaviour. Findings are reviewed by analysts and submitted as proposals with evidence and an explanation. Members vote, and only then is any action taken.

This keeps consensus deterministic and predictable, which is essential for safety, while still benefiting from continuous intelligent monitoring. Every recommendation, its reasoning and the resulting vote are recorded, so decisions can be explained and defended.

The Platform

The Platform gives developers and institutions the full set of services a modern application needs, from one account, on infrastructure located in India.

Services

Account model

Organisation roles include Owner, Administrator, Developer, Billing and Auditor. The Auditor role is read-only and can download Ledger proofs for any record in the organisation, which is what audit and vigilance teams need.

Control plane and data plane

The Platform is split into a control plane, which handles accounts, configuration, scheduling, metering and billing, and a data plane, which runs applications, databases, storage and edge services. If the control plane is unavailable, running applications keep serving; only changes pause. Data plane services are replicated across nodes and cities, so losing one node or one location reduces capacity rather than availability.

Any language, strongly isolated

Developers push source code; the Platform detects the language and framework, builds a signed image and runs it. Each tenant's workloads run inside lightweight virtual machines rather than shared-kernel containers, so one customer's code cannot reach another's. Network policies deny traffic between tenants by default, and every image is scanned for known vulnerabilities before it runs.

Deployment lifecycle

Developer experience

platform login
platform deploy                      # build and run the current directory
platform db create orders --engine relational
platform bucket create invoices
platform domain add portal.example.in
platform usage --month 2026-11
platform proof verify --record rec_8f2c...   # check any record against the Ledger

The same actions are available through a web console and a REST API. From a developer's point of view, the application, its database and its files live together in one project. The developer never writes to the Ledger directly; evidence is produced automatically.

Resilience and recovery

• Databases replicate synchronously within a city and asynchronously to a second city.
• Encrypted backups are stored in a different city from the primary data, and restore procedures are tested on a schedule.
• Recovery point and recovery time objectives are published per service after they have been measured in drills.
• Customers can export all of their data and evidence proofs at any time, in open formats.

Infrastructure trust tiers

Editions

Edge, DNS and delivery

Edge network

Edge locations in multiple Indian cities terminate HTTPS, inspect traffic with the web application firewall, serve cached content and forward dynamic requests to applications. Users are directed to a nearby healthy location through geographic DNS, and later through anycast routing as the network grows.

Customer domains

The Platform hosts DNS but does not sell domain names. Customers keep domains with their existing registrar.

Community content delivery

A server that presents a website's HTTPS certificate needs that certificate's private key, and keys must never sit on devices we do not control. Community nodes therefore never serve customer domains. They serve only public static files, such as images, video segments and scripts, from a separate delivery address where every file is named by its cryptographic hash. The browser or client checks each file's hash, so a malicious node cannot substitute altered content without detection. Contributors earn from delivery without ever holding secrets.

Denial-of-service resilience

Traffic is spread across edge locations in several cities, with rate limiting and firewall rules applied at the edge. Large volumetric attacks are absorbed upstream through scrubbing capacity arranged with data-centre and network partners, before they reach Platform infrastructure.

GPU marketplace

AI workloads need GPUs, and GPU capacity is scarce and expensive. The marketplace connects customers with verified GPU operators, and bills in a unit that measures work rather than time.

The GPU Unit

Hourly rental charges customers for idle time and treats very different GPUs as equivalent. The Platform bills in GPU Units (GU).

For AI inference, the Platform also offers per-token pricing. Each response can carry a receipt committing to the model, input and output hashes, which supports trusted inference for regulated uses.

Scheduling

• Customers choose a GPU class or a price and latency preference; the scheduler selects a matching operator.
• Jobs with government or confidential data run only on core-tier GPUs.
• Each job runs in an isolated environment with no access to other jobs on the same machine.
• Jobs have a GU budget; the scheduler stops a job that exceeds it unless the customer raises the limit.

Verifying untrusted operators

Operator onboarding

1. Organisation or individual verification.
2. Hardware registration with GPU model and capacity, recorded in the Ledger registry.
3. Benchmark run to confirm the declared performance class.
4. Probation period with a higher share of calibration jobs.
5. Full participation, with earnings paid in rupees and backed by receipt proofs.

How the layers connect

The Platform and the Ledger are connected through a single, narrow interface. This keeps each independently operable, secure and replaceable.

Interface principles

• Single gateway. Only the Ledger Gateway holds Ledger credentials. No other Platform service can write to the Ledger.
• Hashes only. The interface accepts digests, pseudonymous identifiers and receipts. It has no field that can carry personal data or file contents.
• At-least-once with idempotency. Evidence is written to an outbox inside each service's own database transaction. The gateway may retry, and idempotency keys ensure each record is anchored exactly once on the Ledger.
• Versioned contract. The interface is versioned independently of both systems, so each can evolve on its own schedule.
• Independent verification. An open verification tool reads the Ledger directly, so trust in records never depends on trust in the Platform.

Gateway operations

Failure modes

Economic model

The Ledger and the Platform are sustained by service revenue, not by a digital currency. There is no token sale, no token appreciation and no staking yield.

Why there is no token

1. Public procurement. Institutions buying infrastructure cannot take on crypto-asset exposure.
2. Predictable costs. Rupee prices do not swing with token markets.
3. Aligned incentives. Revenue comes from customers using services, not from new buyers of a token.
4. Regulatory clarity. Services billed in rupees fit existing tax, accounting and consumer protection frameworks.
5. Security without collateral. Validators are accountable institutions, so there is no need for locked value.

Usage-based billing in rupees

Customers pay as they go or commit to annual usage. Prepaid credits are usable only for Platform services and are not transferable. Invoices include applicable GST.

Verifiable invoices

Revenue flows

Pricing principles

• Every unit price is published. There are no hidden meters.
• Prices are set from measured operating costs, not from speculation about future adoption.
• Customers can set budgets and hard limits on every project.
• Government commitments can be procured through standard contracting.

Security model

We assume some participants will fail, some will be compromised, and a few may act maliciously. Security is layered so that no single failure exposes records or data.

Threats and mitigations

Secure development

• Memory-safe systems languages for ledger, gateway and edge components.
• Mandatory independent code review, with two reviewers for consensus, cryptography and billing code.
• Continuous fuzz testing of parsers and runtime modules.
• Automated checks that reject placeholder or simulated logic in production code.
• Multi-node fault and chaos testing before every release.
• Independent third-party audits and penetration tests before production, with published summaries.
• A responsible disclosure programme for security researchers at launch.

Compliance and privacy

The architecture is designed to support the obligations Indian institutions carry. Formal certifications and empanelments are pursued separately and are not implied by this design.

Why personal data never goes on the Ledger

A ledger is designed so that final data cannot be changed or deleted. Personal data law gives individuals the right to have their data corrected and erased. These properties cannot coexist in the same record. The Ledger therefore stores only salted hashes and proofs. If underlying data is lawfully erased, its proof no longer links to anything readable, while the integrity of every other record remains intact.

Data lifecycle

Use cases

Scenario: a disputed salary change

A municipal body runs its payroll application on the Sovereign edition. Every salary change is written to the payroll database and, in the same transaction, its hash is added to the payroll evidence stream, which anchors every few minutes. Two years later an employee alleges that their pay grade was altered after an approval meeting.

1. The auditor exports the salary record, its approval record and their proofs from the Auditor role.
2. The verification tool confirms both records were anchored within minutes of the approval, in exactly their current form.
3. The stream's sequence numbers show no missing batches in that period.
4. Access grant records show which officials held edit permission at the time.

The dispute is resolved on evidence rather than on the word of the system's administrators.

Scenario: verifying a certificate

A state board issues certificates through an application on the Platform. Each certificate's hash is anchored when issued, and revocations are anchored when they occur. An employer scans a QR code on a certificate; the verification service recomputes the hash, checks it against the Ledger, and confirms that no revocation exists. No personal data is published, and forged certificates fail immediately.

Scenario: a procurement audit

A department runs tenders on a procurement application. Bid submissions, bid opening, evaluation scores and award decisions each produce anchored records. Because bids are anchored at submission, no one can later claim a bid arrived before the deadline if it did not, and no evaluation score can be quietly changed after bids are opened.

Limitations and open research

No system removes every risk. We state the limits of this design plainly, so that institutions can rely on it for what it actually guarantees.

What the design does not guarantee

• Truth of content. Anchoring proves a record has not changed since it was anchored. It does not prove the record was correct when it was created.
• Recency before anchoring. Events inside the current anchoring window are not yet provable. Windows are short, but not zero.
• Availability of off-ledger data. The Ledger proves a record existed; it cannot restore the record if every copy is lost. Backups remain essential.
• Collusion beyond the threshold. If one-third or more of validators collude, finality safety cannot be guaranteed. Institutional diversity, legal agreements and misbehaviour evidence reduce this risk but cannot remove it.
• Trust in admission. The consortium is permissioned, so the quality of membership verification matters.
• Consensus keys. Validator consensus keys use classical cryptography until the planned post-quantum migration is complete. Records themselves already carry hybrid signatures.
• Probabilistic metering checks. Calibration jobs detect sustained over-reporting with high confidence, but not every individual report.
• Performance. Throughput and latency are not yet measured on production-scale networks.

Open research directions

Status and roadmap

The Ledger and the Platform are in active development, with engineering under way since September 2026. Milestones below are planned and may change as development and pilots progress.

Performance reporting

This paper contains no throughput or latency claims. Figures will be published only after they are measured on multi-city networks, together with the hardware, network conditions, workload and method used, so that anyone can reproduce them.

Conclusion and FAQ

Institutions should not have to choose between fast, affordable digital services and records they can prove. By separating serving from recording, the Ledger and the Platform aim to give Indian institutions both: a complete platform for running applications in India, and an independent consortium ledger that makes what happens on it verifiable, without a digital currency and without placing personal data where it cannot be erased.

We invite government bodies, public sector undertakings, academic institutions and enterprises to take part as pilot customers, infrastructure partners and consortium members.

Frequently asked questions

Is there a token, coin or presale?

No. There is nothing to buy and nothing will be sold. Anyone offering a token in connection with this paper is not us.

Is my data stored on a blockchain?

No. Your data stays in Platform databases and storage in India. The Ledger stores only hashes and proofs that contain no personal data.

Who runs the validators?

Verified member institutions admitted through governance, operating in separate locations. The Platform operator has no special control over the Ledger.

Can anyone change a record after it is final?

No. Corrections are added as new records that reference the original, and both remain visible and verifiable.

Why not use a public blockchain?

Public blockchains require digital currencies, rely on anonymous validators and put anything written on them beyond the reach of data-protection rights. None of that suits public institutions.

What happens if the Platform operator stops operating?

The Ledger belongs to its consortium and continues independently. Customers can export their data and proofs at any time, and the verification tool is open.

Can I build on it before launch?

Early access for developers and pilot institutions will open in stages ahead of the public reveal.

Glossary and references

Glossary

References

1. L. Lamport, R. Shostak and M. Pease. The Byzantine Generals Problem. ACM Transactions on Programming Languages and Systems, 1982.
2. M. Castro and B. Liskov. Practical Byzantine Fault Tolerance. Proceedings of OSDI, 1999.
3. R. C. Merkle. A Digital Signature Based on a Conventional Encryption Function. Advances in Cryptology, CRYPTO 1987.
4. B. Laurie, A. Langley and E. Kasper. Certificate Transparency. RFC 6962, IETF, 2013.
5. National Institute of Standards and Technology. FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard. 2024.
6. National Institute of Standards and Technology. FIPS 204: Module-Lattice-Based Digital Signature Standard. 2024.
7. National Institute of Standards and Technology. FIPS 180-4: Secure Hash Standard, and FIPS 202: SHA-3 Standard.
8. S. Josefsson and I. Liusvaara. Edwards-Curve Digital Signature Algorithm (EdDSA). RFC 8032, IETF, 2017.
9. A. Langley, M. Hamburg and S. Turner. Elliptic Curves for Security. RFC 7748, IETF, 2016.
10. Government of India. The Digital Personal Data Protection Act, 2023.
11. Indian Computer Emergency Response Team. Directions under sub-section (6) of section 70B of the Information Technology Act, 2000. 28 April 2022.
12. MITRE Corporation. ATT&CK knowledge base of adversary tactics and techniques.

Preview white paper, version 1.1, September 2026. Published anonymously by the team building these systems; our identity will be revealed at launch. This paper describes systems under development and contains forward-looking statements about planned features and timelines, which may change. There is no token, no coin, no presale and nothing to buy. Anyone offering a token or asking for payment in connection with this paper is not us. Nothing in this paper is an offer of any security, digital asset or investment, and it is not legal advice.