programs/khaata · Anchor · v1

How a Khaata payment actually works.

A cashier creates an order. Khaata signs a message describing exactly that order — amount, fee, expiry, identity — and hands the customer a transaction to approve. A Solana program checks the signature, checks the order, and moves the money. The database records what the chain did; the chain never consults the database.

Verified against the source: the Anchor program at programs/khaata/src/lib.rs and the SDK at packages/sdk. If the code and this page disagree, the code wins.

The server signs the invoice

Creating an order returns a per-order reference keypair and an expiry slot. The server then signs a fixed 127-byte message — the prefix khaata:pay_invoice:v1, then the fields below — with the platform cashier key. That signature is an attestation: Khaata is stating, in a form the program can check, “this is the invoice I created.”

Field	Type	Why it matters
merchant	pubkey	Whose invoice this is — and whose payout address receives it.
order_id	bytes16	The order reference. Binds the ledger row to the settlement.
expected_amount	u64	Base units. The customer can neither underpay nor overpay.
fee_bps	u16	Must equal the merchant's on-chain fee, or the program rejects it.
expiry_slot	u64	A slot deadline. On-chain — not a database timestamp.
reference	pubkey	The per-order PDA. One invoice, one account.
tip_amount	u64	Optional; splits to the same payout address as the sale.

The QR is a transaction request

The QR encodes a Solana Pay link — solana:https://…/api/orders/<id>/pay — not an address. When the customer scans, their wallet fetches a complete Solana transaction from that endpoint: compute budget, create token account setup, the ed25519 attestation instruction, then pay_invoice.

# the transaction the wallet receives

0 ComputeBudget · set_compute_unit_limit 200_000

1 ComputeBudget · set_compute_unit_price

2 create_associated_token_account × 0–2 # payer-funded setup

n ed25519 · # the attestation, at a recorded index

n+1 pay_invoice · transfer → merchant · transfer → treasury

Nothing is left for the payer to edit. The wallet's job is approve or decline.

The program enforces everything

pay_invoice is the source of truth for money. It verifies the attestation at the index the server declared (so a wallet cannot reorder instructions), then runs the checks below before moving anything. Any single failure aborts the whole transaction.

Not paused
The platform admin can pause the program. New payments stop; nobody's existing funds are touched.
Exact amount
The transfer amount comes from the signed attestation, not from the payer. Underpaying and overpaying are not states the program can reach.
Right mint
Only the USDC mint recorded in the Config PDA. A different token fails here.
Right fee
The attested fee basis points must equal the merchant's on-chain fee, so a fee cannot be inflated or skipped after the fact.
Registered cashier
The ed25519 signature must come from the cashier key registered on the merchant account, verified at the instruction index the attestation itself declares.
Not expired
clock.slot <= expiry_slot. The deadline is Solana's clock, never Khaata's.
Distinct accounts
Payer, payout, and treasury token accounts must all differ, so the split cannot be collapsed into a self-transfer.
Owned by the right authorities
Each token account is validated against its expected owner and mint before a single base unit moves.

Settlement, then the ledger

On success the customer's USDC becomes two transfers inside one transaction: the merchant's share to their own payout token account, the platform fee to the treasury. The Order PDA records the paid amount and the payer, and the program's events are indexed into Postgres — where the dashboard, receipts, and exports live as mirrors, never as authority.

Three paths to the same ledger row

Helius webhookNormally, within a second
Signature-deduplicated into a durable inbox before processing. Failed attempts retry with bounds and then dead-letter rather than vanishing.
Status pollWhile a screen is open
The customer's and cashier's poll reads the chain directly for any order still pending after three seconds — so a missed webhook resolves itself.
Reconcile cronEvery minute
Leases fair, due-time-ordered batches so concurrent runs neither duplicate RPC work nor starve older orders, and replays the dead-letter queue.

A reverted transaction still emits logs, so settlement requires a succeededstatus before the ledger is touched. And “we could not reach the server” is never rendered as “the payment did not happen” — that distinction was a real double-charge path.

Verification without trust

The receipt is the signature. Anyone holding an order link can confirm the payment on Solana without Khaata's cooperation — the explorer link, the payout address, the exact amount, the timestamp, and the program's event are all public. The refund path is sequence-guarded and owner-only, and the refund window is measured in Solana blocks, not calendar days.

Without Khaata	The signature, the payout address, and the amount are on-chain. Verify any single payment without contacting anyone.
With Khaata	The receipt page reassembles line items and totals from the settled order — the human-readable view, not the truth.
Without Solana	Nothing settles. The program would not exist, and neither would the guarantee.
What Khaata holds	No funds and no keys. Sessions are digests; the cashier signing key is server-side and never in the browser.

Boundaries

What Khaata is not yet, stated plainly.

The cashier signing key is shared: Every merchant registers the same platform key today. A leak cannot steal funds — it can only author invoices for every merchant at once. Per-merchant keys are tracked as required before real money.
Tips are not yet refundable: The refund ceiling is the invoice amount. The program change to include tips is the tracked blocking item for production.
V1 is single-token: USDC only, exact amount. Multi-token, Jupiter, and partial payments each bring custody and pricing implications that belong after real counter reliability data.
The refund window is on-chain: Roughly three to four weeks, in slots. Past it the network rejects the refund and Khaata cannot override that — by design.
Not audited yet: The program has internal review and a full test suite, not an external audit. That is explicitly among the items before mainnet.

