DEV Community: Peter Sjolin

What eight live testnet contracts taught me about testing, gas, and putting an LLM in a settlement path

Peter Sjolin — Wed, 05 Aug 2026 13:35:44 +0000

Most write-ups about smart contract work show you the parts that worked. This one includes the parts that didn't, because those are the ones worth reading.

Seven contracts, deployed to Base Sepolia. Eight pages that read chain state on every request. No forks, no local Anvil node dressed up as a network, no screenshot standing in for a transaction. Contract addresses print on the page and open on Basescan. You can connect a wallet and make any of them do something.

Here's what I found building them.

One pipeline, seven repos, one definition of green

Each repo vendors a shared pipeline as a submodule and calls its reusable workflow. A fix to a gate lands once instead of seven times.

Order matters more than people give it credit for. forge lint and Solhint run first, because linting takes seconds and fuzzing takes minutes. Then Foundry unit, fuzz and invariant tests on a pinned toolchain — a skipped test is a red build, not a yellow one. Then Slither at fail-on low, with every excluded detector argued in writing. Then Echidna and Medusa, two independent fuzzers running one shared Properties.sol.

The interesting bit is why the property count is a Solidity literal:

A stale build artifact once shrank a property set and reported a smaller green run.

The suite went green with fewer properties registered and nothing said so. Now the expected count is declared in the source and four independent checks must agree with the literal before a build passes. The harness audits itself.

The coverage gate is 100% line, statement, branch and function on every file under src. The only exclusions are snarkjs-generated verifier contracts, excluded by name and printed on every run rather than folded into a percentage. A percentage hides an exclusion; a printed name doesn't.

How the contracts are tested

Two of four gas optimizations are basically noise

One contract, deployed twice. One ordinary version, one with four optimizations, and a compiler-enforced identical ABI so signature drift fails the build. A runner calls both in a single transaction, so both face the same block, the same base fee and the same caller. Figures come out of the receipt.

technique	saving
packed struct on `writeRecord`	71.8% (92,195 → 25,976 gas)
bitmap replacing a `bool` mapping on `setFlagRange`	85.6%
calldata over memory	0.1%
custom error over revert string	1.9%, reverting path only

The last two stay in the table. Calldata-over-memory is swamped by the cold storage writes in the same call. The custom error saves nothing on any path that doesn't revert. A demo where every technique wins is a curated demo.

And the counterpoint sits on the same page: the optimized contract costs 10.1% more to deploy.

Race an operation

The Chainlink guard in everyone's consumer code that never fires

Protocols rarely lose money because an oracle got attacked. They lose it because the consuming contract called latestRoundData, took the answer, and used a price that was already stale, or negative, or from a round that never finished.

A contract reads four live feeds and names which of six failure states applies, reporting the most severe when several apply at once.

Two things fell out of building it.

Per-feed staleness thresholds are not optional. The three crypto feeds republish every few minutes on price deviation. USDC moves on a roughly 24-hour heartbeat — I measured it across two intervals before writing the contract. One estate-wide threshold describes neither feed correctly.

answeredInRound >= roundId is dead code. That guard is still copied into consumer code today. On all four aggregators it returns equal to roundId, so it never fires. It's a comfort check.

One testing note: the staleness boundary is inclusive, and the property harness constructs both sides of the threshold on every run. Interior sampling never catches a > swapped for a >=.

Read the feeds

Putting a language model in the settlement path

This is where the AI and blockchain overlap gets interesting, and it's mostly a division-of-labor problem. A chain records a decision permanently and makes no judgment of its own. A model makes judgment calls and remembers nothing. Two demos draw that line in public.

ZK escrow. Funds release one of two ways. A Groth16 proof of a delivery secret releases them without revealing the secret — the commitment is Poseidon of the secret, derived on your own machine by a script in the repo, so the secret never crosses the wire. A contested delivery goes to an AI arbiter whose ruling and full reasoning are written to chain in the clear.

Two design decisions I'd defend anywhere. Settlements are never pushed — every outcome credits a pull-payment balance, so a recipient refusing a transfer never blocks a settlement. And the proof authorizes the release rather than the sender, bound to one escrow by a nullifier, so anyone can broadcast the transaction.

