Post-grant update: FiberFlow integration and real Fiber testnet settlement
Hi everyone,
I’ve continued working on FiberLatch after the grant, mostly by testing where it can actually fit into existing Fiber applications.
One of the projects I tried was FiberFlow.
The integration worked around a simple boundary:
Fiber payment → FiberFlow invoice.paid → FiberLatch access → protected resource
FiberFlow handles the payment. Once the application trusts the paid event, FiberLatch handles the access that comes after it.
While testing this, I noticed I was repeating the same PostgreSQL logic in both the FiberFlow integration and a separate FiberLatch reference app, especially around limited-use receipts and safe concurrent redemption.
So I extracted that part into a small optional package:
@fiberlatch/[email protected]
The main @fiberlatch/access package is still 0.1.1.
Real settlement test
The first FiberFlow integration was tested around the webhook flow, but I still wanted to complete it with a real Fiber payment.
Since the hosted FiberFlow service was unavailable, I ran FiberFlow locally on testnet and tested the whole flow with separate payer and merchant Fiber nodes.
The payment settled successfully.
From the same payment:
- FiberFlow moved the invoice to
Paid - the real signed
invoice.paidwebhook reached the store - FiberLatch created one entitlement
- the purchaser retrieved the signed receipt
- uses 1, 2 and 3 succeeded
- use 4 was denied
- the final redemption count stayed at
3/3
The first webhook delivery also timed out after it had already been processed, so FiberFlow retried it. The retry still left only one FiberLatch entitlement, which was a useful idempotency check.
I also checked that another account could not retrieve or use the purchaser’s access.
What I learned from this
This test made the FiberLatch boundary clearer.
FiberLatch is not trying to replace Fiber payment tooling. The application still decides whether a payment or permission is valid.
FiberLatch starts after that decision and turns it into a signed access receipt with things like subject binding, resource scope and limited uses.
The PostgreSQL package is just an optional reusable store for apps already using PostgreSQL.
This is currently tested in my FiberFlow fork and local setup, so this is not upstream FiberFlow adoption yet.
It was also testnet-only, so I’m not making any mainnet or production-readiness claim from this test.
Full settlement evidence:
FiberLatch:
PostgreSQL store: