This is what it does

PhishGuard

A sign-in link that replaces the six-digit code: signed, dead after sixty seconds, usable once. Mint one below, open it, then try to use it again.

The token rules, running in your browser — a port of the documented design, nothing sent anywhere

What it does: mints an HMAC-signed link carrying a nonce and a 60-second expiry, verifies the signature before anything else, and refuses the replay.
What to try: press Open the link, then press it again. Then tamper with one character, and mint one that is already expired.
What runs here: a port of the documented token rules with the browser’s own crypto. The product’s implementation is Python and its single-use guarantee is a database row deleted on first verify; this page stands in for that row with a list in the tab.
The documented limit, shown not hidden: the signature covers the nonce and the expiry only. The phone number and the purpose live in the stored row, so editing that row leaves the token valid.
What it is not: a sign-in step. It removes the replayable code; it does not make a compromised phone safe.

Status

Where this stands today

The suite passes: 105 tests, measured by running it on this pass rather than quoting a document — the project’s own files have carried 25, 29, 33, 63, 74 and 105 at different points, and the run is the only copy that counts. It covers mint and consume, the three link outcomes, the carrier webhook signature, the opt-in rules and the rate limits.
Not deployed, and real SMS is blocked on carrier registration. The A2P 10DLC brand and campaign are an external process with fees charged at submission and owner-only steps inside it. The base URL every link is built from is still the placeholder https://verify.phishguard.example, a reserved documentation domain that does not resolve.
Pricing is not set, and this page will not invent one. Billing was deliberately deferred; a pilot would be priced by hand, and nothing here is a rate, a minimum or a discount.
Until the carrier clears, the console has a demo button that stands in for the phone, so the whole mint → click → consumed loop can be shown to a pilot prospect.

Plainly

The difference its own plan claims is not built. Binding a token to the specifics of a payment — the amount and the destination inside the token — is the differentiator in the plan and is explicitly deferred until after launch. What exists today is a sign-in link.
The audit trail is not built either, and is not claimed here. The project’s own README records that the anchoring was never implemented, and pins that correction rather than deleting the sentence.
It is not alone in this category. Large identity providers already sell phone verification at roughly five cents per verification, so the comparison to make is per verification, not per feature.
An intercepted message is still intercepted. What the short expiry and single use remove is the replay: a link that was read, forwarded or screenshotted stops working the moment it is used once, or after a minute either way.

Under the hood

Stack: Python with FastAPI, HMAC-SHA256 for the link signature, PBKDF2-SHA256 at 600,000 iterations for passwords, and Twilio for delivery, over SQLite locally and Postgres in production.
Surfaces: The API, the verification page an SMS link resolves to, an operator console served by the same service, the carrier opt-in page and privacy policy, and the generated API docs. One origin, so no CORS configuration.
Auth: Bearer JWT for minting and the console; consumption is open but rate-limited to 30 attempts a minute per address; the carrier status webhook is signature-checked against the account auth token and fails closed without it.
Payments: None. Billing was deliberately deferred, and the intended path is a handful of pilot customers provisioned by hand.

Whether the carrier registration has cleared, what a pilot would involve, or where the commercial side stands — ask before you plan around any of it.