A token settles where the ledger is sovereign

The rail did not rent its ledger.

The Operator's Map is a series in five chapters for the people who have to run AI rather than admire it, each chapter at its own altitude. This chapter, The Sovereign Stack, teaches the open-source stack: software you can read rather than rent, layer by layer, and what each layer obliges you to check. Its usual spine is global; by declared exception this one edition is built from the Indian record alone, because that is where the one tokenization record of the week with named issuers, dated settlements and a regulator's own ownership statement was published, and the multi-region spine resumes with the next episode. Global Fintech Fest 2026 ran on three pillars, and the Reserve Bank's Governor named them from the record in his own order: “the three technological pillars around which this year’s programme is built - AI, quantum technology and tokenisation”. This chapter takes tokenization at the altitude of the stack: not whether a bond can be a token (three issuers showed it can), but which layer settled it and who owns that layer. The other four chapters carry the same week at their own altitudes; the close links all four.

Why this reaches your desk. Somewhere in your organization a deck now says "tokenization" on a slide, and the slide has a box labeled "ledger" with no owner written on it. The week's record gives you a way to fill that box in, because on 10 September 2026 two regulators published, in their own documents, a detailed account of one working system: SEBI's press release 56/2026 states in one sentence where the ledger lives, “The ledger is owned by the depositories.”, and its twenty-four-question FAQ states who runs the nodes, who holds the keys, which record is authoritative, whose money settles the funds leg and under which statute the whole thing sits. The Reserve Bank's Governor, on the same day, placed the step inside a rail his institution built: “Today, we take the next step in our tokenisation journey as we unveil the tokenisation of corporate bonds with settlement through CBDC as a joint initiative with SEBI and with the involvement of other stakeholders.” Three issuers used it inside three days for ₹1,025 crore. What the record does not say, on any of the twelve Indian primary documents fetched for this chapter, is what software the ledger runs, under what license, maintained by whom. One layer of the map is blank on every page. This chapter is about the map, and about that blank.

Terms that matter this edition

First, the record: three issuers, three days, one blank row

I lead with the record because the record is better than the coverage of it. Every figure below is on a regulator's or an issuer's own page.

SEBI's press release 56/2026 of 10 September 2026 carries the ledger of what happened, in the regulator's words: “Three companies have issued tokenised bonds so far, aggregating ₹1,025 crore:” followed by three lines. “REC Limited, a public sector NBFC, was the first issuer, on September 7, 2026, raising ₹500 crore from 18 investors.” “L&T Limited was the second issuer, on September 9, 2026, raising ₹500 crore from 4 investors.” “IIFL, a private NBFC, was the third issuer, on September 9, 2026, raising ₹25 crore from 1 investor.” Add the three: 500 plus 500 plus 25 is 1,025, and 18 plus 4 plus 1 is 23 investors, a number the release does not print and I derive so it can be checked. The release's status line: “The pilot is being taken forward in phases. Issuances under the first phase are ongoing.”

Two of the three issuers published their own record, and a firm's own numbers are the ones printed here. REC's release, dated 7 September 2026, gives the structure SEBI's does not: “The size of pilot issue was ₹500 Crore (base issue of ₹100 Crore with a green shoe option of ₹400 Crore) and bidding was undertaken at EBP platform of National Stock Exchange of India Limited (NSE).” It reports a book of “₹796 Crore (oversubscribed by ~8x)”, and the multiple is against the ₹100 crore base, not the ₹500 crore accepted, so I write "about eight times the base issue" and nothing stronger. Coupon 7.30 percent a year, tenor one year and nine months, and the sentence that matters most for settlement: “The tokenised mode enabled faster settlement, with pay-in, allotment and listing of the bonds on same day.” Same day is the issuer's phrase, and the chapter's. L&T's release, filed with the exchanges on 9 September, states ₹500 crore with “a 3-year tenure” and one sentence about the plumbing: “The bond issuance and related processes leverage DLT-based infrastructure, with settlement of funds facilitated through a Central Bank Digital Currency (CBDC) wallet.” L&T states no coupon and no investor count; the four investors are SEBI's figure. The third issuer's own record is an allotment intimation filed with BSE the same day: 2,500 debentures of ₹1,00,000 each, which is ₹25 crore, two years, 9.10 percent a year, maturing 8 September 2028, and issued, in the filing's own phrase, “in dematerialised token form”. That filing never says pilot, sandbox, CBDC or DLT. The pilot framing is SEBI's, and I attribute it to SEBI.