There's also a scar in the proxy's history: a UUPS upgrade added arbiter rotation after a dispute stranded behind an arbiter address with no known private key.

Browse the escrows

AI parametric insurance. Parametric means the payout follows a defined condition rather than an assessed loss — and that distinction is the entire reason a model belongs in the loop. Did the stated condition occur has a checkable answer. What is this loss worth does not, and this system never asks it.

Three adjudicators sign, each pinned to a different model, duplicates rejected at construction. Two agreeing verdicts settle a claim. The evidence hash lands on chain when the claim is filed, before any adjudicator sees anything, and a verdict carrying a different hash is refused rather than discounted. The decision is an enum, never prose, so a re-run compares. The adjudicator set has no owner and no setter, because an operator who can swap signers manufactures any majority after seeing the first verdict.

Here's the part I'd most want another engineer to argue with. Within three days of writing down the procedure, two of the pinned models changed behavior underneath their own identifiers. One started rejecting the temperature field outright. One started wrapping its JSON in a code fence. None of that shows up in a published hash. Pinning a model identifier does not pin model behavior, so the page calls this a multi-signer oracle rather than a trustless one.

Read the verdicts

The other three

RWA tokenization. An ERC-3643-inspired token where fractions of an asset trade as an ERC-20 and every mint and transfer passes an on-chain KYC whitelist. Four seeded transactions, and the third is the point: a correctly formed transfer of 500 tokens to an address with no KYC record, reverted by the token itself. Contracts are hand-rolled, no T-REX suite vendored. Try the transfer

ZK KYC pass. Same compliance outcome, no identity list. A holder proves in zero knowledge they hold a valid credential from an approved issuer without revealing the issuer or any identifying data. On chain there's a Merkle root and a set of spent nullifiers — nothing enumerable. The proof binds to the redeemer's address, so a stolen proof is worthless, and rotating the root re-issues the whole credential set in one transaction. See the private gate

Interest rate model. The kinked curve most lending protocols run on, deployed with every parameter fixed at construction — no owner, no setter, no upgrade path. Eight invariants are claimed for the entire valid parameter space, not the one deployed curve, so the harness builds six curves including a kink one wei above zero and one wei below full. The page shows the borrow rate one wei either side of the kink, where two formulas have to agree to the wei. They return the same integer. Move the slider

Why the failures are on the pages

Every page prints its contracts, links its repository, links its CI run, and reads its numbers off the chain while you watch. The gas demo keeps two losing techniques in the table. The AI adjudication demo says at the top of the page, not in a footnote, that the operator holds every key.

That isn't modesty. A demo that only shows wins tells you nothing about the person's judgment, which is the thing you actually wanted to know. If you build something similar, write down the parts you are not claiming — it's the cheapest credibility available.

All repos are public at github.com/pigfox. Corrections welcome, particularly on the multi-signer oracle design.

I built 27 tools and an AI arbiter that settles escrow disputes on-chain

Peter Sjolin — Sun, 26 Jul 2026 15:22:47 +0000

I run pigfox.com as a one-person shop. It's two things now: 27 tools, 16 of them free, covering OSINT, email security, TLS and document forensics — and three live smart-contract demos on Base Sepolia, one of which lets a language model decide who gets the money.

Both halves follow the same rule, and that rule is the actual subject of this post.

The rule: evidence first, interpretation second

There's a genre of tool I refused to build — paste a domain in a box, a model hallucinates a paragraph, you get a confident answer nobody can verify.

Every tool here hits real infrastructure first. DNS. WHOIS. TLS handshakes. Certificate-transparency logs. Raw EXIF bytes. Raw Received: headers. PDF object tables. The output shows you the signals it collected so you can check them yourself.

Five of the 27 call a model at all — and only after the evidence is on the table. Six more are metered without touching a model, because reverse-image lookups and WHOIS history cost money per query whether or not an LLM is involved. The other 16 are free and staying that way.

Now watch what happens when you take that rule on-chain.

The demos: where a model's output becomes a transaction

