Status: working draft · Scope: consolidates the design decisions behind the v0 prototype in this repository.
This is a personal proposal and thought experiment — see DISCLAIMER.md. It is not affiliated with, endorsed by, or developed for any government or institution. All institutional roles below (Identity Authority, Governing Council, enforcement authority, issuer) are hypothetical placeholders describing how such a system could be governed; no real body is implied or committed. Nothing here promises or predicts adoption.
A sovereign hybrid blockchain for Cambodia: public within the country, private to the world.
- Open, composable DeFi and digital-asset activity for anyone inside the perimeter — under strict on-chain KYC.
- Ledger data, infrastructure, and governance under Cambodian sovereign control.
- A single, governed gateway through which only permitted tokens route to global public blockchains (Avalanche, Ethereum, Solana, …).
- A token fee — about 1 riel per payment — routed to a public-good fund rather than burned, so the cost of running the chain becomes visible public benefit (§8).
- Designed for a future in which AI-driven attacks and quantum computing stress the traditional banking system: multisig-everywhere, tamper-evident audit trails, identity-bound recoverable accounts, and crypto-agility as a first-class pillar. These are design targets for mainnet; §10 and
docs/deployment-status.mdrecord which of them the current deployment actually implements (few).
This is not a single CBDC. Money is two-tier: a native, riel-pegged base coin (tRIEL) that also pays gas, and many tokenized-riel stablecoins (KHRt is one reference issuer) that all convert to tRIEL 1:1 — like USDT/USDC redeeming to the dollar. The chain itself is a neutral registry-and-asset layer; see §6.
Decision: Avalanche L1 (Subnet-EVM), permissioned PoA. The deciding requirement is mature, safe egress: Avalanche ICM/ICTT provides audited, natively maintained interchain transport to the C-Chain and onward to other ecosystems. No other sovereign-capable stack offers a controlled gateway without building or adopting third-party bridge security.
| Alternative | Verdict |
|---|---|
| Hyperledger Besu (QBFT) | Named fallback. Fully sovereign, strong government precedent (Brazil Drex, EU EBSI), but no native egress — the killer gap. Both stacks are EVM, so all CSB contracts port unchanged if migration is ever needed. |
| Cosmos SDK + EVM | Maximum sovereignty and flexibility, but high engineering lift, imperfect EVM compatibility, and interop pointed at the wrong ecosystems. |
| Ethereum L2 stacks (OP Stack, Orbit, CDK) | Rejected: data/settlement dependency on Ethereum and single-sequencer designs contradict sovereignty and multi-institution validation. |
| Enterprise DLT (Fabric, Corda, Canton) | Rejected: no EVM, no DeFi ecosystem. |
An Avalanche L1 retains two dependencies on the Avalanche Primary Network, acknowledged and contained rather than hidden:
- Validator-set changes transit the P-Chain. Day-to-day operation is fully autonomous; only (rare, non-urgent) validator registration touches external infrastructure.
- Continuous fees are paid in AVAX (~1.33 AVAX/month per validator) — immaterial in cost, but documented.
Containment: the chain runs even if the P-Chain is unreachable; validator changes can be batched and scheduled; a documented exit path exists to standalone operation or Besu (Subnet-EVM is open source; contracts are stack-portable).
- Validators: public institutions (hypothetically, government bodies such as ministries), each running a validator in in-country data centers under sovereign jurisdiction. PoA via a Validator Manager contract owned by the governing council's multisig.
- Chain parameters (see
chain/genesis.example.json): chainId 8555, a low base fee priced so an ordinary payment costs about 1 riel (§8), and five Subnet-EVM precompiles activated at genesis:txAllowList— only KYC-provisioned addresses may transact (chain-wide KYC enforcement below the contract layer);contractDeployerAllowList— contract deployment restricted to vetted deployers (tier 3+ process);feeManager— sets the fee level; also the pressure valve for raising fees under attack;contractNativeMinter— administrative issuance of the native coin tRIEL, which is riel-pegged base money (not a speculative token); minted only under reserve discipline (§6), never freely;rewardManager— directs gas fees to a public-good fund instead of burning them. Only settable at genesis, so it is enabled from the start (§8).
- Multisig clarification: validators sign blocks automatically with node keys (HSM-protected — no per-block human approval). Multisig lives at the governance layer: the Validator Manager, precompile admin addresses, and every administrative contract role are held by institutional multisigs, so no official below the council can act unilaterally.
- Current deployment: the automatic block signing is true, but the rest is not. No multisignature wallet is deployed anywhere, every role named above is held by a single deployer key, and the staking keys are files on the node's disk rather than in an HSM.
- Trust model honesty: with all validators under one government, BFT does not defend against the state itself. What it buys: tamper-evidence between institutions, auditability, and no single point of technical failure. Credibility can be strengthened later by seating a minority of validators outside the executive (audit bodies, universities, regional partners).
- Current deployment: none of that is realised. There is one registered validator, on one host, run by one party — so there is a single point of technical failure, no tamper-evidence between institutions, and no fault tolerance. This is a property of the prototype's scale, not of the design; it is the first thing mainnet must change.
Root authority is a Governing Council established by an appropriate legal instrument (hypothetical) — this is also the legal vehicle that owns the chain, employs the core team, and holds root multisigs. Succession is automatic: authority follows the office. Changes of officeholders trigger a routine key-rotation ceremony.
Powers are deliberately split across institutions and enforced in code:
Status in the current deployment: not exercised. The table below is the role structure the contracts implement and the assignment mainnet requires. On the testnet every row is held by the same deployer key, and no multisignature wallet is deployed anywhere. The separation is real in code — the roles are distinct and independently grantable — but it buys nothing against a compromise of that one key today. See
docs/testnet-to-mainnet.md.
| Power | Holder | Contract |
|---|---|---|
| Identity issuance, suspension, revocation, address quotas | Identity Authority (placeholder) | IdentityRegistry |
| Asset freezing / confiscation (with mandatory order reference) | Judicial / AML authority | EnforcementRegistry, KHRStablecoin.confiscate |
| tRIEL base issuance (reserve-backed) | Sovereign / treasury reserve (placeholder — the anchor of the whole system) | Native Minter, under reserve discipline |
| Tokenized-riel issuance (mint/redeem) + issuer approval | Government-authorized issuers, not limited to the central bank (treasury / licensed bank consortium / payments authority — placeholders); council approves reserve-backed issuers | ITokenizedRiel ISSUER_ROLE; RielConverter |
| Egress token allowlist, caps, circuit breaker | Governing Council | EgressGateway |
| Validator set, protocol upgrades, precompile admin | Governing Council | Validator Manager + genesis admin keys |
Revocation does not remove the ability to transact. The two gates are independent and nothing connects them:
IdentityRegistry.revoke()andsuspend()change only the attestation, whiletxAllowList(precompile0x…02) decides who may send a transaction and is granted and removed by hand (scripts/allow-dev.js). A revoked address therefore keeps its allow-list entry until an operator explicitly callssetNone.KHRt itself is safe — its transfer hook checks the registry, so a revoked address cannot hold the asset. What a revoked address can still do is send transactions, receive uncompliant receipt tokens (Aave aTokens, Uniswap LP shares — see
docs/defi.md), and callpool.withdraw(asset, amount, attested)to convert such a claim into real KHRt in an attested party's hands. So the receipt-composability leak documented for DeFi becomes realisable exactly for this class of address, where for a genuinely unlisted address it is inert.Audit the current state with
npx hardhat run scripts/audit-allowlist.js, which compares both gates and lists every address that can transact without an active attestation.A second, related decoupling: a redeploy forks the perimeter. Every gated token binds its registry immutably —
IdentityRegistry public immutable identity(KHRStablecoin.sol:28,LandTitleToken.sol:42). Redeploying the suite therefore does not replace the compliance perimeter, it partitions it: the previous tokens keep obeying the previous registry, with their own attestations, and the current authority holds no role on it. Revocation, freezing and confiscation are all inoperative against those assets, and the current registry — the state's own view of who is verified — does not cover their holders.This is not hypothetical. Measured on chain 8555 on 2026-07-30: three live tokens (one reporting symbol
KHRt, twoLAND1) obey registry0x446BE7b3…a101while the chain's registry is0xa33a4C89…, and addresses transacting on them read as unattested against the current registry while beingActivein the old one. Assess an orphan withCSB_TOKEN=0x… npx hardhat run scripts/orphan-check.js.The design fix is to stop binding it immutably — a registry behind a proxy at a fixed address, or a council-settable reference — so a later authority inherits the assets rather than forking away from them. That trades immutability for governability, and the trade should be made deliberately rather than by default.
Two ways to close the revocation gap, and the choice is a real trade:
- Operator procedure — revocation includes
txAllowList.setNone(addr). Cheap and changes no code, but it is a manual step, and manual steps are what produced this gap.- Give
IdentityRegistryallow-list admin sorevoke()removes access atomically. Correct behaviour, but it makes that one contract able to gate every transaction on the chain — a genuine concentration of power to weigh against the separation-of-powers design above.
The point, once the roles are held by different institutions: the Identity Authority can stop new activity (revoke KYC) but cannot seize assets; the enforcement authority can freeze/confiscate but cannot touch identity or issuance. Due process, auditable by construction.
Of that, the order reference is the part in force today: every enforcement action carries a court/AML reference on chain, and the contracts revert without one (EnforcementRegistry, KHRStablecoin.confiscate, LandTitleToken.forcedTransfer/recoveryAddress). The mutual-exclusion property is not, because one key holds both roles.
A single national Identity Authority (placeholder: the body holding a civil registry and national ID apparatus) is the sole identity root. No existing digital-ID product is assumed.
- No PII on chain. An attestation binds an address to a salted commitment hash referencing a record in the Identity Authority's off-chain registry. The identity↔person mapping never leaves Identity Authority systems; access to it is logged and audited (lawful-intercept-style regime).
- Enrollment: citizen presents at an Identity Authority office/licensed agent → biometric match against the national ID database → smart account created → the Identity Authority signs the attestation → address enters the
txAllowList. - Tiers: 1 = citizen basic (capped transfers) · 2 = full KYC (unrestricted DeFi) · 3 = business/KYB · 4 = institutional/qualified investor. Other authorities layer role attestations on top of an Identity Authority identity (a commerce-registry body attests businesses, a finance authority attests qualified investors — all placeholders) — one root, many endorsements.
- Addresses per identity: default one; additional address slots are granted by the Identity Authority after a fee payment (receipt reference recorded on chain). Multiple addresses of one identity are linkable by the state through the Identity Authority's registry but not by the public — privacy from neighbors, transparency to the state.
- Recovery: accounts are smart accounts (account abstraction) with the Identity Authority as recovery agent — lost phone ≠ lost assets; re-verify at any Identity Authority office and rotate the key.
- Open question (explicitly deferred): non-citizen tiers via the Identity Authority's immigration arm (passport KYC) — economically attractive, AML-sensitive, in or out of v1 by policy decision.
CSB uses a two-tier monetary model, mirroring how real money works — base money plus private stablecoins — with everything denominated in riel.
| Tier | Instrument | Analogue |
|---|---|---|
| Base / settlement | tRIEL — the native coin. Pays gas and is the common unit every riel token converts through. 1 tRIEL = 1 riel. | Central-bank reserves / CBDC |
| Tokenized riel | KHRt and others — many issuers, each a KYC-gated riel stablecoin, all convertible to tRIEL 1:1. KHRStablecoin is the reference implementation, not "the" riel. |
USDT / USDC / PYUSD → all redeem to USD |
So KHRt is one issuer's product, not a monopoly: multiple institutions can each issue their own tokenized riel (competing on trust and features), and tRIEL is the neutral denominator they all convert into — which makes every riel token mutually fungible through the base (KHRt → tRIEL → OtherRiel).
Issuance is a government function, but not a single institution's monopoly. Authority to issue a tokenized riel would come from the state, and deliberately is not tied to any one body — the central bank is one possible issuer among several (a treasury, a licensed bank consortium, a designated payments authority). The design keeps the issuer slot pluggable so the monetary question stays a policy decision rather than something the code has already settled. (As throughout: hypothetical placeholders. No real institution is implied, approached, or committed.)
At least one tokenized riel must exist from day 1. A launch with only tRIEL and no tokenized riel would leave the two-tier model theoretical — nothing to convert, and the RielConverter idle. So the chain launches with a reference tokenized riel deployed and approved in the converter (in this pilot, KHRt, approved at deploy time in scripts/deploy.js), and conversion working in both directions on the first day rather than as a later phase.
tRIEL is backed money, not a free utility token. Because 1 tRIEL = 1 riel, it must be reserve-backed exactly like a stablecoin, and minted only via conversion or reserve-backed issuance — never freely. Two consequences:
- The genesis allocation and any Native-Minter use represent issuing real money, under the same reserve discipline as KHRt.
- Gas is priced, not free. An early draft of this design used a zero fee floor and described it as subsidized gas — a budget line the state absorbs. That was replaced: gas now costs about 1 riel per payment and is routed to a public-good fund (§8), so the cost of running the chain is paid by its users and visibly returned to them, rather than absorbed invisibly by a treasury.
Convertibility — both backing tiers supported (RielConverter, planned):
- A. Trustless (tRIEL-collateralized). To mint the token, the issuer locks tRIEL 1:1 in the contract; redemption is contract-enforced and instant. No issuer-solvency risk. All backing concentrates in tRIEL (which is the system anchor).
- B. Reserve-backed issuer. A council-approved issuer holds its own fiat riel reserves (like USDT) and commits to 1:1 convertibility, subject to reserve attestation/audit. Backing is diversified across issuers; convertibility depends on issuer solvency, so issuer admission is governed (allowlist + audits).
Both coexist: trustless wrappers are the safe default; vetted reserve-backed issuers are permitted where real reserves and licenses exist. The Governing Council governs which issuers and tokens are approved (the same allowlist muscle used elsewhere).
Convertibility is exposed, not just implemented. A converter nobody can reach is a claim rather than a feature, so the swap is in the product: the wallet page carries a Swap — KHRt ⇄ tRIEL card (wrap locks KHRt and mints tRIEL; unwrap burns tRIEL and releases the KHRt), and the public Tokens & NFTs page publishes the converter's locked collateral alongside the 1:1 rate. That figure is the backing claim itself — anyone can check that the KHRt sitting in the contract matches the tRIEL it has minted, without an account and without taking anyone's word for it.
Whoever anchors tRIEL anchors everything. Since all riel tokens redeem to tRIEL, the foundational trust question is who guarantees 1 tRIEL = 1 riel — most plausibly a sovereign/treasury reserve (the CBDC-like base). Every tokenized riel inherits its credibility from that answer.
Compliance carries across every riel token (an ITokenizedRiel standard; KHRStablecoin implements it):
- Compliance-gated transfers: both parties must hold an active KYC attestation and not be frozen. Tier-based per-transfer caps for basic accounts.
- System contracts: council-vetted contracts (bridge adapters, DEX pools, escrows) may hold the token without personal KYC — still freezable — so standard DeFi deploys unmodified while every human counterparty stays KYC'd.
- Enforcement: confiscation requires ENFORCER_ROLE plus an order reference and works on frozen accounts.
Until a monetary mandate exists, all of this circulates only as test riel in a sandbox — no riel-pegged instrument is launched publicly without the required license.
The single authorized exit to public blockchains, and the load-bearing requirement of the whole design (EgressGateway):
- Token allowlist: only council-permitted tokens can leave; each carries a minimum KYC tier and a daily volume cap.
- Transport/policy separation: the gateway enforces policy; transport is delegated to per-token
IBridgeAdapters. Production adapters wrap Avalanche ICTT (TokenHome on CSB, TokenRemote on the C-Chain) — audited, maintained bridge infrastructure rather than bespoke bridge security. v0 ships a mock adapter. - Circuit breaker: council can pause all egress instantly.
- Explicit boundary: everything crossing the gateway becomes permanently world-public on external chains. Wallet UX must surface this to users at the moment of egress.
- Staged rollout: caps start small and widen with operational confidence.
Decision: a transaction costs about 1 tRIEL (= 1 riel), and every riel of it goes to a public-good fund.
Gas is paid in tRIEL, which is real riel-pegged money (§6), so gas was never going to be costless — the choice is only who pays and where it lands. Rather than have the state absorb the cost invisibly, the fee is set at roughly 1 riel per payment: small enough to be irrelevant to a citizen (a fraction of a US cent), real enough to price the resource, and — routed to a public fund — it turns the cost of running the chain into visible public benefit.
Why "about" and not exactly 1 riel. The EVM charges gasPrice × gasUsed, so a chain cannot price every transaction at a flat amount; it can only fix the price per unit of gas. CSB sets that price so a plain transfer costs 1 tRIEL, which means heavier work costs proportionally more (a contract call a few riel, a deployment more). This is honest pricing — complex transactions consume more of the shared resource — but it is not a flat fee, and anything advertised as "1 riel per transaction" should be understood as the price of an ordinary payment. Where a genuinely flat charge is wanted, it belongs at the contract layer (KHRStablecoin.transferLevy, RielPay), not the fee config. Set with scripts/set-gas-price.js.
Gas fees are NOT burned — they fund public good. The chain enables the Subnet-EVM RewardManager precompile (0x…04, admin = council) at genesis, which controls where gas fees go. setRewardAddress(fund) routes every transaction's fee to a chosen address instead of the default burn. This had to be decided at genesis — it cannot be added by upgrade — so it was switched on from the start. Set with scripts/set-reward-address.js; reversible to burning or to paying block producers.
Two mechanisms, deliberately different in reach. They are complementary, not duplicates:
| Gas fee → fund (RewardManager) | Transfer levy → fund (transferLevy, RielPay) |
|
|---|---|---|
| Applies to | Every transaction on the chain — transfers, contract calls, mints, deployments | Only payments through that specific contract |
| Charged in | tRIEL (native) | The token being sent (e.g. KHRt) |
| Amount | Proportional to work done (~1 tRIEL for a transfer) | Flat per payment |
| Enforced by | The chain itself, at block production | Contract code |
| Avoidable? | No — nothing transacts without paying gas | Yes — exempt addresses, or use another contract |
The gas route is universal and unavoidable; the levy is targeted and flat. Together they let policy fund public services from all chain activity while keeping a recognisable "1 riel of this payment helps a hospital" story for ordinary users.
Spam defense is the identity layer, not the fee market. Every account is KYC-bound, so abuse is rate-limited and revocable at the identity level. The fee is set for fairness and funding, not as the primary anti-spam mechanism — which is why it can stay near-zero-cost to citizens. Under active attack, feeManager can temporarily raise fees as a pressure valve.
Reversibility. None of this is locked in. Fees can go back to zero (scripts/set-gas-free.js), fees can be burned instead of routed (CSB_REWARD_MODE=burn), and the recipient can change by council decision. What genesis fixed is only that the option to not burn exists.
Decided posture: full validator transparency, controlled edges.
- All nodes hosted in Cambodia; ledger data never leaves sovereign infrastructure except through the egress gateway.
- RPC and the explorer are access-tiered behind authentication (whitelisted explorer): citizens see their own history and public aggregates; regulators see more; raw node access is limited to validator institutions.
- Every node operator can read the full ledger — accepted deliberately, mitigated by pseudonymity (addresses on chain, identities only in the Identity Authority's audited registry) and the multi-address allowance.
- Selective privacy (ZK/encrypted instruments) is scoped out of v1 with architectural room left to add it.
Standard EVM chains depend on ECDSA — broken by a cryptographically relevant quantum computer, with public keys permanently exposed on transparent ledgers. CSB's counter is crypto-agility by governance.
Status: design commitment, not implemented. The v0 prototype has no account abstraction. Accounts are ordinary externally-owned ECDSA keys, exactly as on any EVM chain, and native tRIEL has no recovery path. The bullets below describe what mainnet is designed to provide; only the governance property and the non-public ledger are true of the deployment today.
- (Designed, not built.) Accounts become smart accounts whose signature-verification logic is upgradeable: ECDSA today, post-quantum schemes (ML-DSA/Falcon-class) when tooling matures — without users migrating addresses or losing assets.
- The permissioned validator set allows coordinated, fleet-wide protocol upgrades public chains cannot execute.
- Against AI-driven attacks the claim is resilience, not immunity: multisig-everywhere (no single compromised official can move funds), tamper-evident cross-institution audit trails, identity-bound freeze/recovery, deterministic contract logic. (Of these, only the deterministic contract logic and the order-referenced freeze/recovery are in force today — the testnet holds every role on one key and runs one validator, so neither the multisig property nor the cross-institution property exists yet.)
- "Private to the world" also blunts harvest-now-decrypt-later. A public ledger publishes every account's public key permanently, so an adversary can collect them today and break them once a quantum computer exists. CSB's ledger is not world-readable, so there is far less material to harvest in the first place — a privacy property doing double duty as a cryptographic one.
| Phase | Content |
|---|---|
| 0 — Prototype (this repo) | Contract suite + tests; genesis config; local devnet. |
| 1 — Devnet demo | Multi-node local L1; wallet, tiered explorer, and admin-console UIs; scripted end-to-end demo: KYC onboarding → ~1-riel transfer → KYC'd DeFi swap → freeze/audit → egress allow/deny. Target audience: decision-makers (hypothetical). |
| 2 — Pilot | 3-institution validator testnet; real ICTT adapter to Fuji C-Chain; one non-monetary asset class in production use (e.g. document/land-title attestation, tokenized bond sandbox). |
| 3 — KHR mandate | Issuer mandate resolved politically; stablecoin sandbox with licensed participants; DeFi opening. |
| 4 — Expansion | Full institution validator set; non-citizen tiers; selective-privacy instruments; PQ signature migration as standards mature. |
- Non-citizen KYC tiers (in/out of v1).
- Council composition and the legal instrument text (legal drafting, not engineering).
- Explorer/RPC access-tier details and the de-anonymization audit regime.
- Which non-monetary asset class leads Phase 2.
- Identity Authority fee schedule for additional address slots.