The depository's own record adds a detail the releases do not. CDSL's corporate-bond trade repository, pulled for the trade dates of 8 and 10 September 2026, lists the three issues as ordinary rows beside every other private placement of the week: INE020B08GK9 for REC, issued 7 September, maturing 31 May 2028; INE018A08BO8 for L&T, issued 9 September, maturing 9 September 2029; INE530B07682 for IIFL, issued 9 September, maturing 8 September 2028. The detail page for the L&T bond shows a registrar and two AAA ratings, and a coupon of 7.4, which appears nowhere in L&T's own release and which the same repository field prints as 0 for REC, so that figure carries the depository's attribution wherever it is printed and never stands as a bare number. Nothing on any of those pages says "tokenised" in the filing's spelling, or Demat 2.0, CBDC or DLT. SEBI's FAQ says the ISIN “is flagged as a pilot/tokenised ISIN”; whatever that flag is, it is not on the public repository. The plumbing is ordinary enough that the depository's own public record cannot tell the token from the rest of the week's bonds. That is a compliment to the plumbing, and the first hint of the blank row.

Now the part of the record that makes this a Sovereign Stack chapter rather than a markets note. SEBI's FAQ is unusually precise about who does what. Question 20: “The infrastructure is being developed and operated by the Market Infrastructure Institutions (MIIs), with technology and implementation support from NPCI.” And: “The distributed ledger is private and permissioned. Initially, nodes will be operated by the depositories and stock exchanges, with the possibility of extending controlled access to other regulated entities as the pilot progresses.” The SEBI Chairman's address names the operators: the bonds were issued “under Demat 2.0, led by depositories - CDSL and NSDL, and supported by BSE, MSEI and NSE.” Question 7 says who holds the keys; question 16, which record is authoritative and under which Act.

Not one of those documents says what the nodes run. I searched the twelve Indian primaries fetched for this chapter, on 11 September 2026, for the names of the four ledger codebases an operator would recognize, and for the words license, open source and vendor: SEBI's two press releases of 10 September (55/2026 and 56/2026), the FAQ, the Chairman's address, the Governor's addresses of 10 September 2026 and 8 October 2025, the Reserve Bank's digital rupee FAQ in both its February and April 2026 versions, its Annual Report chapters that mention the rail, REC's release, L&T's release, the IIFL filing and the CDSL repository rows. Zero hits, on every page, for the software, its license or its maintainer. The absence closes its window on 11 September 2026 and names its indexes because an absence claim that does neither is an opinion.

I want to be exact about what the absence is and is not. It is not a criticism of anybody. A pilot under a regulatory sandbox, whose FAQ states that its purpose is “to test the architecture and operational arrangements before a broader regulatory framework is considered”, has no duty to publish a bill of materials on day one. The absence is a property of the public record as of this date, and it matters because every other layer of the same stack is answered in public, in writing, by the institutions that own it. For an operator, that is the row that matters next year, because it is the row that decides whether the word "owned" in the ownership column survives a vendor's change of terms.

The map: a token is only as sovereign as the layer that settles it

The previous chapter of this lane established that sovereignty is a stack property, on a serving stack where the weights you pin run inside software you did not pin. I am going to apply the same method to a settlement stack, the way I do it for a client's inference platform: one layer at a time, one mark per layer, one document per mark. The marks are four. Owned means an institution you can name, under a statute or a contract you can read, holds the layer and can be held to it. Open means the layer's software is published under a license that lets you read it, run it and change it without asking, so ownership is at least possible. Rented means somebody else holds the layer and you hold a right to use it, for as long as the terms last. Not disclosed means the public record does not say, and I print that in copper on the figures rather than guessing. The rule that makes the map honest: "supported by" is not "owned by", and a blank is a finding.

Layer one, the settlement asset: the money that pays

Start at the bottom, with what actually pays, because every other layer is negotiable and this one is not. In the pilot the funds leg settles in wholesale central bank digital currency. SEBI's FAQ, question 9: “CBDC provides digital money (e₹) for the funds leg of the transaction.” The Reserve Bank's digital rupee FAQ, updated 29 April 2026, says why that choice matters in the central bank's own words: “Settlement in central bank money is expected to reduce transaction costs by pre-empting the need for settlement guarantee infrastructure or for collateral to mitigate settlement risk and benefitting from the programmability and smart contracts functionalities of e₹-W.” The same rationale, almost word for word, is in the 2022 release that started the wholesale pilot on 1 November 2022, 1,409 days before the bond announcement, with government securities as the use case and nine named banks. As of the April 2026 FAQ there are sixteen participants and three live wholesale use cases, the third being tokenized certificates of deposit. Corporate bonds are not on that list; the bond leg is SEBI's ledger settled through the Reserve Bank's rail.

The most useful sentence about this layer is in the least-read place, the accounts chapter of the Reserve Bank's Annual Report 2025-26. Paragraph XII.4.8 records that the value of wholesale CBDC in circulation “stood at Nil as on March 31, 2026 and as on March 31, 2025”, and explains why: “Owing to the auto-redemption feature exercised by the participating banks and non-banks, balances in e₹-W are redeemed back to the underlying current account at the end of the day and, therefore, the balances need not be construed to reflect the transaction volumes and values.” That is the settlement asset described by its issuer. It exists intraday, does its work, and returns to reserves at the close. Nobody has to trust an issuer to make it good because the issuer is the central bank and the asset is a liability on its own balance sheet. Mark: owned, central bank.

Layer two, the rail: who built the road

The rail is the Unified Markets Interface. The Governor announced it on 8 October 2025, at the previous festival, with the ownership verb in the sentence: “I am happy to announce that the Reserve Bank has conceptualised the Unified Markets Interface (UMI), as a next-generation financial market infrastructure. UMI will have the capability to tokenise financial assets and settlements using wholesale CBDC.” That was 337 days before the bond step. The Annual Report's first chapter, published 29 May 2026, moves the verb from "conceptualised" to "developed": “On asset tokenisation, the Reserve Bank developed the Unified Markets Interface (UMI), a multi-layer platform to facilitate tokenisation of financial assets while leveraging wholesale CBDC to enhance settlement efficiencies. A pilot on tokenisation of certificates of deposit (CDs) was initiated on UMI.” The supervision chapter adds that “certificates of deposit (CDs) were the first instrument to be issued in tokenised form and settled through wholesale CBDC.” Three sentences across three chapters, a published paragraph rather than an operating document; no rulebook was published, so none is quoted. Mark: owned, central bank, on the strength of the issuer's own report.

Layer three, the securities ledger: who owns the book

This is the layer the chapter's title is about, and it is the layer where the Indian record is at its most direct. SEBI's press release: “The bond is created as a digital token on a distributed ledger -- a shared electronic record maintained simultaneously by market infrastructure institutions using Distributed Ledger Technology (DLT). The ledger is owned by the depositories.” The FAQ's first answer: the bond “is issued as a native digital token on a private, permissioned DLT network owned by the Depositories. The token is the corporate bond.” Two things are stated there that are often blurred. The ledger is private and permissioned: not a public chain, not an anonymous network. And it is owned by two statutory institutions, which the FAQ's sixteenth answer ties to the law: “The depository remains the authoritative record of beneficial ownership.” And: “The DLT ledger is the form in which the record is maintained for purposes of the pilot; it does not displace the depository's statutory role under the Depositories Act, 1996.” So the depository, under a 1996 Act, is the authority, and the ledger is the form its record takes for now. The exchanges run nodes. The payments operator, NPCI, gave “technology and implementation support”, which the FAQ says; REC's release credits NPCI among the participating market infrastructure institutions. Support is not ownership, and the map does not upgrade it. Mark: owned, by statutory market infrastructure institutions.

One caveat: the depositories' own statements on Demat 2.0 were not found on either depository's website on 11 September 2026; the row rests on the regulator's documents, the Chairman's address and CDSL's repository record. If a depository publishes its own words, the evidence upgrades and the mark does not change.

Layer four, the ledger software: the blank

Covered above, and marked not disclosed. I return to it in the fourth move, where "open" is the only route to "owned".

Layer five, identity and the account: who the holder is

The FAQ's sixth answer made the pilot possible in three days, and gets its own move below. For the map: the Demat 2.0 account “is an extension of the investor's existing demat account and is not a separate demat account”, and “The investor's existing KYC is used.” Mark: owned, and pre-existing.

Layer six, key custody: who can sign

A token moves when a private key signs for it, so whoever holds the key holds the layer. Question 7: “The depositories will hold and manage the private keys on behalf of investors.” And: “investors do not need to independently manage cryptographic keys or acquire specialised DLT infrastructure.” That design decision has a cost, which I come to below. Mark: owned, by the depositories.

Layer seven, the rulebook: what the token is allowed to do

