Supplier
Lagos Foods Ltd
Almstins
Verify ยท Receivables Registry
Can two lenders finance the same invoice?
Duplicate financing happens when a second lender never sees that a first lender already advanced against the same receivable. This walks one receivable end to end: a ₦100m invoice, an ₦80m advance already claimed against it, and a second financier who checks before lending. Each claim is a real signed proof; the check runs against the claims, not against anyone's private word.
This is a demo of the mechanism, not the production registry. The cryptography is real — each claim is signed with Ed25519 in your browser and can be timestamped into Bitcoin. Keys are generated fresh in your browser for this page and discarded when you leave, so a demo signature can never pass as Almstins' production signing key. What a production system decides — where the claims live, who may write, who may read — is the design work below the demo. The point here is to show the check working.
1The receivable — the thing every claim points at
Buyer (obligor)
MegaRetail Nigeria PLC
Invoice
INV-4471
Face value
₦100m
Terms
Net 60
Due
2026-09-30
Receivable ID — the SHA-256 of the creation record from Stage 1. Every financing claim references this exact hash, so a claim can't be quietly moved to a different invoice or amount:
computing…
2The registry — every claim standing against this receivable
…
…
3Second financier — check before you lend
₦
4Does the proof stay true?
A signature proves what was true when it was signed. It cannot promise the fact stayed true between the advance and settlement. The debtor's acknowledgment, the address funds point to, the reserves behind a claim — any can change while a claim is still outstanding. So a lender does not lean on the last check. They verify now, at the moment they act, and the proof fails closed: when it cannot be re-confirmed, its confidence steps down on its own rather than vouching forever.
Why this isn't just another intermediary's database
The obvious way to build this is a private table that only one operator can read. That rebuilds the middleman the whole idea is meant to remove, and it asks every lender to trust that operator's book. So it isn't built that way.
It's the model Verify already runs, applied to claims. Verify lets a wallet holder show their own wallet to the world. This lets a financier show their own claim to the world — the same direction of power: a party voluntarily disclosing their own position. The second financier reading it isn't surveilling anyone and isn't reaching across any private boundary, because the claim was published by the party who made it, exactly like a shown wallet. Nothing here touches data a party didn't choose to publish, and the anchor sits on a public chain regardless.
So each claim is a public, signed, Bitcoin-anchored proof bound to the receivable's hash. "Querying the registry" means resolving every claim-proof that points at a given receivable and adding them up. Nobody trusts Almstins' word for the total — they check the proofs. That is what makes it a neutral shared layer rather than a new gatekeeper. Almstins records and proves state; it never makes the financing decision.
Open design questions — the ones worth deciding together
- Where do the claims live so both lenders can resolve them — a public chain index, a neutral shared store, or anchors plus a lookup service?
- Who may write a claim, and how is a claim's face amount tied to an authoritative creation record so it can't be inflated?
- Who may read, and how much — the full claim, or only "₦X already encumbered, ₦Y free" without exposing counterparties?
- How is a claim discharged at settlement so headroom is released honestly?
Real SHA-256 + Ed25519, run entirely in your browser; the Bitcoin anchor is the same one used by /artifacts/sandbox and /artifacts/proof.
almstins.com/verify · almstins.com