Khurram Badar / Archive / Papers / Study Plan + All Queries Answered

Study Plan + All Queries Answered

other · 2026-08-08 · 4382 words · Khurram Badar

Study Plan + All Queries Answered Compani...

ai · education · fintech · pakistan · web

Study Plan + All Queries Answered

Work the modules in order. Each module answers your exact questions from the reading, then gives you a checkpoint — a question you should now be able to answer aloud without notes.

---

MODULE 1 — The Machines and the Ledger

**Q1. "On-premises in Pakistan is the defensible choice — AWS or Azure would reintroduce a foreign dependency through the back door." I don't understand this.**

AWS is Amazon's cloud (American company). Azure is Microsoft's (American company). "Cloud" means: instead of buying your own servers, you rent computing power on *their* machines, sitting in *their* data centers. It's cheap and convenient — which is why the lazy default for any new system is "put it on AWS."

The back door: if Pakistan's debt register runs on Amazon's machines, then a foreign corporation — subject to US law, US sanctions regimes, and US court orders — physically controls the computers holding Pakistan's sovereign register. You would have spent millions escaping dependency on Binance's chain, only to hand the same dependency to Amazon. On-premises means: the servers are physical boxes inside SBP's and CDC's own buildings, on Pakistani soil, under Pakistani law, unpluggable by no foreigner. For ordinary workloads, cloud is fine. For the *legal register of national debt*, the machines must live where the law lives.

**Q2. What is "voting to approve blocks"? Can I sign anytime I want? Voting for what — every hour, every day?**

Forget human voting; no person is involved. Here is what actually happens, continuously, forever:

1. Citizens' transactions ("send 5 tokens from wallet A to wallet B") arrive at the nodes and wait in a queue.
2. Every ~2 seconds, one validator node (they take turns) proposes a block: "here are the next 40 transactions; I say they're all valid."
3. The other fourteen validator machines *automatically check* the proposal against the rules: Is every signature genuine? Does every sender actually have the balance? Does every transfer pass the KYC check?
4. Each machine that finds the block rule-compliant attaches its cryptographic signature — that signature IS the "vote."
5. When a supermajority (say 10 of 15) have signed, the block is committed to the ledger on all fifteen machines simultaneously. Next block, 2 seconds later. Millions of votes per day, executed by software at machine speed.

"Can I sign anytime I want?" — No, and this is the beauty of it. Your server cannot sign an *invalid* block into existence, because signing it alone achieves nothing — nine other machines must independently reach the same conclusion, and they check the rules themselves. And a validator that *refuses* to sign valid blocks doesn't break the chain (the other fourteen carry on); it just becomes visibly non-participating, and the governance council can expel it. One validator has no unilateral power in either direction. That's the whole design.

