Verified is not audited
Audited is a legal word with a liability attached. mintrr claims something narrower, and this post says exactly how narrow that claim is.
"Verified" and "audited" are not two words for the same thing.
One is a property of the software that keeps being checked as the software changes. The other is a legal opinion about one specific file, at one specific version, delivered by somebody else. If you use the second word when you mean the first, you are describing a protection you do not have.
What we mean by a feature claim
When mintrr says a token can blocklist addresses, that claim is checked. We look for the specific marker in the generated code and in the compiled output.
If we ask for a feature and cannot find it in both places, generation stops and nothing is written.
That last part is the important one. The failure we refuse to allow is the quiet one, where a feature was requested, not delivered, and the caller cannot tell the difference. A tool that silently drops what you asked for is worse than a tool that says no.
Here is the limit of that check, stated plainly. It confirms that the right construct is present and correctly named. It does not prove that the construct behaves correctly on every path through the code. We would rather write that sentence down than let you assume more than we checked.
Why we do not say audited
An audit means a third party read the code and issued an opinion on it.
mintrr is not doing that. Claiming it would fail twice. It would overstate what we have done, and it would put a word on the product that we cannot stand behind the first time somebody asks to see the auditor's report.
The honest claim is narrower, and we think it is more useful.
Every claim we make is mechanically re-checked on every single change, by an automated check that fails the build if a claim stops being true. That is not stronger than an audit. It is a different thing. We can continuously verify our own claim. We cannot continuously verify someone else's.
How we describe blockchains
The same discipline applies to which blockchains we will make claims about, and this is where most tools go wrong.
We use a ladder with three rungs, and a claim may only use the top one.
Supported means the chain is live on a real network, with proof that it works there. Not a promise. A measurement.
Code-complete means we built it and tested it, but not on a real money network yet.
Preview means a claim we are holding back until we can measure it.
Arc mainnet is live. An upgradeable token was deployed, upgraded and transferred on the real network, with state and ownership checked after the upgrade. Arc's current maturity is supported; hosted deployment and signing permissions remain separate. The technical record is in docs/chains.md.
The product chain set is Ethereum, Polygon and Arc. Everything else was dropped on 2026-10-23, not because the adapters were bad but because an unproven chain in the list invites a reader to hear a support claim we cannot back. TRON is the clearest example: it had an adapter and templates, and no transaction was ever broadcast to its mainnet, so there was no hash to point at.
The reason is that test networks and real networks do not behave the same way. We found that the hard way on Arc, and it is written up in another post. Passing on a test network does not settle what happens on a real one, so we do not treat it as if it does.
If a claim is not on the ladder, we do not make it. No claim is better than a qualified one, because a qualified claim still reads like a claim.
Why the narrow claim is worth more
It is worth pausing on why a narrower claim is not a weaker product.
An audit is a photograph. It says: on this date, at this version, someone qualified looked at this file and formed an opinion. It is valuable, and it goes stale the moment the file changes. Every tool that generates contracts changes the file on every call, so an audit of a generated contract is an audit of that one generation, not of the thing you will deploy tomorrow.
A mechanical check is a loop. It says: the claim is re-verified on every build, and the build fails if the claim stops holding. It is narrower, because it only covers claims about our own generation, and it does not stand still. On the day the code changes, the check runs again and the claim is re-proven or the build breaks. For a product whose whole job is generating fresh contracts, a check that runs every time is worth more than an opinion that ran once.
So the claim you should trust here is the checkable one. When mintrr says a token is pausable, you can open the generated code, find the marker, and confirm it yourself. When it says a chain is supported, you can read the proof. Neither requires you to trust a person's opinion, and both stay true as the code moves.
What a feature claim covers, and what it does not
The check confirms a specific, load-bearing thing: the construct is present in the generated source and in the compiled output, and it is correctly named. That is the claim, and it is real.
It does not cover behavior on every path. A pausable token can still have a bug in how it resumes. A blocklist can still be bypassed by a transfer path nobody thought about. Those are the kinds of defect a behavioral test or a real run finds, and mintrr runs both, but the marker check is not where they are caught, and saying so is more useful than pretending one check covers everything.
We would rather write the limit down than let you assume more than we checked. An absent claim beats a qualified one, and a stated limit beats an implied guarantee.
How this shows up in the product
When you ask mintrr for a token with a feature, two things can happen. The feature is in the generated code and the build succeeds, and you get a contract plus the exact check that confirmed the claim. Or the feature is not provably present, and generation stops and writes nothing, with a message naming what was ambiguous.
The second outcome is the one that makes the first trustworthy. A tool that can refuse is a tool whose yes means something. If every request succeeded, the success would carry no information.
That is the whole posture. Claim little, prove the little mechanically, re-prove it on every change, and when a claim cannot be proven, refuse instead of qualifying it.
If you are choosing infrastructure for something that has to be right, this is the difference to look for: not whether the vendor has an audit, but whether their claims are re-checked every time the code changes. Reach out from the contact page if you want to see the checks on a contract you care about.