🇰🇭 CSB Use cases

what a permissioned chain makes possible — no login required

Four worked examples of things a chain with a national identity layer can do that a public chain structurally cannot — ending with one that ties a real tree to its twin in a virtual world. All four run on this testnet, and all four are demonstrations rather than products.

1 · Targeted assistance — money that can only buy food

A government transfers cash to households in need. The intent is food on the table. Some of it goes to a moneylender the day it arrives, and the programme finds out months later from a survey, if at all.

CSB puts the condition inside the money. Assistance is issued as an earmarked balance of ordinary tokenized riel — real money, with a rule the chain checks on every single payment.

1
A licensing registrar records that an address is a licensed food merchant.
2
A social-policy authority creates a programme: this money may only reach food merchants.
3
The issuer disburses an earmarked balance to the household.
4
On every transfer, the token asks the policy whether the recipient is permitted.
✓ Paying the grocer works. The earmark is spent first, so assistance is used for its purpose before the household's own money is touched.
✗ Paying a moneylender is refused by the chain. Not flagged for review afterwards — it cannot settle.
✓ Their own wages stay their own. Money the household earns can go anywhere, including to that same lender. Only the assistance carries the condition.

Try it — ask the chain whether a payment would settle

This runs against the live testnet and moves nothing. Pick who the household pays, or paste any address, including your own.

Said plainly: this is a mechanism for controlling how someone spends money. It is defensible for a grant given for a stated purpose, where the alternative is no programme or in-kind distribution. The same machinery pointed at wages or savings would be something else entirely — nothing in the code prevents that, only governance does. The earmark does not spread to the merchant, clawback can never reach earned money, and the chain holds programme rules rather than a list of who is poor.

Full write-up, including what it deliberately does not do ↗

2 · Tokenized land title — issued by a regulated registrar

A land title is a paper deed and a row in a ministry database. Selling a share, or borrowing against it, means manual process and bilateral trust.

CSB makes a parcel 10,000 shares of a permissioned token (ERC-3643). A holder with 2,500 owns a quarter — which is what lets a lender take a partial claim without the parcel being sold or subdivided.

1
Only the land authority can tokenize a parcel. One parcel, one token, recorded in the registry.
2
The token checks the national identity registry before it will settle — the same KYC layer the whole chain uses.
3
Shares transfer between verified parties; the registrar keeps the powers a court needs.
4
An unrelated lending contract takes shares as collateral, verifying through the registry that they are a real title.
✓ A sale between verified parties settles.
✗ A sale to an unverified address cannot settle at all — compliance is in the token, not in an app that could be bypassed.
✓ Borrowing against land works without the registrar building a credit market — the lender just reads the registry.

Why this argues for a sovereign chain. ERC-3643 expects an identity registry deciding who may hold the token. On a public chain every issuer builds and maintains that themselves, badly. Here it already exists and is authoritative, so a security token gets compliance for free.

Try it — ask whether a share transfer would settle

The compliance rule lives in the token itself, so it answers the same way whoever asks. Try the verified co-investor, then any other address.

Two honest limits. A contract has no national identity, so it cannot custody a title unless the registrar approves it — writing a lending protocol against these titles is permissionless, custodying land is not. And the demo vault models the mechanism only: a real lender needs a price oracle, liquidations, and legal enforcement against the parcel.

Full write-up ↗

3 · Delivery escrow — one payment, many payees

A customer pays 20,000 riel for a food delivery. That single payment is really three: the restaurant, the rider, and the platform's commission. Today the platform collects everything and pays the others later — so the rider is an unsecured creditor of the platform, and the customer has no idea what share reaches whom.

CSB agrees the split before the customer pays, holds the money in the contract rather than with the platform, and settles everyone in one transaction. 

Restaurant              15,000.00 KHRt
Delivery rider           3,500.00 KHRt
Platform commission      1,500.00 KHRt
                        ──────────
Customer pays           20,000.00 KHRt   ← agreed before paying
1
The order and its split are recorded. Nothing has moved yet — the customer can see the rider's fare before deciding.
2
The customer pays into escrow. The platform never holds the money.
3
Delivered. The customer confirms — and all three are paid in the same transaction.
✓ Nobody is trusted to forward anything. Either every payee is paid or none is, so a platform that fails mid-delivery cannot take the rider's fare with it.
✓ Stuck orders have a way out. An arbiter can settle or refund with a recorded reason, and the buyer can reclaim after the deadline if nothing happened.
✗ A frozen payee stops the whole settlement — not just their share. Compliance is not suspended inside an escrow.

That last one is deliberate. Paying the other two and stranding the rider's share would leave money in escrow with no owner and an order that is neither settled nor refundable. An enforcement freeze outranks the commercial obligation; the arbiter's remaining move is to refund the buyer.

