regexgen

• 

  screenshot of health

• 

  screenshot of 200 receipt

• 

  screenshot of 402 challenge

• 

  screenshot of architecture

• 

  screenshot of tests

• 

  screenshot of github repo

inspiration

i kept running into the same thing — someone needs a regex, they google it, copy-paste some stack overflow answer that kind of works but not really, and then spend an hour debugging edge cases. i wanted to build something where you just describe the pattern in plain english and get back a regex that's actually been tested against real inputs.

when i saw the x402 protocol on the hackathon resources page, it clicked. the idea of gating an API behind a micropayment instead of an api key or subscription is kind of perfect for this — you pay a cent per call, you get your regex + test cases, done. no account, no rate limiting, no stripe integration. the 402 status code literally means "payment required" and x402 turns that into an actual payment flow on base.

what it does

you POST a natural-language description to /generate (like "match us phone numbers" or "find email addresses"). the server returns a 402 with a payment challenge. your wallet signs it, you retry the same request with the signature, the server verifies + settles through the x402 facilitator on base-sepolia, and you get back:

• the regex
• 3 test cases (two matching, one non-matching) with matched_by results so you can verify it actually works
• a settlement receipt with the on-chain tx hash

the regex engine has two layers:

1. heuristic — keyword-matched templates for common patterns (phone, email, url, ipv4, date, hex, uuid, credit card, ssn, zip). zero dependencies, instant, handles maybe 90% of what people actually ask for.
2. llm fallback — if the heuristic doesn't recognize the request and you've set LLM_URL, it prompts an openai-compatible endpoint to generate a regex + test cases. if you don't set it, the heuristic still covers the common stuff.

how i built it

flask server with the x402 python sdk handling the payment flow. the sdk gives you a resource server that builds payment requirements, verifies signed payloads, and settles through a facilitator. the facilitator listed on the hackathon resources page (facilitator.goplausible.xyz) handles the on-chain verify + settle.

the regex engine is just a list of keyword → regex template mappings. each template ships with 3 test cases that get validated against python's re module at request time, so the client always gets back whether each test case actually matched.

for the payment flow: no payment header → 402 with the challenge in the body + X-PAYMENT-REQUIRED header (base64-encoded json). client signs, retries with X-PAYMENT-SIGNATURE header → server verifies via facilitator → settles → 200 with regex + receipt in the body and X-PAYMENT-RESPONSE header.

challenges i ran into

the hex regex was annoying. at first i had 0x1A2b matching as hex but the "0x" prefix made it match things i didn't want. had to tweak the boundary conditions and ended up reverting once because the fix broke the test suite.

the bigger one was figuring out the x402 flow end to end. the sdk has both sync and async variants and the documentation is still pretty new — i had to read through the sdk source to understand how build_payment_requirements, find_matching_requirements, verify, and settle all connect. the facilitator returns a settlement response with a tx hash, and including that in the 200 response was important because the hackathon explicitly asks for a transaction receipt in successful responses.

i also had to think about what happens when the heuristic misses. originally i had a local llm endpoint hardcoded as the fallback, but then realized anyone else trying to run this wouldn't have that. so i made it optional — LLM_URL is a config var, and if it's not set, the heuristic just handles the common patterns and everything else raises a clean error.

what i learned

the x402 protocol is honestly pretty clean once you get the flow. 402 → sign → retry → verify → settle → 200. the facilitator abstracts away the on-chain stuff so the server doesn't need to touch ethereum directly. the whole payment layer is like 30 lines in server.py.

what's next

• more heuristic templates (timestamps, hex colors, mac addresses, coordinates)
• caching so identical requests don't need a new payment
• a simple web ui on top of the api so you can try it without running demo.py

Built With

• base
• blockchain
• flask
• micropayments
• python
• rest
• usdc
• x402