(Humans DO sign things — but at the *transaction* level, for special powers like minting. That's Module 6.)

**Q3. Can we have more than two or three flavors of nodes? Why only two?**

The "two flavors" are not a limit — they are the only two *power states* that exist: has a vote, or doesn't. Within those, you can have as many nodes and sub-flavors as you like:

All of the last four are the same flavor wearing different job titles: *no vote*. So the honest count is: two castes, unlimited population.

**Q4. Why is the ledger file called RocksDB and not ledger1db?**

RocksDB is a **brand name**, not a description — like asking why a document is stored "in Excel" rather than "in spreadsheet1." RocksDB is a piece of free, open-source database software (originally built by Facebook to handle enormous data at speed) that Besu uses internally as its filing cabinet. The *ledger* is the content; *RocksDB* is the cabinet the content is kept in. You could rename nothing and lose nothing — it's simply the name of the cabinet-maker.

**Q5. Everyone holds an identical copy — but BEFORE creation, who holds it?**

Before the genesis ceremony: **nobody, because it does not exist.** There is no ledger to hold. What exists beforehand is only the genesis file (the constitution) — a text file, distributed to all fifteen institutions in advance, each verifying they have the identical file (by comparing its hash — see Q6). At the ceremony, all fifteen servers start up *from that same file*, and the ledger is **born simultaneously in fifteen places at once**. Nobody hands a master copy to anyone; there is no moment where one party holds it alone. Block 1 and everything after is written by the network itself, by the voting process in Q2. The ledger has no single parent — that's precisely what makes it trustworthy.

**Q6. Is a fingerprint called a hash?**

Yes — same thing, and now you can use the real word. A **hash** is a fixed-length fingerprint computed mathematically from any data. Feed in the entire ledger or a single word — out comes a short string like `9f86d081...`. Two properties make it magic: change even one comma in the input and the hash changes *completely and unpredictably*; and you cannot work backwards from the hash to the data. That's why each block storing the previous block's hash makes tampering self-evident, and why "verify the genesis file" means "all fifteen institutions confirm their file produces the same hash."

**Q7. What is CDC, and explain the contrast sentence.**

CDC = the **Central Depository Company of Pakistan** — the institution that keeps the official electronic register of who owns which shares and bonds in Pakistan's capital market. When you buy a share on the PSX, the proof you own it is an entry in CDC's database. It replaced paper share certificates in the 1990s.

The contrast, unpacked: today, CDC's register is **one** database at **one** institution; authorized staff make the entries; auditors check afterwards whether the entries were right. Trust rests on the institution and the after-the-fact audit. The chain's register is **fifteen** identical databases at fifteen institutions; no entry exists until a supermajority of machines independently verify it; and the hash-chaining means the audit is *structural and continuous* — tampering is self-evident the instant it's attempted, not discovered next quarter. Same job as CDC; trust moved from institution + hindsight to mathematics + supermajority.

**CHECKPOINT 1**: Explain to a colleague why destroying fourteen of fifteen servers doesn't destroy the ledger, and why one rogue validator can't forge a block.

---

MODULE 2 — The Genesis Block and Sovereignty

**Q8. "This doesn't look sovereign" — engineers write the genesis file, so where's the sovereignty?**

You've spotted the exact tension, and the answer is a distinction you already use in government: **the drafter is not the author.** Pakistan's constitution was physically typed by clerks and printed by a press — nobody thinks the typist or the printer holds sovereignty. Sovereignty lives in three acts, none of them typing:

1. **Deciding the contents** — the state (not the vendor) decides the validator list, the voting threshold, the rules. The engineer transcribes decisions already made by the governance council.
2. **Verifying the transcription** — before launch, every institution independently checks the genesis file's hash against the officially approved version. If the vendor slipped anything in, fifteen independent checks catch it.
3. **Adopting it ceremonially** — the file is annexed to a documented government act (a gazette notification, a signed resolution), and the ceremony launches from *that* verified artifact.

The warning in the study — "not a vendor deliverable that arrives by email" — is aimed at the failure mode where steps 2 and 3 are skipped and whatever the contractor sent becomes the constitution by default. Do the three acts, and the engineers are exactly what the typist was: skilled hands executing sovereign decisions.

**Q9. Your idea: "Can I run a blockchain to protect my key-signing ceremony?"**

This is a genuinely good instinct — with one refinement. A blockchain cannot *protect* keys (protection is the multi-sig, the HSMs, the physically separated humans — a chain adds none of that). What a chain does superbly is make events **unforgeable and undeniable after the fact**. So the refined version of your idea is real and used in practice: **anchor the ceremony's evidence on-chain.** Every governance event — a key ceremony completed, a validator admitted or expelled, a software upgrade approved, a freeze executed — gets its signed record hashed, and the hash written to the ledger itself. Result: nobody can later claim a ceremony happened differently, backdate an approval, or quietly rewrite the minutes; the fingerprint sits in an append-only public record. In your custody-policy language: the chain becomes the tamper-evident logbook of its own governance. Keep this idea — "governance events anchored on-chain" is a sophisticated line in any room, and it's cheap to implement.

**Q10. Explain: "Given a private genesis file and a validator list, Besu becomes a node of a standalone permissioned network — same program, different constitution."**

Besu is one program that can serve any network — *which* network is decided entirely by the genesis file you feed it at startup. Feed it public Ethereum's genesis: it joins Ethereum, one node among thousands. Feed it Pakistan's private genesis (different chain ID, fifteen named validators): the same unchanged program becomes a node of Pakistan's network, and public Ethereum doesn't exist as far as it's concerned. Analogy: a judge is one professional who can sit in any country's court — *which law he applies* depends on which constitution is placed before him. Same judge, different constitution, entirely different court. The program is the judge; the genesis file is the constitution.

**Q11. "Place the genesis file and the node's identity key in a folder" — wait, a node's identity key? When was this created? Where do you get it from?**

Created **by each institution itself, before the genesis file is written** — and this ordering is the point. The sequence:

1. During setup, each institution runs a one-line command (Besu can do it, or better, an HSM does it) that generates a fresh **keypair** on its own premises: a private key and its matching public address. Nobody issues it; nobody distributes it; mathematics creates it locally. The private key never leaves the institution — ideally never leaves the HSM.
2. Each institution sends only its **public address** to the governance council.
3. The council compiles the fifteen public addresses into the genesis file's validator list.
4. Launch: each node signs its blocks with its private key; the network checks the signature against the address in the constitution. Match = you're a founding validator; no match = you're nobody.

So the identity key is self-generated, then *recognized* by the constitution — the same pattern as your custody keys: created in ceremony on your own hardware, never handed to you by anyone.

**Q12. Is the genesis file our smart contract? / "A sukuk contract written for the EVM" — do you mean smart contract or the genesis file? / Is "a standard" the genesis file?**

Three questions, one confusion — untangle it with one image: **country, law, drafting template.**

So: the sukuk contract is a smart contract (not the genesis file), shaped according to a standard (which is a template, not a file on your chain), deployed onto the network the genesis file founded. One nuance that caused the blur: a genesis file *can pre-install* a few contracts so they exist from second zero — the constitution can contain a few founding laws. Convenience, not identity: they remain different kinds of thing.

**CHECKPOINT 2**: Say aloud the difference between genesis file, smart contract, and standard — using country, law, and template.

---

MODULE 3 — The Sukuk Contract's Verbs

**Q13. What is mint, transfer, etc.? What is minting? (And from Phase 4: is minting creating wallets?)**

**Minting is NOT creating wallets.** Minting is creating the *tokens themselves* — the securities. Wallets are created separately, by whoever will hold tokens (Q15). Keep the two forever apart: wallets are containers; minting fills the world with things to put in them.

The sukuk contract is a program whose few hundred lines define perhaps six **verbs** — the only actions that can ever happen to this instrument:

That's the entire instrument. A sukuk, reduced to six verbs and the rules about who may speak each one.

**Q14. "First mint — mint ceremony" — explain this.**

Walk through issuance day. The Ministry of Finance has run its auction: PKR 20 billion of 1-year sukuk sold, subscribers' money received. Now the certificates must come into existence:

1. **The instruction**: MoF issues a signed, documented order — "mint 20,000,000 tokens of series SUKUK-2027-A into the Treasury issuance wallet."
2. **The ceremony**: the mint verb obeys only a multi-party key — say 3-of-5, each share held by a different officer in a different institution, each inside an HSM. The officers convene (your key-ceremony framework, verbatim: identity checks, witnesses, recorded minutes). Each signs the mint transaction with their share.
3. **Quorum reached → the network executes**: the transaction goes to the validators, passes the vote (Q2), and in the next block **20,000,000 tokens exist** — visible instantly on the block explorer to the entire world. This moment is to digital sukuk what the banknote press run is to currency: the press turns only when multiple officers turn their keys together, and the run is logged.
4. **Distribution**: from the Treasury wallet, tokens transfer out to each subscriber's whitelisted wallet against their payment. Delivery-versus-payment.
5. **The record**: ceremony minutes hashed and anchored on-chain (your Q9 idea, in production).

Notice what the ceremony protects: not wallets, not servers — the **printing press**. A stolen mint key means counterfeit sovereign debt indistinguishable from real. That is why Phase 4 says "your custody framework, verbatim."

**Q15. The inbound rail — the ERC-3643 part is outbound (checking addresses), but how does the investor GET IN? Does he get a wallet with an ERC address? Who creates it?**

Precisely the right question — the standard polices the door, but someone must give the investor a door to arrive at. The inbound rail, step by step, for a worker in Sharjah:

1. **Downloads the licensed app** (a PVARA-licensed VASP's product — Q19 covers what this app is).
2. **KYC inside the app**: Emirates ID / passport, CNIC or NICOP, selfie, source-of-funds. Standard bank-grade onboarding.
3. **Wallet creation — two models, and this is a policy choice**:
- **Custodial (the likely retail default)**: the VASP generates the keypair and *holds the private key* on the investor's behalf, in its licensed custody system. The investor sees a balance in an app, like a bank account; the ERC address exists but he never touches keys. Protects unsophisticated users from key-loss; concentrates risk at the custodian (which is why the custodian is licensed and inspected).
- **Self-custody (for the sophisticated)**: the app generates the keypair *on the investor's own phone*; he holds the keys, with all the freedom and all the risk.
4. **Whitelisting — the handshake with ERC-3643**: upon KYC approval, the VASP registers the investor's address in the **on-chain identity registry**. Only now do the contract's transfer checks recognize this address as a permitted holder. Un-KYC'd addresses aren't rejected at transfer time so much as they simply *never existed* to the contract.
5. **Money in**: he pays dollars/dirhams through the app (card, bank transfer, or a remittance channel); the VASP converts and subscribes on his behalf; tokens land in his whitelisted wallet at the next settlement.

So: the wallet is created by the app (custodially or on-device), the *address* is admitted by the registry, and the money enters through the licensed VASP's fiat rails. The ERC-3643 bouncer is the last gate, not the whole rail.

**Q16. Testing on a throwaway local blockchain — this is necessary, yes?**

Not just necessary — **non-negotiable, for one brutal reason: deployed contracts cannot be patched.** Ordinary software ships bugs and fixes them Tuesday. A smart contract, once on the chain, is immutable — a bug is permanent, and on a sukuk contract a bug is not a crash, it's *money*: tokens minted wrongly, profit paid to the wrong holders, transfers that can't execute. The industry's graveyards are full of unaudited contracts that lost hundreds of millions to one flawed line. Hence the discipline stack: thousands of automated tests on a laptop chain → months on a testnet (full rehearsal network with valueless tokens) → two independent audits → only then mainnet. For sovereign debt, treat this like aircraft certification: the plane flies simulators for years before it carries passengers.

**CHECKPOINT 3**: Narrate issuance day — instruction, ceremony, mint, distribution — and state what the mint key protects.

---

MODULE 4 — The Toolbox Questions

**Q17. Is there an OpenZeppelin-style pre-written library for ERC-3643?**

Yes. The standard has an official open-source reference implementation called **T-REX** (Token for Regulated EXchanges), originally built by Tokeny — the firm that authored the standard — and now stewarded by the **ERC-3643 Association**, a non-profit whose members include major financial institutions. It's free, audited, and running in production on real regulated-token deployments. So Pakistan's engineers would assemble: OpenZeppelin components for the generic machinery + T-REX for the permissioned-security layer + the sukuk-specific verbs (profit distribution, redemption) written and audited on top. The from-scratch surface is kept deliberately tiny — the same "assemble, don't invent" logic as the whole build.

**Q18. Does the wallet have to be MetaMask? Can it be Trust? Or custom-made? What is it?**

MetaMask was an *example*, not a requirement — and for this program it's mostly the wrong tool. Sort wallets by who they serve:

One sentence for the room: *the wallet is a policy decision dressed as an app choice — retail gets custody they can't hurt themselves with; officers get custody that can't act alone.*

**Q19. The block explorer — where does it appear? A website? Auto-generated? On the same network?**

Not auto-generated — it's a **separate web application that Pakistan deploys deliberately**, and it's the piece that turns a private chain into a *publicly accountable* one. Mechanics: Blockscout (free, open-source) is installed on ordinary web servers; it runs alongside an **observer node** (Module 1 — full copy, no vote) and continuously reads the ledger, storing it in a form a website can display. The public then visits an ordinary URL — imagine **explorer.debt.gov.pk** — over the normal internet, and sees every block, every transaction, every mint, every holder address (pseudonymous), live.

The elegant part: the *validators* stay on their private network, unreachable from the internet; the *explorer* faces the world, holding only a read-only copy. A window into the vault — the vault door stays sealed. And it is the literal answer to the proof-of-reserves theme from your first study: with an explorer running, "trust us" becomes "see for yourself."

**Q20. "What the diaspora-facing app is built on top of" — what app must be built? Mobile? Web?**

Both, and it is the most conventional piece of the whole architecture — a fintech app, like a banking or investment app:

The strategic point: to the investor, the entire sovereign machine — Besu, EVM, ERC-3643, ceremonies — is invisible. He experiences an app as familiar as his bank's. The chain's sophistication is measured by how boring the app feels.

**CHECKPOINT 4**: Explain why retail investors never see MetaMask, and how the public sees a private chain.

---

MODULE 5 — The Governance Question (your deepest one)

**Q21. "Why do engineers write the sukuk contract? Isn't this a governance flaw — shouldn't it be written by constitutions?"**

This is the best question in your list, and the answer is the same distinction as Q8, now applied to laws instead of the constitution — plus a control chain you should be able to recite.

Parliament does not personally type legislation; drafters do. Nobody calls that a governance flaw, because the *authority* is located in what surrounds the drafting: instruction, review, enactment. The same four control points make contract-writing governed rather than delegated:

1. **The specification is a governance document.** Before any code: MoF/the council approves a plain-language term sheet — amount, tenor, profit rate, transfer rules, freeze authority, redemption mechanics. *This* is the authored law; the code must be its faithful translation.
2. **Independent audit is the check on translation.** Two separate audit firms verify: does the code do exactly what the specification says — nothing more, nothing less? (Q16's discipline, now serving governance, not just safety.)
3. **The hash is signed into the government act.** The approved contract's code produces one hash (Q6). That hash is written into the authorizing resolution/notification. What gets deployed must match that hash — verified independently by multiple institutions. Not one hidden character can differ from what governance approved.
4. **Deployment is a ceremony, not a keystroke.** The contract goes live only through the multi-party deployment key — same choreography as the mint ceremony.

So the engineer holds the pen, never the authority: governance writes the meaning, auditors certify the translation, the hash freezes the text, and the ceremony enacts it. If any of those four are missing — *that* is the governance flaw, and now you know exactly which question to ask in a room: "Whose signature is on the specification, and does the deployed hash match the enacted one?"

**CHECKPOINT 5 (final)**: Deliver the whole arc in two minutes — machines nobody trusts individually, a constitution nobody wrote alone, laws nobody deployed unilaterally, a press nobody can run by themselves, and a window anyone in the world can look through. That sentence is the entire system.

---

The study plan at a glance

| Module | Theme | Your questions covered | Checkpoint |
|---|---|---|---|
| 1 | Machines & ledger | Cloud back door, block voting, node flavors, RocksDB, ledger before birth, hash, CDC | Rogue-validator answer |
| 2 | Genesis & sovereignty | Drafter vs author, your on-chain-ceremony idea, same-program-different-constitution, identity keys, genesis vs contract vs standard | Country / law / template |
| 3 | The contract's verbs | Mint & friends, mint ceremony, inbound rail & wallet creation, why testing is non-negotiable | Narrate issuance day |
| 4 | The toolbox | T-REX for 3643, wallet choices, explorer mechanics, the diaspora app | Private chain, public window |
| 5 | Governance | Engineers-write-code resolved via the four control points | The two-minute arc |
| 6 (next) | Integration drill | Mock Q&A: defend the full architecture under hostile questioning — your preferred one-question-at-a-time format | Room-ready |

← The Rise of Open Source EconomyThe morning regime: time perception and productivity →
Two years of working thought, indexed.
Ask me to present it in your conference room — WhatsApp +971 55 623 9111
Book Session →