Three interactive demos, all live, all against Base Sepolia (chain 84532) — deployed contracts, real testnet transactions, hashes you can open in a block explorer.

There's a doctrine behind that: no forking. No --fork-url, no mainnet simulation, no mocked chain state. If a demo says something settled, there's a transaction hash. The Playwright E2E suite runs against the live chain too — slower, occasionally flaky, worth it. A test that passes against a mock proves nothing about a contract.

ZK Escrow Explorer — the AI arbiter

Two parties lock funds in an escrow contract. Something goes wrong. One opens a dispute. An AI arbiter reads the case and issues a ruling — and that ruling settles on-chain, moving funds.

Which is precisely the thing you should be nervous about. A language model deciding who gets paid is a terrible idea if the model is a trusted oracle with an open-ended mandate. So it isn't one:

The action space is enumerated in the contract. The arbiter selects from a fixed set of settlements. It cannot invent an outcome, cannot pay a third party, cannot move an amount nobody escrowed. The worst case is a wrong pick from a short list — not an arbitrary transfer.
The evidence is frozen before the model runs. Same rule as the tools. Case material is assembled first, the model reasons over it second.
A Groth16 circuit carries the proof obligation, so a claim can be verified without the verifier seeing the private inputs behind it.
UUPS proxy for upgradeability, because "we found a bug in the arbiter integration" has to be survivable.

Nine disputes have run end to end on-chain. Every one is inspectable.

That's what bounded AI means concretely: the model's role is narrow, its inputs are fixed, and the thing that executes its decision is a contract that structurally cannot do what the model was never allowed to ask for. The model proposes within a grammar. The chain disposes.

Compare that to the default posture — hand the model a tool that can call any function with any argument and hope the system prompt holds. That's the on-chain equivalent of vibe coding, and it's how you lose a treasury.

RWA Tokenization Explorer

An ERC-3643-style permissioned token. The interesting part versus a plain ERC-20: transfers are conditional. The contract checks an on-chain identity and compliance registry, and a transfer to an unverified address reverts. Tokenized real-world assets don't get to be bearer instruments — the restriction has to live in the token, not in a database somewhere off to the side.

Built with Foundry, pushed through Slither and Echidna.

ZK Compliance Pass

Prove you satisfy a compliance requirement without handing over the data that proves it. Same cryptographic primitive as the escrow circuit, aimed at KYC-shaped problems: the verifier learns you qualify, and nothing else.

Queued behind these: a gas-optimization demo with measured before/after deltas, and an adversarial lab — intentionally vulnerable contracts, Foundry proof-of-concept exploits, and patched versions side by side.

The tools: what's new

The bulk of the recent tool work is a cluster built around one question — is this person, offer, document, or company what it claims to be?

Job-Offer Legitimacy Check (AI) surfaces signals to investigate in a recruiter message, including the sender domain's real age. Candidate Photo Verify does reverse-image evidence: where else that photo appears online. Timeline Discrepancy Checker (AI) reads a résumé for internal-consistency signals — overlapping roles, date-vs-total mismatches, impossible tech or certification dates. Website Legit Check rolls domain age, TLS, redirects, email-security DNS and headers into one pass. Counterparty Due-Diligence Check vets a supplier before you wire anything. Document Authenticity Check scans a PDF's structure for integrity signals — incremental updates, appended content, cross-reference and date anomalies. Username Cross-Platform Check reports presence of a handle across a curated platform set.

Note what the résumé and document checkers don't do: they don't render a verdict on a person. They surface structural anomalies and hand them to you. A date gap is a question to ask, not a conviction.

The free tier, in full

OSINT & security (13 free)

TraceCheck — score a public footprint from live search signals.
Domain Recon — passive recon from public records.
EXIF Metadata Check — the camera, edit history and GPS a photo still carries.
Fake Recruiter Check — does this message match known scam patterns.
Email Header Analyzer — full Received: hop chain plus SPF, DKIM, DMARC.
Phishing & BEC Email Analyzer — scored for payment-redirect patterns.
DNS Email-Security Check — more below.
Data-Breach & Exposure Check — does this address appear in known breaches.
Certificate-Transparency Subdomain Finder — subdomains from public CT logs. No scanning, no traffic to the target.
Prompt-Injection & System-Prompt-Leak Tester — test your own system prompt against the OWASP LLM Top 10.
Username Checker — does this handle exist.
Security Headers Grader — CSP, HSTS, framing, nosniff.
SSL/TLS Certificate Checker — issuer, SANs, expiry, chain, negotiated version.

SEO & marketing (2 free)

AI-Access Checker — which AI crawlers your robots.txt allows, whether you have an llms.txt, whether your content is trapped behind JS.
Open Graph / Social Preview Checker — OG and Twitter Card tags plus a rendered preview.

Utilities (1 free)

Redirect Chain Tracer — every hop, with HTTPS→HTTP downgrades, loops and meta-refresh flagged.

Full index including the paid tools: pigfox.com/tools

The one tool I use every week

SPF allows a maximum of 10 DNS lookups during evaluation. Blow past it and the record fails — silently, from the sender's side. Most orgs find out when a quarter of their mail lands in spam.

DNS Email-Security Check counts the lookups and shows you where you sit against the ceiling. It parses DMARC properly (p, pct, rua, sp — subdomain policy is the one everybody forgets), auto-probes common DKIM selectors instead of making you guess them, pulls MX, and returns a plain-language deliverability verdict instead of a wall of TXT records.

The stack

Go monolith. One binary, html/template server-side, no SPA. Registry-driven, so adding a tool is a struct plus a handler.
PostgreSQL for everything, including the credit ledger behind the metered tools.
River for background jobs. Periodic jobs, not cron.
Solidity + Foundry for the contracts; Slither and Echidna in the loop.
Render for hosting, Playwright for E2E — including against the live chain.
Magic-link auth and Cloudflare Turnstile. Nobody needs another password.

Unglamorous recent work, since this is a developer audience: burned a golangci-lint backlog from 840 findings to zero, moved every template off text/template to html/template (a real P1 XSS), put CSP into enforce mode, and rotated a deployer key after pasting it somewhere it shouldn't have gone. That last one is the most useful thing in this post: assume you will do it too, and have the rotation path ready before you need it.

Try the ZK Escrow Explorer and open one of the settlements in a block explorer. Then run DNS Email-Security Check against your own domain.

Feedback, bug reports, and "this tool is wrong about my domain" all welcome — that last one especially.

I Built a Go App That Scores Business Ideas Before You Waste Months Building Them

Peter Sjolin — Wed, 03 Jun 2026 20:00:22 +0000

Developers are very good at building.

The problem is that we often build before we know whether the idea is worth building.

I built Market Verdict because I needed it myself.

I could not get the kind of job I wanted, so I started looking seriously at a career pivot. But even as a veteran coder, I had a hard time figuring out what was realistic.

Should I build a SaaS?

Should I create a product?

Should I start a service business?

Should I focus on AI, local businesses, SEO, automation, or something else?

I did not need generic motivation.

I needed something that could look at an idea and help me judge whether it had a realistic path forward.

That is how Market Verdict was born.

I wanted a tool that could take a business idea and return a structured, practical analysis before I spent months building the wrong thing.

What Market Verdict does

Market Verdict analyzes a business idea and returns:

A viability score
Market signals
Competitor signals
Risk factors
Break-even estimate
Suggested pivots
Execution plan
Saved idea history
Exportable reports

The goal is not to magically predict the future.

The goal is to reduce bad guesses.

Most business ideas fail because the founder starts with enthusiasm but not enough evidence. Market Verdict is meant to slow that process down just enough to ask better questions before committing serious time and money.

Why I built it in Go

The backend is written in Go.

I chose Go because I wanted:

Fast server-side rendering
Simple deployment
Strong standard library
Easy concurrency
Clean HTTP handlers
Predictable performance
Low operational complexity

Another major reason was goroutines.

A lot of the system depends on background work. Goroutines are a natural fit for that.

I use them for background processes, automation, long-tail SEO workflows, and other jobs that need to run without blocking the main user experience.

For example, I have built systems around:

Auto-generated blog content
Long-tail SEO pages
Background processing
Internal automation
Scheduled content workflows
Search-oriented landing pages

