What changed

A new "Seen before?" check sits on the registry and the financing desk, for a lender about to advance who was handed only an invoice, not a receivable ID. Enter the supplier, the debtor, the invoice number, the amount and the currency, and it says whether a matching invoice is already on record at Almstins. It needs a free sign-in; a signed-out visitor gets a sign-in prompt, never an answer. An account with a verified email, or one that signs in with Google or GitHub, also sees whether the invoice is recorded as financed, whether the debtor has confirmed or disputed it, and when it was first recorded; any other signed-in account sees only whether a match exists. The match is on the invoice itself, not on the debtor’s reference alone. A match is a warning to look closer, never a clean bill and never a legal status, and "not found" covers only records kept at Almstins. When the check cannot run it says so, and that is never read as "not found". The check writes nothing about the invoice you type and tells no one you looked. A plain-language page at almstins.com/verify/seen-before explains it.

On the financing desk, the registry page and the Client Portal, the form now checks the invoice while you fill it in. Once the debtor, the amount, the currency and either the client and invoice number or the debtor’s own reference are in, and about half a second after you stop typing, it asks whether another record at Almstins matches. It waits for you to stop, so it does not ask on every keystroke, and the check itself saves nothing. If another record matches, a "Possible duplicate" note appears above the button. For an account with a verified email, or one that signs in with Google or GitHub, it says when the other record is recorded as financed ("This invoice may already be financed. Check with the debtor before you advance.") and lists your own records that match, each with a link to open it. Other accounts are told only that another record matches. The note never holds up the form: you can still record the invoice, and the decision is yours. After you save, the same place shows the check’s answer for the record you just made, including when the check could not run and, for a verified account, when it could compare only the invoice number because no debtor reference was given. It never names the other record or whose it is. On the Client Portal, where the client records his own invoice, the note says the match may be his financier’s own record of it.

The debtor’s PO or contract number is the one detail the client does not control, so it is the strongest thing the duplicate check compares. The desk kept it under "Add more contract details"; it now sits with the main fields, still optional, with a line saying why it helps. The registry page and the Client Portal ask for it too and record it with the receivable. A receivable recorded without one gets the same receivable ID it always would have.

When the receivable matches another record at Almstins (for a verified account, one recorded as financed), the desk and the registry page show a "Possible duplicate" prompt before the claim is recorded. "Record my claim anyway" records it, with your acknowledgment signed into the claim; "Not now" records nothing. It comes after the debtor-confirmation and headroom prompts when those apply, and each answer carries through, so one claim can show up to three prompts. Until today these pages recorded such a claim without asking. If the duplicate check cannot run, the claim is recorded and the note says the check was not available.

A row that another record at Almstins matches carries a "possible duplicate" tag in your book on the desk, in "Your receivables" on the registry page and on the Client Portal. An opened record shows the warning too, and the public check adds the tag beside the record’s status. The tag never says which record matched or whose it is. On the registry page, "claimed only" now uses the same tag as the desk.

That stopped being true when the duplicate check arrived. It now says what the check does not cover: it compares records at Almstins with the same debtor and debtor’s reference, or the same debtor, client and invoice number, at the same amount and currency. A different amount or currency, or a debtor named differently, does not match; a client named differently, or a different invoice number, matches only through the same debtor reference; and records kept outside Almstins are not compared. The user’s guide says the same, and its glossary adds "Debtor reference" and "Possible duplicate".

Posting almstins.com/receivables on LinkedIn or X showed the site-wide wallet picture. It now shows a receivables card, and the receivables pages are titled with a middle dot, as in "Receivables · Almstins Verify". A preview LinkedIn or X has already saved can take a while to update.

Deleting used to remove the receivable along with your own claims and statements on it, so a financed receivable could vanish from the registry and be recorded again as if nothing stood against it. Now a withdrawn receivable leaves your list, but its record stays. While another party has a claim or a statement on it, the public check still answers for it, with every claim and statement as it was and a "withdrawn" mark beside its usual status, so a dispute or full financing still shows at a glance. It also stays in the book of any financier holding a claim on it. If nobody else has anything on it, the check answers as if it was never recorded. New claims, statements, requests, offers and files on a withdrawn receivable are not recorded. A financier can still mark an existing claim repaid, and a client can still answer a financier’s receipt link for an existing advance, confirming or disputing it. Your own open requests for it stop working, and attached files are kept only as fingerprints: the file list shows each one’s name, size and fingerprint, marked removed. Recording the same details again brings it back. If another account records identical details, it is told the record already exists, even after a withdrawal.