Try it — the real orders on this chain

Each order's split is recorded before any money moves, so the customer can see the rider's share before paying. These are live.

Known interaction, worth stating. The escrow must be a council-vetted system contract to hold tokenized riel without a personal KYC attestation. System contracts are exempt from the public-good transfer levy, so an escrowed payment does not contribute the 1 KHRt levy a direct payment would — the gas fee still funds the public good, but the levy does not apply. Whether that is right is a policy question; it is written down so it stays a decision rather than a surprise.

Full write-up ↗

4 · A tree you can walk to, and the same tree in a virtual world

A farmer plants 500 mangroves. A sponsor on the other side of the world wants to pay for them and has no way to know whether they are still standing in a year. So the money arrives on planting day — which is why there are so many photographs of people planting trees, and so few of the same trees eighteen months later.

CSB does not tokenize the carbon. Nothing here mints a tonne of CO₂, because nobody can walk outside and check one. It records trees — the largest claim this can honestly support — and releases the money only when somebody with a licence to lose has gone and confirmed they are still alive.

1
The farmer measures a plant on her phone. The record is signed on the device; only its hash comes here — no location, no photo, no name.
2
The hash is anchored. The chain stamps it with a block time agreed by validators who have never met her — her phone's clock is a claim, this is not.
3
A licensed commune agriculture officer visits and confirms it. Anyone can generate a thousand keys; only a licence someone can lose counts here.
4
The grove becomes a token whose supply is the verified living-tree count — and a sponsor's pledge pays out against a fresh confirmed record.
5
A virtual world reads the same record and grows the same grove, carrying the verifier's licence with it.
✓ The digital twin is the same object as the payment. The grove you walk through in the metaverse and the riel that reached the farmer are two readings of one record, not two systems that agree.
✗ Last year's healthy photograph will not pay this year's survival check. The proof has to be anchored after the milestone opened, measured in block time.
✗ You cannot verify your own trees — and neither can an address with no licence, however many keys it holds.
✓ The token shrinks when the trees die. Supply is minted and burned to the verified count, and anyone at all can force that correction.

Try it — ask the chain who may confirm a grove, and what pays

Live on this testnet, read-only. The refusals are the point: this is where a virtual tree stops being a picture somebody drew.

Who may confirm a grove? Pick a party, or paste any address — including your own.

Which proof releases the money? Three records exist on this chain. Only one of them pays.

The oracle problem is not solved here, and cannot be. A licensed officer can be lied to, be lazy, or be paid off; a photograph can be of a different grove. What changes is the price of cheating: it now takes a licensed professional putting their registration behind a false statement, on a record with a timestamp they cannot backdate, for a payment the sponsor can see. That is not proof — it is a much worse deal for a fraudster than a spreadsheet, and that is the whole claim.

Have a garden of your own? Record it in a Grove app, then anchor the record here — you sign it with your own wallet, and only the hash ever leaves your phone.

Full write-up ↗ · Grove — the phone side ↗ · CamboVerse — the virtual side ↗

Build on this — deploy your own contract

CSB is a normal EVM chain behind a permission layer. Solidity, Hardhat and Foundry all work unchanged. Two things are different, and both are deliberate:

Your address must be allow-listed to transact Chain-level, below the contract layer. KYC decides who may hold tokens; the transaction allow list decides who may send a transaction at all.
And separately allow-listed to deploy Contract creation is restricted to vetted deployers. A factory contract that deploys other contracts needs this too — the create is performed by the factory's own address.

1. Get a scoped RPC URL — use Connect wallet above, or the Developer access page.

2. Ask an operator to enable your address on both allow lists. On this pilot that is the chain admin; in production it is a governed process.

3. Point your tooling at the chain:

// hardhat.config.js
networks: {
  csb: {
    url: "https://<this-host>/rpc/<your-token>",
    chainId: 8555,
    accounts: [process.env.PRIVATE_KEY],
    // Fixed price: must stay above the chain's fee floor, or a transaction
    // sits unmined and looks exactly like the chain being stuck.
    gasPrice: 55_000_000_000_000,
  },
}
npx hardhat run scripts/deploy.js --network csb

Developer guide — allow lists, RPC access, network config ↗
Source, contracts and deployment scripts ↗

Illustrative demonstrations on a test network. Every institutional role here — licensing registrar, social-policy authority, land authority, lender, grove authority, commune agriculture officer — is a hypothetical placeholder. No real programme, ministry, cadastre, parcel, grove, licence or beneficiary is represented, and no affiliation or endorsement is implied. Tree counts are counts, and carbon figures are estimates; nothing here is a carbon credit.