At this point, I have generated nearly 50,000 URLs with unique content as part of the broader Market Verdict SEO system.

That kind of background workload is one of the reasons Go fits the project well.

The app uses a traditional web architecture instead of a heavy frontend framework. The frontend is mostly server-rendered HTML with HTMX and vanilla JavaScript where needed.

That keeps the product fast, simple, and easier to maintain.

The stack

The current stack includes:

Go backend
PostgreSQL
HTMX
Vanilla JavaScript
HTML templates
Stripe for payments
Magic-link authentication
Server-side sessions
PDF and TXT exports
Docker-based local development
Render deployment

I wanted the app to feel lightweight but still behave like a real SaaS product.

That meant adding the less glamorous parts too:

Auth
Payment flow
Saved ideas
User limits
Free analysis tracking
Export routes
Tests
Error pages
Privacy and terms pages
Sitemap and robots files
Basic abuse prevention

Testing the product seriously

One thing I did not want was a fragile demo.

Market Verdict has more than 90% unit test coverage and close to 300 Playwright tests.

The Playwright tests cover the actual user flows, including:

Login
Magic-link auth
Idea submission
Analysis generation
Saved ideas
Payment-related routes
Export routes
Error states
Public pages
Auth-gated pages

For a SaaS product, especially one with payments and authentication, the boring parts matter.

It is not enough for the main feature to work once on your machine.

The full user flow has to keep working after changes.

The hard part: scoring without pretending to be magic

One of the hardest parts was deciding how to score an idea.

A business idea is not like a math problem where there is one correct answer.

So the score has to be useful without pretending to be absolute truth.

The approach I took was to combine multiple signals:

How clear the idea is
Who the customer is
Whether the problem is painful
Whether competitors already exist
Whether there is obvious demand
Whether the business can plausibly make money
Whether the execution path is realistic

The score is useful only when paired with the explanation.

A number by itself is not enough.

A good analysis should tell the user:

“This might work, but here are the weak spots.”

or:

“This idea is too broad. Narrow the audience and test a smaller version first.”

That is the real value.

Why I avoided making it just another chatbot

A user could technically ask an AI:

“Is my business idea good?”

But the answer will usually be too broad unless the user knows exactly what to ask.

Market Verdict is designed to produce a structured answer every time.

Instead of an open-ended chat, the app gives users a repeatable report format:

Summary
Score
Market analysis
Competitor context
Revenue assumptions
Risks
Suggested next steps

That makes it more useful for comparing multiple ideas.

It also helps non-technical founders who do not want to engineer prompts.

What I learned building it

A few lessons stood out.

First, people do not just want “AI output.”

They want decisions.

A wall of text is less useful than a clear recommendation, a score, and next steps.

Second, business validation needs to be specific.

“Start a coffee shop” is not enough.

“Start a coffee shop near a university with late-night study hours and subscription coffee plans” is much more useful to analyze.

Third, simple UX matters.

The app needs to feel like:

Enter idea
Get answer
Save or export
Improve the idea
Try again

Anything more complicated creates friction.

Fourth, distribution matters as much as code.

Building the product is only one part of the work.

The rest is SEO, content, testing, onboarding, pricing, positioning, and trust.

That is why I have also invested in long-tail SEO, automated content workflows, and thousands of targeted pages designed around specific business questions.

Current monetization model

Market Verdict currently has:

3 free analyses per email
A single paid analysis option
A monthly subscription option

I added the free tier because users need to see value before paying.

I added single purchase because not everyone wants a subscription.

I added subscription because some users will want to test many ideas over time.

What I would improve next

The next areas I am thinking about are:

Better competitor discovery
More local market signals
More industry-specific scoring
Better reports for investors
Business idea comparison
More language support
Deeper execution plans
More realistic revenue modeling

The biggest challenge is making the analysis more factual without making the product slow or expensive to run.

Try it

You can try it here:

https://marketverdict.app

I would be interested in feedback from other developers, founders, and people building SaaS products.

The question I am trying to answer is simple:

Can a structured validation tool help people avoid wasting months on weak business ideas?