Two records match when they have the same debtor, the debtor’s own PO or contract number, amount and currency, or the same debtor, client, invoice number, amount and currency. Differences in how they were typed still match, such as "ACME Ltd" and "Acme Limited", or "INV-0042" and "inv 42". A match reads as a caution. For an account with a verified email, or one that signs in with Google or GitHub, it also says whether the other record is recorded as financed, and when only the debtor’s reference matched, that it may be another installment under the same order. Other accounts are told only that another record matches, and the saved result of each Verify now keeps only that. A receivable with no debtor reference also reads as a caution, because only the invoice number could be compared, so Verify now on most existing receivables now reads "attention" for that reason. The check never names the other record, whose it is, or who financed it, and practice records only ever match practice records. If the check cannot run, it says so and counts as unproven. When someone registers a claim on a receivable that matches one in your book, yours shows as updated. Nothing is held up by a match: the decision stays yours.

The message used to suggest changing a field to record it separately. Recording the same invoice again under small changes is what the new duplicate check looks for, so the message now says a receivable with these exact details is already on record at Almstins under another account, and nothing more.

A site on MetaMask’s verified-safe list read green even when ScamSniffer, GoPlus or another source had flagged it. Any flag from any source now makes the result red. MetaMask’s safe list only overrides MetaMask’s own blocklist.

The yellow state for unreachable sources only switched on when every source failed, and the downloaded lists never fail, so a site could read green while GoPlus or URLScan.io was down. Now any unreachable source shows "Limited check: some sources could not be reached", the way the address checker already did.

If our copy of the OFAC sanctions list could not be read, or Chainalysis did not answer, the address still read as no sanctions match. The sanctions row now says "Unavailable" and the whole result becomes a limited check until the list can be read again.

A clean result means no source we checked has flagged the site yet, not that it is safe. Lists are incomplete and lag behind new scam sites. The site checker and the Verify scan page now say so under every clean result, as the address checker already did. The decision stays yours. The checker page’s title no longer asks "Is this address safe?"; it now reads "Check an Address or Link Before You Send", and the page no longer promises "a verdict": it shows what each listed source reports.

The sanctions card said "OFAC and international sanctions lists"; the check uses the U.S. Treasury OFAC SDN list, from a public copy we refresh every few hours, plus GoPlus Security’s sanctions flag. The Funding tab promised "detailed funding source tracing"; it shows one signal, whether the address is flagged for mixer use. Chainabuse is no longer listed as a source while it is switched off, and the privacy policy now says Chainabuse receives an address only while that lookup is switched on. The policy keeps its version number and effective date.

Each site check asks several outside services, so it now has the same per-visitor limit. When one of those services fails, the result says so in plain words instead of passing along its raw error text.

Until now the desk ended there, while the registry page already let you go ahead with an acknowledged over-claim. Both pages now work the same way: you see what is unencumbered and what is already claimed, and you choose to register only the available amount or record it anyway. On both pages, recording it anyway now signs that acknowledgment into your claim, so the record shows you saw the warning. Claims recorded before today are unchanged. The desk’s over-financed note now reads "Check before you advance." instead of "Do not advance.": the warning is ours to show, and the decision stays yours.

Both were signed when they happened, but the signature was not kept, so nothing outside our records could later show when a claim was released or a receivable was paid. The signature and the exact time now stay with the record, and each one is stamped in Bitcoin the way the receivable itself is. If a stamp cannot be made right away, it is retried automatically, and each Verify now receipt is stamped the same way. Discharges and settlements recorded before today keep their recorded dates without a stamp.

The integrity check accepted only the key in use today, so changing the key would have marked every older record as signed by an unknown key. It now accepts any key Almstins has published, current or retired, and still fails a record signed by any other key.

The registry always had a Disputed status, but nothing ever switched it on, so a receivable the debtor said was not theirs, or one whose client said the money never arrived, still headed the check as "Available to finance" or "Partially encumbered". The dispute itself was listed further down; now the status at the top says it too, ahead of everything except the TEST marker.

