## Summary
This proposal requests a grant of **$3,000** to build **FiberLatch Access**, an open-source access-control layer for Fiber payment flows.
The simple idea is this:
> fiber-pay helps apps accept Fiber payments.
> FiberLatch Access helps apps decide what a paid user can access after payment.
The proposed work will deliver:
1. A proposed access receipt format for Fiber payment-gated resources.
2. Clear expiration rules for paid access.
3. Replay-protection rules to help prevent reuse of access receipts.
4. Clear signing and verification rules for access receipts.
5. A lightweight Node.js package developers can install and adapt.
6. A paid-resource example showing how the pattern works.
7. Documentation and a final report explaining how to use and review the work.
FiberLatch Access is based on my existing FiberLatch work, where I already tested a payment-to-access flow on Fiber testnet. This grant is not for rebuilding that old work. It is for turning the useful access-control part into a small open-source developer tool that other builders can understand, install, and adapt.
**Grant Amount Requested:** $3,000
**ETA to Completion:** 6 weeks
**CKB Wallet or Funding Address:** To be added before Voting Stage
-–
## Project Introduction
Fiber payments become more useful when they can unlock real things inside applications.
For example, a platform may want users to pay before accessing paid content, an API, a file, or a private resource.
Accepting payment is only one part of that flow. After payment, the app still needs to know what the user paid for, whether the user should get access, when that access should expire, and whether the same access is being reused.
FiberLatch Access focuses on this access layer.
It is not a replacement for fiber-pay or any Fiber payment tool. It is a small open-source access-control layer that can work with Fiber payment flows.
The goal is to make it easier for builders to connect Fiber payments to actual product access.
-–
## Why This Matters
As Fiber payment tooling improves, developers will need simple patterns for what happens after payment.
Without a reusable access-control pattern, each developer may need to rebuild the same logic from scratch.
FiberLatch Access aims to provide a small and practical starting point for payment-gated access on Fiber.
It can help propose a consistent pattern for a few important parts of the payment-to-access flow:
- receipt format
- expiration rules
- replay protection
- signing rules
- verification rules
The goal is not to build a large platform. The goal is to create a small reusable building block that other Fiber builders can learn from or adapt.
-–
## Team and Roles
**Timothy Orichi / TicoWorld**
Role: Lead developer
I have been building FiberLatch as part of the CKBuilder program.
FiberLatch started as a backend reference implementation for payment-gated access on Fiber. Through the CKBuilder process, it has gone through live testnet proof work, cleanup, feedback, and review follow-up.
This proposal is the smaller grant-scoped direction of that work.
-–
## Current Status
FiberLatch already exists as prior work.
It has demonstrated this flow on Fiber testnet:
1. A user makes a Fiber payment.
2. The payment is verified.
3. The app issues a signed access receipt.
4. The receipt is verified.
5. Access is granted once.
6. Reuse is denied.
Existing work includes:
- backend reference implementation
- Fiber testnet payment verification
- signed access receipt flow
- one-time access logic
- protected resource demo
- test coverage around the access flow
- CKBuilder review and feedback
This grant will not fund the previous backend work again.
The grant will fund a smaller developer-facing access layer that packages the reusable idea in a simpler and more open-source friendly way.
-–
## What This Grant Will Build
The grant will build FiberLatch Access as a lightweight open-source Node.js developer package and example.
It will include:
- a proposed access receipt format
- expiration rules for paid access
- replay-protection rules to help prevent reused receipts
- clear signing and verification rules for access receipts
- a small package for creating and verifying access receipts
- a paid-resource example
- documentation showing how FiberLatch Access can work with Fiber payment flows
The first version will stay small and easy to review.
-–
## How It Complements Fiber Payment Tools
Fiber payment tools help developers accept payments.
FiberLatch Access focuses on access after payment.
The relationship is simple:
> Payment tools handle the payment side.
> FiberLatch Access handles the access side.
For example, an app could use Fiber payment tooling to confirm that a user has paid, then use FiberLatch Access to issue and verify access to a paid file, API, content page, or private resource.
This keeps FiberLatch Access focused on access control instead of becoming another payment SDK.
-–
## Benefits for CKB and Fiber
FiberLatch Access can help make Fiber payments more practical for real apps.
It can:
- help developers connect Fiber payments to real product access
- provide a reusable access-control pattern for payment-gated apps
- help standardise access receipts for paid resources
- complement existing Fiber payment tooling instead of competing with it
- give builders a small open-source example they can learn from
- make it easier to build paid content, paid API, and paid-resource use cases on Fiber
This is a small proposal, but it supports a useful developer need around Fiber payments.
-–
## Deliverables
The grant will deliver:
### 1. FiberLatch Access scope and design
A short design document explaining what FiberLatch Access does, what it does not do, and how it can work with Fiber payment flows.
### 2. Proposed access receipt format
A reusable receipt format for representing paid access to a resource after a Fiber payment.
### 3. Expiration and replay-protection rules
Clear rules for when access receipts expire and how reuse should be denied.
### 4. Signing and verification rules
A simple standard for signing and verifying access receipts.
### 5. Lightweight access receipt package
A small open-source Node.js package for creating and verifying access receipts.
### 6. Paid-resource example
A simple example showing how a Fiber payment can lead to access being granted to a protected resource, and how reuse can be denied.
### 7. Documentation and final report
Clear setup docs, usage guide, limitations, and a final report showing what was built and how to test it.
-–
## Timeline
The expected completion time is **6 weeks**.
- **Weeks 1-2:** Finalize scope, package design, receipt format, expiration rules, and replay-protection rules.
- **Weeks 3-4:** Build the access receipt package and paid-resource example.
- **Weeks 5-6:** Write documentation, test the package, clean up, and submit the final report.
-–
## Budget
**Total requested:** $3,000
Breakdown:
- Development: $2,400
- Documentation and example work: $400
- Testing, cleanup, and final report: $200
**Hosting cost:** $0
FiberLatch Access is not a hosted service. It is code, documentation, and an example that developers can run in their own projects.
-–
## Out of Scope
This proposal does not include:
- hosted service
- payment SDK
- dashboard
- CLI
- React SDK
- checkout product
- payment gateway
- production readiness
- mainnet readiness
- security audit
- long-term maintenance
These can be considered later only if there is real demand.
-–
## Risks and Mitigation
### Risk: The project may be confused with a payment SDK.
Mitigation: FiberLatch Access will be clearly framed as an access-control layer, not a payment SDK.
### Risk: The scope may grow too large.
Mitigation: The grant is limited to one small package, one example, documentation, and a final report.
### Risk: Developers may misunderstand what FiberLatch Access controls.
Mitigation: The documentation will explain that the host app still owns its users, database, payment flow, and final access enforcement.
### Risk: The first version may not cover every access-control use case.
Mitigation: The first version will focus on a simple paid-resource pattern. More advanced use cases can be explored later if developers find it useful.
-–
## Closing
Fiber payments become more useful when they can unlock real access inside applications.
FiberLatch Access is a small open-source access-control layer for that next step.
The aim is to help developers connect Fiber payments to paid content, APIs, files, tools, or other resources without copying the full FiberLatch backend.
I would appreciate feedback from the community on the scope, naming, budget, and whether this is useful for Fiber application developers.
-–
## Supporting Links
FiberLatch repo:
CKBuilder FiberLatch issue:
fiber-pay:
Live paid Fiber proof tag: