KharchaPay Whitepaper
Finance Autopilot for Organizations — Budgets, Approvals, Payments, and Verifiable On-Chain Proof
1. What KharchaPay Is
KharchaPay is an expense and payment management system for organizations. It connects budgets, approval workflows, and on-chain payments with a canonical memo format so every payout can be verified against the blockchain. Finance teams use it to enforce policies, control spending, and maintain a complete audit trail from request to payment to reconciliation.
2. The Finance Autopilot Loop
The core flow is a closed loop:
- Budget — Monthly budgets per department; requests are checked against remaining budget before approval and payment.
- Request — Staff create expense requests (title, purpose, category, amount, department, vendor).
- Approval policy — Tiered approval (e.g., 1 approver up to a threshold, 2 above). Approvers see pending requests and approve or reject.
- Pay — Admins execute payment only for approved requests that meet policy (receipt, budget, vendor status). Payment is a Token-2022 transfer with a required memo.
- Tx + Memo — Each payment includes an on-chain memo tying the transaction to the request and org. The transaction signature is stored as
paidTxSig. - Reconciliation — Reconciliation runs against the chain to verify memo, amount, source, and destination. Results are stored with status VERIFIED, WARNING, or FAILED.
- Audit & exports — All key actions are audited. CSV exports include payments, requests, and budget vs actual, with verification status.
3. Roles & Permissions
Separation of duties is enforced via four roles:
| Role | Capabilities |
|---|---|
| ADMIN | Full access: create/update org settings, departments, budgets, vendors; manage members; configure approval and spend policy; execute payments; run reconciliation; chain operations. |
| APPROVER | Approve or reject requests; cannot execute payments or change org configuration. |
| REQUESTER (STAFF) | Create and manage own expense requests; submit for approval; upload receipts. Cannot approve or pay. |
| AUDITOR | Read-only: view requests, payments, audit log, reports, exports. No write access to any entity. |
4. Policy Enforcement
Spend policy configures:
- Receipt required — Payment blocked if no receipt is attached and amount exceeds the threshold.
- Over-budget blocking — Payment blocked when it would exceed remaining department budget unless admin override is allowed and a sufficient override note is provided.
- Reauth before sensitive actions — Payment, reconciliation, spend policy, approval policy, and vendor updates require recent re-authentication (within a time window).
5. Verifiable Payments Model
paidTxSig on Request
When a request is paid, the on-chain transaction signature is stored on the request as paidTxSig. This allows anyone with RPC access to verify the payment.
Canonical Memo Format
The memo is a space-separated string: KharchaPay Request followed by the request ID and optionally the org slug. Example: KharchaPay Request clx123abc acme-corp. The memo appears in the same transaction as the Token-2022 transfer and is required for verification.
Verification Statuses
- VERIFIED — Memo, amount, source, destination, and mint match expectations. The payment is confirmed on-chain.
- WARNING — Verification found a non-critical mismatch; used for edge cases.
- FAILED — Transaction not found, memo mismatch, amount mismatch, wrong source/destination/mint, or RPC error. Details are stored in the reconciliation record.
- PENDING — Not yet checked by reconciliation.
6. Security & Data Handling
- CSRF + Reauth — State-changing requests require a CSRF token; sensitive actions require step-up re-authentication within a defined window.
- Receipt storage — Receipts are stored in a controlled directory. Access is restricted to org members with read access (including auditors). Downloads use no-store caching.
- Audit events — Key actions (create, submit, approve, reject, pay, reconcile) are logged immutably. Secrets are stripped from audit payloads.
7. Threat Model & Limitations
What KharchaPay Helps Prevent
- Unauthorized payments (role-based access; reauth for pay)
- Over-budget spending without explicit override
- Payment without required receipts (when policy is enabled)
- Fabrication of payment records (on-chain verification)
What It Cannot Prevent
- RPC downtime or rate limits — reconciliation may fail or be delayed
- Misconfigured treasury or vendor wallet — payments can fail or go to the wrong address
- Compromised admin credentials — an admin can pay approved requests
Confidential Transfer
The product supports confidential transfer flows for demonstration purposes where configured. Standard transfers use Token-2022 with required memo. The current implementation does not enforce confidentiality guarantees beyond what the underlying chain supports.
8. Ops & Reliability
- Reconciliation — Rerunnable and idempotent. Each run verifies paid requests and upserts reconciliation records. Rate limiting is applied to avoid RPC overload.
- Audit events — Append-only; no update or delete. Retention can be configured per org.
- Exports — CSV exports for requests, payments, audit, and budget-vs-actual. Exports include verification status where applicable.
FAQ
- Is KharchaPay open source?
- KharchaPay is an expense and payment management product. See your deployment for licensing.
- Which blockchain does it use?
- KharchaPay integrates with Solana using Token-2022 and required memo for verifiable on-chain payments.
- Can I try it without real data?
- Yes. A per-user Demo Workspace is available. Sign up, then start the demo to get a sandbox org with sample data. Demo data is isolated and never affects real organizations.