Please vote: https://dao.ckb.community/thread/vot-kirea-finance-native-rwa-lending-infrastructure-for-ckb-80639
Summary
Kirea Finance is open-source infrastructure for compliant, native real-world asset (RWA) claims on CKB: a unique-asset pattern, an issuer-revocable KYC attestation cell, and a fixed-term lending contract that uses both. The full flow is implemented and verified end to end on the CKB testnet, with no bridge or custodian required. By open-sourcing these reusable primitives for RWA collateral, issuer-controlled KYC, and fixed-term lending, this work expands the native DeFi capabilities available to CKB projects without relying on bridges or custodians.
This proposal requests $7,250 to harden that infrastructure so other CKB projects can build on it: strengthening the lending contract’s security by enforcing loan rules on every collateral spend and verifying net disbursement and repayment, integrating a live KYC provider, and handling repayment edge cases.
Grant Amount Requested: $7,250
ETA to Completion: 10 weeks from approval
CKB Wallet: ckb1qyqvaj4pmuw9vxurdlg8lx3sv7ywmcge33vsvrvu39
Repository: GitHub - salmansarwarr/Kirea-finance: RWA and lending prototype on CKB with no bridge, no custodian · GitHub
Problem
Tokenizing real-world assets is becoming a major cornerstone for the blockchain industry, yet CKB currently lacks an established pattern for lending against real-world asset claims in a compliant way. While CKB possesses robust DeFi infrastructure, the ecosystem remains constrained by limited access to real-world asset ownership and yields.
An earlier, larger attempt at RWA on CKB aimed to build a full platform, combining a custom identity system, reputation engine, and complete dynamic lending engine in one pass. That scope proved too broad for the team to complete alongside other priorities.
This proposal deliberately takes a narrower slice to solve the core problem: one real asset type (invoice), an established KYC vendor integration (Sumsub), and one simple fixed-term loan mechanic rather than a dynamic collateral-ratio engine. The aim is to harden and generalize the underlying pattern for easily onboarding future assets, not to replicate the full scope of that earlier attempt.
What’s Already Implemented
- Native Asset Claims: RWA claims are issued natively on CKB as unique cells using the Type-ID pattern (no bridge required).
- On-Chain Attestation: An issuer-revocable KYC attestation cell gates access to the lending flow. Using mocked verification, to prove the on-chain mechanics independently of any specific KYC provider.
- Loan Cycle: The full fixed-term lifecycle (deposit, borrow, repay, release) is implemented and tested on CKB testnet.
Technical Architecture
Pipeline
RWA Asset → KYC Attestation → Deposit → Borrow → Repay → Release
Components
| Component | Location | Description |
|---|---|---|
| RWA Asset | asset/ |
On-chain representation of a single real-world claim (invoice), implemented as a unique Cell (Type-ID pattern), not a fungible token. Identity is derived from a hash of a consumed input cell’s outpoint at creation time, which guarantees the claim can be issued exactly once and never duplicated. After issuance, the Type Script allows simple transfers (one input, one output) without re-checking uniqueness; authorization is handled by the Lock Script. |
| KYC Attestation | kyc-attestation/ |
A Cell recording a verification result (subject’s lock hash, status, issued timestamp), written under the issuer’s own Lock Script so only the issuer can revoke it. No custom Type Script is needed for this component: standard Lock Script control is sufficient, since the issuer alone creates and can invalidate the attestation. Verification itself is mocked in the current stage and will be replaced by a live Sumsub integration under this grant. |
| Lending | lending/ |
A fixed-term deposit/borrow/repay/release state machine. This is the one component with on-chain enforcement logic beyond standard Cell/Lock behavior: the deposit step checks that both the correct RWA asset Cell and a valid, matching, non-revoked KYC attestation Cell are present among the transaction’s inputs before allowing a loan to proceed. |
Trust model for this phase
- On-chain ownership: The RWA claim is represented by a unique CKB Cell controlled by an owner’s Lock Script. The holder can therefore own and transfer the on-chain representation of the claim using native CKB transactions.
- The RWA asset Cell alone does not imply custody or legal backing of the underlying real-world claim.
- The lending flow has no price oracle or liquidation logic. Loan terms are fixed at deposit time, which removes the need for live pricing or collateral-ratio monitoring.
Design rationale
Unique Cell instead of a fungible token. The RWA claim (an invoice) is a single, one-of-a-kind item, not a divisible quantity. An earlier version of this project modeled it as a fixed-supply fungible token, which was the wrong fit: there is no meaningful “amount” of one invoice. The Type-ID pattern (uniqueness derived from a consumed input cell’s outpoint) is a well-established CKB technique for exactly this case, used by CKB’s own Type ID script and NFT standards like Spore.
Fixed-term loans instead of a dynamic CDP. A collateralized-debt-position model (like Stable++, an existing live protocol on CKB) requires live pricing and a liquidation engine, real financial-engineering surface area. Since the goal here is building the compliance-gated lending pattern, not building a second CDP protocol, loan terms are fixed at deposit time instead, which removes the need for a price oracle entirely.
A dedicated attestation Cell instead of reusing an existing identity primitive. CKB already has a general-purpose claim/identity system (did:ckb), but its claims are revocable only by the credential holder, not the issuer. That fits reputation use cases well but doesn’t fit compliance: a KYC credential needs to be revocable by the verifying party. This project uses a small, purpose-built attestation Cell instead, rather than retrofitting a primitive built for a different trust model.
Fee Model and Sustainability
The open-source contracts, scripts, and documentation funded by this grant remain free for any CKB project to use. Revenue comes from the production layer built on top of them: a small origination fee on each loan once the platform is live with real loans, and managed onboarding for asset issuers who want a supported integration. Additional revenue can come from paid integration and compliance support for CKB projects that adopt the attestation and unique-asset patterns. As adoption grows, these fees allow the platform to sustain itself without compromising the free, open-source core.
Alignment with CKB philosophy
CKB’s Cell model is well suited to representing a single non-fungible real-world claim with provable uniqueness and explicit ownership. This project uses the Cell model as designed rather than simulating account-based balances.
The RWA application is therefore one use case for a more fundamental primitive: a unique, ownable, transferable on-chain representation of a real-world claim.
Background and Experience
Kirea Finance is built and maintained by Salmandev, I’m a full-stack blockchain developer. My public GitHub (salmansarwarr (Salman Sarwar) · GitHub) holds work across smart contracts and full-stack applications. I have previously completed a project funded under the Nervos Spark program: a “Stripe-Style” React Payment Library for Fiber Network.
For this proposal, I designed and implemented all three core components of Kirea Finance: the Type-ID RWA asset cell, the issuer-revocable KYC attestation cell, and the fixed-term lending state machine. The contracts are written in Rust and compiled for CKB’s RISC-V VM, and the full lifecycle is deployed and verified on CKB testnet.
What This Grant Adds
| Milestone | Deliverable |
|—|—|
| **1. Security hardening, attestation and asset pattern** | Enforce the loan rules on every collateral spend, verify actual net disbursement and repayment, then generalize the attestation cell and asset representation. Details below. |
| **2.Reference KYC integration** |replace mocked verification with a real Sumsub integration that other CKB projects can reuse: webhook handling, mapping results to the on-chain attestation write, sandbox-to-limited-production setup. |
| **3. Repayment edge cases, reference UI and verification tooling** | Explicit late-repayment/default handling on top of the existing repay/release flow; a UI for the lending flow and reference asset (collateral/loan status, lifecycle progress, reproducible testnet activity); expanded testnet verification tooling. |
**Milestone 1 details**
- Enforce the loan rules on every collateral spend: replace the issuer-key vault with a dedicated vault lock that pins the loan type script and only allows the collateral to be spent in a transaction that also consumes the matching loan cell, so the release checks always run.
- Verify actual net disbursement and repayment: borrow and repay compare each party’s token balance across inputs and outputs, so only a real net transfer of at least the loan amount or repay amount passes, not recycled change.
- Tests covering both: a collateral spend without the loan cell must fail, borrow and repay transactions that only recycle the party’s own tokens must fail, and the honest paths still pass.
- Then generalize the attestation cell and asset representation: configurable parameters, documented schema. This lays the groundwork for more asset types in a future phase.
**Acceptance:** the negative tests pass in the test suite, and the updated contracts complete a full deposit-to-release run on testnet.
Budget
Total requested: $7,250 USD equivalent
| Area | Amount |
|---|---|
| Attestation + asset pattern hardening (tests, config-driven design) | $2,500 |
| Live Sumsub integration (engineering + API/sandbox-to-production fees) | $2,500 |
| Repayment handling, UI, and testnet deployment/verification tooling | $2,250 |
Disbursement: staged, 20% ($1,450) on approval, remaining 80% ($5,800) released against milestone completion.
Out of Scope (this phase)
- Real custody or legal backing of the underlying asset
- Dynamic collateral ratios, price oracles, or liquidation auctions
- Mainnet deployment or production issuance
- General-purpose identity/reputation infrastructure
- Formal third-party security audit
- Legal/compliance licensing work
Why This Matters for Nervos
Real-world borrowers need capital, and DeFi has capital looking for yield. Today there is no compliant, on-chain path connecting the two on CKB. Tokenizing real-world assets is increasingly seen as a major direction for the blockchain industry, CKB already has the infrastructure for DeFi applications, but the ecosystem has limited access to high-quality real-world assets and productive external liquidity. This pattern is a first step toward changing that.
This grant turns a working demo into reusable infrastructure:
- For builders: a documented, configurable attestation Cell and unique-asset pattern, usable for any compliance-gated flow, not just lending.
- For reviewers and users: explicit late-repayment and default handling, a UI, and reproducible testnet activity that anyone can verify.
- For the ecosystem: a fully open-source reference showing a bridge-free, custodian-free RWA lending flow on the Cell model.
What this could be used for (future applications, not deliverables of this grant)
- Invoice and receivables financing. A business borrows against a verified invoice instead of waiting 60–90 days for payment.
- **Cheaper credit for underserved borrowers.**Producers of physical goods (coffee, commodities, etc.) in places with no access to normal credit can post their real-world assets as collateral, get verified through an on-chain ID+KYC system, and borrow money from DeFi lenders around the world at reasonable rates, instead of going to loan sharks charging predatory interest.
- Asset-backed short-term loans. Equipment, inventory, or commodity claims used as collateral for fixed-term loans with ability to onboard other types of assets in the future, such as Gold, Real estate, stocks etc.
- Transferable RWA claims. A uniquely identified claim could potentially be transferred between parties on CKB, subject to the legal and contractual framework governing the underlying real-world asset.
Why on-chain RWA matters (what this pattern enables in future phases)
- For asset holders: a business or individual holding a real-world claim, such as an invoice, can unlock liquidity from it without selling it, while keeping ownership of the underlying claim.
- For lenders and liquidity providers: loans backed by verified real-world claims could offer yield sourced from real economic activity, rather than only from crypto-native lending and trading. Yield levels would depend on loan terms and asset quality, and none are promised here.
- For CKB: access to real-world assets and external liquidity that the ecosystem currently lacks, brought in through a transparent, on-chain lifecycle rather than a bridge or custodian.
Risk & Mitigation
- Execution risk (solo developer): mitigated by narrow scope and a complete, working demo on testnet before this proposal. I have a previous history of completing projects under the Nervos Spark program. Asset issuance, KYC attestation, deposit, borrow, repay, and release are all implemented and tested, which demonstrates the core pattern is technically sound.
- KYC vendor dependency: Sumsub is a widely used, established provider; this grant’s integration work is limited to API/webhook integration, not building verification logic from scratch. While also allowing for any KYC to be used without changes to the core design.
- Scope creep risk: explicitly bounded by the Out of Scope list above.
Call to Action
The core pattern, a real-world claim, gated by KYC, used as loan collateral, is fully implemented and verified end to end on CKB testnet. This proposal funds hardening that working, open-source pattern so any builders, asset type or team can pick it up and extend it.
I appreciate the community’s consideration and welcome any feedback on the architecture, scope, or budget.
on the first post. Questions and criticism are equally welcome.
DAO Proposal Sync (Discussion Phase)
