PRITOK
Bond registry and payouts on Solana. Pritok is Russian for "inflow": coupons and principal flowing to bondholders on schedule. The name also reads as PRIncipal + TOKens.
PRITOK services a tokenized bond after placement — the job of a registrar and a paying agent. It knows who held the bond on each record date, calculates what every holder is owed, and lets the platform operator execute each corporate action for all holders with one command: pay onchain or route to a bank, retire the bonds at maturity. It shows publicly when an issuer has not paid. Every entitlement and every payment can be checked in the Solana explorer.
Built for the Superteam Kazakhstan × KASE side track Corporate Actions on Blockchain. Independent prototype, not affiliated with KASE.
Try it in three minutes
- Open https://pritok-sol.vercel.app/demo and press New demo issue. The issuer's form sets face value, coupon rate, term (one to four semi-annual coupons) and issue size; the defaults create the standard demo issue in one click. The interface is in English by default; KZ · EN · RU in the header switches to Kazakh or Russian (or add
?lang=kk|en|ru to a link). In about 10 seconds the bond is created, three investors are admitted, and the issue is placed among them 30% / 20% / 50% (by default 1 000 bonds of 100 000 ₸ at 16%). Time is accelerated: one half-year lasts four minutes, so the whole two-year issue plays out in about 17 minutes.
- Follow the Now bar at the top. It reads the bond's state and offers the next step with a button that switches to the right role.
- Investor: transfer or sell bonds before the record date and watch the coupon follow the bond. Sell at a clean price and see the accrued interest the program adds.
- Issuer: fund a coupon, or fund only 75% to trigger a public default, then pay the rest to cure it. Declare a partial redemption on a future coupon date.
- Operator (platform operator: registrar and paying agent): the console lists every corporate action of the issue with its stage — register fixed, funded, executed. Execute payout pays a coupon to all holders with one command; the execution report shows each holder's payout with its onchain receipt and exports CSV. A holder can also claim earlier, to the wallet or To bank.
- Operator: confirm a bank transfer with a payment reference.
- At maturity the operator presses Execute redemption: principal and the last coupon go to each holder, and the program burns the bonds. A holder can still redeem by themselves.
- Portfolio shows the investor's side across all issues: invested, received, what is due now, a payout calendar.
How it works replays a 9-step tour of the screen. A ? next to a term explains it in plain language.
Coverage of the track requirements
| Requirement | How PRITOK does it | Where to see it |
|---|
| Test tokenized instrument with holder registry | Token-2022 bond mint, one holder record per wallet per bond, admission by the operator | Registry at date, operator console |
| Coupon payment: holders on the record date | Record-date balances frozen onchain at every balance change (see record dates) | Holder register as of |
| Coupon: calculate each investor's entitlement | units at record date × coupon per bond, per holder | Calculation panel of any event |
| Coupon: execute onchain or show a settlement flow | Both. The operator executes the payout for all holders with one command (pay_holder), or a holder claims; to the wallet in stablecoin, or to a paying agent with bank confirmation | Operator console, event card stages |
| Redemption: identify holders, principal due | Transfers close at the maturity record date; principal on the current face after amortization | Maturity event |
| Redemption: settle and retire tokens | redeem_for (operator) or redeem (holder) burns the bonds and pays principal + last coupon atomically | Operator console, "N redeemed and burned", journal |
| One additional corporate action | Partial redemption (amortization), plus secondary DvP trade with accrued interest and default & cure | Issuer screen, sale form |
| Verifiable onchain record | Receipt account per payout, every operation decoded in the journal with an explorer link | Journal, "to wallet ↗" receipt links |
| Clear line between implemented and simulated | Table below | — |
Architecture
flowchart LR
subgraph Solana devnet
P[pritok program]
B[(Bond account<br/>terms + event schedule)]
H[(Holder account<br/>per wallet per bond)]
C[(Claim receipt<br/>per payout)]
M[Token-2022 bond mint<br/>accounts always frozen]
V[Payment vault<br/>tKZT, owned by the bond]
P --- B & H & C
P -- thaw / move / freeze / burn --> M
P -- pays out --> V
end
W[Next.js web app<br/>registry, roles, portfolio] -- reads accounts + decoded history --> P
W -- demo signing, devnet only --> P
| Component | Role |
|---|
programs/pritok | Anchor program: 18 instructions, all corporate-action logic and money movement |
| Token-2022 bond mint | DefaultAccountState = Frozen; mint and freeze authority is the bond PDA |
| tKZT | Test tenge (classic SPL token, 2 decimals) used for placement, payouts and trades |
web/ | Next.js: public registry, operator console, issuer and investor screens, all-issues list, portfolio. Reads accounts and decodes the program's transaction history server-side |
client/ | TypeScript client shared with the web app, and a scripted end-to-end devnet scenario |
Accounts
| Account | Seeds | Holds |
|---|
Config | ["config"] | platform operator (registrar and paying agent), pause flag, allowed payment tokens |
Bond | ["bond", issuer, bond_id] | terms, current face factor, issued_units, supply, reserved obligations, up to 8 events sorted by record date |
| Bond mint | ["mint", bond] | Token-2022 mint, 0 decimals |
| Payment vault | ATA of the bond PDA | funded, not yet claimed obligations |
Holder | ["holder", bond, wallet] | admission flag, balance, record-date balances |
Claim | ["claim", bond, action_id, wallet] | one payout: units, amount, wallet / bank requested / bank confirmed, payment-reference hash |
Instructions
| Who | Instructions |
|---|
| Operator | init_config, allow_holder, revoke_holder, set_paused, pay_holder, redeem_for, claim_to_bank (for a holder), confirm_bank_payment |
| Issuer | create_bond (from the issuer's form), fund_action, declare_partial_redemption |
| Holder | subscribe, transfer_bond, trade_dvp (with the counterparty), claim, claim_to_bank, redeem |
| Anyone | close_subscription, mark_default |
Record dates
A Solana program cannot iterate over token holders, and an offchain snapshot is not verifiable. PRITOK records balances lazily instead.
- The bond keeps its events sorted by record date; each event has a stable
action_id and a position in that order.
- Before any change of a holder's balance — subscription, transfer, trade, redemption — the program writes the holder's current balance into a slot for every record date that has passed since the holder's last change.
- The holder's entitlement for the event at position i is that slot if it was written, otherwise the current balance: nothing has changed since the record date.
Example from the demo: Aigerim holds 300, Bolat 200, the fund 500. Aigerim sends 10 to Bolat before coupon 1's record date, and Bolat sends 10 to the fund after it. Coupon 1 is paid on 290 / 210 / 500; coupon 2 on 290 / 200 / 510.
Rules that keep this correct, each covered by a test:
- An ad-hoc event (partial redemption) can only be inserted with a record date in the future, so no holder has recorded a slot at or after its position yet.
- Units used for every entitlement are fixed when the subscription closes (
issued_units); later burns do not shrink what is owed.
- Transfers and trades are closed from the maturity record date, so the right to principal and the token to burn stay with the same holder.
- Bond token accounts are always frozen: a holder cannot move, burn, delegate or re-assign bonds directly through Token-2022. Every attempt fails with
AccountFrozen.
- The bond PDA is the mint's permanent delegate, so the program can burn bonds in an operator-run redemption. No person holds that right, and the program uses it only in
redeem_for, against a principal payment. Issues created before 2026-10-10 lack the extension; their holders redeem by themselves.
Entitlements
| Event | Per bond | Required from the issuer |
|---|
| Coupon | face × factor × coupon_rate / 2; the factor is the one in force for the whole coupon period | per bond × issued_units |
| Partial redemption | face × redeemed share | funded in full when declared |
| Maturity | face × current factor | per bond × issued_units |
| Accrued interest (trade) | next coupon × elapsed share of the period; zero between the record and payment dates | paid by the buyer |
Amounts are rounded down per holder; any dust stays in the vault. The issuer never withdraws from the vault.
Kazakhstan conventions
| Convention | Kazakhstan practice | PRITOK |
|---|
| Record date | Art. 31(2) of the Law "On the Securities Market": holders are fixed as of the start of the last day of the period the payment is for; older issues may keep a longer window set in their terms | record_offset_secs is set per issue: one day for a real issue, longer where the prospectus says so. The demo stretches it to 30 seconds out of a 240-second "half-year", so a transfer after the record date can be shown |
| Coupon amount | Day-count basis 30/360 is standard on KASE | A semi-annual coupon is face × rate / 2, which is what 30/360 gives for a full regular period |
| Accrued interest | 30/360 | Linear in actual time within the coupon period. Close to 30/360, but not identical around month ends. A 30/360 calendar for real-dated issues is on the roadmap |
| Rounding | Tiyn | Amounts are held in tiyn (2 decimals) and rounded down per holder |
Settlement flows
- Operator execution. After the payment date the operator runs
pay_holder for every holder of record, several per transaction: the vault pays each holder's own token account and creates the receipt. At maturity redeem_for pays principal and the last coupon and burns the bonds. The money can only go to the holder's own account.
- Wallet payout. A holder can also claim by themselves; the same receipt account is created. A second payout fails because the receipt already exists, whoever started it.
- Bank payout. The holder (or the registrar for a holder without a wallet) chooses the bank: the holder's share moves from the vault to the paying agent onchain, and the receipt is marked bank requested. After the bank transfer the paying agent confirms it; only a SHA-256 of the payment reference is stored. A payout goes to the wallet or to the bank, once.
- Default and cure. If an event is underfunded on its payment date, anyone can mark it defaulted and the debt is public. Claims stay closed until the issuer pays the full amount; the debt is never written down.
- Secondary trade (DvP). Seller and buyer sign one transaction: bonds to the buyer and money to the seller, atomically. The parties set the clean price as a share of the outstanding face; the program adds accrued interest and enforces the buyer's maximum total. The trade is logged as a
TradeSettled event.
- Redemption. At maturity the holder redeems: the bonds are burned, principal is paid, and the last coupon too if it is funded and not yet claimed. Otherwise that coupon stays claimable from the record-date balance.
The vault invariant vault balance ≥ funded and unclaimed obligations is checked after every money movement.
Roles and rights
| Role | Can | Cannot |
|---|
| Issuer | create the bond, fund events, declare partial redemptions | change terms or the schedule alone, touch the registry, withdraw from the vault |
| Platform operator (registrar and paying agent) | execute payouts and redemptions to holders' own accounts, route a holder's payout to the bank, admit and revoke holders, pause subscriptions and transfers, confirm bank payouts | issue bonds, change terms, send investors' money anywhere but their own account or the paying agent |
| Holder | subscribe, transfer, trade, claim to the wallet or the bank, redeem | change anything about the bond |
| Anyone | mark an underfunded event as defaulted, read everything | — |
Revocation and pause never cancel a payout that already exists: a revoked or paused holder still receives recorded coupons and principal.
Implemented vs simulated
| Implemented onchain | Simulated |
|---|
| Bond token, holder registry, admission and revocation, pause | KYC: the registrar simply admits an address |
| Record dates, entitlements, coupons, partial redemption, maturity with burn | tKZT instead of a real tenge stablecoin; the payment token is a parameter, so KZTE or another stablecoin replaces it without code changes |
| Default, public issuer debt and cure | Accelerated time: a "half-year" is minutes |
| Bank payout up to the paying agent, confirmation with a payment-reference hash | The bank transfer itself: the confirmation is the paying agent's statement |
| DvP trade with program-computed accrued interest | Price discovery: the parties agree the clean price; there is no order book |
| — | Demo signing: the web server signs with devnet demo keys; in production each party signs on its own device or through a broker or custodian |
Screens
Operator console: every corporate action of the issue with its stage. Coupon 1 executed for all three holders, coupon 2 funded and ready to execute with one command, later events waiting for the issuer.
| |
|---|
| |
| Issuer's form: face value, coupon, term and size, with the coupon per bond and what the issuer raises and pays back | Investor portfolio: result, payouts due now, next payout, calendar, holdings, history |
Testing and review
- 21 tests (
cargo test -p pritok). Integration tests run the compiled program on LiteSVM with a controllable clock:
- direct Token-2022 bypasses fail with
AccountFrozen;
- transfer before and after a record date;
- skipped record dates;
- partial redemption inserted after holders have synced;
- transfer lock at the maturity record date;
- double claim;
- default and cure;
- redemption before the last coupon is funded;
- recreation of a closed empty token account;
- bank payout and confirmation;
- revocation and pause;
- DvP with accrued interest, ex-coupon, buyer limit and pause;
- operator execution for all holders, including a revoked holder, with no double payment against a holder's own claim;
- operator redemption: principal and last coupon to the holder, bonds burned by the program.
- Two rounds of independent design review before the code was written (see
docs/REVIEW-BRIEF.md and docs/PLAN.md). The first round replaced a transfer hook with always-frozen accounts after finding bypasses via owner burn and SetAuthority. The second fixed amortization timing, fixed issued_units, restricted payment mints and added the vault reserve.
- Complete lifecycles run on devnet: three bonds from placement to redemption, one of them entirely through the web app's action API.
Limitations and next steps
- Admission is per bond. In a real market an investor passes KYC once. Next step: an investor registry shared across issues.
- Bank confirmation is an attestation. A production integration needs reconciliation with the paying agent's bank statement.
- At most 8 events per bond: 4 coupons, maturity and up to 3 partial redemptions.
- No tax withholding. Payouts are gross. In Kazakhstan the broker or paying agent often acts as tax agent and withholds tax on coupons, for example for non-residents. In a pilot that role stays with the paying agent or broker: the program would pay it the gross amount and the agent pays holders net.
- Next: KZTE or another tenge stablecoin as the payment token, coupons per year as an issue parameter (today semi-annual), 30/360 accrued interest on real dates, bondholder voting, a yield-to-maturity display.
Build and run
Anchor 0.32.1, Agave 3.1.12, Rust 1.89.
anchor build
cargo test -p pritok
On Windows, scripts/wsl-test.sh builds and tests in the WSL filesystem, which is much faster than /mnt/c.
Web app:
cd web && npm install
cp .env.example .env.local # RPC_URL: a dedicated devnet RPC; DEMO_SIGNING=1 for the role buttons
npm run dev # http://localhost:3100
With DEMO_SIGNING=1 the server signs with devnet demo keys: locally from client/.keys, on a host such as Vercel from DEMO_KEYS (JSON of secret-key byte arrays; Root Directory web). Anyone with the link can press the buttons, so use it on devnet only. The public devnet RPC rate-limits the registry reads; use a dedicated endpoint such as Helius.
Scripted scenarios:
cd client && npm install
npm run scenario # full lifecycle, about 11 minutes
MODE=setup npm run scenario # create and place a bond, continue from the UI
../scripts/drive-sandbox.sh <bond> # drive a setup bond to maturity through the web API
Repository
programs/pritok/ Anchor program and LiteSVM tests
client/ TypeScript client and the devnet scenario
web/ Next.js app: registry, role screens, issues list, portfolio
docs/PLAN.md plan, design decisions and status (Russian)
docs/REVIEW-BRIEF.md brief used for the independent design review
scripts/ WSL build and test, sandbox driver
Кратко по-русски
PRITOK — реестр держателей и платёжный агент для токенизированных облигаций на Solana.
- Дата фиксации: программа сама запоминает балансы держателей, без снимков вне блокчейна.
- Выплаты: права считаются по каждому держателю. Купоны и номинал идут на кошелёк в стейблкоине или через банк с подтверждением платёжного агента.
- Дефолт эмитента виден всем и не списывается.
- Погашение: облигации сжигаются, держатель получает номинал.
- Вторичный рынок: сделка «поставка против оплаты», НКД считает программа.
Демо: https://pritok-sol.vercel.app. Нажмите «Новый демо-выпуск» и следуйте подсказке «Сейчас».