On a serving stack this is the policy engine; on a settlement stack it is the smart-contract terms plus the law above them. Question 3: the bond's key terms, “such as coupon rate, payment dates, day-count convention and redemption terms – are encoded into the token through a smart contract.” Question 2: the token “remains a security under the Securities Contracts (Regulation) Act, 1956 and continues to be governed by the applicable SEBI regulatory framework.” Question 17 carries the control that a demo never has: “A freeze, attachment or direction applicable to the demat account or the relevant ISIN/token holding will apply to the linked tokenised holding as well.” Question 23 states the legal basis of the whole exercise: “The pilot is being conducted under SEBI's Regulatory Sandbox. Any specific relaxation required for the pilot would be provided within the sandbox framework and for a defined scope and period.” Mark: owned, by statute and sandbox.

Layer eight, the venues and the record of evidence

No new market was built. Question 4: issuers “continue to use the existing Electronic Bidding Platform (EBP) of stock exchanges for issuance.” Question 11: “The pilot does not propose a separate trading venue or segregated market segment.” And the observability row, the one an examiner reads first: question 21 lists among the pilot's objectives “cyber security, scalability, resilience and auditability” and “implications for clearing, settlement finality and the roles of MIIs.” There is no model layer on this stack. The week's AI systems on the payments rail are the Ship AI chapter's subject, and I note their absence so that a reader porting this map onto an agentic platform knows which two rows to add: the model, and whoever serves it. Mark: owned, existing institutions.

The same map, four other systems

The title says a token settles where the ledger is sovereign, and a claim like that is only worth making against systems where it is not. SEBI's own release supplies the comparison set, in its own words: “Tokenisation pilots and commercial launches have taken place across the globe. Project Helvetia III in Switzerland, Project Evergreen in Hong Kong, treasury bonds of US, bonds from BlackRock, JP Morgan, AIIB, etc are some of the examples. In these cases, tokenisation has largely been undertaken by individual issuers on separate platforms.” I fetched the self-published record for four of them and drew the same map, reporting roles rather than firms where a central bank's page names a vendor.

Switzerland, the Helvetia pilot. A sovereign settlement asset on a privately operated venue. The Swiss National Bank's own project page states: “In the context of the Helvetia pilot, the SNB is issuing wCBDC on the regulated DLT-based SIX Digital Asset Platform.” Its questions and answers state what the asset legally is, “a representation of sight deposits held at the SNB in a technically different form”, and where it lives: “the SNB issues wholesale CBDC on the SIX Digital Asset Platform, the regulated platform for digital assets operated by SIX Group, and defines the conditions for the settlement of wholesale CBDC transactions (e.g. settlement hours and use cases).” So the money is the central bank's and the venue is a private, regulated infrastructure group's. The pilot “will continue until at least June 2028”. The BIS project page for the same work is stale on that point, giving an end date of 30 June 2024, so I cite the SNB for status. The SNB's pages do not name the platform's software or say who holds participants' keys; those cells print "not disclosed on the SNB's pages", which is a different thing from "not fetched".

The BIS's Project Agorá. A shared platform, tokenized central bank reserves and tokenized deposits, technology from a vendor. The project page describes real-value testing in July 2026: “Twenty-eight financial institutions and central banks across Asia, Europe and North America completed transactions in a selection of currencies totalling approximately CHF 800,000. The programme covered 17 transaction scenarios, with values ranging from CHF 9,000 to CHF 125,000 or local currency equivalents.” Average time from initiation to settlement, “approximately 80 seconds”. The layer ownership is stated on the page: “Central banks used their Project Agorá suites to issue and redeem tokenised reserves and to monitor settlement on the jurisdictional ledger”, while institutions issued tokenized deposits “on the unifying ledger”. And the environment was run by a named operational facilitator under a runbook, with a named firm as “the technology provider”. Agorá's own page says it “has delivered a prototype”, not a product. On the map: settlement asset public and private-regulated, ledger shared with partitions by jurisdiction, ledger software vendor-supplied per the BIS's record.

The United States, a payment stablecoin under Public Law 119-27. A private settlement asset by statute, on a ledger the statute does not specify. The enacted text, approved 18 July 2025, defines the instrument as a digital asset “used as a means of payment or settlement” whose issuer “is obligated to convert, redeem, or repurchase for a fixed amount of monetary value”, and excludes from the definition anything that “is a national currency” or is a deposit, “including a deposit recorded using distributed ledger technology”. Section 4(e)(1) is the sentence for the settlement-asset row: “Payment stablecoins shall not be backed by the full faith and credit of the United States, guaranteed by the United States Government, subject to deposit insurance by the Federal Deposit Insurance Corporation, or subject to share insurance by the National Credit Union Administration.” Section 12 leaves the ledger open, naming “accepted communications protocols and blockchains, permissioned or public.” The statute's effective date is the earlier of eighteen months after enactment, which is 18 January 2027, or 120 days after the primary federal regulators issue final implementing rules. On 11 September 2026 the Federal Register's own index shows no final implementing rule and eighteen proposed ones; the Treasury's proposed rule on issuance, offer and sale is open for comment “on or before October 19, 2026”, the date the Register's own record for it carries, which is 29 days after the 20 September 2026 date by which a final rule would have to appear to pull the effective date earlier. So the private-asset column of the map is still being specified by rulemaking while the central-bank-asset column has settled ₹1,025 crore. That is not a judgment on either; it is two clocks read on the same day.

A tokenized treasury fund on a permissionless chain. The launch release of 20 March 2024, read at the co-publisher's investor site, is the cleanest example of every layer rented from a different private party, and I cite only what the release states. The fund is “issued on a public blockchain”; it “seeks to offer a stable value of $1 per token”; a bank “will serve as the custodian of the Fund’s assets and its administrator”; a tokenization platform “will act as a transfer agent and tokenization platform, managing the tokenized shares”; access is under Rule 506(c) with a $5 million minimum; and “Investors can transfer their tokens 24/7/365 to other pre-approved investors.” Settlement asset private. Ledger permissionless and open, owned by no operator. Ownership record with a private transfer agent. Custody of the fund's assets with a private bank; who holds the keys that move the tokens, the release does not say. Identity through a private accreditation gate. Nothing sovereign on any row, and the release does not claim otherwise; it is a product, and it says what it is.

Read the five columns as an operator and the pattern is the argument. Where the settlement asset is sovereign and the ledger is sovereign, the funds leg and the securities leg can be atomic without a third party guaranteeing either, which is exactly what the Reserve Bank's FAQ says central bank money is for and what the BIS's 2023 blueprint chapter says the unified ledger is for: “the settlement finality that comes from central bank money residing in the same venue as other claims.” Where the asset is sovereign and the venue is rented, as in Switzerland, the operator has added one dependency, the platform operator, that the depository-owned design does not carry, and should say so in its own map. Where the asset is private, as under the US statute, the settlement token is somebody's promise, defined by law as not the government's, and the ledger question has not been answered by anybody yet. The Indian pilot is not the sovereign path because it is Indian. It is the sovereign path because two of its layers, the money and the book, are held by institutions whose ownership is stated in public under a statute, which is the property the title names. The rail did not rent its ledger. It also did not tell us what the ledger runs.

The floor beneath the map: tokenization without an identity layer is a demo

The question I ask of every tokenization deck is not about the token. How did the system know who the holder was, and for how long? In India's pilot the answer is: for years, and not because of the pilot.

SEBI's FAQ, question 6, is the sentence that decided the timeline: “The Demat 2.0 account is an extension of the investor's existing demat account and is not a separate demat account.” Then: “The investor's existing KYC is used. Registration takes place through the existing depository interface by linking the eligible demat account with the CBDC wallet and providing the required consent.” The press release says the same in fewer words, “no separate account to open and no fresh KYC”. The issuer needed even less, per question 5: “The issuer does not require a Demat 2.0 account.” Question 8: the CBDC wallet is “opened with the participant's own bank under the RBI's e₹ pilot” and “No separate technology infrastructure or investment is envisaged for the issuer or investor.” The pilot did not build an identity layer. It plugged a token into one that was already there, with the accounts, the checks, the statutory record-keeper and the freeze power all in place before the first bid was placed.

That layer is older than the pilot by a margin the record lets me date. CDSL's issuer page on distributed-ledger covenant monitoring records that a SEBI circular of 13 August 2021 “recommended to develop a platform” for security and covenant monitoring of non-convertible securities by the depositories, applicable to every issue on or after 1 April 2022. That is a different system from the Demat 2.0 ledger; what it shows is that the depositories were running a distributed-ledger record for bond covenants for more than four years before the week's tokens existed. The record layer was not built for the demo. And the CDSL repository rows cited earlier make the same point from the other end: the three pilot bonds sit beside the week's conventional issues, with an ordinary registrar and ordinary ratings on the L&T record. The record layer the token plugged into is the one every other bond used.

