Superteam Kazakhstan x KASE · Corporate Actions on Blockchain

Bonds keep trading through the record date, and Blum still pays every coupon to the right holder

One Solana program services a tokenized bond from issue to redemption: it keeps the register, pays coupons, redeems, and runs a buyback and a tender offer. Every step below ran on Solana devnet.

IssueA Token-2022 bond, placed with registered holders TradingEvery transfer saves positions at record moments 4 couponsPaid to whoever held the bond at each record moment; a buyback and a tender offer along the way RedemptionPrincipal paid and bonds burned together

SiteLive demonstration CodeGitHub repository DevnetThe program DocTechnical overview

Arrow keys, space or scroll. Every box and dot is a link to its proof.

2 · The track's requirements

Every requirement of the track has code and a devnet run behind it

The listing asks for	Devnet	Slide
Test tokenized instrument		5
Holder registry		6
Record-date mechanism		3, 4
Entitlement calculation		7
Coupon payment		8
Bond redemption		9
One additional corporate action		10
Verifiable on-chain record		11
Implemented versus simulated	n/a	16
Technical overview	n/a	17

Each dot opens its proof: a line of code, a devnet transaction or account, a page of this site. Results in one place: slide 15.

3 · The problem

The bond keeps trading after the record moment, so paying payment-day holders pays wrong amounts

Kazakhstan's depository pays whoever held the bond at 09:00 on the payment day and does not stop trading. A Solana program cannot snapshot every holder at 09:00 in one step, and a list made off chain would let an off-chain party decide who is paid.

09:00 record momenttrades go onpayment BH#45812 bondssold 3 to BH#43, then more6 bonds BH#435 bondsbought 3, then sold4 bonds

Paid by the 09:00 list: Blum, measured

BH#458, 12 x 50600.00

BH#43, 5 x 50250.00

Paid by holdings at payment: wrong

BH#458, 6 x 50300.00

BH#43, 4 x 50200.00

Across the 1000-holder run, paying by holdings at payment would have got 1,039 of 4,000 coupon payments wrong. The two payments above are links to their transactions.

DevnetBH#458 sells 3 to BH#43 SiteStages: the record moment DocThe depository's rule, with sources

4 · Record-date mechanism

Each transfer first saves both holders' positions for the record moments that have passed

BH#458 sends 3 bondsA Token-2022 transfer, right after record moment 0

Token-2022 calls the programThe bond's transfer hook

Save firstBH#458: 12 and BH#43: 5, for record moment 0

Then the bonds moveBH#458: 9, BH#43: 8

BH#458 trades

09:00: holds 12

Sells 3The hook saves 12 first

Paid on 12: 600.00

BH#9 never trades

09:00: holds 10

No transferNothing to save

Paid on its current 10: 500.00

Either way the program knows each holder's position at 09:00: no snapshot, no freeze, and nobody has to act at 09:00.

SiteFlow: this transfer, step by step SiteProgram: the position history CodePositionHistory CodeThe transfer hook

5 · Test tokenized instrument

The bond is a Token-2022 token, and every power over it belongs to the program

MintThe program: to registered holders, before the first record moment, up to the issue size

Bond token1 token = 1 bondface 1,000, 10% a year, paid twice a year, 2 years

Transfer hookThe program: runs inside every transfer

BurnThe program only (permanent delegate, permissioned burn), always with a payment

FreezeNobody: the token has no freeze authority

At creation the program also checks the payment and record days against the terms, and refuses a cash token that could shrink or take a payment.

SiteFlow: create_bond SiteProgram: create_bond CodeThe cash token check DevnetThe 1000-holder bond

6 · Holder registry

Only registered wallets can hold the bond

The registrar creates one holder record per wallet (KYC is simulated). The transfer hook checks both sides of every transfer.

A transfer is sentFrom BH#458

The hook checksBoth sides have a holder record; each uses its one bond account

To BH#43: movesregistered To an unregistered wallet: refusedAccountOwnedByWrongProgram To its own second account: refusedNotAssociatedTokenAccount

1,000 registered holders on devnet. Each box above opens its transaction.

SiteProgram: register_holder Coderegister_holder CodeHolderRecord

7 · Entitlement calculation

The program computes each payment from the terms and the record-moment position

10bonds at the record moment

1,000face

10%a year

2payments a year

= 500.00BH#9's first coupon

10bonds at maturity

1,000face, at par

= 10,000.00BH#9's principal+ 500.00BH#9's final coupon

The listing's own example on one holder: BH#9 held 10 bonds from the first coupon to maturity and never traded. Rounded down once per holder; each coupon's budget uses the same formula on the whole supply, so payments never exceed it. 4,000 of 4,000 amounts in the 1000-holder run match the terms; the math matches QuantLib and FinancePy.

SiteProgram: amounts Codecoupon and principal CodeQuantLib and FinancePy check

8 · Scenario 1: coupon payment

A coupon is paid from its own vault, and only once that vault can pay everyone

open_eventAnyone, after the record moment. Creates the coupon's own vault, owned by the program. Budget: 512,550.00 FundingThe issuer fills the coupon's own vault (simulated bank) confirm_fundingAnyone: vault holds the whole budget, or nobody is paid pay_coupon x 1,000Anyone, any order. Cash and the paid mark in one transaction: never twice

Vault: 0.00All 1,000 holders paid

4 coupons, 2,003,300.00 paid to 1,000 holders; every vault emptied.

SiteFlow: pay_coupon SiteTimeline: one bond, step by step Codepay_coupon

9 · Scenario 2: bond redemption

At maturity, bonds are burned and principal is paid in the same transaction

Final record momentThe hook closes trading

one transaction: redeem_holder

BH#9's 10 bonds

Burnedsupply -10

Redemption vault

10,000.00 to BH#9

Final coupon, separately500.00 to BH#9

Both or neither: no bond is burned unpaid. 9,665 bonds from 918 holders redeemed; final supply 0.

SiteFlow: redeem_holder SiteStages: redemption Coderedeem_holder

10 · Scenario 3: the additional corporate action

Tendered bonds still earn their coupon, and the issuer buys exactly its maximum

Offer funded410 bonds x 1,000.00, in the offer's own vault

Window: 441 tendered132 holders. Bonds stay in their accounts, locked

Record moment 2, inside the windowCoupon 2 paid on the locked bonds: 132 of 132

Resolved pro rata, in tender orderEach tender gets its share of 410 / 441: 410 accepted, 31 released

SettledBurned and paid 410,000.00: exactly the maximum

Also a buyback, first come first served: 176 bonds at 990.00, each sale burned and paid in one transaction.

SiteFlow: tender, resolve, settle SiteProgram: the tender rule CodeOffer::accept_next DocBuyback and tender design

11 · Verifiable on-chain record

The ledger is the record, and an audit that never reads the program re-checks it

The programEvery step is a transaction; events such as CouponPaid in its log

Solana ledgerPublic transactions and token balances

Ledger-only auditPlus the run's scenario file. Never the program's accounts or the operator's report

3,959 of 3,959 checks pass1000-holder run

0.000001 slipped into a vault: 2 checks failTamper test, on a local network

Every balance and payment is checked against the bond's terms to the smallest cash unit.

SiteStages: the audit DocHow the audit works Codeaudit.py Doc1000-holder run: every account and transaction

12 · Servicing does not depend on our operator

Any wallet can continue servicing the bond: ours stopped after coupon 0, and an outside wallet finished it

Coupon 0Coupon 1Coupon 2Coupon 3RedemptionOur operatorpaidOutside wallet, no rolepaid paid paid paid

Keeper run, a separate 3-holder bond. Amounts come from on-chain positions, so the sender cannot change who is paid or how much. Audit of this run: 23 of 23.