Answers that come back through a request link open with a marker word: DISPUTED, DILIGENCE, UNANSWERED or DECLINED. Anyone holding the receivable ID could type a statement that opened the same way. Every new statement now records where it came from, and the public check decides whether a record is disputed from that, not from the opening word, so a typed statement stays a typed statement however it opens. A typed statement that opens with one of those four words in capitals, or with one of them followed by a dash, comes back with a note to start it another way. Statements already on file are read by their opening word, as before.

The record was still found, but the claims already standing against it were looked up with the untrimmed ID, none were found, and the whole face value read as available. Existing claims are now always counted against the record itself.

It used to count by an address the caller could supply, so the limit was easy to sidestep, and the list it kept never shrank. It now uses the visitor’s real address (an IPv6 network counts as one visitor per /64), the way sign-in counts attempts, and the answers are marked never to be cached, so every check reads the record as it stands now.

Marking a claim repaid used to just close it out, nothing else. Now you can add a short note when you do it, "wire received Sept 28" for example, and it is signed into the same discharge record as the release itself. Optional: skip it and nothing changes. It stays yours — the public check never shows it, same as every other detail that would say who you are.

The registry, the desk, the client portal, confirm, offer, invite and the rest work from either address, so nothing already bookmarked or already sent to someone breaks. The public pages also lock down harder: no embedding in someone else’s page, no search-engine indexing, and a same-origin referrer policy, so leaving one of these pages for another site does not hand it your full page address.

Signed in, you get your account menu and "Open the desk", no sign-in links, no demos. Signed out, you get "Log in to get started" and the interactive demos instead. The demo link also stopped signing a real account out just to show the demo: it sends you on to the page you asked for, or your dashboard.

A signature proves what was true when it was signed, not that it stayed true. Verify now re-runs every load-bearing check at the moment you rely on the record: the signature itself, the financing headroom, the debtor’s acknowledgment, whether claims are confirmed as funded, and the Bitcoin anchor. It fails closed, so anything that cannot be re-confirmed drops the verdict to "needs attention" rather than passing quietly, and every run leaves its own dated, signed receipt as evidence the check was made.

The page always asked for your own receivables list in the background, and that request was blocked for anyone not signed in. It now returns an empty list for a visitor instead of an error, and your own list once you are signed in. Also fixed: Verify now’s numbers are grouped with commas like the rest of the page (50,000,000, not 50000000), and the "See how it works" demo link is back at the bottom of the registry now that the demo shows the Verify-now step accurately too.

One tile links the three tools you can open directly, the Financing Desk, Check a receivable, and the Client Portal, beside a tile marking what is still coming. A two-column hero previews the product instead of only describing it, and the three trust points (read-only and no custody, organizes but never decides, provable not promised) open into the fuller explanation of why each one holds. The steps that only open from a link sent to one specific party (accepting an offer, acknowledging a debt, confirming an invoice, attesting a deal, confirming funds arrived, accepting an invitation) are named on the page but not linked as cards, since visiting one directly used to dead-end on "this link is not valid".

Registering a claim already blocks a double-pledge over the available headroom. Now financing a receivable with no buyer attestation on record throws a clear caution instead of allowing it silently: "Recorded" is not "Attested", and any claim rests on the supplier’s word alone until the debtor confirms. It is a caution, not a block, so you can ask the debtor to acknowledge first, or finance anyway with your eyes open. The same warning shows on the public check, and the attestation role list now reads "inspector / surveyor", since an inspector or surveyor attests to the goods the same way a buyer attests to the debt.

The form reads your country from the request and pre-selects USDC if you are financing from the US; everyone else still sees NGN first. It is only a default. Every currency on the list stays one click away.

The desk, the public check, and the offer, attest and countersign pages already marked test records everywhere, but a supplier recording a deal at the Client Portal had no way to flag one as practice, so every receivable a supplier recorded was real. A "Practice run, record as a test" checkbox now does the same job there: a loud TEST treatment on the record, on the tracking panel, and on your own receivables list.

Client intake, debtor confirmation, and client acceptance are now three sections divided by a green rule, each numbered with a short note on what it is for. Attaching the first contract marks intake done and dims it; recording marks debtor confirmation done and lights up client acceptance as the next thing to do, scrolling to it and focusing the email field. Recording no longer throws the check result over the desk, which had been burying the very step you needed next, and a "Start another deal" button resets the tin for the next client.

A debtor confirming, a client accepting, or another financier registering a competing claim on one of your deals now bolds that row with an accent dot and floats it to the top, with a banner counting how many contracts changed since you last looked. An "Updated only" filter chip sits next to the existing search, and opening a contract clears its own flag right away.