The SEBI Chairman's phrase for this, in the published address, is that the project brings together “tokenised securities, digital settlement assets through CBDC and smart-contract functionality, while building on existing market infrastructure and preserving legal certainty around ownership.” Legal certainty around ownership is an identity statement. It means a court, a tax authority or an examiner can find the holder, and question 17 says the finding has teeth: a freeze or attachment on the demat account “will apply to the linked tokenised holding as well.”

Contrast the demo-grade version, which I have watched several teams build, in my own work and in reviews of other people's, over the last three years. It builds the token first, on a chain chosen for the demo, and defers the question of who the holder is to a later sprint. Then the first real question arrives, from compliance or from a counterparty: who is allowed to hold this, who verified them, what happens when a court orders the holding frozen, and who can execute that order against a key the holder controls. The demo has no answer because the floor it needed was never poured. That is what "tokenization without an identity layer is a demo" means. It is a statement about the order of construction.

Two qualifications, because the argument is stronger with them. First, "identity layer" does not have to mean a statutory depository. The tokenized treasury fund above has an identity layer, a private transfer agent and an accredited-investor gate, and it was launched on that basis in March 2024, its later state not fetched; the map marks it private, not absent. Second, the Indian design pays for its certainty with a property the festival's own definition prizes. The organizers define the tokenization pillar, on their site, as “Making every asset - public, private, physical, or digital - programmable, divisible, and instantly transferable on global infrastructure.” A token whose keys are held by the depository and whose interim transfers, before secondary trading is enabled, run through “a peer-to-peer/demat-to-demat transfer” on request, is not instantly transferable on global infrastructure, and it is not meant to be. The pilot traded that property for legal certainty, deliberately, and the map should say so rather than pretend the trade was free.

Filling the blank: open-source ledgers are the only credible alternative to a vendor ledger

Back to the blank row. If the record does not say what the ledger runs, an operator drawing the same map for its own stack has to decide how that row will be filled, and there are exactly two ways: a vendor's platform, or a codebase published under a license that lets the operator read it, run it and change it. I fetched the self-published record of three such codebases on 11 September 2026, and I cite what their own documentation and license files say, nothing more.

Besu describes itself as “an open source Ethereum client developed under the Apache 2.0 license and written in Java. It runs on public and private networks.” Its private-networks page states the relevant mode: “A private (also known as permissioned) network is a network not connected to Ethereum Mainnet or an Ethereum testnet. Private networks typically use a different chain ID and proof of authority (PoA) consensus (QBFT or IBFT 2.0).” And it states, without being asked, the fact that matters most for the ownership map: “Besu doesn't support key management inside the client.” Key custody is a separate layer on every stack, and the software says so of itself; SEBI answered the same question with "the depositories." The license file in the repository is the Apache License, version 2.0.

Fabric calls itself “an open-source enterprise-grade permissioned distributed ledger technology (DLT) platform, designed for use in enterprise contexts”, hosted “under the Linux Foundation, which itself has a long and very successful history of nurturing open-source projects under open governance”. Its explanation of permissioned is the clearest I have read: “the participants are known to each other rather than anonymous and, therefore, fully untrusted”, so the network can use “more traditional crash fault tolerant (CFT) or byzantine fault tolerant (BFT) consensus protocols that do not require costly mining.” Its license is Apache 2.0. And it carries the sentence I will use against my own argument in a moment.

Corda's repository README describes “an open source blockchain project, designed for business from the start”, with a notary infrastructure whose job, in the README's words, is “to validate uniqueness and sequencing of transactions without global broadcast”, which is a different answer to who sequences settlement. Its license is Apache 2.0. The same README says the current architecture lives in a different repository, so I cite it only as an Apache-licensed ledger with a notary model and say nothing about versions.

Against those three, the vendor-ledger class, and the record for it is the BIS's own. Agorá's real-value environment was run with a named firm as “the technology provider” and coordinated by a named operational facilitator using a detailed runbook. That is what a rented ledger layer looks like when it is written down plainly: the central banks own the settlement asset, the participants own their suites, and the software under the shared platform was supplied. The BIS is entitled to that choice. What the choice does to the map is what I am pointing at: the ledger-software row of the Agorá column reads "vendor-supplied," and no amount of ownership on the other rows changes it.

So the move, stated carefully. Open code does not put "owned" in the ownership column. It is the only thing that makes "owned" possible in that column. A vendor's ledger can be excellent, audited, certified and supported, and its row still reads rented, because the terms under which you run it are somebody else's to change. An Apache-2.0 codebase can be read line by line, forked, patched and run on your own machines; that is what the license permits, and it permits it without asking anybody. Whether you then do those things is a separate question, and it is the question the counterargument turns on.

