I’m exploring what it takes to lend against a real-world asset claim natively on CKB with no bridge, or external custody dependency.
RWA lending is particularly interesting to me because, unlike a lot of DeFi primitives, it has an actual multi-year track record in production, not just testnets and pilots.
For the initial prototype, I will be using a simple self-originated claim (e.g. an invoice or warehouse receipt) as the reference asset.
The focus is not on launching a lending platform or a production financial product. Instead, I want to prototype the core technical pattern end to end:
RWA Asset → KYC Attestation → Deposit → Borrow → Repay → Release
The prototype will focus on:
-
A native CKB-side representation of a real-world asset claim
-
An on-chain, issuer-revocable KYC attestation Cell (verification mocked for this phase)
-
A fixed-term loan flow: deposit collateral + valid attestation → borrow → repay → release
-
A reproducible testnet end-to-end flow with full transaction hashes
With Force Bridge gone, CKB currently has no path for external RWA collateral without a bridge or custodian. This prototype tests a way around that by originating the real-world claim natively on CKB instead requiring no bridge, no external custody dependency.
If this works, it’s a reusable pattern for something CKB doesn’t currently have: a way for the value of real-world assets, and the lending activity built on top of it, to enter CKB DeFi without needing a bridge.
This idea started with me thinking about how to bring an existing asset like PAXG (Pax Gold, a gold-backed token issued by Paxos, with each token representing one fine troy ounce of physical gold) onto CKB via an oracle-and-swap pattern. Turns out that path needs a bridge or custodian for the external asset infrastructure CKB doesn’t currently have this as mentioned. Hence this version will sidestep that problem entirely by originating the real-world claim natively on CKB instead.
I’m being deliberately narrow in scope here. A prior, much larger attempt at RWA lending on CKB tried to build a full platform in one pass: a custom identity/reputation system plus a complete lending engine, and the team stepped back as priorities shifted elsewhere. Learning from that, my plan has no custom identity system, no dynamic collateral ratios, no liquidation logic. Where a solved problem already exists (e.g. identity/KYC via something like Sumsub), so the plan is to integrate rather than reinvent.
Still deciding the on-chain format for the attestation itself, a fully custom Cell type built for issuer-side revocation, or adapting an existing claim standard on CKB, separate from the KYC/identity check itself, which stays outsourced.
I’ll be developing this publicly and sharing the architecture, implementation progress, and testnet results as the work progresses. I’m still fleshing out some of the architecture details before diving into the main build.
Feedback from developers and the community is very welcome.