You're running a project. Your team needs to pay people, but you can't be around to approve every transaction. One teammate needs to pay a designer. Another needs to pay a service provider. You trust them to do their jobs, but does that mean they should have unrestricted access to the project's treasury? That's the problem I'm building QuotaCell to solve on CKB. Imagine your project treasury holds 200 tokens. You want Alice to handle design payments and Ben to handle operational expenses, but you only want them to spend 100 tokens altogether. So you give Alice permission to spend up to 70 tokens on her approved recipient, and Ben permission to spend up to 50 on his. They each have their own signing authority. Neither needs your approval for every permitted transaction. Here's where it gets interesting. Alice and Ben aren't spending from separate budgets. They're drawing from the same 100-token allowance. Alice makes a payment of 60 tokens to her approved designer. Ben then tries to pay 50 tokens to his approved service provider. Even though Ben hasn't reached his personal limit, that payment is rejected. There are only 40 tokens left in their shared allowance. Ben can pay 40, but not 50. And once they collectively spend that 100, neither can make another delegated payment. The treasury still holds 100 tokens, but that doesn't mean they're authorized to spend them. Now imagine someone deposits another 200 tokens into the treasury. The delegated spending allowance is still exhausted. Even receiving a refund doesn't restore it. Only the owner can explicitly renew that authority. That's the distinction I wanted QuotaCell to enforce. A normal application can display a budget and track payments in a database. But what happens if someone bypasses that application and constructs a transaction using another tool? With QuotaCell, the spending restrictions are enforced by a native CKB policy protecting the funds. Having a valid signing key isn't enough to override those restrictions. If a transaction exceeds the shared allowance, pays an unauthorized recipient, or breaks the policy, CKB rejects it. The idea is to let teammates make legitimate payments independently while keeping the owner's treasury protected by rules that don't depend on QuotaCell's server. And this becomes even more interesting when the people making payments aren't people at all. Consider two AI agents working for the same project. One handles approved data purchases. Another handles payments for a different operational service. Each agent has its own signing key, permitted recipient and spending restrictions. Both operate within one shared allowance. The agents can independently request and construct payments, but they can't simply exceed the authority granted to them because an AI model decides to. We've already investigated this architecture alongside existing CKB agent, wallet and transaction-building infrastructure. Our current native policy can accommodate two independently controlled software signers without changing its core spending rules. Building and testing the agent-facing transaction integration is the next part of that work. The same foundation also opens possibilities for sponsored team budgets, contributor spending permissions and other applications built around shared financial authority. I've already implemented QuotaCell's native spending policy and run 89 local CKB verification cases, all producing their expected results. Those tests cover permitted payments, attempts to exceed the shared allowance, unauthorized state changes, owner administration and recovery. The current proof uses a synthetic xUDT asset with two delegates and fixed recipient rules. It's not yet deployed publicly or independently audited, and the application itself is still being built. The goal is to turn this into something real teams can use, while making the underlying native spending policy available for other CKB applications to build around. Because giving someone access to your treasury and giving them permission to spend a limited amount are two very different things. I shared the full breakdown on Nervos Talk, including the mechanism, current progress and where QuotaCell is heading. I'd welcome real-world use cases, integration ideas and technical feedback from other builders as the work continues. talk.nervos.org/t/quotacell-… @CKBdev @NervosCatalyst @NervosNetwork @ckba_build

Line clear. Names that get paid. cellula.id

Good ideas don't stop at the hackathon or the first grant. We're seeing Fiber builders revisit earlier projects, try new things, and improve their work with feedback from the community: Twine refined its P2P trading design after security feedback, FiberLatch extended its grant-funded work with a new FiberFlow integration, and FiberSurvivors turned a browser game experiment into a reusable Unity SDK. ⚡ See how these projects are evolving in Pulse 16: fiber.world/blog/pulse/issue…

FiberLatch Access is now complete. @fiberlatch/[email protected] is live on npm, with a reusable Node.js access-receipt package, paid-resource example, documentation, and final verification. It focuses on the part that comes after a trusted payment decision: what the user can access, for how long, and how reuse is controlled. Final completion report: talk.nervos.org/t/dis-fiberl…