The strongest counterargument, and where it lands

The best objection to this chapter is not that the map is wrong. It is that the map's marks flatter ownership and punish rental, when the operator's real duty is neither. Let me make it as strong as I can.

Open code is not owned operation. Fabric's own documentation says a permissioned network runs “under a governance model that is built off of what trust does exist between participants, such as a legal agreement or framework for handling disputes.” The BIS's blueprint chapter says the operator's role in a tokenized environment is “as a trusted intermediary serving in a governance role as the rule book's curator, rather than as a bookkeeper who records individual transactions on behalf of account holders.” An Apache-licensed ledger run by a vendor under a support contract, with the vendor's engineers holding the deployment and the vendor's runbook defining the rules, is a rented layer wearing open clothes. Marking it "open" on the map tells the reader nothing about who can change it tomorrow.

And a rented layer can be the right layer. Agorá's prototype, technology supplied and operation facilitated, moved real value between twenty-eight institutions across three continents in about eighty seconds without being integrated into anybody's real-time gross settlement system; that is a result, and the vendor is part of why it exists. Switzerland has settled central bank money on a privately operated platform since the end of 2023, and the SNB's own pages now carry a horizon of at least June 2028. The BIS itself warns, in the same chapter I have been quoting, that a unified ledger “does not mean ‘one ledger to rule them all’” and that “multiple ledgers, each with a specific use case, could coexist.” Insisting that every layer be owned is how you end up with a sovereign stack that does nothing, and nothing is not sovereign either. The Reserve Bank's Deputy Governor said something adjacent on 9 September, in his own address: that the emerging concern is institutions coming to depend on a small number of cloud, technology and model providers, so that a common dependency could transmit disruption across many institutions at once. Read one way, that is an argument for owning your layers. Read the other way, it is an argument that an owned open-source layer run by the same three integrators everybody else uses is still a common dependency, and the map cannot see that.

Here is where it lands. The chapter's claim is not that owned beats rented. The claim is that an operator must be able to say, for each layer, which it is, from a document, and that the only mark that survives a vendor's change of terms is one earned by running the code, holding the keys and curating the rulebook yourself. The counterargument is right that "open" on its own is a weak mark, which is why the map has four marks and not two, and why "open" sits between "rented" and "owned" rather than beside "owned." It is also right that a rented layer can be the correct choice; the map does not forbid rental, it forbids not knowing. What the counterargument cannot do is fill the blank row. A rented ledger under a good contract still leaves the software's license, its maintainer and its exit terms in somebody else's hands, and the concentration point above cuts against that harder than it cuts against open code, because a rented layer is a common dependency by construction and an owned open layer is one only by choice. The Indian record makes exactly this distinction on its other rows, each said in its own words. It has not yet said the software's name. When it does, the row gets a mark. Until it does, the row is the reason to read the map at all.

Two artifacts to take to your own stack

Everything above is a worked example. The two files below are the method, with the example filled in and your columns left blank on purpose.

The stack ownership map. A CSV file with one row per layer and eight columns: the layer, what it is in the pilot, who owns it, who runs it, the mark, the evidence with its quote fragment, and two blank columns, who owns it in your stack and what document proves that. The nine seeded rows are the nine rows of the ownership map above, each with its source. The rule is written into the file: a blank in the owner column is a finding, not an omission, and "supported by" is not "owned by". I use the same shape on inference platforms, where the rows are model, runtime, orchestration, driver, policy engine and telemetry, and the row that comes back blank is usually the one a vendor's support contract quietly covers.

The settlement-record schema. A Markdown document listing the fields a single tokenized settlement must be able to show an examiner, each keyed to the primary that makes the field necessary. It exists because the observability row of the map is the one examiners read first, and because the Governor's line about trust being built transaction by transaction, which the AI Boardroom chapter of this special owns and reads as an engineering requirement, has a data-model consequence: a transaction can only build trust if it leaves a record with these fields in it. Twelve groups of fields, from the ISIN and whether its pilot flag is visible on the public repository to what evidence is retained, where and for how long. One group, the ledger software with its license and maintainer, the pilot record answers "not disclosed", and the schema prints that rather than dropping it.

What to ask your team

