Hi everyone,
I’m Long Tran, a blockchain engineer at Texlabs and founder of Midnight Explorer. My team and I are currently exploring the CKB and Fiber ecosystem, particularly the intersection of Fiber, machine payments, and autonomous AI agents.
After reading the recent “AI, machine payments, and Fiber in 2026” opportunity map, we became interested in the Routed CKB-Asset Sessions (RCS) direction.
Before building anything, we would like to validate whether the following developer-infrastructure direction fills a meaningful gap in the current Fiber ecosystem.
1. The Problem
AI agents and autonomous software are increasingly able to consume external services such as:
-
AI inference APIs
-
search/data APIs
-
compute services
-
agent-to-agent services
-
other metered APIs
Protocols such as x402 can handle the HTTP payment negotiation layer:
request → payment required → payment → service access
However, we are interested in a different problem:
What happens when an autonomous agent has a long-running relationship with multiple paid services and needs to make many small payments without requiring human approval for every request?
For example:
AI Agent
|
+---- Search API
|
+---- AI Model Provider
|
+---- Data Provider
|
+---- Compute Service
A developer should not need to manually manage Fiber invoices, routes, retries, payment state and recovery for every individual service interaction.
2. Proposed Direction
We are considering building a developer-oriented integration layer for routed machine-payment sessions on Fiber.
The goal is NOT to create another payment protocol.
Instead, the layer would reuse existing pri mitives:
AI Agent / Software
|
v
Developer SDK / Session API
|
+---- spending policy / authorization
|
+---- x402 payment negotiation
|
+---- routing / retry / recovery
|
+---- receipts & payment state
|
v
FNN / Fiber
/ | \
/ | \
API A API B API C
A developer could conceptually create a limited session:
const session = createPaymentSession({
budget: 100,
asset: "CKB",
expiresIn: "1h"
})
await session.request(searchAPI)
await session.request(modelAPI)
await session.request(dataAPI)
The agent would operate inside the user’s predefined spending policy while the SDK handles interaction with the underlying payment infrastructure.
3. What We Do NOT Want to Rebuild
There are already several relevant projects in the ecosystem, including:
-
FNN / Fiber payment primitives
-
x402 integrations
-
AgentPay
-
FiberPass
-
fiber-pay
-
FiberLatch
-
Infern
-
Spindle
We do not want to duplicate these projects.
In particular, FiberPass already explores spending permissions and payment sessions, while AgentPay already provides agent-oriented payment APIs.
Our current hypothesis is therefore narrower:
Can we provide a reusable integration layer focused specifically on multi-provider routed sessions, while reusing existing wallet/payment/session primitives wherever possible?
The interesting Fiber-specific property we want to investigate is whether one funded Fiber environment can efficiently support repeated payments across several independent providers, rather than simply implementing another one-way paid API flow.
4. Why Fiber?
For a normal one-way USDC API payment, Fiber may not be necessary.
The reason we are exploring Fiber is its combination of:
-
payment channels
-
repeated off-chain payments
-
multi-hop routing
-
CKB / UDT asset support
-
bidirectional payment capability
-
hold invoices / keysend
-
potential interoperability with the broader CKB/RGB++ ecosystem
The hypothesis is that these properties become useful when an autonomous service interacts repeatedly with multiple independent providers.
If this hypothesis is wrong and x402 + a conventional payment rail already solves the problem sufficiently, we would prefer to discover that before building another abstraction.
5. Initial Validation Scope
Rather than starting with a large product, we propose first validating a small end-to-end scenario.
Example:
Payment Budget
|
v
AI Agent
|
Payment Session
/ | \
/ | \
Provider A B Provider C
\ | /
\ | /
Fiber Network
The initial experiment could measure:
-
repeated payments within one session;
-
payments to multiple providers;
-
payment completion rate;
-
payment latency;
-
retry behaviour;
-
route failures;
-
session recovery after process restart;
-
receipt and payment-state reconciliation;
-
developer integration complexity.
The demo applications themselves would not be the product.
For example, an AI model API or search API could simply be used as test consumers to demonstrate the payment infrastructure.
6. Potential Deliverables if the Direction Is Validated
If community feedback confirms that this is a useful gap, an initial implementation could include:
-
Open-source TypeScript SDK
-
session lifecycle
-
Fiber/x402 adapter
-
payment state handling
-
retries and recovery
-
-
Multi-provider demonstration
-
at least 2–3 independently deployed services
-
repeated payments through Fiber
-
-
Reproducible test environment
-
FNN setup
-
example paid APIs
-
Docker-based development environment
-
-
Metrics and technical report
-
payment latency
-
success/failure rates
-
recovery behaviour
-
routing behaviour
-
operational limitations discovered during testing
-
-
Developer documentation
-
integration guide
-
example agent
-
example service provider
-
7. What Success Would Look Like
Rather than measuring success only by “the SDK exists”, we would like to produce evidence that is currently still limited in the ecosystem.
Potential validation targets could include:
-
1,000+ repeated test payments;
-
at least 3 service integrations;
-
successful multi-provider payment sessions;
-
documented restart/recovery testing;
-
publicly reproducible deployment;
-
at least 2–3 developers outside the core implementation testing the SDK.
These numbers are only initial ideas and we would refine them based on community feedback.
8. Team
We are a team from TexLab
- Long Tran — Senior Blockchain Engineer
- Hiep Tran — Senior DevOps Engineer
- Bach Trinh — Engineering Manager
- Minh Le Dinh — Business Development
- Trung Pham — Senior Software Engineer
Together, we cover blockchain development, backend and infrastructure engineering, DevOps, product execution, and business development.
9. Questions for the Community
Before investing significant development time, we would really appreciate feedback from Fiber developers and existing project builders.
Specifically:
-
Does this multi-provider routed-session problem represent a real missing layer in Fiber today?
-
Is this sufficiently different from FiberPass, AgentPay, Spindle and existing x402/Fiber work, or would it be more useful to contribute directly to one of those projects?
-
Which existing Fiber components should we reuse rather than rebuild?
-
What would be the most valuable real-world workload to validate this architecture?
-
Would measurements around repeated payments, routing, recovery and independent provider integrations provide useful evidence for the RCS direction?
Our intention at this stage is to validate the problem and technical boundary first.
If the community believes this direction is useful, we can build a small proof of concept and then return with a more concrete implementation plan, milestones, measurable deliverables and funding request.
Feedback and criticism are very welcome.