{ "base_url": "https://talk.nervos.org", "generated_at": "2026-04-27T03:32:14.943160+00:00", "since": "2026-04-26T03:32:08.351135+00:00", "until": "2026-04-27T03:32:08.351135+00:00", "window_hours": 24, "topics": [ { "topic_id": 10203, "title": "CellFabric: A UTXO-Generation and Inter-Protocol Composition Layer for CKB", "slug": "cellfabric-a-utxo-generation-and-inter-protocol-composition-layer-for-ckb", "url": "https://talk.nervos.org/t/cellfabric-a-utxo-generation-and-inter-protocol-composition-layer-for-ckb/10203", "created_at": "2026-04-23T04:52:02.945000+00:00", "last_posted_at": "2026-04-27T01:31:47.844000+00:00", "category_id": 49, "tags": [ "CKB", "DAG", "Graph" ], "posters": [ "Original Poster", "Frequent Poster", "Most Recent Poster" ], "recent_posts": [ { "post_id": 24042, "post_number": 4, "topic_id": 10203, "topic_title": "CellFabric: A UTXO-Generation and Inter-Protocol Composition Layer for CKB", "topic_slug": "cellfabric-a-utxo-generation-and-inter-protocol-composition-layer-for-ckb", "author": "phroi", "created_at": "2026-04-27T00:48:01.381000+00:00", "updated_at": "2026-04-27T00:48:01.381000+00:00", "reply_to_post_number": null, "url": "https://talk.nervos.org/t/cellfabric-a-utxo-generation-and-inter-protocol-composition-layer-for-ckb/10203/4", "content_text": "Hey Arthur, the CellScript / CellFabric split reads much clearer now! I think that part is mostly resolved: CellFabric makes sense as a UTXO-generation / inter-protocol coordination surface, not as a new ledger or transaction-DAG L2.\nCellScript - A DSL for Cell-Based Contracts\nCellScript: authoring and compiling individual cell protocols, including ProofPlan metadata that makes guarantees, coverage, and assumptions explicit;\nCellFabric: a higher inter-protocol intent and composition layer, describing how different protocols coordinate with each other before final CKB settlement.\nOne concrete positive is that the current CellScript code already supports some of the single-protocol side you describe. receipt is a first-class cell type, claim only accepts receipt values, and read_ref lowers through Source::CellDep. That already supports “compose around existing cells” without implying a new settlement layer.\nArthurZhang:\nIdeally, conflict keys should not be arbitrary strings asserted by the intent submitter. They should be recomputable from the protocol’s declared policy, CellScript metadata, or a verifier interface.\nThis is the one part where I still want to hear your view. The repo already exposes per-action touches_shared, read_refs, verifier_obligations, and transaction_runtime_input_requirements, and cellc scheduler-plan can derive simple shared-state conflicts from that metadata. But that still reads to me as intra-module compiler metadata, not yet a standard inter-protocol conflict-key or verifier surface.\nThe same semantics_preserving_claim says stateful lowering is represented in metadata and asm but is “not yet a proved schema decoder/verifier”. Structured WitnessArgs / Source views are still planned for v0.14, and the ProofPlan audit surface with trigger/scope/coverage and builder_assumption reporting is still planned for v0.15.\nSo my current read is: the split is right, the single-protocol foundation is already in the code, and the cross-protocol conflict-key / verifier surface still sits on the roadmap.\nI was wondering: How do you see token standards and the wider inter-protocol interface evolving from here? The small Token / MintAuthority base already in the repo makes that especially interesting to me.\nPhroi", "content_html": "

Hey Arthur, the CellScript / CellFabric split reads much clearer now! I think that part is mostly resolved: CellFabric makes sense as a UTXO-generation / inter-protocol coordination surface, not as a new ledger or transaction-DAG L2.

\n\n

One concrete positive is that the current CellScript code already supports some of the single-protocol side you describe. receipt is a first-class cell type, claim only accepts receipt values, and read_ref lowers through Source::CellDep. That already supports “compose around existing cells” without implying a new settlement layer.

\n\n

This is the one part where I still want to hear your view. The repo already exposes per-action touches_shared, read_refs, verifier_obligations, and transaction_runtime_input_requirements, and cellc scheduler-plan can derive simple shared-state conflicts from that metadata. But that still reads to me as intra-module compiler metadata, not yet a standard inter-protocol conflict-key or verifier surface.

\n

The same semantics_preserving_claim says stateful lowering is represented in metadata and asm but is “not yet a proved schema decoder/verifier”. Structured WitnessArgs / Source views are still planned for v0.14, and the ProofPlan audit surface with trigger/scope/coverage and builder_assumption reporting is still planned for v0.15.

\n

So my current read is: the split is right, the single-protocol foundation is already in the code, and the cross-protocol conflict-key / verifier surface still sits on the roadmap.

\n

I was wondering: How do you see token standards and the wider inter-protocol interface evolving from here? The small Token / MintAuthority base already in the repo makes that especially interesting to me.

\n

Phroi

", "like_count": 0, "quote_count": 1 }, { "post_id": 24043, "post_number": 5, "topic_id": 10203, "topic_title": "CellFabric: A UTXO-Generation and Inter-Protocol Composition Layer for CKB", "topic_slug": "cellfabric-a-utxo-generation-and-inter-protocol-composition-layer-for-ckb", "author": "ArthurZhang", "created_at": "2026-04-27T01:14:07.607000+00:00", "updated_at": "2026-04-27T01:16:36.623000+00:00", "reply_to_post_number": 4, "url": "https://talk.nervos.org/t/cellfabric-a-utxo-generation-and-inter-protocol-composition-layer-for-ckb/10203/5", "content_text": "Thanks Phroi.\nI agree that the current CellScript metadata is still mostly intra-protocol compiler metadata. It exposes useful raw material : read_refs, touches_shared, verifier obligations, runtime input requirements, receipts, and so on, but it is not yet a stable CellFabric-level conflict-key or verifier-interface standard.\nI also agree that conflict keys should not be arbitrary strings asserted by the intent submitter. At most, they can be hints.\nThe meaningful key should eventually be derivable or checkable from protocol policy, script args, cell schema, CellScript metadata, or a verifier interface.\nThat said, I want to be careful about scope. I probably do not have the bandwidth to design the full CellFabric conflict-key / verifier-interface layer in the current CellScript sprint. My near-term focus is still to make the single-protocol side safer and more inspectable first.\nSo my rough layering is:\nCellScript now / near term: expose the raw materials clearly;\nv0.14/v0.15: make trigger, scope, reads, coverage, enforcement, and builder assumptions explicit through ProofPlan;\nCellFabric later: decide which parts are stable enough to become inter-protocol conflict keys, verifier interfaces, and token/composition standards.\nThe token / MintAuthority example may indeed be a good first narrow domain for that later work. But I would not want to overclaim that it is already designed.\nYour suggestions have been consistently useful for me in sharpening the boundary here. For now I probably need to let the design breathe a little and spend more time building. Maybe at some point, once the lower layers are more solid, we could try some application-level collaboration to stress-test how strong the CellScript / CellFabric split really is.", "content_html": "

Thanks Phroi.

\n

I agree that the current CellScript metadata is still mostly intra-protocol compiler metadata. It exposes useful raw material : read_refs, touches_shared, verifier obligations, runtime input requirements, receipts, and so on, but it is not yet a stable CellFabric-level conflict-key or verifier-interface standard.

\n

I also agree that conflict keys should not be arbitrary strings asserted by the intent submitter. At most, they can be hints.

\n

The meaningful key should eventually be derivable or checkable from protocol policy, script args, cell schema, CellScript metadata, or a verifier interface.

\n

That said, I want to be careful about scope. I probably do not have the bandwidth to design the full CellFabric conflict-key / verifier-interface layer in the current CellScript sprint. My near-term focus is still to make the single-protocol side safer and more inspectable first.

\n

So my rough layering is:

\n\n

The token / MintAuthority example may indeed be a good first narrow domain for that later work. But I would not want to overclaim that it is already designed.

\n

Your suggestions have been consistently useful for me in sharpening the boundary here. For now I probably need to let the design breathe a little and spend more time building. Maybe at some point, once the lower layers are more solid, we could try some application-level collaboration to stress-test how strong the CellScript / CellFabric split really is.

", "like_count": 0, "quote_count": 0 }, { "post_id": 24044, "post_number": 6, "topic_id": 10203, "topic_title": "CellFabric: A UTXO-Generation and Inter-Protocol Composition Layer for CKB", "topic_slug": "cellfabric-a-utxo-generation-and-inter-protocol-composition-layer-for-ckb", "author": "phroi", "created_at": "2026-04-27T01:31:47.844000+00:00", "updated_at": "2026-04-27T01:31:47.844000+00:00", "reply_to_post_number": 5, "url": "https://talk.nervos.org/t/cellfabric-a-utxo-generation-and-inter-protocol-composition-layer-for-ckb/10203/6", "content_text": "That makes sense, Happy Building!!\nPhroi", "content_html": "

That makes sense, Happy Building!! \":hugs:\"

\n

Phroi

", "like_count": 0, "quote_count": 0 } ] }, { "topic_id": 10187, "title": "[CN/EN] CTO - 去中心化的链上时间预言机 Decentralized On-Chain Time Oracle", "slug": "cn-en-cto-decentralized-on-chain-time-oracle", "url": "https://talk.nervos.org/t/cn-en-cto-decentralized-on-chain-time-oracle/10187", "created_at": "2026-04-18T21:04:28.521000+00:00", "last_posted_at": "2026-04-26T23:54:54.412000+00:00", "category_id": 45, "tags": [ "CKB", "dapp" ], "posters": [ "Original Poster", "Frequent Poster", "Frequent Poster", "Most Recent Poster" ], "recent_posts": [ { "post_id": 24041, "post_number": 5, "topic_id": 10187, "topic_title": "[CN/EN] CTO - 去中心化的链上时间预言机 Decentralized On-Chain Time Oracle", "topic_slug": "cn-en-cto-decentralized-on-chain-time-oracle", "author": "phroi", "created_at": "2026-04-26T23:54:54.412000+00:00", "updated_at": "2026-04-26T23:54:54.412000+00:00", "reply_to_post_number": 2, "url": "https://talk.nervos.org/t/cn-en-cto-decentralized-on-chain-time-oracle/10187/5", "content_text": "Hey Hanssen, interesting idea!! I looked through the repo after reading this. CTO keeps the lock hash unchanged and only accepts newer timestamps proven by header_deps. That does look like a rotating on-chain time source to me. Just the red-envelope example seems to overstate what the published code proves.\nHanssen:\nThe rules are straightforward: recipients must claim the envelope within 24 hours; otherwise, only the sender can reclaim it.\nFor that quoted 24-hour claim, I still see three limits in the published repo:\nThe full group is not proved on chain. The design doc says the updater should include the other N - 1 group cells. The script only counts same-type cell_deps, but CKB allows the cell being updated to also appear as a cell_dep. So the count can pass without proving the other live group cells are actually present.\nCurrent time is still a consumer choice. Consumers can select any cell from the group, the SDK sorts newest first, and the quick start treats group.cells[0] as the latest timestamp. So latest is still a client-side convention.\nFreshness to the network tip is still off chain. The contract only checks the provided header_deps, while the supplier command calls supplyTime() and supplyTime() uses getTipHeader() off chain.\nCTO already gives a fresher shared time reference than arbitrary per-tx header_deps.\nFor stricter deadline logic, a two-tx pattern can prove more. iCKB already uses that staged shape for deposits: phase 1 records the deposit, and phase 2 uses the deposit block header to transform the receipt into iCKB.\nKeep up the Great Work, Phroi", "content_html": "

Hey Hanssen, interesting idea!! I looked through the repo after reading this. CTO keeps the lock hash unchanged and only accepts newer timestamps proven by header_deps. That does look like a rotating on-chain time source to me. Just the red-envelope example seems to overstate what the published code proves.

\n\n

For that quoted 24-hour claim, I still see three limits in the published repo:

\n
    \n
  1. \n

    The full group is not proved on chain. The design doc says the updater should include the other N - 1 group cells. The script only counts same-type cell_deps, but CKB allows the cell being updated to also appear as a cell_dep. So the count can pass without proving the other live group cells are actually present.

    \n
    2. \n
  2. \n

    Current time is still a consumer choice. Consumers can select any cell from the group, the SDK sorts newest first, and the quick start treats group.cells[0] as the latest timestamp. So latest is still a client-side convention.

    \n
    3. \n
  3. \n

    Freshness to the network tip is still off chain. The contract only checks the provided header_deps, while the supplier command calls supplyTime() and supplyTime() uses getTipHeader() off chain.

    \n
    4. \n
\n

CTO already gives a fresher shared time reference than arbitrary per-tx header_deps.

\n

For stricter deadline logic, a two-tx pattern can prove more. iCKB already uses that staged shape for deposits: phase 1 records the deposit, and phase 2 uses the deposit block header to transform the receipt into iCKB.

\n

Keep up the Great Work, Phroi

", "like_count": 0, "quote_count": 1 } ] }, { "topic_id": 10212, "title": "Spark Program | Dular", "slug": "spark-program-dular", "url": "https://talk.nervos.org/t/spark-program-dular/10212", "created_at": "2026-04-26T16:35:20.268000+00:00", "last_posted_at": "2026-04-26T23:47:00.339000+00:00", "category_id": 49, "tags": [ "Spark-Program" ], "posters": [ "Original Poster", "Most Recent Poster" ], "recent_posts": [ { "post_id": 24038, "post_number": 1, "topic_id": 10212, "topic_title": "Spark Program | Dular", "topic_slug": "spark-program-dular", "author": "duongja", "created_at": "2026-04-26T16:35:20.375000+00:00", "updated_at": "2026-04-26T23:47:21.330000+00:00", "reply_to_post_number": null, "url": "https://talk.nervos.org/t/spark-program-dular/10212/1", "content_text": "Dular — Mobile Money Stablecoin Wallet on Fiber Network\nTeam Profile & Contact\nApplicant: duongja\nGitHub: GitHub - duongja/Dular · GitHub\nRole: Full-stack developer with experience in blockchain development\nTelegram: @craxe21\nEmail: itsored9@gmail.com\nProject Description\nProblem\n1.4 billion people across Africa, Southeast Asia, and Latin America depend on mobile money (M-Pesa, MTN MoMo, Airtel Money) as their primary financial infrastructure. These users face:\nHigh fees: Cross-border transfers cost 6–9%, eating into remittances that families depend on\nSlow settlement: 1–3 business days for cross-network transfers\nClosed ecosystems: M-Pesa users can’t send directly to MTN MoMo users\nCrypto complexity: Existing stablecoin wallets require understanding hex addresses, gas fees, and blockchain concepts — inaccessible to mobile money users\nSmartphone dependency: Most crypto wallets require smartphones, excluding hundreds of millions of feature phone users\nSolution\nDular is a stablecoin wallet that speaks the language of mobile money users. It is built natively on CKB’s Fiber Network and wraps it in interfaces that mobile money users already understand:\nPhone Number Identity: Users send stablecoins to phone numbers (+254712345678), not hex addresses. Dular maintains a phone-to-pubkey registry that maps phone numbers to Fiber Network identities.\nM-Pesa On/Off Ramp: Users deposit KES (Kenyan Shillings) via M-Pesa STK Push and receive RUSD stablecoins in their Dular wallet. To cash out, they withdraw RUSD and receive KES back to their M-Pesa. Powered by Safaricom’s Daraja API.\nUSSD Support for Feature Phones: Users dial a short code (e.g., *384*55#) to access their wallet from any phone, no smartphone, no internet, no app download required. Built on Africa’s Talking USSD API.\nInstant, Near-Zero Fee Payments: Fiber Network’s off-chain payment channels enable millisecond settlement at < 0.001% fees. We demonstrated this with a successful end-to-end 1 RUSD payment through the public testnet relay nodes.\nWhy CKB / Fiber Network?\nCKB’s Fiber Network provides unique advantages:\nNative stablecoin support (UDT): Fiber channels natively support UDT assets like RUSD, no wrapped tokens, no bridges, no extra complexity\nMulti-asset channels: A single channel can carry multiple stablecoin types, enabling future local currency stablecoins (KES, GHS, NGN) without separate infrastructure\nPTLC security: Point Time-Locked Contracts (more advanced than HTLCs) provide stronger privacy and atomicity guarantees\nLow on-chain costs: CKB’s cell model keeps channel open/close transactions inexpensive, critical for users transacting $1–$50 at a time\nExpected Deliverables\nCode Repository\nGitHub: GitHub - duongja/Dular · GitHub (MIT licensed, already public)\nAll code open source throughout development\nDeliverable 1: Phone Number Identity Layer\nPhone number → Fiber pubkey mapping service\nRegistration flow: verify phone via OTP, link to wallet\nSend-to-phone-number UI in Dular web app\nContact lookup and resolution\nDeliverable 2: M-Pesa On/Off Ramp\nM-Pesa STK Push integration (deposit KES → receive RUSD)\nM-Pesa B2C integration (withdraw RUSD → receive KES)\nTransaction status tracking and receipt generation\nBasic KYC-lite flow (phone number verification)\nDeliverable 3: USSD Interface\nUSSD menu system for feature phones:\nCheck balance\nSend to phone number\nReceive (display invoice)\nDeposit from M-Pesa\nWithdraw to M-Pesa\nSession management and security PIN\nDeliverable 4: 30-User Pilot\nRecruit 30 seed users\nStructured testing protocol:\nWeek 1: Onboarding and first deposit\nWeek 2: Peer-to-peer transfers between pilot users\nWeek 3: Cross-corridor transfers and edge cases\nWeek 4: Feedback collection, interviews, and iteration\nDocumented user feedback report with key insights\nProduct improvement recommendations based on real usage\nDocumentation\nTechnical documentation and deployment guide\nUSSD menu flow diagrams\nUser testing report with data and feedback\nVideo demonstration of full user flow\nRequired Funding: $2,000\nFunding is structured around three milestone deliverables:\nMilestone\nAmount\nDeliverable\nMilestone 1: Phone Identity + M-Pesa Ramp\n$600\nPhone-to-pubkey registry, OTP verification, send-to-phone-number UI, M-Pesa deposit/withdraw integration, end-to-end fiat→stablecoin→fiat flow working\nMilestone 2: USSD Interface\n$600\nFeature phone USSD menu (balance, send, receive, deposit, withdraw), security PIN, multi-handset testing, API costs\nMilestone 3: 30-User Pilot + Documentation\n$800\nRecruit and onboard 30 seed users, structured testing protocol, user feedback report, demo video, final documentation, project summary\nTotal\n$2,000\nJustification for $2,000\nBridges CKB/Fiber to a 1.4 billion person market with zero current ecosystem exposure\nRequires three distinct technical integrations (phone identity, M-Pesa API, USSD API) plus a real-world user pilot with 30 users\nA working prototype is already shipped this funding accelerates a proven product, not a concept\nMilestone 3 includes real costs\nEstimated Completion Time: 5.5 Weeks (~1.3 Months)\nWeek 1–2: Milestone 1: Phone Identity + M-Pesa Ramp\nPhone-to-pubkey registry service and OTP verification\nSend-to-phone-number UI in Dular\nM-Pesa Daraja API integration (STK Push deposits, B2C withdrawals)\nEnd-to-end flow: deposit KES → send RUSD → withdraw KES\nWeek 3–4: Milestone 2 — USSD Interface\nAfrica’s Talking USSD integration\nMenu system: balance, send, receive, deposit, withdraw\nSecurity PIN and session management\nFeature phone testing across multiple handsets\nWeek 4.5–5.5: Milestone 3 — 30-User Pilot + Documentation\nRecruit and onboard 30 seed users\nStructured testing: onboarding → transfers → feedback\nUser feedback report with key insights and improvement directions\nDemo video and final project documentation\nTo-Do List\nPhone number → pubkey registry service\nOTP phone verification flow\nSend-to-phone-number in Dular UI\nM-Pesa STK Push deposit integration\nM-Pesa B2C withdrawal integration\nUSSD menu interface for feature phones\nSecurity PIN system\nRecruit 30 pilot users (Kenya + Ghana)\nRun structured 2-week pilot test\nCollect and document user feedback\nWrite project completion report\nRecord video demonstration\nPublish all code and documentation\nRelevance to CKB Ecosystem\nMeeting Actual Needs\nFirst mobile money bridge in CKB: No project currently connects CKB/Fiber to mobile money rails. Dular creates an entirely new user acquisition channel.\nReal user validation: The 30-user pilot generates structured feedback from a demographic (mobile money users in Africa) that no CKB project has ever reached.\nFiber Network adoption: Every Dular user runs a Fiber node and opens payment channels, directly growing the network’s liquidity and routing capacity.\nCKB’s Unique Technical Advantages\nUDT stablecoins on Fiber: CKB’s native UDT standard allows stablecoins in payment channels without bridges or wrapping\nMulti-asset channels: Fiber’s multi-asset support enables future local currency stablecoins (KES-stable, GHS-stable) on the same infrastructure.\nCell model efficiency: Low on-chain costs make $1–$50 transactions economically viable, matching mobile money transaction sizes.\nProgrammable verification: CKB scripts enable custom logic for phone number verification and on/off ramp settlement contracts.\nWeb5 Alignment\nDular embodies the Web5 philosophy, organic combination of Web2 and Web3:\nWeb2 interface (phone numbers, USSD, M-Pesa) meets Web3 infrastructure (Fiber Network, non-custodial keys)\nSmall but real: Not a speculative DeFi protocol, a practical tool for people sending money to their families\nUser-centric: Designed around how mobile money users actually behave, not how crypto users think they should\nHuman-oriented: Feature phone USSD support ensures nobody is excluded by technology barriers\nExisting Progress\nDular is not a concept it is a working prototype with a verified end-to-end payment flow:\nWeb app built (Vite + React) with premium dark-mode UI\nFiber Network RPC integration (node_info, list_channels, open_channel, send_payment, new_invoice)\nRUSD stablecoin channel opened with public testnet relay node\nRUSD payment successfully executed through multi-hop routing (nodeA → relay node1 → relay node2)\nOpen source on GitHub: GitHub - duongja/Dular · GitHub\nThis grant funds the next phase: making it accessible to real mobile money users.\nPost-Spark Program Plans\nAfter successfully completing the pilot, Dular will be positioned to apply for Community Fund DAO funding to:\nLaunch local stablecoins: KES-pegged, GHS-pegged, NGN-pegged stablecoins as UDTs on CKB, tradeable through Fiber channels\nScale to 1,000+ users across multiple East and West African corridors\nBuild agent network tools: enable local agents to provide cash-in/cash-out services\nExpand to additional mobile money networks: MTN MoMo (Ghana, Uganda), Airtel Money (across Africa), GCash (Philippines)\nDular: Instant stablecoin payments for mobile money markets, no banks, no borders, no middlemen. Just your phone number.", "content_html": "

Dular — Mobile Money Stablecoin Wallet on Fiber Network

\n

Team Profile & Contact

\n\n
\n

Project Description

\n

Problem

\n

1.4 billion people across Africa, Southeast Asia, and Latin America depend on mobile money (M-Pesa, MTN MoMo, Airtel Money) as their primary financial infrastructure. These users face:

\n\n

Solution

\n

Dular is a stablecoin wallet that speaks the language of mobile money users. It is built natively on CKB’s Fiber Network and wraps it in interfaces that mobile money users already understand:

\n
    \n
  1. \n

    Phone Number Identity: Users send stablecoins to phone numbers (+254712345678), not hex addresses. Dular maintains a phone-to-pubkey registry that maps phone numbers to Fiber Network identities.

    \n
    2. \n
  2. \n

    M-Pesa On/Off Ramp: Users deposit KES (Kenyan Shillings) via M-Pesa STK Push and receive RUSD stablecoins in their Dular wallet. To cash out, they withdraw RUSD and receive KES back to their M-Pesa. Powered by Safaricom’s Daraja API.

    \n
    3. \n
  3. \n

    USSD Support for Feature Phones: Users dial a short code (e.g., *384*55#) to access their wallet from any phone, no smartphone, no internet, no app download required. Built on Africa’s Talking USSD API.

    \n
    4. \n
  4. \n

    Instant, Near-Zero Fee Payments: Fiber Network’s off-chain payment channels enable millisecond settlement at < 0.001% fees. We demonstrated this with a successful end-to-end 1 RUSD payment through the public testnet relay nodes.

    \n
    5. \n
\n

Why CKB / Fiber Network?

\n

CKB’s Fiber Network provides unique advantages:

\n\n
\n

Expected Deliverables

\n

Code Repository

\n\n

Deliverable 1: Phone Number Identity Layer

\n\n

Deliverable 2: M-Pesa On/Off Ramp

\n\n

Deliverable 3: USSD Interface

\n\n

Deliverable 4: 30-User Pilot

\n\n

Documentation

\n\n
\n

Required Funding: $2,000

\n

Funding is structured around three milestone deliverables:

\n
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
MilestoneAmountDeliverable
Milestone 1: Phone Identity + M-Pesa Ramp$600Phone-to-pubkey registry, OTP verification, send-to-phone-number UI, M-Pesa deposit/withdraw integration, end-to-end fiat→stablecoin→fiat flow working
Milestone 2: USSD Interface$600Feature phone USSD menu (balance, send, receive, deposit, withdraw), security PIN, multi-handset testing, API costs
Milestone 3: 30-User Pilot + Documentation$800Recruit and onboard 30 seed users, structured testing protocol, user feedback report, demo video, final documentation, project summary
Total$2,000
\n

Justification for $2,000

\n\n
\n

Estimated Completion Time: 5.5 Weeks (~1.3 Months)

\n

Week 1–2: Milestone 1: Phone Identity + M-Pesa Ramp

\n\n

Week 3–4: Milestone 2 — USSD Interface

\n\n

Week 4.5–5.5: Milestone 3 — 30-User Pilot + Documentation

\n\n
\n

To-Do List

\n\n
\n

Relevance to CKB Ecosystem

\n

Meeting Actual Needs

\n\n

CKB’s Unique Technical Advantages

\n\n

Web5 Alignment

\n

Dular embodies the Web5 philosophy, organic combination of Web2 and Web3:

\n\n
\n

Existing Progress

\n

Dular is not a concept it is a working prototype with a verified end-to-end payment flow:

\n\n

This grant funds the next phase: making it accessible to real mobile money users.

\n
\n

Post-Spark Program Plans

\n

After successfully completing the pilot, Dular will be positioned to apply for Community Fund DAO funding to:

\n
    \n
  1. Launch local stablecoins: KES-pegged, GHS-pegged, NGN-pegged stablecoins as UDTs on CKB, tradeable through Fiber channels
    2. \n
  2. Scale to 1,000+ users across multiple East and West African corridors
    3. \n
  3. Build agent network tools: enable local agents to provide cash-in/cash-out services
    4. \n
  4. Expand to additional mobile money networks: MTN MoMo (Ghana, Uganda), Airtel Money (across Africa), GCash (Philippines)
    5. \n
\n
\n

Dular: Instant stablecoin payments for mobile money markets, no banks, no borders, no middlemen. Just your phone number.

", "like_count": 0, "quote_count": 0 }, { "post_id": 24040, "post_number": 2, "topic_id": 10212, "topic_title": "Spark Program | Dular", "topic_slug": "spark-program-dular", "author": "zz_tovarishch", "created_at": "2026-04-26T23:47:00.339000+00:00", "updated_at": "2026-04-26T23:47:55.937000+00:00", "reply_to_post_number": null, "url": "https://talk.nervos.org/t/spark-program-dular/10212/2", "content_text": "Hi duongja,\nThanks for the submission. The proposal aligns well with Spark 2026’s technical focus on Fiber Network and UDT-based payments, and the fact that you already have a working multi-hop RUSD payment through testnet relays is a strong differentiator. Before I bring this to the committee for formal review, I’d like you to revise a few sections so the evaluation can move efficiently.\nAdd a “How to Verify” section. Starting from 2026, every Spark proposal is required to include a low-cost, reproducible verification scheme. For Dular specifically, please describe how a committee member or community reviewer can independently confirm: the phone-to-pubkey registry is live, the M-Pesa STK Push and B2C flows actually settle end-to-end, and the 30-user pilot data is real. Public demo URLs, signed transaction hashes, screen recordings, or a sandbox the reviewer can poke are all acceptable. This is the single most important addition.\nProvide a line-item funding breakdown. Spark’s standard ceiling is $1,000. The $2,000 tier is reserved for projects with exceptional impact, so the justification needs to be concrete. Please upgrade the current per-milestone summary with itemized costs: Daraja API fees (sandbox vs production), Africa’s Talking USSD per-session pricing × estimated sessions, KES float for cash-in/cash-out reconciliation during the pilot, user incentives or transport reimbursement for the 30 testers, and any developer-hour estimate you’d like to include.\nPayment currency. The committee recently decided that, currently, Spark grants will be disbursed in 100% CKB only (no USDI option for now). If this materially affects your numbers, adjust the breakdown accordingly.\nAddress two execution risks up front. First, Safaricom Daraja Production approval typically takes 4–8 weeks and usually requires a Kenyan legal entity or local partner, especially for B2C. Please clarify whether you already hold production credentials, hold sandbox only, or have a partner arrangement in Kenya. Second, please describe your on-the-ground resources for recruitment, vernacular support, and field testing. The 2025 cycle had a project that delivered the technical MVP cleanly but was penalized 10% because the user-testing portion was thin, so this is a recurring committee concern.\nOptional but encouraged. Add a verifiable checkpoint at the end of each milestone (a public release tag, a recorded demo, or a published tx hash). For the existing proposal, appreciate sharing the transaction hash of the successful multi-hop RUSD payment in the proposal itself. This both strengthens the credibility of the application and feeds directly into the “How to Verify” framework above.\nLooking forward to the revised draft.\nBest,\nCC @xingtianchunyan", "content_html": "

Hi duongja,

\n

Thanks for the submission. The proposal aligns well with Spark 2026’s technical focus on Fiber Network and UDT-based payments, and the fact that you already have a working multi-hop RUSD payment through testnet relays is a strong differentiator. Before I bring this to the committee for formal review, I’d like you to revise a few sections so the evaluation can move efficiently.

\n
    \n
  1. \n

    Add a “How to Verify” section. Starting from 2026, every Spark proposal is required to include a low-cost, reproducible verification scheme. For Dular specifically, please describe how a committee member or community reviewer can independently confirm: the phone-to-pubkey registry is live, the M-Pesa STK Push and B2C flows actually settle end-to-end, and the 30-user pilot data is real. Public demo URLs, signed transaction hashes, screen recordings, or a sandbox the reviewer can poke are all acceptable. This is the single most important addition.

    \n
    2. \n
  2. \n

    Provide a line-item funding breakdown. Spark’s standard ceiling is $1,000. The $2,000 tier is reserved for projects with exceptional impact, so the justification needs to be concrete. Please upgrade the current per-milestone summary with itemized costs: Daraja API fees (sandbox vs production), Africa’s Talking USSD per-session pricing × estimated sessions, KES float for cash-in/cash-out reconciliation during the pilot, user incentives or transport reimbursement for the 30 testers, and any developer-hour estimate you’d like to include.

    \n
    3. \n
  3. \n

    Payment currency. The committee recently decided that, currently, Spark grants will be disbursed in 100% CKB only (no USDI option for now). If this materially affects your numbers, adjust the breakdown accordingly.

    \n
    4. \n
  4. \n

    Address two execution risks up front. First, Safaricom Daraja Production approval typically takes 4–8 weeks and usually requires a Kenyan legal entity or local partner, especially for B2C. Please clarify whether you already hold production credentials, hold sandbox only, or have a partner arrangement in Kenya. Second, please describe your on-the-ground resources for recruitment, vernacular support, and field testing. The 2025 cycle had a project that delivered the technical MVP cleanly but was penalized 10% because the user-testing portion was thin, so this is a recurring committee concern.

    \n
    5. \n
  5. \n

    Optional but encouraged. Add a verifiable checkpoint at the end of each milestone (a public release tag, a recorded demo, or a published tx hash). For the existing proposal, appreciate sharing the transaction hash of the successful multi-hop RUSD payment in the proposal itself. This both strengthens the credibility of the application and feeds directly into the “How to Verify” framework above.

    \n
    6. \n
\n

Looking forward to the revised draft.

\n

Best,

\n

CC @xingtianchunyan

", "like_count": 0, "quote_count": 0 } ] }, { "topic_id": 10015, "title": "[DIS] Decentralized privacy order-book appchain based on CKB L1 - 2026.phase-1", "slug": "dis-decentralized-privacy-order-book-appchain-based-on-ckb-l1-2026-phase-1", "url": "https://talk.nervos.org/t/dis-decentralized-privacy-order-book-appchain-based-on-ckb-l1-2026-phase-1/10015", "created_at": "2026-02-28T04:17:08.724000+00:00", "last_posted_at": "2026-04-26T17:08:44.990000+00:00", "category_id": 65, "tags": [ "appchain" ], "posters": [ "Original Poster, Most Recent Poster", "Frequent Poster", "Frequent Poster", "Frequent Poster" ], "recent_posts": [ { "post_id": 24039, "post_number": 22, "topic_id": 10015, "topic_title": "[DIS] Decentralized privacy order-book appchain based on CKB L1 - 2026.phase-1", "topic_slug": "dis-decentralized-privacy-order-book-appchain-based-on-ckb-l1-2026-phase-1", "author": "Lawliet_Chan", "created_at": "2026-04-26T17:08:44.990000+00:00", "updated_at": "2026-04-26T17:08:44.990000+00:00", "reply_to_post_number": null, "url": "https://talk.nervos.org/t/dis-decentralized-privacy-order-book-appchain-based-on-ckb-l1-2026-phase-1/10015/22", "content_text": "周报\n2026.4.27\n完成desktop端的bip39钱包的开发：导入助记词和导入链下UTXO明文功能\n开始撰写Invisibook论文的威胁模型", "content_html": "

周报

\n

2026.4.27

\n", "like_count": 0, "quote_count": 0 } ] }, { "topic_id": 10098, "title": "Spark Program | CKB-UGMP —— A Universal Spore/DOB Seamless Minting Infrastructure Prototype on CKB —— 基于 CKB 的通用 Spore/DOB 无感铸造基础设施原型", "slug": "spark-program-ckb-ugmp-a-universal-spore-dob-seamless-minting-infrastructure-prototype-on-ckb-ckb-spore-dob", "url": "https://talk.nervos.org/t/spark-program-ckb-ugmp-a-universal-spore-dob-seamless-minting-infrastructure-prototype-on-ckb-ckb-spore-dob/10098", "created_at": "2026-03-17T07:21:55.306000+00:00", "last_posted_at": "2026-04-26T12:23:13.118000+00:00", "category_id": 45, "tags": [ "In-Progress", "Spark-Program" ], "posters": [ "Original Poster", "Frequent Poster", "Frequent Poster", "Most Recent Poster" ], "recent_posts": [ { "post_id": 24036, "post_number": 14, "topic_id": 10098, "topic_title": "Spark Program | CKB-UGMP —— A Universal Spore/DOB Seamless Minting Infrastructure Prototype on CKB —— 基于 CKB 的通用 Spore/DOB 无感铸造基础设施原型", "topic_slug": "spark-program-ckb-ugmp-a-universal-spore-dob-seamless-minting-infrastructure-prototype-on-ckb-ckb-spore-dob", "author": "HNO3Miracle", "created_at": "2026-04-26T11:48:26.872000+00:00", "updated_at": "2026-04-26T11:48:26.872000+00:00", "reply_to_post_number": null, "url": "https://talk.nervos.org/t/spark-program-ckb-ugmp-a-universal-spore-dob-seamless-minting-infrastructure-prototype-on-ckb-ckb-spore-dob/10098/14", "content_text": "各位好，向各位汇报本周的工作\n1. 前端工程初始化完成\n已完成基于 Next.js 14 + TypeScript + Tailwind CSS 的前端项目初始化，并整理为后续可扩展的仓库结构。\n2. CCC Provider 与钱包连接层已接入\n已完成 @ckb-ccc/connector-react 的接入，并在全局布局中注入 Provider，作为后续所有链上交互的基础。\n3. Mint 主流程 UI 骨架已建立\n当前 Mint 工作台已包含：\n本地图片选择入口\n已选文件名与体积状态展示\nStorage Selector 下拉菜单\n预留的 Mint Pipeline Preview 区块\n后续 Mint DOB 按钮的禁用态占位\n九、下周计划\n第 2 周计划进入“上传层与请求状态管理”阶段，优先推进以下事项：\n接入 Pinata / IPFS 上传逻辑，完成本地图片到 CID 的基础链路。\n增加上传相关状态管理，包括上传中、成功、失败和错误提示。\nHi there,\nWeekly Progress Report\n1. Frontend Project Initialization\nSuccessfully initialized the frontend project using Next.js 14 + TypeScript + Tailwind CSS. The repository structure has been organized to ensure scalability for future development.\n2. Integration of CCC Provider and Wallet Connection Layer\nIntegrated @ckb-ccc/connector-react and injected the Provider into the global layout. This establishes the essential foundation for all subsequent on-chain interactions.\n3. Mint Main Flow UI Skeleton Established\nThe Mint workspace now includes the following components:\nLocal image selection entry.\nDisplay for selected filename and file size status.\nStorage Selector dropdown menu.\nReserved block for Mint Pipeline Preview.\nDisabled placeholder for the Mint DOB button.\nNext Week’s Plan\nThe second week will focus on the “Upload Layer and Request Status Management” phase, prioritizing the following:\nIntegrate Pinata / IPFS upload logic to complete the basic pipeline from local images to CIDs.\nImplement upload-related state management, including loading, success, and failure states, along with error prompts.\nBest,\nHNO3Miracle", "content_html": "

各位好，向各位汇报本周的工作

\n

1. 前端工程初始化完成

\n

已完成基于 Next.js 14 + TypeScript + Tailwind CSS 的前端项目初始化，并整理为后续可扩展的仓库结构。

\n

2. CCC Provider 与钱包连接层已接入

\n

已完成 @ckb-ccc/connector-react 的接入，并在全局布局中注入 Provider，作为后续所有链上交互的基础。

\n

3. Mint 主流程 UI 骨架已建立

\n

当前 Mint 工作台已包含：

\n\n

九、下周计划

\n

第 2 周计划进入“上传层与请求状态管理”阶段，优先推进以下事项：

\n
    \n
  1. \n

    接入 Pinata / IPFS 上传逻辑，完成本地图片到 CID 的基础链路。

    \n
    2. \n
  2. \n

    增加上传相关状态管理，包括上传中、成功、失败和错误提示。

    \n
    3. \n
\n
\n

Hi there,

\n

Weekly Progress Report

\n

1. Frontend Project Initialization

\n

Successfully initialized the frontend project using Next.js 14 + TypeScript + Tailwind CSS. The repository structure has been organized to ensure scalability for future development.

\n

2. Integration of CCC Provider and Wallet Connection Layer

\n

Integrated @ckb-ccc/connector-react and injected the Provider into the global layout. This establishes the essential foundation for all subsequent on-chain interactions.

\n

3. Mint Main Flow UI Skeleton Established

\n

The Mint workspace now includes the following components:

\n\n

Next Week’s Plan

\n

The second week will focus on the “Upload Layer and Request Status Management” phase, prioritizing the following:

\n
    \n
  1. \n

    Integrate Pinata / IPFS upload logic to complete the basic pipeline from local images to CIDs.

    \n
    2. \n
  2. \n

    Implement upload-related state management, including loading, success, and failure states, along with error prompts.

    \n
    3. \n
\n

Best,

\n

HNO3Miracle

", "like_count": 0, "quote_count": 0 }, { "post_id": 24037, "post_number": 15, "topic_id": 10098, "topic_title": "Spark Program | CKB-UGMP —— A Universal Spore/DOB Seamless Minting Infrastructure Prototype on CKB —— 基于 CKB 的通用 Spore/DOB 无感铸造基础设施原型", "topic_slug": "spark-program-ckb-ugmp-a-universal-spore-dob-seamless-minting-infrastructure-prototype-on-ckb-ckb-spore-dob", "author": "yixiu.ckbfans.bit", "created_at": "2026-04-26T12:23:13.118000+00:00", "updated_at": "2026-04-26T12:23:13.118000+00:00", "reply_to_post_number": 14, "url": "https://talk.nervos.org/t/spark-program-ckb-ugmp-a-universal-spore-dob-seamless-minting-infrastructure-prototype-on-ckb-ckb-spore-dob/10098/15", "content_text": "Cool，论坛已经接入了AI智能翻译组件，以后不必“发双份”带翻译的内容了，用自己擅长的语言表达即可。", "content_html": "

Cool，论坛已经接入了AI智能翻译组件，以后不必“发双份”带翻译的内容了，用自己擅长的语言表达即可。

", "like_count": 0, "quote_count": 0 } ] }, { "topic_id": 10131, "title": "Spark Program | CKB Developer Onboarding Guide", "slug": "spark-program-ckb-developer-onboarding-guide", "url": "https://talk.nervos.org/t/spark-program-ckb-developer-onboarding-guide/10131", "created_at": "2026-03-26T08:49:26.745000+00:00", "last_posted_at": "2026-04-26T06:34:24.804000+00:00", "category_id": 49, "tags": [ "In-Progress", "Spark-Program" ], "posters": [ "Original Poster, Most Recent Poster", "Frequent Poster", "Frequent Poster" ], "recent_posts": [ { "post_id": 24035, "post_number": 14, "topic_id": 10131, "topic_title": "Spark Program | CKB Developer Onboarding Guide", "topic_slug": "spark-program-ckb-developer-onboarding-guide", "author": "Mateja3m", "created_at": "2026-04-26T06:34:24.804000+00:00", "updated_at": "2026-04-26T06:34:24.804000+00:00", "reply_to_post_number": null, "url": "https://talk.nervos.org/t/spark-program-ckb-developer-onboarding-guide/10131/14", "content_text": "Hi @xingtianchunyan, below you can find the progress report for Milestone 1, week 2\nWeek 2 Milestone 1 Progress Report\nStatus\nMilestone 1 has been completed.\nThis phase focused on finishing the remaining Milestone 1 onboarding documents, replacing placeholder-only setup sections with validated guidance, and extending the validation evidence behind the local CKB node and RPC flow. The work completed during this period strengthens the project goal of reducing beginner ambiguity and making the path to first successful RPC interaction more explicit and repeatable.\nRepository And Publication Status\nThe repository structure established in Week 1 remains in place, and the Week 2 work was completed in the local repository workspace.\nDuring this run:\nno GitHub push was performed\nno pull request was opened\nno git commit was created\nno remote configuration was changed\nThis is important because the Week 2 work was intended to refine Milestone 1 content locally before any later publication or review step.\nWork Completed\n1. Remaining Milestone 1 Setup Sections Completed\nThe previously placeholder-only Milestone 1 setup sections were expanded into beginner-oriented, validation-first documentation.\nCompleted or substantially completed sections include:\n03 Quick Start\n04 CKB Node Setup\n05 RPC Setup\n07 Configuration Setup\nThese sections now provide:\na shortest validated path to first RPC success\nexplicit step-by-step node startup guidance\nRPC request and response interpretation for beginners\nminimal configuration awareness without speculative file-edit instructions\nThis directly supports the Milestone 1 requirement to help a developer reach first successful RPC interaction through a documentation-first onboarding flow.\n2. Milestone 1 Navigation And Scope Messaging Refined\nThe top-level project messaging was updated so the repository no longer describes the completed Milestone 1 setup sections as placeholders.\nUpdated files include:\nREADME.md\n00 Overview\n02 Environment Setup\nThese updates improved:\ndocument sequencing\nscope clarity\ninternal cross-references\nthe distinction between completed Milestone 1 content and later placeholder sections\n3. Validation-First Boundaries Strengthened\nThe Week 2 documentation pass preserved the rule that the guide should not guess commands, paths, ports, or behaviors that were not validated locally.\nAs part of this cleanup:\nvalidated commands were kept explicit\nspeculative configuration editing was not introduced\nendpoint ambiguity was documented instead of hidden\nlater scope was left as placeholders rather than filled with weak guidance\nThis keeps the guide aligned with the project’s positioning as a complement to official Nervos documentation rather than a replacement for it.\n4. Placeholder Milestone Labels Added\nLater placeholder sections were updated so TODO: VALIDATE markers now include a milestone label where the planned sequencing is already clear.\nUpdated placeholder sections include:\n06 Indexer Setup: Milestone 2\n08 First Developer Workflow: Milestone 2\n09 Common Errors and Remediation: Milestone 2\n10 Troubleshooting Matrix: Milestone 2\n11 AI-Assisted Debugging: Milestone 3\n12 CKB Mental Model: Milestone 3\n13 Common Misconceptions: Milestone 3\nThis improves planning clarity by showing which unfinished sections belong to later milestones instead of leaving all later work under one undifferentiated validation marker.\nValidation Work Completed\n5. Environment Connectivity Validation Refined\nThe Week 1 connectivity failure around https://example.com was revisited and clarified through a more meaningful real-URL test.\nPublished findings updated in Week 2 include:\nEnvironment Validation Findings\nThe updated validation now shows:\nrepeated example.com hostname resolution failure in the local environment\nsuccessful HTTPS header retrieval from https://google.com\nevidence that target selection matters when using a simple connectivity check\nThis is useful because it prevents the guide from incorrectly treating one failed hostname test as proof that all network-dependent onboarding is blocked.\n6. Node And RPC Validation Expanded Significantly\nThe local CKB node and RPC evidence base was expanded through multiple additional validation passes.\nPublished findings updated in Week 2 include:\nCKB Node And RPC Validation Findings\nThe expanded validation covered:\nrepeated offckb node startup after initial installation\nrepeated successful JSON-RPC responses from localhost:8114\nsuccessful JSON-RPC responses from 127.0.0.1:28114\nwrong-method behavior on both endpoints\nHTTP 200 OK confirmation for JSON-RPC POST requests\nlocal process inspection with lsof\ncustom --binary-path startup using the discovered local CKB binary\nconfirmation that the devnet path exists after initialization\nThis strengthens confidence that the Milestone 1 onboarding path is not a one-off success case.\n7. Local Endpoint Relationship Clarified\nWeek 2 validation materially improved the explanation of local endpoint behavior.\nThe observed local evidence now shows:\nckb listening on port 8114\nnode listening on port 28114\nvalid JSON-RPC POST responses from both endpoints\nThis does not fully document the internal implementation details, but it is strong enough for beginner-facing onboarding guidance. It supports the practical explanation that 28114 behaves like a Node.js / OffCKB proxy layer while 8114 behaves like the underlying ckb RPC listener.\n8. Binary Path And Devnet Path Validation Added\nWeek 2 also validated filesystem-level details that were previously only partially understood.\nThe local validation now confirms:\nthe installed CKB binary can be discovered at runtime rather than guessed\nthe binary version can be checked directly from that path\noffckb node -b works on the validation machine\nthe devnet directory appears after initialization and contains real configuration and data paths\nThis improves the quality of the configuration guidance while still avoiding unsafe or speculative edit instructions.\n9. Milestone 1 Scope Boundaries Confirmed\nWeek 2 also confirmed that some sections should remain intentionally incomplete at the end of Milestone 1.\nThe validated scope decision is that Milestone 1 now covers:\nprerequisites\nenvironment setup\nquick start\nCKB node setup\nRPC setup\nminimal configuration awareness\nThe following remain intentionally outside the completed Milestone 1 scope:\nindexer setup details\nfirst full developer workflow\nremediation and troubleshooting matrix content\nAI-assisted debugging guidance\nbroader conceptual materials such as mental models and misconceptions\nThis keeps the milestone focused on onboarding and first success rather than expanding prematurely into later-phase documentation.\nOutcome Against Week 2 Scope\nWeek 2 successfully delivered:\ncompleted Milestone 1 setup documents for quick start, node setup, RPC setup, and configuration setup\nstronger internal consistency across the main onboarding docs\nupdated validation findings based on repeat local testing\nclearer explanation of local RPC endpoint behavior\nmilestone labels for later placeholder sections\na stronger basis for declaring Milestone 1 substantially complete\n第2周里程碑1进展报告\n状态\n里程碑1已完成。\n本阶段重点是完成里程碑1剩余的入门文档，将仅占位的设置部分替换为经过验证的指导，并扩展本地 CKB 节点和 RPC 流程的验证依据。本阶段完成的工作进一步强化了项目目标，即减少新手的不确定性，使首次成功进行 RPC 交互的路径更加清晰和可复现。\n仓库与发布状态\n第1周建立的仓库结构保持不变，第2周的工作在本地仓库环境中完成。\n在此期间：\n未进行 GitHub 推送\n未创建 Pull Request\n未创建 git 提交\n未更改远程配置\n这一点很重要，因为第2周的工作目标是在本地完善里程碑1内容，以便后续再进行发布或评审。\n已完成工作\n1. 完成里程碑1剩余设置部分\n此前仅为占位的里程碑1设置部分已扩展为面向初学者、以验证为优先的文档。\n已完成或基本完成的部分包括：\n03 快速开始\n04 CKB 节点设置\n05 RPC 设置\n07 配置设置\n这些部分现在提供：\n达到首次 RPC 成功的最短验证路径\n明确的逐步节点启动指导\n面向初学者的 RPC 请求与响应解释\n最小化配置认知（避免推测性文件修改指引）\n这直接支持了里程碑1的目标，即通过以文档为核心的入门流程帮助开发者实现首次成功的 RPC 交互。\n2. 优化里程碑1导航与范围说明\n更新了顶层项目说明，使仓库不再将已完成的里程碑1部分描述为占位内容。\n更新文件包括：\nREADME.md\n00 概览\n02 环境设置\n这些更新提升了：\n文档结构顺序\n范围清晰度\n内部交叉引用\n已完成内容与后续占位内容的区分\n3. 强化“验证优先”的边界\n第2周的文档完善过程中，始终遵循不猜测未验证内容的原则。\n具体包括：\n保留明确验证过的命令\n不引入推测性的配置修改\n明确记录端点不确定性\n后续内容保持占位而非填充不可靠信息\n这使文档继续作为官方 Nervos 文档的补充，而非替代。\n4. 添加里程碑标签到占位部分\n后续占位部分新增了里程碑标签，用于明确规划顺序。\n更新包括：\n06 Indexer 设置：里程碑2\n08 首个开发工作流：里程碑2\n09 常见错误与修复：里程碑2\n10 故障排查矩阵：里程碑2\n11 AI 辅助调试：里程碑3\n12 CKB 心智模型：里程碑3\n13 常见误解：里程碑3\n这提升了规划清晰度。\n验证工作\n5. 优化环境连接验证\n第1周中 https://example.com 的失败测试已被重新分析，并通过更有意义的真实 URL 测试进行验证。\n更新结果包括：\n本地环境中 example.com 解析失败\n成功获取 https://google.com HTTPS 响应头\n证明测试目标选择会影响结果\n这避免了错误地将单一失败当作整体网络问题。\n6. 扩展节点与 RPC 验证\n对本地 CKB 节点与 RPC 进行了多轮验证。\n新增验证包括：\n多次执行 offckb node 启动\n从 localhost:8114 获取成功响应\n从 127.0.0.1:28114 获取成功响应\n错误方法测试行为\nJSON-RPC POST 返回 HTTP 200\n使用 lsof 检查进程\n使用 --binary-path 启动\n验证 devnet 路径存在\n增强了稳定性信心。\n7. 明确本地端点关系\n验证结果显示：\nckb 监听端口 8114\nnode 监听端口 28114\n两者均可返回有效 JSON-RPC\n可解释为：\n28114：Node.js / OffCKB 代理层\n8114：底层 CKB RPC\n8. 验证二进制路径与 devnet\n确认：\n可动态发现 CKB 二进制路径\n可直接检查版本\noffckb node -b <路径> 可用\n初始化后生成 devnet 目录\n9. 确认里程碑范围边界\n里程碑1覆盖：\n前置条件\n环境设置\n快速开始\n节点设置\nRPC 设置\n基础配置\n不包含：\nIndexer 设置\n完整开发流程\n故障排查矩阵\nAI 调试\n概念性内容\n第2周成果总结\n成功交付：\n完整的里程碑1核心文档\n更一致的文档结构\n更新的验证数据\n更清晰的 RPC 行为说明\n明确的后续里程碑规划", "content_html": "

Hi @xingtianchunyan, below you can find the progress report for Milestone 1, week 2

\n

Week 2 Milestone 1 Progress Report

\n

Status

\n

Milestone 1 has been completed.

\n

This phase focused on finishing the remaining Milestone 1 onboarding documents, replacing placeholder-only setup sections with validated guidance, and extending the validation evidence behind the local CKB node and RPC flow. The work completed during this period strengthens the project goal of reducing beginner ambiguity and making the path to first successful RPC interaction more explicit and repeatable.

\n

Repository And Publication Status

\n

The repository structure established in Week 1 remains in place, and the Week 2 work was completed in the local repository workspace.

\n

During this run:

\n\n

This is important because the Week 2 work was intended to refine Milestone 1 content locally before any later publication or review step.

\n

Work Completed

\n

1. Remaining Milestone 1 Setup Sections Completed

\n

The previously placeholder-only Milestone 1 setup sections were expanded into beginner-oriented, validation-first documentation.

\n

Completed or substantially completed sections include:

\n\n

These sections now provide:

\n\n

This directly supports the Milestone 1 requirement to help a developer reach first successful RPC interaction through a documentation-first onboarding flow.

\n

2. Milestone 1 Navigation And Scope Messaging Refined

\n

The top-level project messaging was updated so the repository no longer describes the completed Milestone 1 setup sections as placeholders.

\n

Updated files include:

\n\n

These updates improved:

\n\n

3. Validation-First Boundaries Strengthened

\n

The Week 2 documentation pass preserved the rule that the guide should not guess commands, paths, ports, or behaviors that were not validated locally.

\n

As part of this cleanup:

\n\n

This keeps the guide aligned with the project’s positioning as a complement to official Nervos documentation rather than a replacement for it.

\n

4. Placeholder Milestone Labels Added

\n

Later placeholder sections were updated so TODO: VALIDATE markers now include a milestone label where the planned sequencing is already clear.

\n

Updated placeholder sections include:

\n\n

This improves planning clarity by showing which unfinished sections belong to later milestones instead of leaving all later work under one undifferentiated validation marker.

\n

Validation Work Completed

\n

5. Environment Connectivity Validation Refined

\n

The Week 1 connectivity failure around https://example.com was revisited and clarified through a more meaningful real-URL test.

\n

Published findings updated in Week 2 include:

\n\n

The updated validation now shows:

\n\n

This is useful because it prevents the guide from incorrectly treating one failed hostname test as proof that all network-dependent onboarding is blocked.

\n

6. Node And RPC Validation Expanded Significantly

\n

The local CKB node and RPC evidence base was expanded through multiple additional validation passes.

\n

Published findings updated in Week 2 include:

\n\n

The expanded validation covered:

\n\n

This strengthens confidence that the Milestone 1 onboarding path is not a one-off success case.

\n

7. Local Endpoint Relationship Clarified

\n

Week 2 validation materially improved the explanation of local endpoint behavior.

\n

The observed local evidence now shows:

\n\n

This does not fully document the internal implementation details, but it is strong enough for beginner-facing onboarding guidance. It supports the practical explanation that 28114 behaves like a Node.js / OffCKB proxy layer while 8114 behaves like the underlying ckb RPC listener.

\n

8. Binary Path And Devnet Path Validation Added

\n

Week 2 also validated filesystem-level details that were previously only partially understood.

\n

The local validation now confirms:

\n\n

This improves the quality of the configuration guidance while still avoiding unsafe or speculative edit instructions.

\n

9. Milestone 1 Scope Boundaries Confirmed

\n

Week 2 also confirmed that some sections should remain intentionally incomplete at the end of Milestone 1.

\n

The validated scope decision is that Milestone 1 now covers:

\n\n

The following remain intentionally outside the completed Milestone 1 scope:

\n\n

This keeps the milestone focused on onboarding and first success rather than expanding prematurely into later-phase documentation.

\n

Outcome Against Week 2 Scope

\n

Week 2 successfully delivered:

\n\n
\n

第2周里程碑1进展报告

\n

状态

\n

里程碑1已完成。

\n

本阶段重点是完成里程碑1剩余的入门文档，将仅占位的设置部分替换为经过验证的指导，并扩展本地 CKB 节点和 RPC 流程的验证依据。本阶段完成的工作进一步强化了项目目标，即减少新手的不确定性，使首次成功进行 RPC 交互的路径更加清晰和可复现。

\n

仓库与发布状态

\n

第1周建立的仓库结构保持不变，第2周的工作在本地仓库环境中完成。

\n

在此期间：

\n\n

这一点很重要，因为第2周的工作目标是在本地完善里程碑1内容，以便后续再进行发布或评审。

\n

已完成工作

\n

1. 完成里程碑1剩余设置部分

\n

此前仅为占位的里程碑1设置部分已扩展为面向初学者、以验证为优先的文档。

\n

已完成或基本完成的部分包括：

\n\n

这些部分现在提供：

\n\n

这直接支持了里程碑1的目标，即通过以文档为核心的入门流程帮助开发者实现首次成功的 RPC 交互。

\n

2. 优化里程碑1导航与范围说明

\n

更新了顶层项目说明，使仓库不再将已完成的里程碑1部分描述为占位内容。

\n

更新文件包括：

\n\n

这些更新提升了：

\n\n

3. 强化“验证优先”的边界

\n

第2周的文档完善过程中，始终遵循不猜测未验证内容的原则。

\n

具体包括：

\n\n

这使文档继续作为官方 Nervos 文档的补充，而非替代。

\n

4. 添加里程碑标签到占位部分

\n

后续占位部分新增了里程碑标签，用于明确规划顺序。

\n

更新包括：

\n\n

这提升了规划清晰度。

\n

验证工作

\n

5. 优化环境连接验证

\n

第1周中 https://example.com 的失败测试已被重新分析，并通过更有意义的真实 URL 测试进行验证。

\n

更新结果包括：

\n\n

这避免了错误地将单一失败当作整体网络问题。

\n

6. 扩展节点与 RPC 验证

\n

对本地 CKB 节点与 RPC 进行了多轮验证。

\n

新增验证包括：

\n\n

增强了稳定性信心。

\n

7. 明确本地端点关系

\n

验证结果显示：

\n\n

可解释为：

\n\n

8. 验证二进制路径与 devnet

\n

确认：

\n\n

9. 确认里程碑范围边界

\n

里程碑1覆盖：

\n\n

不包含：

\n\n

第2周成果总结

\n

成功交付：

\n", "like_count": 0, "quote_count": 0 } ] } ] }