Why this chain

The counter sets the requirements.

Sub-second confirmation: The sale clears while the customer is still at the counter.
Fees under a cent: The customer's transaction pays for itself; the sale's margin is not the fee.
One atomic transaction: Merchant share and fee split are legs of the same instruction.
USDC natively: Merchants price in what they understand, not in instrument exposure.

programs/khaata · Anchor · v1

How a Khaata payment actually works.

Verified against the source: the Anchor program at programs/khaata/src/lib.rs and the SDK at packages/sdk. If the code and this page disagree, the code wins.

The server signs the invoice

Field	Type	Why it matters
merchant	pubkey	Whose invoice this is — and whose payout address receives it.
order_id	bytes16	The order reference. Binds the ledger row to the settlement.
expected_amount	u64	Base units. The customer can neither underpay nor overpay.
fee_bps	u16	Must equal the merchant's on-chain fee, or the program rejects it.
expiry_slot	u64	A slot deadline. On-chain — not a database timestamp.
reference	pubkey	The per-order PDA. One invoice, one account.
tip_amount	u64	Optional; splits to the same payout address as the sale.

The QR is a transaction request

# the transaction the wallet receives

0 ComputeBudget · set_compute_unit_limit 200_000

1 ComputeBudget · set_compute_unit_price

2 create_associated_token_account × 0–2 # payer-funded setup

n ed25519 · # the attestation, at a recorded index

n+1 pay_invoice · transfer → merchant · transfer → treasury

Nothing is left for the payer to edit. The wallet's job is approve or decline.

The program enforces everything

Not paused
The platform admin can pause the program. New payments stop; nobody's existing funds are touched.
Exact amount
The transfer amount comes from the signed attestation, not from the payer. Underpaying and overpaying are not states the program can reach.
Right mint
Only the USDC mint recorded in the Config PDA. A different token fails here.
Right fee
The attested fee basis points must equal the merchant's on-chain fee, so a fee cannot be inflated or skipped after the fact.
Registered cashier
The ed25519 signature must come from the cashier key registered on the merchant account, verified at the instruction index the attestation itself declares.
Not expired
clock.slot <= expiry_slot. The deadline is Solana's clock, never Khaata's.
Distinct accounts
Payer, payout, and treasury token accounts must all differ, so the split cannot be collapsed into a self-transfer.
Owned by the right authorities
Each token account is validated against its expected owner and mint before a single base unit moves.

Settlement, then the ledger

Three paths to the same ledger row

Helius webhookNormally, within a second
Signature-deduplicated into a durable inbox before processing. Failed attempts retry with bounds and then dead-letter rather than vanishing.
Status pollWhile a screen is open
The customer's and cashier's poll reads the chain directly for any order still pending after three seconds — so a missed webhook resolves itself.
Reconcile cronEvery minute
Leases fair, due-time-ordered batches so concurrent runs neither duplicate RPC work nor starve older orders, and replays the dead-letter queue.

Verification without trust

Without Khaata	The signature, the payout address, and the amount are on-chain. Verify any single payment without contacting anyone.
With Khaata	The receipt page reassembles line items and totals from the settled order — the human-readable view, not the truth.
Without Solana	Nothing settles. The program would not exist, and neither would the guarantee.
What Khaata holds	No funds and no keys. Sessions are digests; the cashier signing key is server-side and never in the browser.

Boundaries

What Khaata is not yet, stated plainly.

The cashier signing key is shared: Every merchant registers the same platform key today. A leak cannot steal funds — it can only author invoices for every merchant at once. Per-merchant keys are tracked as required before real money.
Tips are not yet refundable: The refund ceiling is the invoice amount. The program change to include tips is the tracked blocking item for production.
V1 is single-token: USDC only, exact amount. Multi-token, Jupiter, and partial payments each bring custody and pricing implications that belong after real counter reliability data.
The refund window is on-chain: Roughly three to four weeks, in slots. Past it the network rejects the refund and Khaata cannot override that — by design.
Not audited yet: The program has internal review and a full test suite, not an external audit. That is explicitly among the items before mainnet.

Why this chain

The counter sets the requirements.

Sub-second confirmation: The sale clears while the customer is still at the counter.
Fees under a cent: The customer's transaction pays for itself; the sale's margin is not the fee.
One atomic transaction: Merchant share and fee split are legs of the same instruction.
USDC natively: Merchants price in what they understand, not in instrument exposure.

How a Khaata payment actually works.

The server signs the invoice

The QR is a transaction request

The program enforces everything

Settlement, then the ledger

Verification without trust

What Khaata is not yet, stated plainly.

The counter sets the requirements.

How a Khaata payment actually works.

The server signs the invoice

The QR is a transaction request

The program enforces everything

Settlement, then the ledger

Verification without trust

What Khaata is not yet, stated plainly.

The counter sets the requirements.

Building with, or selling with, Khaata?