1. For every token we hold or issue, which layer settles it, and can we name the owner of that layer from a document rather than a slide?
2. What money settles our funds leg: central bank money, a bank deposit, or a private issuer's obligation? What happens to the token if that issuer fails, and where is that written?
3. What software runs the ledger our tokens sit on, under what license, maintained by whom? If the answer is "the vendor," what do the exit terms say, and have we ever read them?
4. Who holds the private keys, and can a holder move a token the record-keeper did not sign for? If yes, how does a court order reach it?
5. Which of our identity, KYC and freeze controls apply to the tokenized holding because they already applied to the account, and which were rebuilt for the token? The rebuilt ones are the ones to test.
6. Where secondary trading is not yet enabled on the ledger, what is the interim exit, and does it leave the atomic path? The Indian FAQ says its interim payment leg “may be completed outside the atomic settlement architecture”; ours should say something as plain.
7. Which rows of our ownership map say "supported by" a third party, and have we mistaken support for ownership anywhere?
8. Which of our tokenization claims describe a pilot with a defined scope and period, and which describe production? Does our language to clients keep the distinction the regulator's does?

Cut in verification, and why

• The phrase "T+0" for the pilot's settlement. It appears in none of the five pilot documents fetched: the press release, the FAQ, the Chairman's address, REC's release, the L&T filing. REC says “on same day”; SEBI says the bond and the money “move instantaneously”. Cut; the record's own words are printed instead, on the page and on the figure.
• "Wholesale CBDC on a public rail." The FAQ says the ledger is “private and permissioned”, and a public chain is a different thing from a state-owned rail. Using one word for both would have put two meanings in one figure. Cut; the chapter says "central-bank rail" and "private, permissioned ledger owned by the depositories".
• Three repository field values that conflict with, or go beyond, the issuers' records. The REC row's coupon field of 0 against REC's published 7.30 percent, and an issue description of "Bonus" on the REC and IIFL rows where both issuers describe private placements through the bidding platform: repository artifacts, not printed. The L&T coupon of 7.40, which exists only in the same repository field, is printed only with the depository's attribution, never alone.
• Any later assets-under-management figure for the tokenized treasury fund. Only the launch release was fetched. Cut; the launch record is cited as a launch record, 905 days old on 11 September 2026.
• A media-coverage mirror of the 2025 rail announcement on a political office's website. Not an instrument, and out under the series rule on political speeches. Cut; the Governor's address is cited instead.

Did not resolve

• Any primary naming the ledger software behind Demat 2.0 or the Unified Markets Interface. Absence, window closed 11 September 2026, across the twelve Indian primaries named above plus the Financial Stability Report of June 2026 and the Payment System Report of December 2025, both fetched and silent on the rail.
• NPCI's own statement of its “technology and implementation support” role. Its press listing refused every fetch route on three runs; a domain-restricted search of its site found nothing on Demat 2.0 or the rail. NPCI's role is cited only as SEBI's FAQ and REC's release state it.
• The depositories' own statements on Demat 2.0. NSDL's press index loaded only a month filter for 2026 with no September entry; CDSL's press pages returned a not-found page and, on one path, an internal error. CDSL's trade repository substitutes as a record, not a statement.
• An operating document for the Unified Markets Interface on the Reserve Bank's site. Not found. The rail row rests on two speeches and three sentences of the Annual Report 2025-26, and the chapter says so where it uses them.
• The third issuer's own website copy of its filing. The site's press index ends at 24 July 2026 and its announcements list is script-loaded. The exchange-filed copy stands.
• The statute's pages on congress.gov and the Federal Register's page for the Treasury proposed rule. Both refused the fetcher three times; both were routed to the Government Publishing Office's authenticated text, which the chapter cites.
• Corda's vendor documentation host and a second self-published tokenized-treasury record. One refused the fetcher, the other served an empty script shell, three times each. Corda is cited from its repository; the second record is not used.

Each row carries a re-verify marker in the sources file: a retry that succeeds adds a source; one that fails is restated as of the publish date, never dropped.

Next in the series

The next chapter of The Sovereign Stack in the numbered series is A safety setting was handed to a function that has no such setting, so the code it was meant to stop ran anyway. It takes the same map one layer further down: who can reach into the layers you own, and whether you can name them.

The series

This is the Sovereign Stack chapter of The Operator's Map, GFF 2026 Special, dated 11 September 2026 and standing outside the episode numbering. The four sibling chapters take the same week at their own altitudes. Ship AI: The agent gets a slot, not a button. The AI Boardroom: "The model said so" is not an answer. Beyond the Benchmark: Ninety-five percent is a projection. Twin & Machine: The key inside the machine that moves. This lane's live predecessor, which set the method this chapter applies, is Episode 3: A weights hash pins nothing.