ulegend

Another update on QuotaCell When I first introduced QuotaCell, I talked about a problem I wanted to solve on CKB: letting teammates or software agents make approved payments from a shared treasury without giving them unrestricted access to the funds. Since then, I've demonstrated that CKB itself can enforce those spending limits, even when the transactions are constructed outside the application. But there's another important question. What happens when the owner no longer wants someone to have spending authority? Can they revoke access and recover their treasury funds without depending on that person? That's what I've been working on next. I've now tested the owner-control lifecycle using real signed transactions on a fresh, isolated CKB node. Here's what I was able to demonstrate: Revoking access: The treasury owner signed and submitted a transaction to revoke a delegate's spending permission. It committed successfully. Enforcing that revocation: I constructed another payment using the latest policy state and the delegate's valid signature. CKB rejected it specifically because the delegate's authority had been disabled, not because the transaction was using an outdated Cell. Recovering treasury funds: The owner closed the spending policy and recovered all 200 protected synthetic tokens, together with the fund Cell's 154 CKB capacity, into an owner-controlled token Cell. No delegate signature was needed. Recovering funds sent after closure: I also tested what happens when tokens arrive after the policy has already been closed. I sent 50 of the recovered tokens back into the protected treasury, then successfully recovered them through a separate owner-signed transaction. The final owner balance remained 200 tokens. Why does this matter? Giving someone limited spending authority is only one part of managing a treasury. The owner also needs a reliable way to withdraw that authority, stop future permitted spending and recover supported funds when a working relationship ends or the treasury is closed. That's the bigger product I'm working toward with QuotaCell: making delegated spending practical for CKB teams, services and eventually autonomous agents, with restrictions enforced on-chain rather than depending entirely on an application's backend. There's still an important limitation. The current experimental policy permanently retains a 600 CKB Cell after closure, with about 572 CKB required for its occupied state. That isn't a transaction fee, but it does mean capital remains tied up. The recovered fund capacity also remains inside owner-controlled token Cells. Improving capital efficiency, supporting native CKB payments and making recovery accessible through proper owner tools are still important parts of the work ahead. This is local-node testing with synthetic xUDT, not a public-testnet release or a security audit. I've published the new signed transaction evidence, accounting records and reproduction instructions on GitHub so other CKB developers can inspect the result. 🔗 New evidence: github.com/Ticoworld/QuotaCe… 🔗 Full progress discussion: talk.nervos.org/t/quotacell-… Still a lot to improve, but it's good to see another important part of QuotaCell working through actual CKB transactions. Feedback from CKB builders is always welcome, especially around owner recovery, capacity costs and practical treasury workflows. @CKBdev @ckba_build @NervosNetwork @NervosCatalyst #CKB #Nervos