Live on Solana devnet

Every coupon, redemption and bondholder vote, executed on-chain

Record date, per-holder entitlements, escrowed settlement and ISO 20022 reporting for tokenized bonds, under Kazakhstan market rules.

Last completed payoutOn-chain
BTRK-tmnc80MCAL · Early redemptionCompleted
Total paid
10.208236USDC
3 holders paid· Oct 9, 2026
All 6 steps on-chain2pTE…KdJs

Follow one coupon to the last tenge

The issuer funds an escrow; the program pays each holder their exact share, sends withheld tax to the tax vault and bank payouts through the paying agent. Band widths follow the money; every leg is a transaction.

On-chainTerms on this page:Record dateThe moment that decides who gets paid: whoever holds the bond then receives the coupon, even if they sell it afterwards.EscrowA program-owned account the issuer funds before payment. Money can only leave it to the holders, the tax vault or the paying agent recorded on-chain.EntitlementWhat one holder is owed for one action: units × amount per bond, gross, tax and net, rounded half-up per holder.Tax vaultWhere withholding tax goes at source, per the holder's investor class, before the net amount is paid.Paying agentThe bank that receives payouts for holders who chose a bank route and confirms the transfer with a reference. Bank transfer is simulated.Permissionless stepAny wallet can push this step forward. The program checks every rule, so nobody — not even the issuer — can stall a funded payment.

BTRK-tmnc80 · MCAL

Paid out 10.208236USDC
Issuer
BTRK-tmnc80
Funded
10.208236USDC
Escrow
10.208236USDC

Proven on devnet

Verified on-chain
Verified build hash
4a2e46778847f8b6277194a74ee89e9145fc8c03f8e4e8c9ede3bdda752a3505
Demo runs · 2026-10-09
28 transactions — every plan-15 instruction succeeded
60 transactions — the full bond lifecycle

The program on devnet is the binary built from this repository — reproducibly, in Docker. Nothing on this page is a mock-up.

Verify the build yourself

One command rebuilds the program in Docker and compares its hash with the binary deployed on devnet.

cargo install solana-verify --locked
solana-verify verify-from-repo https://github.com/savvax/qupon \
  --program-id QPN1zdVm6PgMdJo4YxemtDxxbUczqaAk9sDsJQsJ2qd \
  --library-name qupon_bonds \
  --base-image solanafoundation/solana-verifiable-build:4.3.0

Docker required. On any mismatch solana-verify exits non-zero.

Beyond a coupon

A coupon is the smallest thing Qupon does. The plan-15 mechanics below each ran for real on devnet — follow the transaction.

  • Default and cure

    The issuer missed the payment date. One series day later anyone declared the default on-chain; the issuer's late funding cured it, and the record-date holders were still paid in full.

  • Paid to your bank

    Simulated

    Only the holder's own signature chooses the payout route. This coupon went to the paying agent, who confirmed the transfer with a reference hash — the bank transfer itself is simulated.

  • Anyone can push the next step

    Snapshot, payout, completion — every crank step is permissionless. This snapshot was pushed by an outsider key, not by the registrar or the issuer.

  • Accrued interest on every trade

    A DvP trade between coupon dates carries its accrued interest: clean 4,975.00 ₸ + accrued 25.00 ₸ = a 5,000.00 ₸ cash leg, computed by the program.

  • The notice is anchored

    The sha256 of the seev.031 notice is anchored on-chain once; attaching it a second time is rejected. Download the notice and compare the hash yourself.

From record date to payout in five on-chain steps

  1. Register

    Investors pass KYC; the provider attests it on Solana (SAS) and the registrar admits the wallet.

  2. Record date

    The bond mint is paused and every holder's position is snapshotted on-chain.

  3. Entitlements

    Per-holder amounts under 30E/360, rounded half-up, with resident and non-resident tax.

  4. Escrow & payout

    The issuer funds an escrow; payouts run in batches and withheld tax goes to a tax vault.

  5. Report

    ISO 20022 seev.031 / seev.036 files and a KASE-style notice are generated from chain state.

Everything around the engine, for every participant

  • Accounts and KYC

    Investors sign up, link their own wallet by signature and apply with documents; the registrar's approval attests the wallet on-chain.

  • kase.kz data

    Bond terms, schedules and market data from kase.kz: one-click import into a new series and a check of every record date against KASE.

  • Tenge on Solana

    Settle in any registered token: test tenge stand-ins on devnet, Evo's KZTE ready for mainnet, or USDC. Each mint is verified on-chain.

  • Notifications

    Holders hear about new actions, meetings and payments the moment they land on-chain, in the language they chose.

  • Admin panel

    Users and organisations, series visibility, cash assets, system health and a searchable audit trail with CSV export.

  • Mainnet-ready

    Same code, a network profile per deployment: demo access off and a typed confirmation for every write on mainnet.

Scenarios

The corporate actions a bond actually lives through

INTR

Coupon

1,000 ₸ face, 10% paid semi-annually. Holders of 10, 25 and 65 bonds receive 500, 1,250 and 3,250 ₸.

REDM

Redemption

At maturity holders receive the principal plus the final coupon; the bonds are burned and the series is closed.

BMET

Bondholder meeting

Holders vote with snapshot weights to raise the coupon from 10% to 12%; quorum and majority are checked on-chain.

MCAL

Early redemption

The issuer calls the bonds early; interest accrued over the 47 days since the last coupon is paid with the principal.

For issuers

  • Issue a series from its terms in minutes
  • Fund each coupon into escrow, the registrar does the rest
  • Call bondholder meetings and change terms with a full audit trail

For investors

  • Holdings, next coupon and every payout with its transaction
  • Subscribe at par with delivery versus payment
  • Vote in bondholder meetings from your own wallet

What is real, what is simulated

On-chain

Running on Solana devnet: the program enforces it and every step is a transaction.

  • Bond token, holder registry, record date, entitlements, coupon payment, redemption, burn and close, voting, terms change, on-chain eventsImplemented

    Running on Solana devnet.

  • Secondary settlementImplemented

    Trades between registered investors settle on devnet through the Solana Foundation's DvP program; Qupon admits the escrow, refuses a record date while a trade is open and can return the bonds to the seller. Order matching and a trading venue are not included.

Simulated

Stand-ins for outside systems, labelled wherever they appear. Nothing real leaves the demo.

  • Cash legTest tokens

    Real token transfers from an admin-managed registry: devnet USDC (Circle), tKZT and two tenge stand-ins (KZTE-dev, dKZT) with an investor faucet. Evo's KZTE is pre-registered for mainnet, off until its official mint is added.

  • KYCReview simulated

    Investors upload documents and a registrar decides by hand, with no licensed KYC vendor. Approval is real: a Solana Attestation Service attestation and the on-chain registration.

  • ISO 20022 seev.031 / seev.036Delivery simulated

    Generated from on-chain state; Swift delivery is replaced by downloadable files.

  • KASERead only

    Bond data is read from kase.kz and cached; the disclosure notice and package are generated automatically. Submission to KASE is simulated.

Roadmap

Designed, not built yet.

  • ARDFM registration of a terms changeSimulated

    Represented by a registrar signature step.

  • MainnetReady, not deployed

    Network profile, write confirmations and a dry-run deploy script are in place; everything runs on devnet.

  • Multisig issuer approval (Squads)Roadmap

    Planned.

Meeting thresholds (quorum 50%, approval ⅔ of votes cast) are series configuration, not a statement of Kazakh law.