Recorded, debtor confirmed, terms accepted, advance registered, receipt confirmed, repaid: each stage now shows the date it actually happened, inside its own bordered card. A stage not yet reached shows no date rather than a guess, and every stage still jumps to its matching card.

What the desk is, the terms in plain English (available to finance, debtor confirmation, claim, receipt), what it proves, and, just as prominently, what it does NOT prove: who actually answered or whether they had authority to, that goods were delivered, claims recorded outside this registry, and legal priority, which is decided by law, not by Almstins. It shows once; "How this works" in the header reopens it any time.

Choosing a file used to give no sense it had actually attached. Each file you choose now joins a running, removable list, and a "ready to attach" checklist appears just above Record so you can see exactly what will go up before you submit. Files still upload only once the receivable exists, on Record.

It only unlocked in the same browser session right after you recorded a deal. Come back later, even to a deal the debtor had since confirmed, and it sat disabled with nothing to click. It is now always available as its own tool: recording a deal fills in its receivable ID automatically, or you can paste the ID of any earlier deal to send the request without opening it from your book first.

Closes with an × button, a click on the backdrop, or Escape, and locks the page behind it from scrolling while it is open.

A debtor, a client, or a party answering an offer or a receipt request used to land on a bare success message with nowhere to go. All four now land on one thank-you page that confirms the answer is signed and timestamped, and points to the same three Almstins tools (Wallet Checker, Verify, Wallet Watcher) shown elsewhere.

Record the deal, scan the papers in, and ask the debtor, in one submission. Then step two asks your client to confirm you took it down correctly. It was four cards and three trips down the page.

The amount, the charge, whether it is recourse, and how it is repaid. Your client initials the recourse clause and accepts in his own name, signed and timestamped. His signature is worth most while he still wants something.

Practise without anyone mistaking it for real. The flag sits inside the signed record, so it shows on the public check and on every page you send, and a test record can never be quietly promoted into a real one.

Seven stages across the top, each marked done, current or still ahead, and a line naming the single next action. Both are clickable and take you to the card that does the work.

A client who goes quiet used to leave nothing behind, not even a record that you asked. Now the request and its silence are signed onto the receivable, and everything outstanding across your whole book sits in one panel.

The request was spent before the answer was checked, so a client who missed the initials box was locked out of an offer he never answered. A rejected answer now leaves the request exactly as it found it.

A record ten seconds old showed a red "no debtor acknowledgment". Nobody had confirmed because nobody had been asked. Red is now reserved for something overdue or gone wrong.

The financing position as a bar, every piece of evidence as present or absent, and beside it an explicit list of what none of it proves. From the first pilot review: decide from one screen, not by assembling four.

Every deal you have recorded, newest first, with the receivable ID copyable or clickable. Before this the desk could only reach a record by pasted ID, and nobody can hoard twenty 64-character hashes.

Create and email a request, and replies come back to your own address. Create link only copies it instead, and the link stays in the list afterwards, for email, WhatsApp, or however you reach them.

Two separate faults, both ours, both caught by a real person clicking a real link. Every link already sent now redirects itself to the right page rather than dead-ending.

The public check promises no identities, and the statement included the address the request went to. The name stays, because an attestation exists to say who asserted something. The address does not.

It appeared only once an advance existed, which taught people it had never been built. It now shows what it is for before you can use it.

With the fields a real contract carries: invoice and delivery dates, goods, payment instructions, the debtor’s own reference, and free fields for anything else. You should never need a field and not have it.

They type their own reference from their own records, tick four separate statements, and can disagree as easily as agree. Asking a supplier to make his customer sign up for software is how the step quietly never happens.

Registering a claim costs nothing and anyone with the ID can do it. Until the man who was supposed to receive the money says he received it, a claim is one firm’s word.

Fingerprinted on upload and named in any confirmation given while it was visible, so a swap afterwards is provable. The file is dropped once everyone asked has answered. We witness the paperwork; we never become its custodian.

Including a section on what the platform does not prove, which is the part worth reading twice.

The same company had been called a supplier, a seller, a borrower and a client on one screen.

So "who is my client" has an answer, without either side seeing into the other’s account.

An hourly job records each confirmation as it lands, so a record’s date becomes permanent without anyone reopening the page.