DevnetThe outside wallet DocKeeper run: accounts and transactions

13 · Attacks

35 attacks on devnet, 35 refused

Holder11 refused

take-bonds take-as-delegate burn-bonds burn-permissioned burn-as-program freeze-holder redirect-coupon claim-as-owner redirect-principal sell-others-bonds delegate-cash-token

Issuer13 refused

mint-bonds mint-as-program place-late place-beyond-issue pay-twice late-buyer redeem-twice other-vault coupon-from-principal over-maximum sell-tendered drain-vault drain-as-program

Depository8 refused

Bank2 refused

fee-cash-token frozen-cash

Exchange1 refused

trade-at-maturity

Attacker run, a separate 6-holder bond. Solid tiles were refused by the bond's own program (22); dashed tiles by Solana's token programs or runtime (13). Each tile is a failed transaction anyone can open. 21 more are refused in local tests. Trusted, not stopped: the registrar, the cash issuer's freeze, and the program's upgrade authority.

SiteParties: what was refused, per party DocEvery attempt, explained CodeThe attacker run

14 · Real-world applicability

Market rules are terms of the bond, not code, so fixed-rate bonds from any market can be serviced

Kazakh depository ruleThe bond's term

Holder list at 09:00 Almaty on the payment day

Record time 09:00, UTC+5, record day = payment day

Trading goes on during coupon day

Transfers stay open; the hook saves positions

Trading stops for redemption

Transfers close at the final record moment

Payments move off weekends and holidays

Weekend days and a holiday calendar file

For MUM108_0015, a real KASE bond, the computed payment dates equal KASE's published ones.

SiteStages: each rule next to its measurement DocThe depository's rules, with sources CodeMUM108_0015 dates equal KASE's

15 · Results on devnet

1,000 holders, every bond accounted for: 10,251 placed, 0 left

10,251bonds placed with 1,000 holders

-176buyback: 174,240.00 paid

-410tender: 410,000.00 paid

-9,665redemption: 9,665,000.00 paid

0bonds left

2,003,300.004 coupons paid; 4,000 of 4,000 amounts exact

2,318transactions, including 600 trades right after record moments

3,959 / 3,959ledger-only audit checks

833–2,500lamports to pay one holder one coupon, with no new storage

Doc1000-holder run: every account and transaction SiteParties: what each party expects, measured

16 · Implemented versus simulated

Everything on Solana is real; only the cash, KYC and the trading venue are simulated

On Solana devnet: implemented

Bond tokenHolder registryPositions at record momentsEntitlementsCoupon vaultsCoupon paymentRedemption with burnBuybackTender offerEvents and accountsServicing by any wallet

Simulated: cash and the issuer's bankA test token minted into the vaults, standing for fiat or a stablecoin

Simulated: KYCThe registrar registers generated wallets, BH#1 to BH#1000

Simulated: the trading venueTrades are direct transfers: no order book, no cash leg

Devnet time is compressed: 1 bond day = 1 to 20 seconds. Limits: fixed-rate bonds, up to 40 coupon periods, direct holders; the registrar and the program's upgrade authority, a single wallet, are trusted.

DocImplemented vs simulated DocTechnical overview: limits

17 · Technical overview

One repository: the program, the checks that doubt it, and this site

Scenario fileTerms, holders, trades, offers

OperatorSends each step on time

bond_servicingAnchor program on devnet; uses bond_math

Solana ledger

Report checkQuantLib, FinancePy

Ledger-only audit

This siteBuilt from measured data

36 + 5program tests on the compiled program

14 + 6bond math tests, against QuantLib and FinancePy

327271f3…sha256: the program on devnet is a build of the repository, byte for byte

DocTechnical overview SiteProgram: the code as flowcharts CodeGitHub repository CodeThe tests

Or press Claude or ChatGPT at the top: your own AI reads the sources and explains them.