
Margin Trading Delisting from Top Exchange
Pretty sure because CKB has been sliding down in the market cap ranking. Do you think this will influence other exchanges to do the same?

Pretty sure because CKB has been sliding down in the market cap ranking. Do you think this will influence other exchanges to do the same?
26th May 11 GMT on Reddit.
Hello, ladies and gentlemen of the CKB variety. Another Nervos community AMA is rolling out on May 26th, and this time it’s with one of CKB’s community DAO projects.
Raheem Jr, is a mobile software engineer and blockchain enthusiast, he joined the ckb community in 2021 and started developing on CKB in August 2025 after joining the CKBuilder cohort and he's currently building Pocket Node: a light client wallet on the CKB Nervos network
Github: https://github.com/RaheemJnr
Pocket node website: www.pocket-node.com
X: Jr.bit u/mumedi6
Nervos talk post: https://talk.nervos.org/t/dis-mobile-ready-ckb-light-client-pocket-node-for-android/9879/37
So don't be shy, ask some questions.
Jan Xie has been working behind the scenes Vibe coding and this popped up on Talk.nervos.org
"I’d like to introduce CKBadger, a local-first CKB-native explorer. It’s a small homebrew project that I’ve been working on for months.
CKBadger is highly opinionated and not meant to be for everyone. It’s built around a few questions that I wanted to explore.
CKBadger started from several personal interests.
I chose the explorer scenario because it fits all of the above goals.
An explorer is useful enough to be real, but also safe enough to be a good playground. CKBadger only needs to read data from a CKB node. It does not need to manage private keys, sign transactions, or run on-chain scripts. That means I could focus on product structure, data presentation, performance, local-first architecture, and the human-AI development workflow, instead of worrying about high-risk security requirements.
Now I’m pretty sure that 100% vibe coding can already produce a medium-sized project with good usability, maintainability, optimization, and production-level usefulness.
That does not mean the human becomes irrelevant. Quite the opposite.
The human may not need to code, but the human still needs to make design decisions. The human needs to choose trade-offs. The human needs to decide what matters, what can be ignored, what should be simplified, and who the project is for.
The human may not need to code, but the human still needs to know how to write documentation, how to design tests, and how to manage a codebase where they cannot personally review every line. A developer working with agents becomes a product+project manager.
AI can help with execution. It can generate the flesh and bones. But only the human can give a project its soul.
I deployed a public demo so people can try CKBadger before deciding whether it is worth running locally. This is not very “local-first” but a preview should help the project’s cold start and overall understanding - a reasonable compromise
It also shows a well-designed local-first app may run as a web2 app, while a centralized web service usually cannot easily become a local-first app.
Please do not treat the demo as a long-term official service. It is only a preview and demonstration. It will be taken down after a month or so. 0% service gurantee.
The best way to use CKBadger is to run it yourself, locally.
Enjoy and have fun!"
Today, we’re announcing the establishment of the Common Knowledge Base Association (CKBA): a Swiss Verein registered in Baar, Switzerland, created to serve as the new coordination layer for the CKB ecosystem.
This marks the natural progression of the Nervos Foundation into a more durable, participatory, and contributor-driven structure.
The people, the mission, and the commitment to CKB remain the same.
What changes is the structure around that work.
For years, the Foundation model helped steward CKB through a period of regulatory uncertainty, where separation between the network, its founders, contributors, and coordinating entities was necessary.
That distance served an important purpose: it gave CKB room to mature as neutral and resilient public infrastructure.
Over time, however, it also became a source of operational friction.
Today, the circumstances have changed.
Both CKB and the broader regulatory landscape have matured, creating the opportunity to bring the teams and people who have spent the last eight years contributing to CKB into a more aligned structure.
CKBA is that structure.
It is a membership-based, contributor-driven non-profit association with two membership tiers:
Importantly, this does not change CKB itself.
CKB remains a permissionless and neutral network governed by its own PoW consensus rules and maintained by independent participants across the ecosystem.
CKBA does not own or control CKB. Its role is to support contributors and improve coordination around CKB’s long-term development, adoption, and resilience.
If you have been contributing to CKB, join us 👇
This is not a reinvention of CKB.
It is the next stage in its evolution.
Read the full announcement on Nervos Talk: https://talk.nervos.org/t/a-new-chapter-for-ckb-introducing-the-common-knowledge-base-association/10249
Welcome to the latest CKB Ecosystem Biweekly Update. Here’s a quick summary of key dev and ecosystem progress from the past two weeks.
Every step forward in CKB is powered by the community. Let’s keep building!
Thanks to u/JackyLHH for his contribution to the edition of the bi-weekly report.
This is pretty cool that someone is buidling how to use Fiber nodes for the non super tech crowd. If anyone tries it give the OP some feedback on the forum post https://talk.nervos.org/t/fiber-desktop-run-fiber-fnn-on-your-laptop-without-the-public-node-headache/10247
Hi everyone,
If you follow Nervos, you may have heard of Fiber — a way to move value quickly on top of CKB using channel-style payments, routing, and invoices. To use it, you normally need a small program running in the background: the official Fiber Network Node (often called fnn). That program is the “engine” that opens channels, listens for payments, and creates invoices.
The awkward part is not the idea of Fiber. It is where that engine is supposed to live. Many people end up looking at rented servers, router settings, always-on home machines, and security checklists just to feel like they can participate. That is a lot of work for something that should feel closer to “install an app and use the network.”
There is a second wall that hits even on your own laptop: setup is often CLI-heavy. Getting from zero to a working node can mean a long chain of terminal commands — right binary, paths, config, key material, then RPC-style steps for connecting to peers, opening channels, creating invoices, and so on. That is fine for power users, but it filters out anyone who wants to try the network without treating the docs like a daily homework assignment.
I built Fiber Desktop to narrow both gaps: less hosting pressure and less death-by-CLI. This post explains what it is and how it fits together for people who are not deep into ops or protocol details.
Fiber Desktop is a desktop application for Mac or PC (tested properly for Mac). It does not replace the official Fiber software. It wraps it: it helps you install and run the same official node (fnn) on the machine you already use, with clearer steps, start/stop controls, and safer handling of secrets.
In plain roles:
Where you would otherwise juggle many CLI commands and hand-built RPC calls, the app pushes you toward guided flows and in-app actions (for example connecting to documented relays or trying channel and invoice steps from the UI) so you are not memorizing command order on day one.
Under the hood it is a native app (Tauri + React, etc.). If you are not technical, you can ignore that: what matters is that it is a normal desktop app controlling the official Fiber node on your desk or laptop.
Source: github.com/chukwuma619/fiber-desktop
Using Fiber seriously usually means keeping that engine running and connected enough to be useful on the network. That often pushes people toward:
On top of that, day-one onboarding is often a long sequence of CLI and JSON-RPC steps: easy to get stuck on one wrong path, flag, or payload even when you are not trying to self-host.
Fiber Desktop is aimed at a different default: run the official node locally, on hardware you already own, with a user experience closer to consumer software — guided setup instead of a wall of commands — while still following how the Fiber ecosystem expects nodes to connect and discover each other, including documented public relay nodes.
Fiber nodes talk to each other peer-to-peer. Public relay nodes are well-known peers listed in the official docs. They act like on-ramps: you connect out to them so your node is no longer isolated.
In Fiber Desktop that shows up as actions like connecting to relay 1 or relay 2 for your chosen network, using the same public keys the Fiber project documents. https://github.com/nervosnetwork/fiber/blob/develop/docs/public-nodes.md
You are not inventing a custom bridge; you are joining the same mesh the docs describe. That is different from “I must run a public website that exposes my wallet.” You are participating in a network of nodes, not necessarily running a personal datacenter as the default onboarding story.
After you are connected, the next big step is usually opening a channel with another node (often one of the public relays when you are learning). A channel is a rules-based pipe between two nodes.
Important nuance: payments usually do not flow as “one big public server receives everything and then downloads it to your laptop.” They move hop by hop across many channels when needed. Public relays help you plug in and become part of that map, but a payment route can be longer than a single hop.
When you create an invoice, that request is generated by your local node. You share it (text / QR) with whoever pays. You do not need a public payment website for that step.
When someone pays your invoice, their software searches for a path across the network — a chain of channel hops from them to you. If a valid path exists and every hop has enough capacity pointing the right way, the payment settles on your node — the one running under Fiber Desktop.
So this high-level picture is right: the payment is routed across the Fiber network until it reaches my local node. The small correction is: it is not always “only the public relay sends it down to me”; it is often several hops across different nodes, with yours as the final stop.
Receiving reliably in channel-based networks usually needs incoming capacity (liquidity and channel layout that allow value to flow toward your node). If someone tries to receive before channels are set up sensibly, they may see “no route” even when the app is working. Fiber Desktop makes the machinery easier; the economics of the graph are still part of the real network.
Fiber Desktop does not change what Fiber is. It changes how painful it is to run the real thing on a normal computer: official software first, local control, less accidental sysadmin, and less reliance on a long CLI checklist just to get started.
If you try it, feedback is welcome — especially first-time setup, key handling, connectivity to public relays, and whether the guided flows replace the commands you used to need.
The Linkdn Nervos Community Account is also a good place to follow this news and subscribe to email bulletin updates (link below)
The most exciting work happens when builders take the lead.
Fiber Link has published its latest product delivery report, marking its transition from an engineering prototype toward a product-ready, deployable release.
Built as an open-source tipping layer for online communities, Fiber Link lets users tip posts or replies directly from familiar forum interfaces (starting with Discourse), without requiring members to run their own Fiber nodes.
This milestone includes a video demo with comprehensive documentation for administrators and operators to deploy the service.
Fiber Pay is a toolkit that allows AI agents to manage Fiber Network operations like opening channels and making payments. Its latest release introduces ConnectButton, a simplified way for frontend apps to connect to a Fiber browser node using passkey or password authentication with minimal setup.
This update also includes stability fixes for useFiberNode under React StrictMode, a refreshed browser-wallet demo with the new connect flow, and a quick-card demo showing payment integration and UI customization.
Built on top of the latest Fiber-Pay release, this experiment explores a decentralized AI Agent calling platform. Users can invoke agents running on remote hardware from their browsers, with peer-to-peer payments, similar in experience to cloud-based agent services.
Key aspects include:
Dular is a stablecoin wallet designed to bridge Fiber with the mobile money ecosystem. It replaces hex addresses with phone number identities and supports USSD access for feature phones. It leverages Fiber’s low-fee, native multi-asset channels to enable instant payments, with integrated M-Pesa on/off ramps.
The latest Nervos AMA focuses on the Fiber Network! Join us to chat with DevRel engineer Retric about his recent experiments with paywalled applications, including the Fiber Audio Player and L402 blog prototype.
Join the discussion or drop questions in advance here before May 12th at 11 GMT!
Fiber Network is a community-driven ecosystem with real support behind its builders. If you’re thinking about building something, here is how we can help:
Share your idea on the Nervos Talk forum and reach out to the programs above. We’d love to see what you build show up in our next update!